[Bug 1899308] Re: failure to boot groovy daily (again)
Thomas Schmitt
1899308 at bugs.launchpad.net
Thu Oct 15 17:31:08 UTC 2020
Hi,
Steve Langasek (vorlon) wrote:
> I've manually run through the steps of casper's persistent partition
> creation [...]
> it also "fixes" the protective MBR, removing the empty bootable partition.
That explains why the machines which demand the boot flag boot exactly
once.
sudodus (nio-wiklund) wrote :
> p-ed-commands.txt
In the cases 4, 7, 11, 12, and 14 the bootable but nearly non-existing
partition has vanished, because its MBR slot became all 0.
This matches what Steve found out.
-----------------------------------------------------------------------
> https://code.launchpad.net/~ubuntu-
installer/casper/+git/casper/+merge/392318
> sfdisk --no-reread -q $DEVICE -A 1 -X dos || true
If this attributes the boot flag to the first partion of type EE, then
this is a semi-violation of EFI specs and known to be punished by some
firmwares. UEFI 2.8 says:
"Table 20. Protective MBR Partition Record protecting the entire disk
BootIndicator 0 1 Set to 0x00 to indicate a non-bootable partition
[...]
Must be ignored by UEFI implementations."
It turned out back in 2015 that some EFIs interpret the latter statement
as instruction to ignore the device if BootIndicator is present in the
only existing partition. That's why --mbr-force-bootable was invented to
mark a nearly non-existent partition as bootable.
The changelog description is wrong in these aspects:
> "If our partition table is GPT, we *may* have a protective MBR;"
We *must* have a protective MBR to have a valid GPT.
> "we mark the iso9660 partition as bootable"
The ISO 9660 partition is number 1 in the GPT. Partition 1 in MBR is not
mountable as ISO 9660 because it starts at LBA 1. 0 or 64 would be ok for
mounting, but then it would not mark a valid GPT any more.
-----------------------------------------------------------------------
Casper needs to bring these bytes (decimal) into bytes 462 to 477 of
the ISO image (i.e. the MBR):
128 0 1 0 0 0 1 0 0 0 0 0 1 0 0 0
With bash i could do this by help of dd if=/dev/zero and echo -n $'\x80'
$'\x01'. But with dash ...
Would a temporary 16-byte binary file by acceptable for Casper ?
Extract it before manipulation of the original GPT of the ISO:
dd if="$DEVICE" bs=1 skip=462 count=16 of=/tmp/boot_flag_bytes_$$
and instead of the sfdisk -A 1 -X dos, insert the extracted file:
dd if=/tmp/boot_flag_bytes_$$ conv=notrunc bs=1 seek=462 of="$DEVICE"
-----------------------------------------------------------------------
Have a nice day :)
Thomas
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to casper in Ubuntu.
https://bugs.launchpad.net/bugs/1899308
Title:
failure to boot groovy daily (again)
Status in Ubuntu CD Images:
Fix Released
Status in casper package in Ubuntu:
Triaged
Status in cd-boot-images-amd64 package in Ubuntu:
Confirmed
Bug description:
This is either a duplicate or return of
- https://bugs.launchpad.net/ubuntu-cdimage/+bug/1883040
- https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148
Most probably "groovy daily won't boot anymore on some older BIOS
boxes" or the 1883040 bug, as it's impacting only my older slow boxes
(but it's also different).
thumb-drive has been successfully used in QA live & install tests,
however it won't boot on
hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915)
The last timing issue also impacted d755-5 (older dell optiplex 755)
when dc7700 was impacted, but that booted successfully this ISO.
I see thumb-drive flash as it tries to boot, eventually it stops
flashing, but no boot. At least 6 attempts made to boot, thumb-drive
being tested on another 2x d755 boxes..
(ISO written by mkusb/dus & gnome-disks [#11] is identical)
** Expected result
It boots & is usable
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/+subscriptions
More information about the foundations-bugs
mailing list