Impish live session takes ages to boot on BIOS systems

Bug #1922342 reported by José Marinho
58
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Fix Released
Undecided
Unassigned
casper (Ubuntu)
Fix Released
High
Unassigned
Impish
Won't Fix
High
Unassigned
Kinetic
Fix Released
High
Unassigned

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)

Related branches

Revision history for this message
José Marinho (jmarinho) wrote :
Revision history for this message
Chris Guiver (guiverc) wrote :

Thank you for taking the time to report this problem, and help making Ubuntu better.

QUESTION: What OS & release are you writing the thumb-drive with? (ie. details of the GNOME-DISKS and StartUp Disk Creator, as I wonder if it's how you write your ISO to media.

I am writing various ISOs (mainly Lubuntu, but other flavors too and on occasion Ubuntu) to thumb-drive and booting it on various BIOS only devices (hp dc7700, dc7900, dell 745, 755, 780 etc).

I personally use `mkusb` to write my media, but regularly also just use `dd`.., but I'm usually writing media on a hirsute box (hence the request for details on what OS/release you use to write your ISO)

I note your `lshw` shows an "i5-3570" CPU which is more modern than any BIOS only box I use (my boxes are c2d (t6570, u9400, e6600, e6850, e8300..), c2q-q9400 etc) so maybe it's a quirk on your hardware, compared to the older hp, dell, lenovo.. I test with.

Revision history for this message
José Marinho (jmarinho) wrote :

Hi.

The software versions I have installed are:

cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

apt policy gnome-disk-utility
gnome-disk-utility:
  Instalado: 3.36.1-1ubuntu1
  Candidato: 3.36.1-1ubuntu1
  Táboa de versións:
 *** 3.36.1-1ubuntu1 500
        500 http://es.archive.ubuntu.com/ubuntu focal/main amd64 Packages
        100 /var/lib/dpkg/status

 apt policy usb-creator-gtk
usb-creator-gtk:
  Instalado: 0.3.7
  Candidato: 0.3.7
  Táboa de versións:
 *** 0.3.7 500
        500 http://es.archive.ubuntu.com/ubuntu focal/main amd64 Packages
        100 /var/lib/dpkg/status

Furthermore, it can be related to the tool I use for write the ISO to usb, or perhaps like you say, to a quirk on my hardware. But in many years I was using ubuntu and others linux distributions I never or exceptionally had this kind of issues.
The fact is that some changes was introduced in the way that ISO images are created because if I use an Ubuntu 20.04 ISO and write it to a usb drive it defaults to a mbr partition table and now it defaults (using the same tool and doing it in the same manner) to a gpt partition table and that causes the issue on my hardware.
I just want to let you know. It is on your decision if this is right for you and the distribution or not. You (the whole Ubuntu staff not only you personally) are the developer and know better than me if the pros of doing in that way worth it or not against the contras (It have issues on some hardware). I only put this information at your disposal.
I, at least, have a workaround and can make use of it.
Any other information that could be useful for debugging this issue, I send without any problem.

Revision history for this message
Chris Guiver (guiverc) wrote :

To José Marinho (jmarinho)

I'm not a developer, but involved in QA-testing primarily with Lubuntu.

Today's hirsute (Lubuntu) daily was written to media using

`sudo dd bs=4M oflag=sync status=progress of=/dev/sdb if=/de2900/lubuntu_64/hirsute-desktop-amd64.iso`

and it was test booted on a number of BIOS devices (see http://iso.qa.ubuntu.com/qatracker/milestones/419/builds/228949/testcases/1303/results)

The last device (thinkpad sl510; c2d-t6570) was rebooted & using the installed bionic system, the Ubuntu Desktop hirsute daily was written to a thumb-drive using usb-creator-gtk (0.3.2ubuntu16.04.2)

The thinkpad sl510 was then rebooted & the thumb-drive that was just written was successfully booted on sl510 (http://iso.qa.ubuntu.com/qatracker/milestones/419/builds/228934/testcases/1303/results).

I cannot re-create this issue on
- lenovo thinkpad sl510 (c2d-t6570, 2gb ram, i915)
- motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series)
- hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
- dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
- dell [optiplex] 755 (c2d-e8300, 8gb, amd/ati radeon rv610/radeon hd2400 pro/xt)
- dell [optiplex] 780 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

being BIOS c2d/c2q devices (all tested today)

Revision history for this message
José Marinho (jmarinho) wrote :

To Chris

I have to admit that you are right and the system finally boots but it take ages (it takes less time if I change partition table to mbr).

I see that in the last testcase you point that the device is extremely slow and perhaps that is the bug.

I don't know the specs of the device you tested, but my pc is pretty decent and it is not normal that slowness.

And like I said, that wasn't the case on previous Ubuntu versions and that wasn't the case too on other distributions (Fedora, Opensuse, Debian, Devuan, etc)

What is clear is that this bug must be closed and I don't know if it is better to file a new bug or that behavior isn't consider as that

Changed in casper (Ubuntu):
status: New → Invalid
status: Invalid → New
José Marinho (jmarinho)
summary: - HIrsute live session does not work on BIOS systems
+ HIrsute live session takes ages to boot on BIOS systems
description: updated
Revision history for this message
José Marinho (jmarinho) wrote : Re: HIrsute live session takes ages to boot on BIOS systems

Finally, I change the description of the bug for better match the nature of the problem.

description: updated
description: updated
Revision history for this message
José Marinho (jmarinho) wrote :

I was doing some new text and I'm going to put some information about what I have done.

First I create another media with startup disc creator. I think that the tool is not relevant here and I test with dd, gnome-disk and this tool and in all I get the same results.

Once created I booted it, but I edit the grub for removing "quiet splash" parameters. After I hit F10 and continue the boot sequence the computer gets stuck with the following message in the screen:

"Booting a command list"

This last for almost 10 minutes and then begin the normal boot sequence.

I'm going to append two more files to help to debug the issue: the output of dmesg and the output of /var/log/syslog.

Revision history for this message
José Marinho (jmarinho) wrote :
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1922342

tags: added: iso-testing
Revision history for this message
Chris Guiver (guiverc) wrote :

I just rebooted and timed (phone stopwatch) the boot of
- motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series)

using Ubuntu 21.04 desktop daily (see comment #4; http://iso.qa.ubuntu.com/qatracker/milestones/419/builds/228934/testcases/1303/results)

which is the device that @jmarinho noted I referred to as booting "extremely slow"

I started the stopwatch when a GRUB message appeared on screen

** the first sign of plymouth (ubuntu logo) appeared @ 8mins 45secs

** the wallpaper first appeared @ 9 mins 58 secs

** the "Try Ubuntu/Install Ubuntu" question appears at 10 mins 18 secs

I haven't installed hirsute on that box, so I don't know if it's an issue only with the live/casper system, or related to the 5.11 kernel (I've not used that box all that frequently this hirsute cycle, but I do use it on occasion and don't recall it being that slow a ~month ago or at least 5.8 days)

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in casper (Ubuntu):
status: New → Confirmed
Revision history for this message
Ice-Tea (ice-tea) wrote :

If you look at the freshly written image with Gnome disks , 1st ubuntu partition , click the cog wheel and choose edit partition you'll notice that the build team have not enabled the Legacy BIOS bootable option?

If you enable it and click change the drive will now boot , there is still a really long 20 second pause with a black screen and blinking cursor but it eventually swaps over to the Ubuntu boot logo and starts.

Revision history for this message
José Marinho (jmarinho) wrote :

Well, I just test it with the final ISO downloaded from ubuntu.com and the problem persists, but with your workaround it boots more quickly.
Perhaps it's a minor issue but I think that it should be avoided because it gives a bad image to whoever tries Ubuntu for the first time. On a short term support release it's not as important as on a LTS is. Since Ubuntu is often considered a friendly option to test a GNU/Linux-based system, these kinds of details should be avoided as much as possible IMHO.

1 comments hidden view all 128 comments
Revision history for this message
José Marinho (jmarinho) wrote :

As you like.
I don't know if it's necessary to open a new bug for that, but no problem.
I already marked that the bug you opened as it affects me.
It seems that you have to fill the bug against a package. I don't know which. I fill that bug against casper, but I think that is not correct.

Regards

Revision history for this message
Ice-Tea (ice-tea) wrote :

@José Marinho

I've removed the other bug report as i see that you've been trying to get this resolved for ages with no luck so i'm guessing they just don't care so it was pointless starting a new one.

I've given up to be honest as there is some really odd stuff going on with regards to the live image with legacy computers as after i installed hirsute the USB stick was no longer bootable so the Gnome disks work around does not resolve it , i had to go back to Gnome disks and uncheck the legacy bios option and then re-enable it to get the USB stick to boot again?

The latest versions of Ubuntu Live writes install log files to the USB stick so something it's doing is corrupting the stick on legacy computers but no problem on EFI boards.

It's annoying to have to use a different distro on legacy computers if they are no longer going to support them?

Revision history for this message
Chris Guiver (guiverc) wrote :

@lucap

I dispute that 'they' don't care.

Canonical employees are paid to work only a set number of hours a week, and have responsibilities/tasks they need to complete in their hours, so have very limited time to fix extra issues.

This bug was reported once during the hirsute cycle in QA-testing (by http://launchpad.net/~jmarinho).

I would also likely have reported it too, only at the time the bug report was NOT that the system took ages to boot, but instead that "HIrsute live session does not work on BIOS systems" so my QA tests did not fit the then description of this report (it booted).

Two boxes (of the six) I used were specifically chosen as they were troublesome in the groovy cycle as they were slow. The result of lack of reports (in QA-testing) was this was not a high priority bug.

A number of issues with BIOS devices were discovered during recent cycles in QA-testing (esp. groovy if I recall correctly), and I saw a lot of energy spent on resolving those issues (ISOs were spun for me to download & boot on the two (plus one other) boxes I described as troublesome earlier just so more could be learnt). Late in the cycle though there is limited time, thus bugs with low rating being ignored is to be expected.

The time to get issues detected is usually earlier in the cycle (alpha stage), and via the QA testing site (so testing is tracked, appears in weekly reports regularly/repeatedly etc).

80% of my QA-testing is on BIOS only boxes, but I tend to QA-test lighter flavors as GNOME isn't much 'fun' on c2d & like machines

Revision history for this message
José Marinho (jmarinho) wrote :

Well, what they do with this bug report is beyond what you and me can do so it's their decision. I think that the official iso of Ubuntu (at least if we talk about a Long Term Support Release) should't have this problem.
Perhaps as they are preparing a new installer that is intended to be used on next LTS, they don't pay attention to this.
But that's simply my guess. They will do what they consider better for their purposes. You and me too.
I have several options. Firstly, stay on Ubuntu 20.04 and wait if that is solved on 22.04. Secondly, we have at least 2 workarounds to avoid the issue and finally, we always could choose another distro on Debian/Ubuntu family or on a different taste.

Regards

Revision history for this message
Ice-Tea (ice-tea) wrote :

@Chris Guiver

>>>I dispute that 'they' don't care.
>>>thus bugs with low rating being ignored is to be expected.

Bad choice of words , i should have used i guess it's not considered important.

Revision history for this message
Ice-Tea (ice-tea) wrote :

How far into the ‘Impish Indri’ Development should we start reporting that the live image doesn't boot on legacy computers and do we report it here or start a new bug?

Revision history for this message
Ice-Tea (ice-tea) wrote :

https://cdimage.ubuntu.com/daily-live/current/

@José Marinho

Don't know if you have tried the latest 21.10 development build but it's still exactly the same as before as you still have to enable legacy bios in gnome disks to get it to boot and there's still a long freeze before it starts.

Revision history for this message
José Marinho (jmarinho) wrote :

Hi @Lucap

I don't kown either at what time is best for reporting that issue and if it is better continuing here or creating a new bug report.
Perhaps the last option is better because the bug will be reported against next release and this one is reported against Hirsute Hippo and it's no longer under development.
I heard that Ubuntu devs are working on a new installer (https://www.omgubuntu.co.uk/2021/02/ubuntu-is-working-on-a-brand-new-installer) so perhaps is more appropiate to wait some time and see if the new installer is included on next Ubuntu release. If this is the case, try it and, if the bug persists, fill a bug against it.
I did not try any daily-live yet, but I suppose that the problem persists as you said.
So, for what was said above, if no one opposes on next days I'll close this bug report because I think it is useless now and later, if in next release the bug persists, someone could create a new one

Revision history for this message
Chris Guiver (guiverc) wrote :

I'll provide my 2c.

Hirsute (21.04) ISO is already released & development completed. Only security fixes are now being performed on the now stable 21.04 system, which does not include this issue (as this issue relates to the ISO itself, and re-spins are only done for LTS releases, ie. next ISO will likely be 20.04.3 or a respin of focal, then impish/21.10 though that's likely not a complete list)

If this issue matters, I'd test using the impish (21.10) ISO and report on the QA testing site, even filing a new bug (referencing back to this one yes, but start a new bug). Even if the report is marked duplicate of this, it'll increase heat & gain more detail/attention. This issue was reported only once on the QA-tracker for hirsute (http://iso.qa.ubuntu.com/qatracker/reports/bugs/1922342) which indicates it wasn't a very important issue. Yes I may have included myself too, had the bug report been about speed, but it was "not booting" at the time, where my QA-test booted so I didn't link to this.

As for the new installer; the boot process occurs before the installer is started. Yes there is a `maybe-ubiquity` kernel parameter but the system is booted prior to ubiquity running.. so I'd suggest not waiting for the new installer, but test with `impish` now giving developers the most time possible to address if they're able.

If you look at testing done so far in 'impish' you'll note well more than 100 QA-tests have been performed (http://iso.qa.ubuntu.com/qatracker/reports/testers) so it's not too early.

Revision history for this message
Ice-Tea (ice-tea) wrote :

Well i don't hold much confidence if it's not considered important...

I wouldn't be the best person to start a new bug as i don't know what package this is supposed to be put against , how best to articulate it or how best to provide any extra information needed as i'm just a point and click user.

Revision history for this message
Chris Guiver (guiverc) wrote :

This issue still exists in impish.

Refer https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1928939

Current Lubuntu Focal daily vs Impish daily
plymouth: Focal: ~46 sec Impish: 7 mins 20 secs
scan media start: Focal: ~50 sec
scan media pass: Focal: 3 min 08 sec
black screen & mouse-pointer: Focal: 3 min 32 sec Impish: ~8 mins 00 secs
full LXQt running: Focal: 3 min 45 sec Impish: 8 mins 33 secs

If the boot needs to be this slow - some messages on screen are needed !

The much faster FOCAL boot shows the scan start & progress for more than a couple of minutes meaning details are shown on screen, yet on IMPISH it's just black screen, and is taking far longer.

Revision history for this message
José Marinho (jmarinho) wrote :

I have confirmed that the bug still exists in Impish and mark your bug report as it affects me.
@Chris Guiver, as you are more involved in that project and know better than me the quirks of this processes, tell me if I must close this bug report and if it is convenient to do something else on your bug report apart from mark the bug as it affects me.
You suggests to the developers that, if the boot should be slow it could be convenient to insert a message warning that. I think that the fix suggested by @Lucap (to enable the boot flag on the first partition) does not have any side effect and reduce the boot time ostensibly.
Besides that, your filled your bug report with reference to Lubuntu iso. I tested Lubuntu and regular Ubuntu and is the same thing on both. For that reason I submit the Ubuntu test result. If I do something wrong feel free to correct me. The tests results are here: http://iso.qa.ubuntu.com/qatracker/milestones/424/builds/230926/testcases/1303/results

Revision history for this message
Ice-Tea (ice-tea) wrote :

https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/comments/12

Yeah, if you do as post 12 it cuts the black screen boot time of Hirsute and Impish down to about 20 seconds , not tried it with Lubuntu...

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

If this is it do with the partition table / flags then it needs to be fixed in debian-cd. You can see the options passed to xorriso here: https://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/view/head:/tools/boot/impish/boot-amd64

As you can see, it's a bit complicated. The name of the --mbr-force-bootable sounds like it should be adding a partition with a bootable flag...

Revision history for this message
Ice-Tea (ice-tea) wrote :

Yeah it is complicated , when you look at a freshly written USB stick with gnome disks there is a box you can tick that says Legacy BIOS bootable , I'm not sure if gnome disks is doing as described below with the "bios_grub" flag as the link talks about a hardrive so i'm not sure if it would apply to a USB stick?

https://help.ubuntu.com/community/DiskSpace

>BIOS-Boot or EFI partition (required on GPT disks)

>The BIOS-boot partition contains GRUB 2's core. It is necessary if you install Ubuntu on a GPT >disk, and if the firmware (BIOS) is set up in Legacy (not EFI) mode. It must be located at the >start of a GPT disk, and have a "bios_grub" flag.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote : Re: [Bug 1922342] Re: HIrsute live session takes ages to boot on BIOS systems

On Fri, 21 May 2021 at 02:00, Lucap <email address hidden> wrote:

> Yeah it is complicated , when you look at a freshly written USB stick
> with gnome disks there is a box you can tick that says Legacy BIOS
> bootable , I'm not sure if gnome disks is doing as described below with
> the "bios_grub" flag as the link talks about a hardrive so i'm not sure
> if it would apply to a USB stick?
>

That is perhaps setting the bootable flag on the single partition entry in
the "protective" MBR, which is AIUI technically a violation of the GPT
spec. But if it helps here maybe we should hack it anyway. I'm going to
subscribe Thomas Schmitt, xorriso upstream, who knows enormously more than
I do about all this stuff.

Revision history for this message
Ice-Tea (ice-tea) wrote : Re: HIrsute live session takes ages to boot on BIOS systems

Thanks :)

Revision history for this message
Thomas Schmitt (scdbackup) wrote :
Download full text (3.5 KiB)

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...

Read more...

Revision history for this message
Chris Guiver (guiverc) wrote :

I'm 'floored' (WOW) by Thomas Schmitt (scdbackup)'s comment 32.

The long delay still exists in impish (on some devices only).

Ubuntu impish - https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1929029
Lubuntu impish - https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1928939

Delay occurs regardless of ISO being written using mkusb, dd, or gnome-disks..

It would be nice if something could be shown on screen, the fact that the OP of this bug report originally wrote that the issue wasn't that it took ages, but failed to boot - highlights some don't wait long enough...

I wait 30-60mins in QA-testing & just comment the time in the iso.qa.ubu report (when I consider excessive), which is longer than I suspect end-users would expect/accept..

tags: added: impish
Revision history for this message
Thomas Schmitt (scdbackup) wrote :
Download full text (3.9 KiB)

Hi,

Chris Guiver wrote:
> Delay occurs regardless of ISO being written using mkusb, dd, or gnome-
> disks..

Hmm. IIRC mkusb offers to unpack the ISO into a filesystem of the USB stick.
If the problem survives that conversion, then it is far inside the GRUB
equipment.

It should be possible to make experimental changes with the .cfg files of
such an USB stick.
(I can propose xorriso runs which repack an ISO to bear new .cfg content
and the same boot entry points as the original ISO. But directly editing
in a FAT filesystem would be much more straightforward.)

Being curious i looked into ubuntu-20.10-desktop-amd64.iso for occurences
of grub_platform and found in /boot/grub/grub.cfg

    grub_platform
    if [ "$grub_platform" = "efi" ]; then
    menuentry 'Boot from next volume' {
            exit
    }

It could be that the complaint of GRUB is about the command grub_platform,
not about the use of $grub_platform.

I fail to find the implementation of the command in a freshly pulled GRUB git.
(Other known commands have a call to grub_register_command() with their
name as argument. grub_platform has not.)

A first experiment would be to remove above snippet from grub.cfg and
to check whether its presence caused the long delay.

--------------------------------------------------------------------------
Red herring warning:

The documentation about "normal" mode and grub_platform might be not helpful
for understanding our special problem. Possibly its text describes not the
work of the command but only the situation when it is _not_ needed.

Maybe GRUB is not running in "normal" mode, or maybe grub_platform updates the
variable, which is set at initialization time in grub-core/normal/main.c
from macro GRUB_PLATFORM:

    GRUB_MOD_INIT(normal)
    {
      ...
      grub_env_set ("grub_platform", GRUB_PLATFORM);
      ...

That macro seems to be set by the compile time configuration of GRUB in
./configure which is supposed to stem from configure.ac

    GRUB_PLATFORM="${platform}"
    ...
    AC_SUBST(GRUB_PLATFORM)

The variable platform is set in the same file, either from option
--with-platform or from automatic detection

    # Guess the platform if not specified.
    if test "x$with_platform" = x; then
      case "$target_cpu"-"$target_vendor" in
        ...
        x86_64-apple) platform=efi ;;
        x86_64-*) platform=pc ;;
        ...

So i'd assume that if /boot/grub/grub.cfg expects the possibility to see
"efi", then GRUB would have to be compiled with --with-platform=efi .
Meanwhile the GRUB in Ubuntu ISOs serves both, EFI and legacy BIOS.
I wonder how this is supposed to play with the compile time setting.

There is a compile time variable GRUB_PLATFORMS:
  https://wiki.gentoo.org/wiki/GRUB2_Quick_Start#Installing_GRUB2_software
  "To install GRUB2, first set the GRUB_PLATFORMS variable with one or more
   appropriate values in the system's make.conf. If unset, GRUB2 will guess
   which platform to use on the system. It guesses pc (which is the MBR
   style of installation) for x86/amd64 architectures."
But the relation of the single value GRUB_PLATFORM and the value list in
GRUB_PLATFORMS is not clear to me.

The GRUB manual talks ...

Read more...

Revision history for this message
José Marinho (jmarinho) wrote :

Well, I'm only came here again firstly to say thanks to Michael and Thomas for taking into account this problem. Specially, knowing that this bug probably is quite exceptional and affects at only few cases. Today I was trying on some old computers on my job and it booted fairly well on all of this so, I had bad luck with this issue.
Secondly, I don't know what is the best approach for fixing this problem. If it would be easy to insert a message when the boot process gets stuck or what. I think it is normal that, if the USB does not reach the desktop environment after more than 5 or 6 minutes and if you listen the cpu fan working at full speed, it is normal to think that the usb it's not going to boot.
I was timing how long it takes to reach plymouth and the full desktop environment with a Lubuntu daily build iso and this was the results (the start point was grub in all cases):
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.
With this results is clear that the last is the best so, a naive question for my part is: would it be too inconvenient to release 2 isos: a main iso for most computers and a legacy iso with an MBR partition table for use if somebody has problems with the main iso?
And finaly, other possible solution might be to include on the release notes or somewhere more suitable that, on some systems, this problem could be present and the possible workarounds.
And nothing more on my part. It's time for the people on charge of this decide what is better. If something more is needed from me let me know.
Thanks and have a nice day.

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

José Marinho wrote:
> Marking the first partition as bootable legacy BIOS:
> - Plymouth --> 54 seconds.
> - Desktop environment --> 1 minute 45 seconds

Without converting to GPT ?
That would be really strange and surely no solution for the gerneral public.

(It is not allowed by GPT specs to set the "bootable" flag on the
"protective MBR partition" of type 0xEE, which serves as indication that
GPT is valid and also shall protect the data range of the GPT partitions.
Tests with grub-mkrescue ISOs on EFI systems failed. This led to the
introduction of the second partition of type 0x00 with boot flag.)

> 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 the BIOS or GRUB on that BIOS get deceived by a boot flag at the second
(dummy) partition, but the BIOS does not demand the boot flag on MBR
partition table.

> would it be too inconvenient to release 2 isos: a main iso
> for most computers and a legacy iso with an MBR partition table for use if
> somebody has problems with the main iso?

Debian does something similar for its "netinst" ISOs.
The BIOS-only ISO with no GPT and no EFI partition is deceivingly named
"mac", because the machines which need it are old x86 Apple machines.
Those machines are said to take offense from the presence of the EFI
partition or of the invald GPT in mjg's partition layout.

Normal BIOS+EFI ISO:
  https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.9.0-amd64-netinst.iso
The BIOS-only "mac" ISO is at:
  https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-mac-10.9.0-amd64-netinst.iso
Each has about 330 MB.
The version number may change in a few weeks or days. Look by a web browser at
  https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/
for
  debian-*.*.*-amd64-netinst.iso
  debian-mac-*.*.*-amd64-netinst.iso

Have a nice day :)

Thomas

Revision history for this message
Ice-Tea (ice-tea) wrote :

Amazing how we can all get different results doing the same thing. :)

For me a freshly written ubuntu ISO to a USB regardless if i use Ubuntu USB creator or DD refuses to boot my old legacy gear that is the last generation phoenix bios just before EFI was released.

It shows an error just before the grub screen starts "cannot find grub_platform" then it shows the grub menu and then boots to a black screen with a blinking cursor and just sits there forever and never boots even if i leave it for 15 or 20mins before i give up.

If i look at the USB sticks first partition with gnome disks , edit partition and tick the box that says Legacy BIOS bootable then the USB stick no longer shows "cannot find grub_platform" and goes straight to the grub menu , then it boots to a black screen with a blinking cursor for about 20 seconds and then it boots as normal just like any previous Ubuntu release?

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

Lucap wrote:
> If i look at the USB sticks first partition with gnome disks , edit
> partition and tick the box that says Legacy BIOS bootable then the USB
> stick no longer shows "cannot find grub_platform" and goes straight to
> the grub menu , then it boots to a black screen with a blinking cursor
> for about 20 seconds and then it boots as normal just like any previous
> Ubuntu release?

Is this a question or a report of an observed fact ?

If it is an observation, then i would be strongly interested in seeing the
results of two runs of

  STICK=/dev/sdc
  xorriso -indev stdio:"$STICK" -report_system_area plain

with STICK holding the device address which you used with dd.

Each run will emit about 50 lines of text.
You may catch them in a /tmp file by

  xorriso -indev stdio:"$STICK" -report_system_area plain 2>&1 | \
    tee -i -a /tmp/report_system_area.txt

Please make one run after freshly writing the unmodified ISO to the stick
before you use gnome disks. Afterwards make a second run to show the result
of gnome disk's activities.

Have a nice day :)

Thomas

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

just in case somebody wants to make experiments with changed grub.cfg,
here are instructions how to create a modified ISO from an Ubuntu amd64
original (but not from a "powerpc" ISO):

Set paths to the original ISO image and for the emerging ISO image:

  ORIG=ubuntu-21.04-desktop-amd64.iso
  NEW=ubuntu-21.04-test.iso

Extract grub.cfg from the original ISO to the current working directory:

  xorriso -indev "$ORIG" -osirrox on -extract /boot/grub/grub.cfg ./grub.cfg

Make the extracted file writable:

  chmod u+w ./grub.cfg

Now edit the file.
My proposal is to remove the 5 lines about grub_platform.

Make sure that a file with path "$NEW" does not yet exist.
Then create the new modified ISO:

  xorriso -indev "$ORIG" \
          -outdev "$NEW" \
          -map ./grub.cfg /boot/grub/grub.cfg \
          -boot_image any replay

This run of xorriso will issue some righteous warnings
  xorriso : WARNING : -volid text problematic as automatic mount point name
  xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
because of the blanks and lower case characters in
  Volume id : 'Ubuntu 21.04 amd64'
It will analyze "$ORIG" for boot equipment and boot entry points in order to
create the same in "$NEW"
  xorriso : NOTE : Replayed 22 boot related commands
  xorriso : NOTE : Copying to System Area: 32768 bytes from file '--interval:imported_iso:0s-15s:zero_mbrpt,zero_gpt:ubuntu-21.04-desktop-amd64.iso'

Then it begins to write to "$NEW" an ISO image of roughly the same size as
the size of "$ORIG". Enjoy the progress messages. :))

