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

Wed May 18 09:58:33 UTC 2022

Hi,

Chris Guiver wrote:
> libburn : SORRY : Failed to open device (a pseudo-drive) : Permission denied

Oops. No read permission for normal users on USB sticks.
(I should really operate my workstation with a more conventional setup
so that i better anticipate other's adventures.)

> My thumb-drive K does not boot on
> - hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
> - hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915)
> as it stands now.

Obviously the addicted HPs don't see a boot flag.

>  echo $'\x80' | dd of=/dev/sdb bs=1 count=1 conv=notrunc seek=446
> it NOW BOOTS ON
> - hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
> - hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915)

Another confirmation that the flag was not set before.

The only small chance for a red herring would be a prolonged history of
experiments with the ISO on the stick, which would have caused casper to
not do what it normally does. We had that in the #50s comments.

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

So if we want to propose a workaround for the current layout, it would
be a good base if you could confirm that j3400 boots after the plain
procedure with no other experiments inbetween:

  # Patch the ISO already as image on hard disk
  ISO=ubuntu-22.04-desktop-amd64.iso
  dd if=/dev/zero bs=1 count=16 of="$ISO" conv=notrunc seek=462

  # Put it onto the USB stick as you usually do. E.g.
  sudo dd bs=4M oflag=sync status=progress of=/dev/sdb if="$ISO"

Then you would check if it boots twice on the j3400. If the second boot
succeeds and shows a writable big partition as last one, then we could be
sure that this procedure is a valid workaround.

A run of

  sudo xorriso -indev stdio:/dev/sdb -report_system_area plain

would (hopefully) confirm that there is no second MBR partition with boot
flag.

Of course it would be enough if you can confirm that you did this already
during the experiments, with no intermediate manipulations.
But given the curvy way of this bug report, we need to be sure.

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

Assumed that

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

is really a reliable way to make the Ubuntu ISOs boot on the few old
BIOS machines, which slow down GRUB when encountering the combination of
GPT and MBR dummy partition, we would need a way to inform the downloaders
of Ubuntu ISOs about this trick.

To whom would we have to talk to get this proposal onto sites like
  https://ubuntu.com/tutorials/install-ubuntu-desktop
which gets pointed to by a link on
  https://ubuntu.com/download/desktop

I think it should be mentioned in
  https://ubuntu.com/tutorials/install-ubuntu-desktop#4-boot-from-usb-flash-drive
like
  "On some very old and meanwhile rare machines it can last 8 minutes or
   longer until you see this welcome screen.
   If you plan just a single installation then simply wait until the screen
   appears.
   But if you plan to repeatedly use the "Try Ubuntu" offer on such an old
   machine, then see [link to new page tutorials/remove-boot-flag-from-iso]
   for a way to substantially shorten this time span."

The new page would briefly explain the problem and propose the manipulation
before putting the ISO onto the USB stick.
It would warn not to do this unless a first boot attempt really lasted
unreasonably long.

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