[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems

Fri May 20 07:28:55 UTC 2022

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 <steve.langasek at ubuntu.com> 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

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

Title:
  Impish live session takes ages to boot on BIOS systems

Status in Release Notes for Ubuntu:
  Fix Committed
Status in casper package in Ubuntu:
  Confirmed
Status in casper source package in Impish:
  Confirmed
Status in casper source package in Kinetic:
  Confirmed

Bug description:
  First of all, I change the description of this bug because, thanks to
  Chris Guiver comments, I could check that the live session effectively
  works but it takes too long to complete. That's why I change the
  description of the bug from live session does not boot to live session
  takes ages to boot. I hope this is the best approach to this.

  I think the problem is the same as described here:
  https://discourse.ubuntubudgie.org/t/20-10-grub-error-can-t-find-
  command-grub-platform/4292. I can see prior to grub menu, briefly, the
  same error: Error can't find grub_platform. After the solution
  described below, this error is not showed and the system is able to
  boot.

  I try making the live usb using startup disk creator and with gnome-
  disks --> Restore disk image and get the same results.

  The live-usb has a gpt partition table instead of mbr like 20.04 live-
  usb has. That implies, I think, that the first one does not boot on
  BIOS systems and the second does.

  I try the same live-usb on an EFI laptop and it boots perfectly
  (perhaps it takes long time, but more less than in this case.

  If I try the solution described here:
  https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1905491/comments/8
  then it works.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: casper 1.461
  ProcVersionSignature: Ubuntu 5.11.0-13.14-generic 5.11.7
  Uname: Linux 5.11.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu61
  Architecture: amd64
  CasperMD5CheckResult: pass
  CasperVersion: 1.461
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Apr  2 09:55:24 2021
  LiveMediaBuild: Ubuntu 21.04 "Hirsute Hippo" - Beta amd64 (20210331.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=gl_ES.UTF-8
   SHELL=/bin/bash
  SourcePackage: casper
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions