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

Bug #1977644 reported by Thomas Schmitt
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
casper (Ubuntu)
Fix Released
Medium
Michael Hudson-Doyle
Jammy
Confirmed
Medium
Unassigned
Kinetic
Fix Released
Medium
Michael Hudson-Doyle

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

Related branches

description: updated
Revision history for this message
Brian Murray (brian-murray) wrote :

I'm pretty sure my HP TouchSmart tm2 (model tm2t-1000) is also affected by this bug.

tags: added: rls-jj-incoming rls-kk-incoming
Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

Brian Murray wrote:
> I'm pretty sure my HP TouchSmart tm2 (model tm2t-1000) is also affected
> by this bug.

Then please verify the remedy. I assume you have an USB stick which
already booted at least once an Ubuntu ISO (with much delay).
In this case do:

  # Take care not to name any of your valuable disks as USB_STICK
  USB_STICK=/dev/sdX
  sudo dd if=/dev/zero bs=1 count=16 of="$USB_STICK" conv=notrunc seek=462

If you have no such USB stick with casper-made persistent partition at
hand, then put an Ubuntu ISO onto some USB stick and apply above remedy
before booting it the first time.
Booting should be swift (relatively), but then the USB stick will need the
remedy once again. (This second dd run is what i want to avoid by this bug
report.)

Have a nice day :)

Thomas

tags: added: fr-2456
Revision history for this message
Brian Murray (brian-murray) wrote :

I tested with a USB stick with an alpha version of Ubuntu 22.04 and it took approximately 10 minutes to boot. After following the dd instructions in comment #2 the system displayed the Ubuntu logo in less than one minute.

Changed in casper (Ubuntu):
milestone: none → ubuntu-22.04.1
Changed in casper (Ubuntu Jammy):
milestone: none → ubuntu-22.04.1
Changed in casper (Ubuntu Kinetic):
milestone: ubuntu-22.04.1 → none
Changed in casper (Ubuntu Jammy):
importance: Undecided → Medium
Changed in casper (Ubuntu Kinetic):
importance: Undecided → Medium
tags: removed: rls-jj-incoming rls-kk-incoming
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I patched the requested change into an ISO at https://people.canonical.com/~mwh/lp1977644.iso, can someone give it a go?

Changed in casper (Ubuntu Kinetic):
assignee: nobody → Michael Hudson-Doyle (mwhudson)
status: New → In Progress
Revision history for this message
Chris Guiver (guiverc) wrote (last edit ):

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 secs

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

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

Revision history for this message
Chris Guiver (guiverc) wrote :

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

Alas NO I missed that... I didn't realize I was supposed to sorry.

(won't do it tonight; and tomorrow my focus is Ubuntu News, but I'll try to re-test)

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in casper (Ubuntu Jammy):
status: New → Confirmed
Revision history for this message
José Marinho (jmarinho) wrote :

Hi.

I tried the ISO with this patch and I can confirm that:

- The boot time without any change is still too long.
- Setting the second partition as bootable BIOS Legacy did the trick and, after that, it boots in less than 2 minutes.
- The subsequent boots was fine too and it preserves changes on partition 2 and partition 4.

Hope that helps.

Have a nice day.

Jose.

Changed in casper (Ubuntu Kinetic):
milestone: none → ubuntu-22.10-beta
Changed in casper (Ubuntu Jammy):
milestone: ubuntu-22.04.1 → ubuntu-22.04.2
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package casper - 1.473

---------------
casper (1.473) kinetic; urgency=medium

  * casper-helper: preserve entries 2-4 in the MBR when creating a new
    partition. (LP: #1977644, #1922342)

 -- Michael Hudson-Doyle <email address hidden> Fri, 05 Aug 2022 17:45:05 +1200

Changed in casper (Ubuntu Kinetic):
status: In Progress → Fix Released
tags: added: foundations-todo
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.