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

Mon May 24 08:58:20 UTC 2021

Hi,

José Marinho wrote:
> 4- [...] I assume that the usb drive shoud have an original ubuntu
> 21.04 ISO burned.

The "$STICK" in the setting of Lucap at comment #44 was additionally
treaded with gnome disks: "edit partition and tick the box that says
Legacy BIOS bootable".
This yielded GPT flags 0x0...05.

> 8- Verify that these 8 bytes into $NEW are now like in "$STICK".
> GPT partition flags:   1  0x1000000000000001  --> But you said it must be
> GPT partition flags: 1 0x0000000000000005

0x10...01 is the original setting of Ubuntu ISOs.

> Did I something wrong or that is OK but this solution will not work?

Your dd transplantation did not change the flags of GPT partition 1,
because the "$STICK" did not get the gnome disks treatment before
the flags bytes were copied out of it.

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

> Oh wait! I'm just to see this:
> echo $'\005' | dd bs=1 count=1 conv=notrunc seek=1072 of="$NEW"
> [yields]
> GPT partition flags:   1  0x1000000000000005

Now you are back on the proposed test track.

> It does not work.
> I mount the resulting ISO ($NEW) as a loop device and inspect the
> partition layout with fdisk.

(fdisk does not need mounting. Actually the device should not be mounted
if you change partitions, in order not to confuse the system drivers.
Whatever if loop34 is connected to "$NEW" then the result should be the
ame as with fdisk examining the plain file "$NEW".)

But fdisk is picky with the GPT checksum, which we spoil by inserting the
new flags value. Mine reports
  The primary GPT table is corrupt, but the backup appears OK,
  so that will be used.
and my very restricted spanish skills tell me that yours raises protest,
too:
> La tabla GPT primaria está dañada, pero la de respaldo parece que está
> bien, así que esa será la que se utilice.

All firmwares which i know do not react on checksum mismatches.
But well, we are in unchartered territory.

So fdisk shows you the unchanged content of the GPT backup at the end of
the ISO image:

> Tipo de etiqueta de disco: gpt
> [...]
> /dev/loop34p1       64 5494643  5494580   2,6G Datos básicos de Microsoft
> /dev/loop34p2  5494644 5504683    10040   4,9M Sistema EFI
> /dev/loop34p3  5504684 5505283      600   300K Datos básicos de Microsoft

This looks like what i expect after echo | dd to the original ISO.

> But the layout is different from the usb stick burned with that ISO file
> jose at jose-pc:~/Impish_tests$ sudo fdisk /dev/sdd
> [...]
> Tipo de etiqueta de disco: dos
> [...]
> /dev/sdd1                 1 7907327  7907327   3,8G ee GPT
> /dev/sdd2   *             0       0        1   512B  0 Vacía

But this cannot be the original ISO treated by the echo | dd pipeline.
The size of /dev/sdd1 already reflects the size of the stick, which the
original ISO cannot have known in advance. So some software must have
manipulated the table before or after copying to the stick.

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

Please check again by

  xorriso -indev stdio:"$NEW" -report_system_area plain

that "$NEW" still contains
  ...
  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x00  0xee            1      5505347
  MBR partition      :   2   0x80  0x00            0            1
  ...
  GPT partition flags:   1  0x1000000000000005
  GPT start and size :   1  64  5494580
  ...
  GPT start and size :   2  5494644  10040
  ...
  GPT start and size :   3  5504684  600
  ...

Then, without letting partition editors or other smart programs interfere,
use dd to put "$NEW" onto /dev/sdc.
If you want to check the tables on stick, use instead of fdisk:

  xorriso -indev stdio:/dev/sdc -report_system_area plain

Then try booting.

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

It might be that the firmware ignores the main GPT because of the checksum
mismatch and rather uses the backup GPT. In that case our experimental
flags setting would not get into effect.

So if the boot problem persists, the next try is to change the flags of
partition 1 in the backup GPT, too:

  echo $'\005' | dd bs=1 count=1 conv=notrunc seek=2818705968 of="$NEW"

(The number computation for this is somewhat complicated:
  GPT entry array    :      2  248  separated
  GPT lba range      :      64  5505284  5505347
tell that the backup header block is 5505347 (512 bytes per block) and that
there are 248 partition slots (of 128 bytes each). I.e. they occupy 62
blocks. So the backup partition slot number 1 is at block 5505347 - 62 =
block 5505285 = byte offset 2818705920.
The flags begin 48 bytes after the slot start = byte offset 2818705968.)

After this echo | dd, the backup GPT has the desired flags value.
Its checksum is now as broken as with the main GPT.
(My fdisk does not complain or announce the use of the backup GPT any more.)

Put this "$NEW" onto USB stick and try booting.

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

Given the GPT checksum woes, it might be necessary that i develop a GNU
xorriso tarball which creates the ISO with flags bit 2 at GPT partiton 1
and computes the correct GPT checksums.

I will now begin to explore where libisofs sets the flags value and how
i could control the "Legacy BIOS bootable" flag bit 2 from xorriso.
(You'd then download xorriso-1.5.5.tar.gz and replay "$ORIG" to "$NEW".)

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