does not boot on bare metal amd64/i386

Bug #1414251 reported by Alexander Sack
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snappy
Fix Released
High
James Hunt

Bug Description

if you produce generic_amd64 or _i386 image (4G) and dd it to USB key it fails to boot on a laptop/netbook/etc.

Revision history for this message
Alexander Sack (asac) wrote :

This fixes it for me on amd64 and I can log in on console in the end

Would need testing in other configurations like arm etc.

=== modified file 'scripts/ubuntu-core-rootfs'
--- scripts/ubuntu-core-rootfs 2015-01-21 08:29:21 +0000
+++ scripts/ubuntu-core-rootfs 2015-01-24 01:57:08 +0000
@@ -159,6 +159,9 @@
  [ "$quiet" != "y" ] && log_end_msg

  # Make sure the device has been created by udev before we try to mount
+ wait-for-root /dev/disk/by-label/system-a 180
+ wait-for-root /dev/disk/by-label/system-b 180
+ udevadm trigger
  udevadm settle

  # There are 2 root partitions but grub tells us which to boot

Changed in snappy-ubuntu:
assignee: nobody → James Hunt (jamesodhunt)
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Alexander Sack (asac) wrote :

any update when this will land?

Revision history for this message
Alexander Sack (asac) wrote :

note the above patch has hardcoded timeout etc. as I didn't know which direction we want to take in this script. You could pull in the logic from "local" to to parse arguments etc... or maybe it would be even easier to start with that script as a template, but would equate to a rewrite...

Thanks for checking and landing something for short term help on this front. Please ensure we test in kvm and cloud with Ben Howard after the new image is out so we can back out if this causes troubles somewhere

Revision history for this message
James Hunt (jamesodhunt) wrote :

I can confirm that the patch above allows a USB key to boot for me. Note that -- currently -- we shouldn't have to wait for both rootfs's to be available.

However, we are soon to land a change to devel-proposed that does in fact require both rootfs's so I think we could change the logic very slightly to be something like:

wait-for-root LABEL=system-a ${ROOTDELAY:-30}
wait-for-root LABEL=system-b ${ROOTDELAY:-30}

How did you arrive at the 180 timeout? Were lower timeouts not sufficient?

Revision history for this message
James Hunt (jamesodhunt) wrote :

The code in #4 works for me, but maybe pitti can comment on this?

Revision history for this message
Steve Langasek (vorlon) wrote :

> However, we are soon to land a change to devel-proposed that does in fact
> require both rootfs's so I think we could change the logic very slightly to
> be something like:

The boot must absolutely not be dependent on both partitions being available. Even if one partition has been *completely* scrambled, the system should be resilient and still boot.

So we should only wait-for-root on whichever partition is currently active, and let the other partition be mounted via normal post-initramfs methods (that don't slow the boot down).

> How did you arrive at the 180 timeout? Were lower timeouts not sufficient?

Since the timeout is only for when we completely give up on booting (and - in the ubuntu-core world - fall back to booting the alternate partition), longer is better. If the boot takes so long that the user thinks the system is hung and pushes the power button, that counts as a failed boot and should trigger booting the alternate partition anyway. If the user *doesn't* intervene, we prefer to wait as long as the disk actually takes in practice to become available.

Revision history for this message
Alexander Sack (asac) wrote :

yes, steve is correct. the reason i made the patch like this is because i didnt want to reinvent the cmdline parsing logic and be smart... its a proof of concept pach as explained, but should be easy to clean it up.

I guess for the command line parsing we could borrow a bit more from "local" ... but thats just my feeling :).

Revision history for this message
Alexander Sack (asac) wrote :

may i ask what the change that would require boot rootfs'es being availabel is tryuing to do? just curious about the case...

still believe we shouldn't depend on both partitions being clean to boot as steve said.

Revision history for this message
Alexander Sack (asac) wrote :

on the delay i agree with steve too... i saw in local that there is 30 secs for x86 archs and 180 for arm iirc... think minimizing wait time is really the goal here though as steve explained. we should however ensure that if the device doesnt show up that we reboot with fallback attempt? not sure how to best do that in the initramfs code ...

guess our initramfs code should have a common approach to failing hard to trigger fallback

Revision history for this message
James Hunt (jamesodhunt) wrote :

This change is now available in amd64 devel-proposed image r264.

Ben - as per #3, please could you test r264 or newer in the cloud environments to ensure they boot as expected.

James Hunt (jamesodhunt)
Changed in snappy-ubuntu:
status: Confirmed → Fix Committed
James Hunt (jamesodhunt)
Changed in snappy-ubuntu:
status: Fix Committed → Fix Released
Michael Terry (mterry)
affects: snappy-ubuntu → snappy
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.