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

Tue May 17 10:38:22 UTC 2022

Hi,

Chris Guiver wrote:
> I performed the command
> `sudo dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462`
> to Ubuntu Desktop 22.04 LTS thumb-drive (K)
> Booted on j3400
> BOOT1: 
> it was fully-operational at 2 min 45 secs

So it looks like the dd run brought about the best boot-up speed we can
expect from this hardware. (Please contradict me if i'm wrong.)

> system just rebooted  (alt-sysreq+reisub)
> 03:11  system fully-operational

So casper did not re-install the dummy partition 2 when creating a persistent
partition.

Well, did it create a new partition at all ?
What do you get from

  xorriso -indev /dev/sdb -report_system_area plain

Expectation:
The report about the MBR partition table should list only one partition

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

with possibly the Blocks number adjusted to the size of your USB stick.
(The original ISO would show a MBR partition 2
  MBR partition      :   2   0x80  0x00            0            1
which obviously makes the trouble with j3400.)

The GPT part of the report would list a fourth GPT partition, if casper
created one.

> BUT FAILED TO BOOT on
> - hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)

This is obviously one of the machines which demand a boot flag in MBR.

Does it boot after you (rawly and naughtily) set the boot flag to MBR
partition 1:

  echo $'\x80' | dd of=/dev/sdX bs=1 count=1 conv=notrunc seek=446

(If Ubuntu decides to leave these machines behind, this run could be the
remedy for hp dc7700 and others. It is simpler than a dd run which installs
partition 2. On the other hand it is clearly violating the specs.)

What does the j3400 do with this state of the USB stick ?

(If it boots slowly:
Above dd run can be revoked by "cat /dev/zero" instead of "echo $'\x80'".)

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

It looks like a fundamental decision by Ubuntu is needed:

Since GPT specs forbid the boot flag with the MBR partition of type 0xee
and since some EFI implementations indeed take offense if it is there,
the MBR partition with its boot flag was the best compromise ... until
j3400 and José Marinho's machine of which i could not find a model name.

But now seems that Ubuntu needs to decide with its ISOs whether to leave
behind either j3400 or hp dc7700.
A good reason for keeping j3400 bootable is that this partition layout is
fully specs compliant and tasty to all EFI implementations (... so far).

The only partition layout for hp dc7700 which complies to UEFI and its GPT
specs would be a MBR partition table marking the EFI partition by type 0xEF
and no GPT.
But although this is covered by the specs, there are EFI implementations
known which don't boot from a device without GPT.

(Really annoying to me is the fact that the old ISOLINUX/GRUB jackalope works
for all machines with its MBR partition table and a dead GPT strapped on its
back. Somehow i hope for a widely used EFI which hates it and forces it
out of the world.)

I guess that it is not an option to provide full ISO sets for both, the
mainstream and some old exotic firmwares. I hope that the old jackalope is
not an option either.

So we should find easy-to-apply remedies for those old machines which need
to be left behind. To do so, we need to know which group of them will be
abandoned by the unmodified ISOs.

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

Status in Release Notes for Ubuntu:
  Fix Committed
Status in casper package in Ubuntu:
  Confirmed
Status in casper source package in Impish:
  Confirmed
Status in casper source package in Kinetic:
  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-release-notes/+bug/1922342/+subscriptions