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

[Thomas Schmitt]

Hi,

José Marinho wrote:
>  changes only work at first boot [...]
> This happened today with the new version of xorriso and yesterday with
> "dd if=/dev/zero bs=1 count=16 of="$NEW" conv=notrunc seek=462" command.
> [...]
> the output of two xorriso commands BEFORE trying to boot from
> the stick, just after dd the iso file on it.
> https://launchpadlibrarian.net/540588248/boot1.txt

So xorriso is now able to at ISO production time do what gnome disks did
for Lucap to make the stick bootable.

The fact that "dd ... seek=462" did the trick too, indicates that the
problem is associated with the MBR partition 2.

(So probably the command
  -boot_image any mbr_force_bootable=off
after
  -boot_image any replay
would be sufficient, whereas
  -boot_image any gpt_iso_bootable=on
  -boot_image any gpt_iso_not_ro=on
were not really needed with the xorriso-1.5.5 run.
If you are curious, you could check this. Just to be sure.)

> The second one (boot2.txt)
> [https://launchpadlibrarian.net/540588529/boot2.txt]
> is the same but AFTER the first successful boot.

Surprisingly the MBR dummy partition is back again.
(The "GPT partition flags:" of GPT partition are the same as in boot1.txt,
 namely 0x0...5, which indicates that not the "$ORIG" ISO sneaked in with
 flags value its 0x1...1.)

What does happen if you zeroize it again ?

  dd if=/dev/zero bs=1 count=16 of=/dev/sdd conv=notrunc seek=462

Does it boot and then that partition gets installed again ?

Does the stick stay bootable (i.e. without MBR partition 2) if you
end the boot attempt at the first GRUB menu which shows up ?

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

I have no idea how the MBR partition slot 2 gets back onto the stick.
There is no backup of it which could be restored by any partition
editor.

Somehow the bootloader or the booted system install that partition.
This partition is not an official GRUB feature, although it was originally
invented as workaround of a boot problem with grub-mkrescue ISOs on
old HP laptops. (One has to add xorrisofs option --mbr-force-bootable
to the grub-mkrescue run in order to get that second partition.)

Ubuntu intentionally brings the second MBR partition into the ISO.
But i wonder which stage of a booting Ubuntu system copies the original
MBR partition table over the table of the stick from where it booted.

I am doubtful that a modern partition editor would be willing to create
such an MBR partition on a device with proper "protective" MBR partition
table and thus with valid GPT.
So when it happens, it seems to be some raw binary operation, similar to
our dd run which removes the partition.

I will try to reproduce this strange behavior, but would still be clueless
how to identify the particular culprit in the booting system.
Any idea is welcome.

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

Whatever exactly is happening here, the findings already indicate that
there will be no Ubuntu ISO possible which fits all firmwares.
(Without the problematic MBR partiton 2 there cannot be an MBR boot flag
and without that flag, some old HP firmwares don't boot.)

A possible solution would be a standard Ubuntu ISO without MBR partition 2
and thus a neat GPT. It has to refrain from re-installing that dummy
partition, of course.

For the old HPs there would be a BIOS-only ISO with no GPT and no EFI
partition. (This would also address the old Macs, which Debian's "mac"
netinst ISO addresses.)

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