When done, put "$NEW" onto the USB stick and try what happens.
(Maybe mount "$NEW" and check whether your changes really did get into
 effect in /boot/grub/grub.cfg, before the lengthy dd to USB stick.)

Have a nice day :)

Thomas

Revision history for this message
José Marinho (jmarinho) wrote :

Hi Thomas,

I made the experiment you proposed modifying grub.cfg file. In this case I use a regular Ubuntu (Main edition with Gnome) Impish iso file.
After Grub I get a blank screen with the cursor blinking and after only 32 seconds I reach Ubuntu logo and after 1 minute and 22 seconds the window where you select language settings and if you want to try Ubuntu first or begin installation process now without trying Ubuntu.
So it seems that you find the cause of the problem.
Hope that helps.

Have a nice weekend.

tags: added: rls-ii-incoming
Changed in casper (Ubuntu):
importance: Undecided → High
tags: added: fr-1415
tags: removed: rls-ii-incoming
summary: - HIrsute live session takes ages to boot on BIOS systems
+ Impish live session takes ages to boot on BIOS systems
48 comments hidden view all 128 comments
Revision history for this message
Chris Guiver (guiverc) wrote :

Booting Ubuntu Desktop (groovy RC 2020-10-16.4)
- - motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series)

and plymouth takes ~8 mins to appear on screen
the maybe-ubiquity (try or install) screen took >10 mins

