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

[Thomas Schmitt]

Hi,

as far as i can tell, the change in lp1977644.iso does what i asked for in
this bug report.

---------------------------------------------------------------

Chris Guiver wrote:
> 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)
> [...]
> ~10:32 the try/install (maybe-ubiquity) dialog appears & music-chime is
> played

Did you patch lp1977644.iso (as discussed in bug 1922342) by

  ISO=lp1977644.iso
  dd if=/dev/zero bs=1 count=16 of="$ISO" conv=notrunc seek=462

before you put it on the USB stick ?

The question is not whether unchanged lp1977644.iso boots fast, but
whether the USB stick with dd-patched lp1977644.iso stays in the fast
booting state after the first time it was booted and got its 4th
partition created by casper.

---------------------------------------------------------------

I tried this now with a 2-years-old ASUS PRO WS C246-ACE board.
(It does not show the long delays. Booting from a 30 MB/s USB stick is
not really fast. But after about a minute i see a pink facetted
jellyfish and some icons. Debian 11 from SSD reaches its login screen
much faster and then fvwm is up in a second. :))

The MBR partition entry 2 which causes the j3400 to boot so slowly, did
not re-appear after the first Ubuntu session in "Try" mode.

As proof that casper did its work, i see a new GPT partition 4 on the USB
stick which marks the remaining space on the stick, which is not occupied
by the ISO and its three original partitions.
The hex dump of the first 512 bytes of the USB stick shows in bytes 448 to
463 the Protective MBR partition 1 which announces the presence of GPT.
The offending entry of partition 2 is still all zero, as caused by the
dd run on the ISO image file.
(In original lp1977644.iso i see the boot flag of partition 2 as 0x80 in
byte 464 (= 0x1D0) and some bytes of value 0x01 which tell that the
partition has only one block.)

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