Trusty server OEM mode hangs at first boot

Bug #1296883 reported by Jason Gerard DeRose
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Invalid
Critical
Rushikesh Deore

Bug Description

When doing a server install with the latest Trusty daily (2014-03-24) in OEM mode, the boot hangs during the first boot after the install. Please see the attached screenshot.

At the time when it hangs, this is the final output on the console:

* Starting End-user configuration after initial OEM installation (debconf)
* Starting
plymouth stop
* Stopping End-user configuration after initial OEM installation (debconf)
* Stopping System V runlevel compatibility
rc
* Starting
tty1

Not sure if "ubiquity" is the correct source package to file this bug against, and also note that the information collected by Apport in this case is totally irrelevant as I'm filing from a laptop desktop install, not a server. I filed the bug this way only because the "Report a Bug" link on Launchpad currently seems broken as it just redirects to this page:

    https://help.ubuntu.com/community/ReportingBugs

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: debian-installer (not installed)
ProcVersionSignature: Ubuntu 3.13.0-19.40-generic 3.13.6
Uname: Linux 3.13.0-19-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Mar 24 12:17:00 2014
DeviceMapperTables: No devices found
DmraidDevices: no raid disks
DmraidSets: no raid disks
MachineType: System76, Inc. Kudu Professional
MemoryUsage:
 total used free shared buffers cached
 Mem: 16352400 12303640 4048760 462992 174464 8675116
 -/+ buffers/cache: 3454060 12898340
 Swap: 4194300 0 4194300
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-19-generic root=UUID=436ce328-4f8a-4123-a3da-46cf3ea3c1f6 ro quiet splash vt.handoff=7
SourcePackage: ubiquity
UpgradeStatus: Upgraded to trusty on 2014-03-08 (15 days ago)
dmi.bios.date: 01/15/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1.03.03RS76
dmi.board.asset.tag: Tag 12345
dmi.board.name: Kudu Professional
dmi.board.vendor: System76, Inc.
dmi.board.version: kudp1
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: System76, Inc.
dmi.chassis.version: kudp1
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1:
dmi.product.name: Kudu Professional
dmi.product.version: kudp1
dmi.sys.vendor: System76, Inc.

Revision history for this message
Jason Gerard DeRose (jderose) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Revision history for this message
Alberto Salvia Novella (es20490446e) wrote :

It renders the system temporarily or permanently unusable.

Changed in ubiquity (Ubuntu):
importance: Undecided → Critical
Revision history for this message
Jamin W. Collins (jcollins) wrote :

Have you tried swtiching to other virtual terminals? I believe I was experiencing the same issue, only to find that the display was stuck on vt7 for some reason, but there were in fact logins waiting on vts 1-6. Adding "text" to the kernel command line seems to mitigate this issue in my case.

Revision history for this message
Jason Gerard DeRose (jderose) wrote :

@jcollins... interesting, I'll give that a try. Thanks!

I'm installing into a VM (golden image mastering for Sytem76), so vt switching is a bit less obvious there :P

Revision history for this message
Jamin W. Collins (jcollins) wrote :

@jderose

Assuming the VT switch works for you, and assuming that you're not working with a GUI, you'll end up getting bit by another bug:
https://bugs.launchpad.net/ubuntu/+source/oem-config/+bug/1361595

The referenced bug report does have a patch that fixes the issue. Seems that the upstart job was changed to no longer connect STDIN, which is required by oem-config. You'll just need to make sure to add the patch before running oem-config-prepare.

Revision history for this message
Jamin W. Collins (jcollins) wrote :

@jderose

There's another bug you'll get bitten by, along with a workaround:
https://bugs.launchpad.net/ubuntu/+source/oem-config/+bug/1362920

Revision history for this message
Jamin W. Collins (jcollins) wrote :

The attached patch should completely work around this issue.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "switch to vt1 if not running oem-config" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
kamiar (kamiar321)
Changed in ubiquity (Ubuntu):
status: Confirmed → New
Changed in ubiquity (Ubuntu):
status: New → Confirmed
luke (luke+l)
description: updated
Changed in ubiquity (Ubuntu):
assignee: nobody → Rushikesh Deore (rushi0205)
Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

I'm closing this bug because Ubiquity is not the server installer anymore and the d-i based installer for server has been replaced by subiquity.

Changed in ubiquity (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.