I did mention groovy in comment #17, but I don't believe I filed bugs, just noted on iso.qa.ubuntu.com QA-test reports.

I didn't use stop-watch, but looked at room clock in room (digital without seconds so my times are approx only).. My ISO may also not have been released groovy; just last I zsync'd prior to release for QA.

Changed in ubuntu-release-notes:
status: New → Fix Committed
Revision history for this message
Chris Guiver (guiverc) wrote :

Lubuntu 22.04 LTS (jammy) ISO booting on
- motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series)

00:10 secs enter pressed at grub

(I could reduce 10secs from following times, but have opted not to)

BLINKING CURSOR without change until

7:19 (7 mins 19 secs) first boot message
7:27 lubuntu plymouth is seen
8:04 system messages replace plymouth
8:31 Xorg mouse pointer is seen
9:12 lubuntu wallpaper is drawn
by 9:20 the system is fully functional

tags: added: jammy
Revision history for this message
tlk (sarcasticskull) wrote (last edit ):

Hitting this with Ubuntu MATE 22.04 iso dd'ed onto a USB stick.
Spotted the grub_platform thingy, then had to wait like ~20 min after the GRUB menu for it to start booting.

Run of the mill legacy (I guess) platform:
Gigabyte GA-970A-DS3/GA-970A-DS3, BIOS F7a 01/24/2013
AMD FX-6100
8GB

