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

[Thomas Schmitt]

Hi,

Michael Hudson-Doyle wrote:
> I'm going to
> subscribe Thomas Schmitt, xorriso upstream, who knows enormously more than
> I do about all this stuff.

Well, firmware can always outsmart any preparation in an ISO.

My personal expertise is restricted to ISO 9660 and ends when firmware found
the bootloader in the ISO image.
When the machine can complain about "grub" then the firmware obviously found
such an entry point and ran some GRUB equipment.

Naive guess:
Can the problem here be related to the switch from ISOLINUX to GRUB for
legacy BIOS booting ?
(Ubuntu 19.04 has ISOLINUX, 20.10 has GRUB in the MBR.)

The fact that it works better after conversion from GPT to MBR partition
table could be explained that GRUB wants some more of its components when
having been booted from a medium with valid GPT. I write "wants", because
it finally is able to boot without it, possibly after a long timeout.

The complained "grub_platform" is documented to be a variable which is
promised to be set by GRUB "normal" mode.
  https://www.gnu.org/software/grub/manual/grub/html_node/grub_005fplatform.html
So i wonder whether the BIOS MBR of GRUB and its subsequent boot stages
do not set grub_platform because they are not in "normal" mode ?

Maybe grub-devel mailing list can give hints about MBR boot code, normal
mode, and the grub_platform variable.

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

Whatever, here is a summary of recent efforts to make all x86 firmwares
recognize one of the offered entry points:

The youngest attempt to get it right for all existing machines was
  https://bbs.archlinux.org/viewtopic.php?id=264096
where in the end a slightly improved variation of the Fedora layout by
Matthew J. Garrett seems to have done the trick. The layout by mjg was
used by Ubuntu up to october 2020 and is still used by Debian and Fedora.

Last year Ubuntu for a short time moved to a neat MBR partition table layout,
but then had to switch to GPT, because some EFIs did not recognize the
MBR-only ISO:
  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148
But that neat GPT did not work for some old HP machines. So a small deviation
from the GPT specs was added in form of an extra MBR partition of type 0x00
which carries the "bootable" flag:
  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308

The archlinux thread above started about an ISO with that layout. But it
was discovered that Lenovo Thinkpad T420 did not work with it in legacy
BIOS mode (CSM). It did well with EFI.
The solution was to go back to mjg layout with the improvement that the
EFI partition ins not inside the ISO 9660 partition any more (i.e. it is
not a data file in the ISO 9660 filesystem).

The result is still not as neat as Ubuntu's current partition layout.
I suspect that nearly 10 years of mjg layout in Fedora, Ubuntu, and Debian
spoiled the firmware programmers who made sure that this weird jackalope
is recognized by their EFI.
To my theory the mistake sneaked in that some firmwares decide that there
is no EFI equipment if there is no GPT (valid or not) whereas some decide
there is no BIOS equipment if there is a valid GPT.
Additionally there is the old mistake of some BIOS-only machines to ignore
the MBR boot code if there is no MBR partition with "bootable" flag.

But as said above: If it can say "grub" then the problem happens after
successful recognition of the boot entry point.

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

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