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

Thu May 27 13:08:36 UTC 2021

Hi,

the Ubuntu system really manipulates the installation stick's partition
table if i choose to try out Ubuntu.

It looks like i was involved as adviser when the addition of MBR
partition 2 was introduced to "casper's persistent partition creation".
See
  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308
beginning at comment #60 up to
  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/comments/63
(Sorry for my dim memory. It's just half a year ago.)

Can we assume that Steve Langasek is already subscribed to this bug report ?
Else we should notify him.

I repeat my opinion that under these circumstances no single ISO can serve
all firmwares.

-------------------------------------------------------------------------
Details:

I tested the result of xorriso-1.5.5 repacking gnome-disks-style, i.e.
with only one MBR partition and no MBR boot flag:

  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x00  0xee            1      5503775
  GPT                :   N  Info
  ...
  GPT lba range      :      64  5503712  5503775
  ...
  GPT partition flags:   1  0x0000000000000005
  GPT start and size :   1  64  5493608

The stick stays that way if i reset the computer when it shows the first
white-on-black GRUB menu. (Stick afterwards inspected by the Debian on
the SSD of that machine.)

If i instead choose "Ubuntu" and the try-out option in the subsequent menu,
i get to the drawing of a stubbly hippo and cannot find any way to start
a shell terminal. (Is it Gnome or is it Ubuntu, which is to blame ?
The user impression for me is abysmal. I was unix-ly socialized in 1985.)
At least i find the logout button to the upper right.

Afterwards, xorriso on Debian reports about the stick

  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x00  0xee            1    245759999
  MBR partition      :   2   0x80  0x00            0            1
  GPT                :   N  Info
  ...
  GPT lba range      :      64  245759936  245759999
  ...
  GPT partition flags:   1  0x0000000000000005
  GPT start and size :   1  64  5493608

The difference affects the MBR partition table, where the protective
partition was expanded to the size of the USB stick (nominally "128 GB").
Further the MBR partition of type 0x00 with boot flag was added.
Also affected is the GPT header block, were the partitionable size was
adapted to the real stick size.
The backup GPT was moved to the end of the stick's block range.

Contrary to my expectation this looks like the work of a partition editor,
which can deal with GPT. On the other hand it - or some other program -
is willing to add MBR partition 2 to a GPT.

At this point i began to remember that Steve Langasek, sudodus, and i
discussed the same effect back last year: The HP machine, which needed
the MBR boot flag, booted the new ISO once because casper's partition
editing then removed MBR partition 2.
Now casper probably does after the partition editor run:

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

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:
  HIrsute live session takes ages to boot on BIOS systems

Status in casper package in Ubuntu:
  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/+source/casper/+bug/1922342/+subscriptions