Kinda frustrating that the fixes/kludges for both "advanced" EFI and legacy crap "proprietary" systems suddenly make booting an Ubuntu LTS live ISO impossible (not having any hint on what's going on).

Revision history for this message
Chris Guiver (guiverc) wrote :

I just booted Lubuntu kinetic daily on
- motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series)

I didn't set up stopwatch to time correctly; but room clock said 13:16 at start of boot, and system was fully functional just as it hit 13:22, which is way faster than comment #90 on same box with jammy ISO.

The ISO wasn't cloned to thumb-drive; but written using

`sudo -H dus-iso2usb kinetic-desktop-amd64.iso /dev/sdb msdos grub-2.0.4 persistent`

guiverc@d960-ubu2:/de2900/lubuntu_64$ apt-cache policy mkusb
mkusb:
  Installed: 22.0.1-1ubuntu2
  Candidate: 22.0.1-1ubuntu2
  Version table:
 *** 22.0.1-1ubuntu2 500
        500 http://ppa.launchpad.net/mkusb/unstable/ubuntu kinetic/main amd64 Packages

This comparison isn't complete; as different ISOs used (jammy vs kinetic) & different writes (clone/dd vs mkusb-altered), but noted here.

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

Chris Guiver wrote:
> The ISO wasn't cloned to thumb-drive; but written using
> `sudo -H dus-iso2usb kinetic-desktop-amd64.iso /dev/sdb msdos grub-2.0.4 persistent`

Ahum. Congrats to sudodus then. :))

I read in
  https://help.ubuntu.com/community/mkusb#Installation
  "The main function of dus-iso2usb is to
   1. extract the first partitions and the grub structure from compressed
      image files
   2. create new partitions, one for an iso file labeled 'isodevice',
      and one optional for persistence labeled 'writable' (or in older
      systems labeled 'casper-rw').
   3. copy iso file to 'isodevice' and add some tweaks.
   "

So this indicates that GRUB alone is not to blame for the slow booting.
Something in the ISO's partitioning or GRUB configuration is needed for
the problem.

What do you get reported about the USB stick partitions by fdisk -l ?

I wonder what is meant by "add some tweaks".

Have a nice day :)

Thomas

Revision history for this message
sudodus (nio-wiklund) wrote (last edit ):

Hi Thomas Schmitt,

> I wonder what is meant by "add some tweaks".

1. Made grub use UUID instead of device name to identify partition where to find the grub files

---
# create grub.cfg to match iso file's name

echo -e "$inversvid tweak grub ...$resetvid"

# tweak 3: search by UUID

sleep 2
partprobe
sleep 2
targ1=$(mktemp -d --tmpdir dus.XXXXXXXXXX)
uid2=$(lsblk -o uuid,label "$target" |grep -i 'usbboot'|sed "s% *usbboot%%")
uid3=$(lsblk -o uuid,label "$target" |grep 'isodevice'|sed "s% *isodevice%%")
echo "uid2=$uid2"
echo "uid3=$uid3"
mount -U "$uid2" "$targ1"
sleep 2
if [ "$uid3" != "" ]
then
 sed -i '/set isofile/'a" search --set=root --fs-uuid $uid3" "$targ1"/boot/grub/grub.cfg
 sed -i 's/(hd0,3)/($root)/' "$targ1"/boot/grub/grub.cfg
 if [ $? -ne 0 ]
 then
  error="$error - sed: tweak 3 grub.cfg"
  result="target drive might work, but setting 'search by UUID' failed :-("
  echo "$result"
 fi
