[Bug 1977644] Re: Please preserve MBR partition entries 2 to 4 when creating persistent partition

[Chris Guiver]

I just downloaded lp1977644.iso & wrote to thumb-drive (K) and it was booted on
- motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series)

start stopwatch (phone) as I hit ENTER at grub option  (min:secs)

~07:56 black cursor top left disappeared & screen blanked (first change visible on screen & ~audible click from speakers)
08:03 screen redrew & plymouth screen visible
~10:15 wallpaper appears on screen
~10:32 the try/install (maybe-ubiquity) dialog appears & music-chime is played

In comparison; same thumb-drive booted on
- hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
has that whole process done in ~2:24 (~2 mins 21 secs) with the key difference being the first ~7m:56s of the j3400 device done in 1-3 secs

-- 
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/1977644

Title:
  Please preserve MBR partition entries 2 to 4 when creating persistent
  partition

Status in casper package in Ubuntu:
  In Progress
Status in casper source package in Jammy:
  New
Status in casper source package in Kinetic:
  In Progress

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1977644/+subscriptions