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

Mon May 16 14:17:42 UTC 2022

Hi,

Chris Guiver wrote:
> BOOT2:  LIVE
> 00:25 secs & screen blanks & messages
> 00:35 plymouth visible
> 01:11 message(s) again & plymouth gone
> 02:23 system fully-operational

The overall boot time is still very long. But no particular stage stands
out as the big time waster.

>...> motion computing j3400

This one is possibly allowed to be somewhat slow.

> Ubuntu Desktop 22.04 LTS
> 08:01 screen blanked

I really wonder which side, GRUB or vmlinuz, causes this delay.

After wasting time with clueless experiments i re-read what we have and
what i vastly forgot.

----------------------------------------------------------------------
This prompts another test request @ Chris Guiver:

Does it help to remove MBR partition 2 similarly to what i proposed a year
ago to José Marinho and what helped to boot:

  # (When replacing the "X", take care not to zap your system disk)
  STICK=/dev/sdX
  dd if=/dev/zero bs=1 count=16 of="$STICK" conv=notrunc seek=462

Last year this worked only once, because casper added the partition again
during "persistent partition creation". This could be fixed now:
  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/comments/60
If not fixed: A second dd treatment after the first boot was not overridden
by casper in the next Live system run.

----------------------------------------------------------------------
Summary of my re-reading:

José Marinho wrote in
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/comments/35
> With the iso without any change:
> - Plymouth --> 7 minutes
> - Desktop environment --> 7 minutes 50 seconds
> Marking the first partition as bootable legacy BIOS:
> - Plymouth --> 54 seconds.
> - Desktop environment --> 1 minute 45 seconds
> Without marking any partition as bootable but changing the partition table from GPT to MBR:
> - Plymouth --> 25 seconds.
> - Desktop environment --> 1 minute 20 seconds.

So we had already a good suspect for a delay of about 6 minutes.

Then we had the red herring of these lines in grub.cfg which for a while
seemed to be the culprit. I proposed a change in #39. But in #55,
José Marinho finally reported that the intermediate success was rather
due to inadverted partition table changes during the experients.

In #60 i propose to remove partition 2 from the MBR.
(This partition exists to lure in some HP laptops which want to see a
boot flag. This flag is forbidden for the GPT-announcing partition slot.)
José Marinho reports in #61 that this helps for one time booting, but not
for further attempts to boot.
In #70 i demonstrated that the software in the ISO manipulates the MBR
partition table of the stick.
In #73 i point to "casper" and its "persistent partition creation".

Chris Guiver introduced the j3400 tablet to us in #76.

Chris Guiver and Brian Murray let GRUB be verbose in #82 and #83.
It prints:
> "Booting a command list"
Screenshots are at #84 and #85.

Since the messages do not look to me like from a Linux kernel, it appears
that the delay is in GRUB.
We could ask at grub-devel for help. But it happens only to a few (old ?)
machines and it is about the boot flag, which at least Vladimir Serbinko 
rejected firmly when the HP laptops showed up which don't boot without it.

So the conclusion of "tlk (sarcasticskull)" in #91 is noteworthy:
> kinda frustrating that the fixes/kludges for both "advanced" EFI and
> legacy crap "proprietary" systems suddenly make booting an Ubuntu LTS
> live ISO impossible

I thought i had read the proposal to have two flavors of Live ISOs
but cannot find currently it in this giant bug report.
So without the claim to have invented it myself:
Have an EFI+BIOS flavor without the problematic boot flag in the MBR,
and an Odd-Old-BIOS flavor without GPT and with boot flag.

Most machines, including those which are affected by this bug would boot
by the EFI+BIOS ISOs. Only a few would need Odd-Old-BIOS.

-------------------------------------------------------------------------
A peek over the fence:

Fedora considers to adopt for its ISOs the GPT partition layout without
boot flag in MBR:
  https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2G3DQ5SGCV5DSD7NPVXU3KAKQ57BOXVU/
They found a Dell XPS 15 L502X laptop which does not boot from this
but also does not boot if a boot flag MBR partition is added.
Nevertheless it looks like Fedora is willing to leave it behind together
with the HP laptops which want the boot flag.

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