Comment 115 for bug 1922342

Hi,

Chris Guiver wrote:
> On j3400; pressed ENTER (at grub) at 13:10 (room clock).. I didn't note
> time of plymouth but I had maybe-ubiquity @ 13:13 (room clock) for
> altered version of 2022-04-19 ISO
> [...]
> so I'll now boot twice
> [...]
> alas should have noted clock.. it 'feels' slow... nah it's slow :(
> [...]
> another boot on j3400, hit ENTER (at grub) at 13:31, maybe-ubiquity jingle
> waking me from sleep at 13:41
> [...]
> MBR partition : 2 0x80 0x00 0 1

Looks like casper is still re-installing MBR partition 2 on the first
run of the Live system, although it was not there before this run.

If you now apply the remedy to the stick
  dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462
then i expect it to be permanently booting in reasonable time.
(Not because it was applied to the stick, but because casper will not
manipulate the partition table any more.)

Please confirm.

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

I had hoped that capser would save the partition entry and re-install it after
the creation of the persistent overwrote the MBR partition table. But it
seems to just write a pre-recorded partition entry with the boot flag.

So we'd need a change in casper if the description of the workaround
shall be reasonably safe.
I don't consider dd of=/dev/sdb safe considered that the Ubuntu tutorial
advises to use Balena Etcher for the copy-to-USB-stick step.

Casper would have to save before the additon of the persisten partition
at least 16 bytes beginning at offset 462, or 48 bytes to cover all three
unused MBR partitions. After creation of the partition the saved bytes
would be written back to the MBR of the USB stick.

In
  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/comments/66
i read:

   casper (1.455) groovy; urgency=medium
     [...]
     * Limit our dd to only change 16 bytes in the MBR regardless of input,
     [...]
   -- Steve Langasek <email address hidden> Fri, 16 Oct 2020 09:51:20 -0700

But this is not what Chris Guiver observes.

In
  https://git.launchpad.net/ubuntu/+source/casper/commit/?id=5c3637a224e7eca4c8998d72ac1711cd8b58b335
i see unconditional insertion of the boot flag partition:

  + 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

The current state in
  https://git.launchpad.net/ubuntu/+source/casper/tree/scripts/casper-helpers
still has this gesture:

  find_or_create_persistent_partition () {
      [...]
      echo "start=$start" | sfdisk --no-reread -q $DEVICE -a || return
      [...]
      if sfdisk -d $DEVICE | grep -q 'label: gpt'; then
          [...]
          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
      fi
      [...]

I would propose to do something like:

 + MBR_STASH=/tmp/mbr_stash_$$
 + dd if="$DEVICE" bs=1 skip=462 count=48 of="$MBR_STASH"
      echo "start=$start" | sfdisk --no-reread -q $DEVICE -a || return
      [...]
 - 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
 + dd if="$MBR_STASH" bs=1 seek=462 conv=notrunc count=48
      fi
 + rm "$MBR_STASH"

@Steve Langasek: Are you watching ? Do we need to open a new bug ?

Have a nice day :)

Thomas