fi
umount "$targ1"
rmdir "$targ1"
sleep 2
partprobe
sleep 1
}
---
# tweak 1: maybe modify label of partition for persistence

mntpt=$(mktemp -d --tmpdir dus.XXXXXXXXXX)
mount -o loop "$source" "$mntpt"
syslbl=$(lsblk -o label,mountpoint | grep "$mntpt"|sed "s% *$mntpt%%")
umount "$mntpt"
sleep 2
isover=$(<<< "$syslbl" grep -o ' [0-9]*\.'|grep -o '[0-9]*')
pptarg=$(lsblk -lo name,label "$target" |grep writable|sed -e 's/ .*//' -e 's#^#/dev/#')

if [ $isover -lt 20 ]
then
 tune2fs -L casper-rw "$pptarg"
 sleep 1
fi

# tweak 2:
# To make Firefox work in Jammy & newer:
# apparmor.service.d/30_live_mode.conf: ConditionPathExists=

if [ $isover -ge 22 ]
then
 targ1=$(mktemp -d --tmpdir dus.XXXXXXXXXX)
 /bin/echo -e "$inversvid To make Firefox work in Jammy & newer $resetvid
 apparmor.service.d/30_live_mode.conf: ConditionPathExists="
 umount "$targ1" 2>&1
 targ0=$(mktemp -d --tmpdir dus.XXXXXXXXXX)
 mount -o loop "$source" "$targ0" 2>&1
echo '$pptarg $targ1'": $pptarg $targ1"
 mount "$pptarg" "$targ1" 2>&1
 tghme=$(find "$targ0" -name '*ubuntu*.seed')
# echo "$tghme"
 tghme=${tghme##*/}
 tghme=${tghme%.seed}
 if [ "$tghme" == "ubuntustudio" ]
 then
  tghme='ubuntu-studio'
 elif [ "$tghme" == "" ]
 then
  tghme=$(grep -om1 'ubuntu-kylin' "$targ0"/casper/filesystem.manifest)
 fi
 echo "target's home directory: /home/$tghme"
 mkdir -p "$targ1"/upper/home/"$tghme"/.config/autostart
 mkdir -p "$targ1"/upper/usr/local/sbin
 cp /usr/share/mkusb/fixfox.desktop "$targ1"/upper/home/"$tghme"/.config/autostart
 cp /usr/share/mkusb/fixfox "$targ1"/upper/usr/local/sbin
 umount "$targ1" "$targ0" 2>&1
 rm -r "$targ1" "$targ0"
# read -p "press Enter to continue"
fi
---

I think tweak 3 is most relevant in this case (of this bug report).

I have also noticed that it is difficult to 'make all computers happy with the same configuration' even within the group that want an MSDOS partition table.

The bug of this report seems to be somewhat worked around by the version in dus-iso2usb version 22.0.1, but I think old HP computers with core2duo processors want a bootable flag on the partition where grub is located. However, adding that boot flag seems to stop booting in UEFI mode. I am trying to make a configuration work for all these test cases ...

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

sudodus wrote:
> # tweak 3: search by UUID
> sed -i '/set isofile/'a" search --set=root --fs-uuid $uid3" "$targ1"/boot/grub/grub.cfg
> sed -i 's/(hd0,3)/($root)/' "$targ1"/boot/grub/grub.cfg

Where does the grub.cfg come from, in which you find "set isofile"
and "(hd0,3)" ?

I looked into /boot/grub/grub.cfg of ubuntu-22.04-desktop-amd64.iso and
of ubuntu-20.04.1-live-server-amd64.iso . Nothing to see of above search
texts.

Have a nice day :)

Thomas

Revision history for this message
sudodus (nio-wiklund) wrote :

Hi again Thomas,

The grub comes from a compressed tarball, that is extracted onto the target drive. This makes it independent of the current operating system and its version of grub.

So in order to look at it, use dus-iso2usb, or if you want only the basics, extract only the tarball, in this case if you installed mkusb 22.0.1

/usr/share/mkusb/dd_grub-boot-template-for-uefi-n-bios_msdos_grub-2.0.2-n-2.0.4.img.xz

If you don't want to install mkusb into your main system, you can install it into a persistent live system in a USB pendrive or into a system in a virtual machine.

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

sudodus wrote:
> The grub comes from a compressed tarball,

Well, then the hope to find a simple explanation from tweak 3 was an
illusion.

I am staring at the /boot/grub/grub.cfg of ubuntu-22.04-desktop-amd64.iso
and compare it with Chris Guiver's comment #90:
>...> "00:10 secs enter pressed at grub
>...> BLINKING CURSOR without change until
>...> 7:19 (7 mins 19 secs) first boot message

So i assume that /boot/grub/grub.cfg was executed. But then would last very
long to get from
        linux /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash ---
        initrd /casper/initrd
to a usable system.

Do i look at the wrong ISO ?
(I could not find Ubuntu "live" ISOs in the web.)

Have a nice day :)

Thomas

Revision history for this message
sudodus (nio-wiklund) wrote :

At

https://releases.ubuntu.com/22.04/

you find the amd64 iso file and its sha256sum, and at

http://cdimage.ubuntu.com/lubuntu/releases/22.04/release/

you find the corresponding Lubuntu files.

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

sudodus wrote:
> http://cdimage.ubuntu.com/lubuntu/releases/22.04/release/

The "Try or Install" menu item of grub.cfg in lubuntu-22.04-desktop-amd64.iso
differs from the one of ubuntu-22.04-desktop-amd64.iso mainly by kernel
parameter file=/cdrom/preseed/lubuntu.seed instead of ubuntu.seed.

The .seed files differ by:

--- ubuntu.seed 2022-05-15 19:02:13.187611554 +0200
+++ lubuntu.seed 2022-05-15 19:01:54.003611482 +0200
@@ -1,9 +1,8 @@
+# The Lubuntu seeds assume that installation of Recommends is disabled.
+d-i base-installer/install-recommends boolean true
 # Enable extras.ubuntu.com.
 d-i apt-setup/extras boolean true
-# Install the Ubuntu desktop.
-tasksel tasksel/first multiselect ubuntu-desktop
-# On live DVDs, don't spend huge amounts of time removing substantial
-# application packages pulled in by language packs. Given that we clearly
-# have the space to include them on the DVD, they're useful and we might as
-# well keep them installed.
-ubiquity ubiquity/keep-installed string icedtea6-plugin openoffice.org
+# Install the Lubuntu desktop.
+tasksel tasksel/first multiselect standard, lubuntu-desktop
+# No LXDE translation packages yet.
+d-i pkgsel/language-pack-patterns string

It is noteworthy that ubuntu.seed talks of avoiding "huge amounts of time",
whereas lubuntu.seed does not.

Does ubuntu-22.04-desktop-amd64.iso boot faster than the lubuntu ISO ?

Have a nice day :)

Thomas

Revision history for this message
sudodus (nio-wiklund) wrote :

@ guiverc,

I think you have suitable hardware and the best experience of us to answer the question in comment # 99.

Revision history for this message
Chris Guiver (guiverc) wrote :

Booting the released image of Ubuntu Desktop 22.04 LTS

- 00:00 word 'GRUB' appeared on screen (where I started stopwatch, so these results will be ~10 secs slower sorry)

- 00:09 enter pressed at GRUB
- 08:06 screen blacked
- 08:20 ubuntu plymouth first appeared
- 09:52 plymouth is gone, system text message appears
- 10:10 maybe-ubiquity TRY INSTALL prompt
- 10:37 system fully operational

quick comparison with comment #90 (https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/comments/90) shows ~minute longer to be fully functional; given a 1-5 secs gets lost as touch 'try ubuntu' it's still longer

