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

Tue May 25 08:17:38 UTC 2021

Hi,

José Marinho wrote:
> GPT PMBR size mismatch (5505347 != 7907327) will be corrected by write.
> ...
> /dev/sdd1                 1 7907327  7907327   3,8G ee GPT
> /dev/sdd2   *             0       0        1   512B  0 Vacía

Looks like fdisk reports to you what would be the result if you let it
write what it thinks would be correct.

> another strange fact is this:
> Tipo de etiqueta de disco: dos (Disk label type: dos).

(It would help if you do
   export LANG=C
before running fdisk, in the hope that it will then talk english.
Revoke this later by
   unset LANG
)

Probably fdisk does not accept the partition table as GPT because of the
second MBR partition of type 0x00 which carries the boot flag.

> Disco /home/jose/Impish_tests/ubuntu-21.04-test.iso: 2,64 GiB, 2818738176
> Tipo de etiqueta de disco: gpt

For some reason it believes in GPT as long as the ISO image is not on the
stick. Not very consistent.

We should not give fdisk too much attention here. It has its own ideas
which it does not communicate transparently.

> the first ISO burned on the stick disklabel is dos but the first partition
> is type GPT.

It is of MBR partition type 0xee which the EFI specs call "GPT Protective".
(EFI is where GPT is specified.)
This partition is supposed to cover the whole block range of the storage
device. It is also supposed to be the only MBR partition to indicate the
presence of a valid GPT.

The latter expectation is not fulfilled by the Ubuntu ISO because of the
boot flag and non-zero bytes in MBR partition slot 2.
But the EFI specs also say:
  A [MBR] Partition Record that contains an OSType value of zero or a
  SizeInLBA value of zero may be ignored.
The MBR partition 2 of the Ubuntu ISO has OSType zero (0x00). So EFI
firmwares normally ignore it and accept the MBR as "protective" indicating
the presence of a valid GPT.

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

So the manipulations about setting the "Legacy BIOS bootable" flag in the
GPT EFI partition did not help.

(We can revisit this attempt when xorriso-1.5.5 can set this flag while
producing a GPT with correct checksums. I began to implement this
yesterday but will also have to offer the opportunity to suppress the
"read-only" flag, which gnome disks did not set.)

For now our experiments exhausted the first alternatives of
  https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/comments/45

This leaves us with the last alternative:
  "If the transplated flags field does not fix the problem, then it must be
   about the MBR partition 2 with its boot flag.
   In this case it would not be possible to create an ISO that pleases all.
   So if "$NEW" does not boot swiftly after the first transplantation, try
   whether it helps to overwrite MBR partition slot 2 by zeros"

So try this now:

  cp "$ORIG" "$NEW"
  dd if=/dev/zero bs=1 count=16 of="$NEW" conv=notrunc seek=462

Afterwards

  xorriso -indev "$NEW" -report_system_area plain

should then report only a single MBR partition

  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x00  0xee            1      5505347

Now the "protective MBR" is flawless (but also some old BIOS machines
will not boot this from USB stick, because of no MBR boot flag).

Copy "$NEW" onto USB stick and see whether it boots better.
At least fdisk should be less confused. :))

This does still not do exactly what gnome disks did to yield success for
Lucap. For a better approximation to that state, we will need the new
xorriso-1.5.5 which will be able to achieve the same.

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