Public bug reported: Hi,
i propose to let function find_or_create_persistent_partition in scripts/casper-helpers preserve the MBR partition entries 2 to 4 when it applies sfdisk to create the persistent partition. Currently it writes an MBR partition entry 2 with start LBA 0, size 1, and boot flag if it detects GPT after the persistent partition was created. (sfdisk had overwritten it by zeros but normally the ISO shall have it.) My idea for casper-helpers is to record the three entries in a file: MBR_STASH=/tmp/mbr_stash_$$ dd if="$DEVICE" bs=1 skip=462 count=48 of="$MBR_STASH" and to restore them after creation of the new partition dd if="$MBR_STASH" bs=1 seek=462 conv=notrunc count=48 of="$DEVICE" instead of writing a newly composed entry 2, as is done now: echo $escape_arg -n '\0200\00\01\00\00\00\01\00\00\00\00\00\01\00\00\00' \ | dd of=$DEVICE bs=1 seek=462 conv=notrunc count=16 ----------------------------------------------------------------------- Reasoning: In the course of https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342 we found out that some rare old machines need 10 minutes or longer to boot the current Ubuntu ISOs from USB stick. The trigger is the presence of the MBR partition 2 with boot flag. This partition exists for some old but not so rare machines. It is a mild violation of UEFI/GPT specs which don't offer a clear way to equip a GPT partitioned device with an MBR boot flag. If MBR partition entry 2 of the ISO image is overwritten by zero bytes before the image is put onto the USB stick, then it boots substantially faster. E.g. 3 minutes rather than 10 minutes. But casper re-installs MBR partition 2 when starting the first Live session. So after one swift boot, the problem is back and the USB stick needs the removal of MBR partition 2 again. This time the remedy is permanent. But it has to be applied to the USB stick with superuser authority. Given that the Ubuntu tutorial proposes to put the ISO image onto the USB stick by Balena Etcher rather than by cp or dd, i deem it not safe to propose a dd run as superuser. I make this change proposal so that it is possible to apply the remedy as normal user to the ISO image file rather than as superuser to the stick. ----------------------------------------------------------------------- Additional details: Affected are: - a tablet computer "motion computing j3400" of Chris Guiver, - a Gigabyte H61M-D2H-USB3 mainboard of José Marinho (see also https://launchpadlibrarian.net/531427797/lshw.txt), - (a Gigabyte GA-970A-DS3, BIOS F7a 01/24/2013 of tlk, of which we have no confirmation that removing MBR partition 2 really helps). The long delay happens after the GRUB boot menu, probably still in GRUB. I lack of ideas how to even find out whether vmlinuz hasn't started yet, not to speak of diagnosing why it only happens with particular firmwares. Bug 1922342 mentions an error message "Error can't find grub_platform" which is related to a few lines grub.cfg. In the end it turned out that disabling these lines silences the message but does not speed up booting. Have a nice day :) Thomas ** Affects: casper (Ubuntu) Importance: Undecided Status: New ** Description changed: Hi, i propose to let function find_or_create_persistent_partition in scripts/casper-helpers preserve the MBR partition entries 2 to 4 when it applies sfdisk to create the persistent partition. Currently it writes an MBR partition entry 2 with start LBA 0, size 1, and boot flag if it detects GPT after the persistent partition was created. (sfdisk had overwritten it by zeros but normally the ISO shall have it.) My idea for casper-helpers is to record the three entries in a file: MBR_STASH=/tmp/mbr_stash_$$ dd if="$DEVICE" bs=1 skip=462 count=48 of="$MBR_STASH" and to restore them after creation of the new partition - dd if="$MBR_STASH" bs=1 seek=462 conv=notrunc count=48 + dd if="$MBR_STASH" bs=1 seek=462 conv=notrunc count=48 of="$DEVICE" instead of writing a newly composed entry 2, as is done now: echo $escape_arg -n '\0200\00\01\00\00\00\01\00\00\00\00\00\01\00\00\00' \ | dd of=$DEVICE bs=1 seek=462 conv=notrunc count=16 ----------------------------------------------------------------------- Reasoning: In the course of https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342 we found out that some rare old machines need 10 minutes or longer to boot the current Ubuntu ISOs from USB stick. The trigger is the presence of the MBR partition 2 with boot flag. This partition exists for some old but not so rare machines. It is a mild violation of UEFI/GPT specs which don't offer a clear way to equip a GPT partitioned device with an MBR boot flag. If MBR partition entry 2 of the ISO image is overwritten by zero bytes before the image is put onto the USB stick, then it boots substantially faster. E.g. 3 minutes rather than 10 minutes. But casper re-installs MBR partition 2 when starting the first Live session. So after one swift boot, the problem is back and the USB stick needs the removal of MBR partition 2 again. This time the remedy is permanent. But it has to be applied to the USB stick with superuser authority. Given that the Ubuntu tutorial proposes to put the ISO image onto the USB stick by Balena Etcher rather than by cp or dd, i deem it not safe to propose a dd run as superuser. I make this change proposal so that it is possible to apply the remedy as normal user to the ISO image file rather than as superuser to the stick. ----------------------------------------------------------------------- Additional details: Affected are: - a tablet computer "motion computing j3400" of Chris Guiver, - a Gigabyte H61M-D2H-USB3 mainboard of José Marinho (see also https://launchpadlibrarian.net/531427797/lshw.txt), - (a Gigabyte GA-970A-DS3, BIOS F7a 01/24/2013 of tlk, of which we have no confirmation that removing MBR partition 2 really helps). The long delay happens after the GRUB boot menu, probably still in GRUB. I lack of ideas how to even find out whether vmlinuz hasn't started yet, not to speak of diagnosing why it only happens with particular firmwares. Bug 1922342 mentions an error message "Error can't find grub_platform" which is related to a few lines grub.cfg. In the end it turned out that disabling these lines silences the message but does not speed up booting. Have a nice day :) Thomas -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1977644 Title: Please preserve MBR partition entries 2 to 4 when creating persistent partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1977644/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