lubuntu (jammy) plymouth seen at 7:27 (#90)
 ubuntu (jammy) plymouth seen at 8:20 (#101)

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

Chris Guiver wrote:
> lubuntu (jammy) plymouth seen at 7:27 (#90)
> ubuntu (jammy) plymouth seen at 8:20 (#101)

So it is not about the "huge amounts of time" which ubuntu.seed wants
to avoid.
Are those times stable or do they vary by minutes ?

We know that the firmware executes GRUB without much delay.
I am pondering how we could find out when GRUB hands over execution
to vmlinuz. Any ideas anybody ?

Have a nice day :)

Thomas

Revision history for this message
Chris Guiver (guiverc) wrote :
Download full text (3.3 KiB)

I grabbed my phone (stopwatch app) & lubuntu (kinetic; what was used last time) thumb-drive & timed a boot of Lubuntu kinetic (no new write of ISO)

Purpose:
> (#102) Are those times stable or do they vary by minutes ?

I hoped it would be a re-creation of #92 (but didn't read was there so it wouldn't influence result), alas I didn't use stopwatch then & didn't note which option I used

> (#92) I didn't set up stopwatch to time correctly; but room clock said 13:16 at start of boot, and system was fully functional just as it hit 13:22

ie. system operation in ~5 mins (<5 I believe as clock had just flipped 13:22 as it appeared), but I didn't say if persistent OR live was used.

OPTION USED THIS TIME = LIVE only (not persistent)

BOOT 1: LIVE
started stopwatch as I pressed ENTER at grub
by 2 mins 43 secs the system appeared functional

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

BOOT3: LIVE
00:29 secs & screen blanks & messages
00:35 plymouth visible
01:10 message(s) again & plymouth gone
02:25 system fully-operational

BOOT4: PERSISTENCE
00:27 secs & screen blanks & messages
00:34 plymount visible
01:41 message(s) again & plymouth gone
03:06 system fully-operational

(boot 4 and there was a longer delay between wallpaper being drawn & the menu responding to wacom-pen or SUPER key being pressed & menu appearing which is what I use to detect 'fully-operational)

Boot 2 & 3 are identical; any differences will be me needing to press the screen on the phone more than once to get it to register 'lap' time.

Re-creating test #101 using Ubuntu Desktop 22.04 LTS (comment #101)

> - 00:09 enter pressed at GRUB
> - 08:06 screen blacked
> - 08:20 ubuntu plymouth first appeared
> - 09:52 plymouth is gone, system text message appears
> - 10:10 maybe-ubiquity TRY INSTALL prompt
> - 10:37 system fully operational

(I started time at ENTER PRESSED at GRUB, so 9 secs difference expected)

08:01 screen blanked
08:08 ubuntu plymouth first appeared
09:41 plymouth is gone, system text message(s) appear
10:08 maybe-ubiquity; TRY/INSTALL prompt
10:55 system fully operational

Times here start out consistent (9 secs difference expected as I started time with right hand as I hit enter at grub with left, last time it was when I saw 'grub' prior to grub.menu appearing), however at MAYBE-UBIQUITY times differed a bit.. and final-operational differs well beyond any user/me error(s)

Picking when a system is 'fully operational' is subjective, so a few secs difference can be just me using wacom-pen touching screen OR hitting SUPER at the right sec, versus a short delay (as I'm not hitting key/pen rapidly), but we have ~30 secs difference (10mins37secs-9sec 10m55s?)

> (#102) Are those times stable or do they vary by minutes ?

To me as a user they feel ~stable; but BOOT 1 of Lubuntu LIVE was slower than BOOTS 2 & 3 (which were consistent; boot 4 was different mode).. and some some times of Ubuntu Desktop were identical; but by end they differed beyond I believe could be me.

They don't vary by minutes though in my opinion; secs like this is all I've generally noted (a...

Read more...

Revision history for this message
Thomas Schmitt (scdbackup) wrote :
Download full text (4.4 KiB)

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...

Read more...

Revision history for this message
sudodus (nio-wiklund) wrote :

I agree with Thomas about the problems to boot some old computers.

I'm continuing to develop/tweak dus-iso2usb, added an extra (optional) parameter 'boot-flag' that can be added when mkusb partition table is selected. It helps HP computers, but may spoil booting some other computers.

So I think we probably need ways to get boot drive versions with and without a boot flag. One way would be two different iso files, another way is to use some special tool (like dus-iso2usb) for the corner cases that need a boot flag.

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

i have to correct a statement of mine in #104:

> 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

It's probably not fixed.
The comment by Steve Langasek rather announces the problem which José
Marinho experienced:
casper was probably adjusted to create the boot flag when creating the
persistent partition. Originally it did not preserve it.

We will see what the j3400 does on first and second boot attempt.

Have a nice day :)

Thomas

Revision history for this message
Chris Guiver (guiverc) wrote (last edit ):

Thomas Schmitt in #104

>...> motion computing j3400
> This one is possibly allowed to be somewhat slow.

From me (comment #76)
> ((or 3 mins 30 secs for `hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)`

The time for lubuntu kinetic actually beat a comparison time of one of an old hp.dc7700 I use heaps in QA-testing.

> 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:

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

(note: times for BOOT1 will be ~3-8 secs slower than reported due my-error operating phone-stopwatch)

BOOT1:
(I won't give times as I can't be sure which are which)
00:18, 00:27, 01:57, 02:18, 02:45
HOWEVER either way it was fully-operational at 2 min 45 secs (or 3-8 secs after that anyway)

system just rebooted (alt-sysreq+reisub)

BOOT2:
00:25 screen clears & message(s)
00:28 plymouth seen
02:17 maybe-ubiquity; try/install selection (I may have been a tad slow here in selecting try)
02:41 (i forget sorry)
03:11 system fully-operational

Maybe my [estimated] 3-8 secs is inaccurate; but I'd suggest it was similar.

FYI: If you need more testing; just ask (or I miss anything I was asked).. I'll boot the thumb-drive on a few boxes to confirm no issues with the

I'll go & boot the thumb-drive on some boxes to ensure it's usable elsewhere.. I'll edit this and add boxes it was tested on (I'm not expecting any issues)

It booted successfully on (got to maybe-ubiquity/try/install anyway; then I sysrq-reisuo)
- hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)
- dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
- dell [optiplex] 780 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)
- sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)
- samsung 700t1c-p10aat (i5-3317u, 4gb, 3rd gen.core.intel.graphics.4000)

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

Revision history for this message
Thomas Schmitt (scdbackup) wrote :
Download full text (3.4 KiB)

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 fi...

Read more...

Revision history for this message
Chris Guiver (guiverc) wrote (last edit ):

My thumb-drive K (what was used in #107 & #101) which contains Ubuntu 22.04 LTS (20220416) resulted in

PLEASE NOTE: I just noted the ISO date shows it wasn't the released image.. It'll be the last daily/final/RC i actually used in testing... I'd expect 20220419 for the released ISO. I don't expect it'll impair these results though.

(parts of lsblk & blkid are included... I'm not sure the provided command xorriso contains I expected)

sdb 8:16 1 7.5G 0 disk
├─sdb1 8:17 1 3.4G 0 part /media/guiverc/Ubuntu 22.04 LTS amd64
├─sdb2 8:18 1 4.1M 0 part
├─sdb3 8:19 1 300K 0 part
└─sdb4 8:20 1 4G 0 part /media/guiverc/writable
sr0 11:0 1 1024M 0 rom

guiverc@d960-ubu2:~/uwn/issues/735$ xorriso -indev /dev/sdb -report_system_area plain
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

xorriso : FAILURE : Drive address '/dev/sdb' rejected because: not MMC and -drive_class 'caution' '/dev'
xorriso : HINT : If the address is a legitimate target, prepend "stdio:"
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
guiverc@d960-ubu2:~/uwn/issues/735$ lsblk^Crriso -index /dev/sdb -report_system_area plain
guiverc@d960-ubu2:~/uwn/issues/735$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
.. redacting loop devices & my sda disk
sdb 8:16 1 7.5G 0 disk
├─sdb1 8:17 1 3.4G 0 part /media/guiverc/Ubuntu 22.04 LTS amd64
├─sdb2 8:18 1 4.1M 0 part
├─sdb3 8:19 1 300K 0 part
└─sdb4 8:20 1 4G 0 part /media/guiverc/writable

-- I stopped at this point & haven't performed
> 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

Please advise if I should continue, or other (the xorriso output didn't appear right to me)

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

Chris Guiver wrote:
> └─sdb4 8:20 1 4G 0 part /media/guiverc/writable

So it seems that casper added its persistent partition without creating
a dummy MBR partition with boot flag.
This simplifies the task of making current Ununtu ISOs digestible for
the j3400. One run of

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

suffices.

Chris Guiver wrote:
> guiverc@d960-ubu2:~/uwn/issues/735$ xorriso -indev /dev/sdb -report_system_area plain
> xorriso : FAILURE : Drive address '/dev/sdb' rejected because: not MMC and -drive_class 'caution' '/dev'

My mistake. The program is right. The command proposal should have been

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

Please run this to verify that the dummy partition is really not there
after the first successful booting of the USB stick.

(The demand for the "stdio:" prefix is a safety precaution to protect
system disks from dangerous superuser activities.
I forgot about it because i have a file /etc/opt/xorriso/rc which declares
  -drive_class harmless '/dev/sd[c-e]*'
so that i don't have to use "stdio:" with my USB sticks.
Whatever, -indev without -outdev to the same device prevents writing
and -report_system_area "plain" does not want to write to the device.
So it would be safe even for the system disks.)

Have a nice day :)

Thomas

Revision history for this message
Chris Guiver (guiverc) wrote (last edit ):
Download full text (5.0 KiB)

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.. (No big news as dc7700 & dc7900 usually react the same; but confirmed it won't boot on dc7900)

Likely not required; but again
--
guiverc@d960-ubu2:~/uwn/issues/735$ xorriso -indev stdio:/dev/sdb -report_system_area plain
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

libburn : SORRY : Failed to open device (a pseudo-drive) : Permission denied
xorriso : FAILURE : Cannot acquire drive 'stdio:/dev/sdb'
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
--
Executed
--
[sudo] password for guiverc:
root@d960-ubu2:~# echo $'\x80' | dd of=/dev/sdb bs=1 count=1 conv=notrunc seek=446
1+0 records in
1+0 records out
1 byte copied, 0.000132766 s, 7.5 kB/s
root@d960-ubu2:~#
--

Safely ejected thumb-drive; tested and it NOW BOOTS ON
- hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
- hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915)

I only booted to maybe-ubiquity|try/install then used sysrq-REISUO. If you needed me to complete boot & shutdown like a user, you'll have to ask me to do that.

I tested boot again on
- dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
- dell [optiplex] 780 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)
and sysrq-REISUO when it reached maybe-ubiquity|try/install

The following would NOT BOOT thumb-drive K now
- sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)
(I didn't get it to boot on samsung 700t1c-p10aat either, but I can't rule out me; as I find that device a pain booting external media)

Inserting thumb-drive K into my primary box
--
guiverc@d960-ubu2:~/uwn/issues/735$ xorriso -indev stdio:/dev/sdb -report_system_area plain
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

libburn : SORRY : Failed to open device (a pseudo-drive) : Permission denied
xorriso : FAILURE : Cannot acquire drive 'stdio:/dev/sdb'
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
guiverc@d960-ubu2:~/uwn/issues/735$ xorriso -indev stdio:/dev/sdb -report_system_area plain
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

libburn : SORRY : Failed to open device (a pseudo-drive) : Permission denied
xorriso : FAILURE : Cannot acquire drive 'stdio:/dev/sdb'
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'

guiverc@d960-ubu2:~/uwn/issues/735$ sudo xorriso -indev stdio:/dev/sdb -report_system_area plain
[sudo] password for guiverc:
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 940 nodes read in 1 seconds
libisofs: NOTE : Found hidden El-Torito image for EFI.
libisofs: NOTE : EFI image start and size: 1782345 * 2048 , 8496 * 512
xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
Drive current: -indev 'stdio:/dev/sdb'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record : El Torito , MBR protective-msdos-label grub2-mbr cyl-align-off GPT
Med...

Read more...

Revision history for this message
Thomas Schmitt (scdbackup) wrote :
Download full text (3.4 KiB)

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 ...

Read more...

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

i wrote towards Chris Guiver:
> it would
> be a good base if you could confirm that j3400 boots after the plain
> procedure with no other experiments inbetween

I should have written:

  it would be a good base if you could confirm that j3400 boots without
  the extra delay of ~6 minutes after the plain procedure with no other
  experiments inbetween

Reading my text proposal for the tutorial, i now think it should give
less info. Like

  On some very old and meanwhile rare machines it can last 10 minutes or
  longer until you see this welcome screen.
  If you really have to wait that long, consider to read the article [link]
  about a possible cause and a workaround.

The article would explain that
- the Ubuntu ISOs contain a boot flag as inavoidable workaround for booting
  some old and not so rare machines,
- which causes the long boot delay with some other old and rarer machines,
- and can be disabled by the dd procedure.

Have a nice day :)

Thomas

Revision history for this message
Chris Guiver (guiverc) wrote (last edit ):
Download full text (8.1 KiB)

-- reply to @Thomas #112 (start paste)
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.
-- (end paste)

I grabbed my thumb-drive 2; Ubuntu-MATE jammy (2022-04-19)
- plugged into j3400; enter pressed [just] @12:28 using room clock, plymouth seen at 12:36, maybe-ubiquity appeared at 12:38

This wasn't required/requested; but I omitted `sudo` for last; so added here

--- (start paste)
guiverc@d960-ubu2:~/uwn/issues/735$ sudo xorriso -indev stdio:/dev/sdb -report_system_area plain
[sudo] password for guiverc:
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 774 nodes read in 1 seconds
libisofs: NOTE : Found hidden El-Torito image for EFI.
libisofs: NOTE : EFI image start and size: 1422522 * 2048 , 8496 * 512
xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
Drive current: -indev 'stdio:/dev/sdb'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record : El Torito , MBR protective-msdos-label grub2-mbr cyl-align-off GPT
Media summary: 1 session, 1424812 data blocks, 2783m data, 4849m free
Volume id : 'Ubuntu-MATE 22.04 LTS amd64'
System area options: 0x00004201
System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT
ISO image size/512 : 5699248
Partition offset : 16
MBR heads per cyl : 0
MBR secs per head : 0
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x00 0xee 1 15630335
MBR partition : 2 0x80 0x00 0 1
GPT : N Info
GPT disk GUID : 92da1293cf19e54b80558e26d983bc85
GPT entry array : 2 248 separated
GPT lba range : 64 15630272 15630335
GPT partition name : 1 490053004f003900360036003000
GPT partname local : 1 ISO9660
GPT partition GUID : 1 92da1293cf19e54b80548e26d983bc85
GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 1 0x1000000000000001
GPT start and size : 1 64 5690024
GPT partition name : 2 41007000700065006e006400650064003200
GPT partname local : 2 Appended2
GPT partition GUID : 2 92da1293cf19e54b80578...

Read more...

Revision history for this message
Thomas Schmitt (scdbackup) wrote :
Download full text (3.4 KiB)

Hi,

Chris Guiver wrote:
> On j3400; pressed ENTER (at grub) at 13:10 (room clock).. I didn't note
> time of plymouth but I had maybe-ubiquity @ 13:13 (room clock) for
> altered version of 2022-04-19 ISO
> [...]
> so I'll now boot twice
> [...]
> alas should have noted clock.. it 'feels' slow... nah it's slow :(
> [...]
> another boot on j3400, hit ENTER (at grub) at 13:31, maybe-ubiquity jingle
> waking me from sleep at 13:41
> [...]
> MBR partition : 2 0x80 0x00 0 1

Looks like casper is still re-installing MBR partition 2 on the first
run of the Live system, although it was not there before this run.

If you now apply the remedy to the stick
  dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462
then i expect it to be permanently booting in reasonable time.
(Not because it was applied to the stick, but because casper will not
manipulate the partition table any more.)

Please confirm.

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

I had hoped that capser would save the partition entry and re-install it after
the creation of the persistent overwrote the MBR partition table. But it
seems to just write a pre-recorded partition entry with the boot flag.

So we'd need a change in casper if the description of the workaround
shall be reasonably safe.
I don't consider dd of=/dev/sdb safe considered that the Ubuntu tutorial
advises to use Balena Etcher for the copy-to-USB-stick step.

Casper would have to save before the additon of the persisten partition
at least 16 bytes beginning at offset 462, or 48 bytes to cover all three
unused MBR partitions. After creation of the partition the saved bytes
would be written back to the MBR of the USB stick.

In
  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/comments/66
i read:

   casper (1.455) groovy; urgency=medium
     [...]
     * Limit our dd to only change 16 bytes in the MBR regardless of input,
     [...]
   -- Steve Langasek <email address hidden> Fri, 16 Oct 2020 09:51:20 -0700

But this is not what Chris Guiver observes.

In
  https://git.launchpad.net/ubuntu/+source/casper/commit/?id=5c3637a224e7eca4c8998d72ac1711cd8b58b335
i see unconditional insertion of the boot flag partition:

  + echo $escape_arg -n '\0200\00\01\00\00\00\01\00\00\00\00\00\01\00\00\00' \
  + | dd of=$DEVICE bs=1 seek=462 conv=notrunc count=16

The current state in
  https://git.launchpad.net/ubuntu/+source/casper/tree/scripts/casper-helpers
still has this gesture:

  find_or_create_persistent_partition () {
      [...]
      echo "start=$start" | sfdisk --no-reread -q $DEVICE -a || return
      [...]
      if sfdisk -d $DEVICE | grep -q 'label: gpt'; then
          [...]
          echo $escape_arg -n '\0200\00\01\00\00\00\01\00\00\00\00\00\01\00\00\00' \
          | dd of=$DEVICE bs=1 seek=462 conv=notrunc count=16
      fi
      [...]

I would propose to do something like:

 + MBR_STASH=/tmp/mbr_stash_$$
 + dd if="$DEVICE" bs=1 skip=462 count=48 of="$MBR_STASH"
      echo "start=$start" | sfdisk --no-reread -q $DEVICE -a || return
      [...]
 - echo $escape_arg -n '\0200\00\01\00\00\00\01\00\00\00\00\00\01\00\00\00' \
 - ...

Read more...

Revision history for this message
Chris Guiver (guiverc) wrote (last edit ):

> If you now apply the remedy to the stick
> dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462
>then i expect it to be permanently booting in reasonable time.
> .. Please confirm.

Inserted thumb-drive(2) [Ubuntu-MATE jammy] into box and

-- start paste
guiverc@d960-ubu2:/de2900/ubuntu_mate_64$ sudo dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462
[sudo] password for guiverc:
16+0 records in
16+0 records out
16 bytes copied, 0.0107609 s, 1.5 kB/s
-- end paste

booted it on j3400
- motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series)

on boot (noting when at grub) it had reached maybe-ubiquity in ~3 mins using room clock (no seconds as digital). I made an error in typing SysRq-REO (intended REISUB) so as no sync.. ignoring this bot.

turned box back on & booted again; again at maybe-ubiquity in ~3 mins by room clock. Correctly used SysRq-REISUB to restart

another boot & again ~3 mins by room clock. SysRq-REISUO now

NOTE: I didn't wait for clock to change minute & press enter this time, thus the extra seconds (making 2+ mins ~3 mins) is just ME not starting hitting the timing at ~:01 secs or hitting ENTER just after minute changes.. Either way ~3 mins is NOT TEN minutes as the slow boot takes to reach maybe-ubiquity.

This confirms what I believe you wanted.

Revision history for this message
sudodus (nio-wiklund) wrote :

Congratulations Thomas (for theory) and Chris (for experiments). This is like development of physics ;-)

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

Chris Guiver wrote:
> This confirms what I believe you wanted.

Yes.
The stick needs the remedy once again after casper created the persistent
partition.

sudodus wrote:
> This is like development of physics ;-)

Like a unification of relativity theory and quantum mechanics ?

My apologies again for not remembering the results from one year ago
and wasting everybody's time with my first questions of this year.
Between #94 and #103 i was off track.

I'll wait a few days whether Steve Langasek shows up at this bug report.
If not, i plan to file a new wishlist bug for casper which describes
our findings and proposes the code change as of #115.

I re-re-read this report to list the affected machines:
- a tablet computer "motion computing j3400" of Chris Guiver,
- a Gigabyte H61M-D2H-USB3 mainboard of José Marinho (see also
  https://launchpadlibrarian.net/531427797/lshw.txt),
- (a Gigabyte GA-970A-DS3, BIOS F7a 01/24/2013 of tlk in #91, of which we
   have no confirmation that removing MBR partition 2 really helps).

Have a nice day :)

Thomas

Revision history for this message
tlk (sarcasticskull) wrote :

which post details the "removing MBR partition 2"?
I'll try when I come around to it.

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

tlk wrote:
> which post details the "removing MBR partition 2"?

#112 by me, confirmed by #114 by Chris Guiver:

If the USB stick with the the slowly booting ISO is overwritten meanwhile:

  # 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/sdX if="$ISO"

In any case after the USB stick has already booted once, you have to apply
the change again directly to it, because casper installed MBR partition 2
again after creating its persistent partition:

  # Take care not to name any of your valuable disks as USB_STICK
  USB_STICK=/dev/sdX
  sudo dd if=/dev/zero bs=1 count=16 of="$USB_STICK" conv=notrunc seek=462

Have a nice day :)

Thomas

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

i opened a separate bug with my wish for not needing a second zeroizing dd
run when the ISO is already on the USB stick:

  https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1977644
  "Please preserve MBR partition entries 2 to 4 when creating persistent partition"

Have a nice day :)

Thomas

Revision history for this message
tlk (sarcasticskull) wrote :

I can confirm that "removing MBR partition 2" indeed WORKS.

I've tested the "second" step as I've already had booted from the stick a couple of times (and always had experienced the daunting delay).
Thus I've patched the partition on the stick directly as you've advised.

As expected the insanely long pause after hitting enter on the GRUB menu is gone.

Thank you for your investigation!

Incidentally, I'm assembling a new desktop system for me right now, it's a modern platform obviously... so I'm expecting all this to not be needed for it.

Revision history for this message
Brian Murray (brian-murray) wrote :

Ubuntu 21.10 (Impish Indri) has reached end of life, so this bug will not be fixed for that specific release.

Changed in casper (Ubuntu Impish):
status: Confirmed → Won't Fix
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package casper - 1.473

---------------
casper (1.473) kinetic; urgency=medium

  * casper-helper: preserve entries 2-4 in the MBR when creating a new
    partition. (LP: #1977644, #1922342)

 -- Michael Hudson-Doyle <email address hidden> Fri, 05 Aug 2022 17:45:05 +1200

Changed in casper (Ubuntu Kinetic):
status: Confirmed → Fix Released
Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

the fix for #1977644 does not solve the problem of #1922342. It only reduces
the need for ISO patching to a single operation which can be done on the
ISO image file before putting it onto a USB stick (and not a second time
directly on /dev/sdX after the first boot):

  # 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

I think that #1922342 can only be considered solved if the users of Ubuntu
ISOs can easily find this procedure and an explanation when it should be
applied.
My proposal would be to put a brief hint into
  https://ubuntu.com/tutorials/install-ubuntu-desktop#4-boot-from-usb-flash-drive
and to add a new page
  https://ubuntu.com/tutorials/remove-boot-flag-from-iso
which gives details.

The brief hint would be 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."

Does anybody here know how to contact the custodians of the tutorials ?

Have a nice day :)

Thomas

Revision history for this message
sudodus (nio-wiklund) wrote :

Hi Thomas,

It might work to ask [the same question] at

https://discourse.ubuntu.com/

in order to find how to contact the custodians of the tutorials.

tags: added: foundations-todo
Changed in ubuntu-release-notes:
status: Fix Committed → Fix Released
tags: removed: foundations-todo
Revision history for this message
Chris Guiver (guiverc) wrote :

Lubuntu daily booted (2022-09-17) on
- motion computing j3400 (c2d-u9400, 4gb, intel mobile 4 series)

boot started (used arrow keys at grub to stop booting, hit enter at grub prompt) at 16:44
just blank screen & cursor top left until 16:52 so nothing seen for 'ages'
at 16:52 the lubuntu plymouth started
by 16:53 the session had started

system boots fine... just slow with >8 mins of nothing changed on screen but a non-blinking cursor ... which leads people to think the boot failed as per initial bug report in my opinion.

(I've not tried Ubuntu desktop; can if helpful; but it always responded the same except slightly slower.. I'd expect the same here unless it was changed & Lubuntu/flavors weren't)

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

following sudodus' advice i found
  https://discourse.ubuntu.com/t/install-ubuntu-desktop/25312
matching
  https://ubuntu.com/tutorials/install-ubuntu-desktop#4-boot-from-usb-flash-drive
but the "Sign Up" button first urges me to enable JavaScript (booh !)
and then says my browser is too old for its "rich content".
I could probably work around, but this is a demand which i only accept
from my local tax authorities (teeth-gnashingly).

-----------------------------------------------------------------
@Chris Guiver:

On my way to that discourse page i came to
  https://discourse.ubuntu.com/t/create-a-bootable-usb-stick-on-ubuntu/14011
where i see comments from "guiverc".
So, i assume that you can point the participants of
  https://discourse.ubuntu.com/t/install-ubuntu-desktop/25312
to my summary in

  https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/comments/125

Better warn them that the overall thread is long and full of wrong
theories. But meanwhile the diagnosis is clear.

As background you can point to

  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148

where Ubuntu ISO production had to switch from MBR partition table to
GPT partitioning, because some buggy EFI implementations need it,
and to

  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308

where Ubuntu ISO production had to add a MBR partition of type 0x00 with
boot flag for getting some buggy BIOS implementations to work again.
This boot flag partition is what slows down the boot process on the machines
which are reported at this bug (1922342).

If the need arises for discussing with me, then please on this bug report.

Have a nice day :)

Thomas

Displaying first 40 and last 40 comments. View all 128 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.