Unable to boot/install Impish daily in UEFI boot mode

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/1937115

This also occurring on Lubuntu Impish daily 2021-07-21
Machine tested Dell [ Optiplex] MT 7060, i7-8700 booting in UEFI+secure boot mode

Further tests on 2 Lenovo machines and cannot reproduce the bug.
Strange but seems to only affect Dell machines -- also tested a Dell laptop 7280 aand also could not boot into efi modes.

Lubuntu impish QA-test install to
- sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)
testcase: full disk, uEFI, ... (fails to boot so doesn't matter)

"INVALID IMAGE"
"FAILED TO BOOT"

then quickly boots to "Attempting to decrypt master key..." of the prior QA-test install located on ssd

the actual messages are more than I typed; but they only flash before switching to the ssd boot which boots the prior QA-test install to the box (an encrypted lubuntu install).

Xubuntu & Ubuntu impish dailies also fail to boot in the same/identical manner. The dailies boot though in other boxes tested.

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

Another user has reported issue (yesterday) on askubu

https://askubuntu.com/questions/1353382/any-ubuntu-21-10-iso-download-that-isnt-corrupted

Picture of screen end-user reported can be seen at https://i.stack.imgur.com/oeYYg.jpg

The picture fits what @Leok describes I believe; which is different to the sony vaio I used - however as the sony quickly moved to the next boot device (ssd) it booted a prior installed image meaning I never got a good look at it.

Details relating to the machine involved in the previous post by guiverc
========================================================================

Make/Model: Dell Inspiron 5567
CPU: Intel i5-7200U @ 2.5 GHz x 4
RAM: 16GB
GPU: AMD Radeon R7 M445 AMD� Iceland/Mesa; Intel� HD Graphics 620 (KBL GT2)
Desktop Env: Gnome 3.36.8
Windowing System: X11
Storage: 2 x SSD 250 GB + 2 x USB 15/30 GB
Booting: UEFI

Daily 20210721 .iso . This Bug was reported in QA Test Live Session.
Just installed .iso in Virtual Box from a download file,
Tested as Live Session, Success. Loaded good everything worked.
Except for some outdated files that apport would not collect.
Most likely files being used until developed ones finish.
Please check your media and .iso checksum.
Could have a corrupt download or bad USB.

My media and the .iso checksum are good.

Please note that my success in Virtual Box is due to the fact that it is running in BIOS mode.

This bug has been confirmed by other users as well.

Today's boot contains 4 lines (Lubuntu impish) on
- sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)

invalid image
failed to load
failed to load
... returns unsupported

the message is still very quick; the screen quickly being cleared and "Attempting to decrypt master key..." from the last successful QA-test install of Lubuntu impish on this box.

The thumb-drive boots normally on other boxes I've tested as usual...

Daily 20210721 .iso . This Bug was reported in QA Test Live Session.
Flashed .iso to USB with Etcher. The image failed due to the Linux Header.
Image did not attempt to start, Showed a warning sign.
UEFI boot mode on computer attempting to do live Session.
Lenovo Think Center M78 / 2 core AMD A6-5400B APU / Radeon HD 7540D Graphics
Display: X11
Daily build 20210731 UEFI failed to boot on USB live. Linux Header Failed.

@bernard010 Bernard Stafford

Please also mark this bug as affecting you and also advise what machine and model this occurred on.

Thank you for testing.

Ubuntu impish ISO fails to boot again on
- sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)

It fails to boot if ISO is written using mkusb CLONE OR LIVE modes.

(as noted earlier; applies to Xubuntu & Lubuntu too)

Testing Ubuntu Impish daily ISO 25-07-2021

Tested 8 machines and had 3 boot failures - all machines that failed were Dell machines,and all tests were in UEFI and/or UEFI with secure boot modes.

The boot media was created with "Startup Disk Creator".

The error messages are as follows (see also attached image):

Failed to open \EFI\BOOT\? - Invalid Parameter
Failed to load image \EFI\BOOT\?: Invalid Parameter
start_image() returned Invalid Parameter

Test results posted on the QA testing site -
http://iso.qa.ubuntu.com/qatracker/milestones/424/builds/234198/testcases/1303/results

Well this is a bit strange. Does anyone know when this started? The way the ISO is put together hasn't changed since the hirsute release, so this is probably related to a change in grub2 or shim. The bug was reported less than 24 hours after a new version of grub2 landed which is definitely something that makes one go "hmm". I'll reassign the package there -- this certainly isn't a syslinux problem as that hasn't been used at all to boot ISOs since focal, and afaik never ever when booting via UEFI.

@mwhudson Michael Hudson Doyle

This bug first appeared with the Ubuntu Impish daily on 21 July 2021 as in the original report -
I test the daily builds every day and can confirm that this was the first instance of the bug.

Seems to be an issue with shim / the UEFI firmware on those machines. Could be a regression from the load option parsing, but confused as to how we end up trying to boot a non existing file instead of falling back.

Could also be memory corruption (shim pull #365).

Need to mokutil --set-verbosity true and record the log during boot with a camera.

Please also include the output of efibootmgr -v on those systems. There is likely garbage in the boot loader entries the UEFI generated for those devices.

@juliank Julian Andres Klode

Sorry for any confusion -- how can I run the commands if I cannot boot the machines?

I have posted a work around for this issue upstream: https://github.com/rhboot/shim/pull/393

This will add a 2s delay on invalid filenames or not found files, and then fallback to the default loader. Hence it's still a good idea to parse the load options properly to avoid the errors in the first place :)

Thanks Julian - will check this out when available.

The timing of the bug report matches the rebuild of cd-boot-images-amd64 against shim-signed 1.50

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

This bug affects my Dell Latitude E7240 in UEFI mode (but booting works in BIOS mode).

I'd still like to see efibootmgr -v output from affected machines, for the boot entry that failed to boot.

Seeing that this affects multiple machines, bumping the priority. Also, looks like we might want to get this fixed before 20.04.3 is released.

I can report about a workaround:

The current Lubuntu Impish file, impish-desktop-amd64.iso, dated 2021-07-28 17:22 worked for me this way:

- Create a persistent live drive with mkusb-dus.

- Verify that it can boot both in UEFI and legacy BIOS mode.

- Install Lubuntu in UEFI mode (there was no problem for cloned systems to boot in BIOS mode).

But it did not work, when there was a system in the target drive. After wiping the first mibibyte, it was straightforward to install Lubuntu, and I have a working system now :-)

I should add, that I installed in a Toshiba,

http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/

and then moved the [internal] SSD to a USB3 to SATA adapter and booted my Dell Latitude E7240 and it works in UEFI mode. I don't want to overwrite the internal M2 drive of my Latitude.

Someone else, who has a computer that is affected by this bug may want to try via mkusb-dus and Lubuntu directly in the affected computer. (But it seems to me, that the problem is booting the live drive, not installing and booting after installation.)

Tested latest Lubuntu Impish ISO dated 29-07-2021 on 2 Dell computers Optiplex 7060 and Optiplex 7040
if I used "startup disk creator" to create the boot media I had 2 failures as in previous tests.

After that I tested the same 2 machines using the suggestion from sudodus(nio-wiklund) and created boot media persistent live media with mkusb-dus - and can confirm that I could boot up in both UEFI and UEFI+secure boot modes.I have not tested booting in BIOS (Legacy) as this has not been a problem.

Hope this is helpful.

Further - here is a link to my test results on the QA site:

http://iso.qa.ubuntu.com/qatracker/milestones/424/builds/234402/testcases/1303/results

@leok,

Thanks for testing :-)

I think it could be interesting if you have time to test in one of your Dell Optiplex computers, if it is possible to *install Lubuntu Impish* from a persistent live session, and that the installed system can boot.

@sudodus (nio-wiklund)

Tested Dell 7060 Optiplex box in UEFI+secure boot mode and installed Lubuntu - rebooted and applied updates and rebooted again - all good -

@leok,

Thanks again :-)

Now we can conclude that the booting problem is only affecting the live system, maybe only a cloned live system (we have not yet tested systems made with Rufus; probably such systems will work too).

@sudodus

I can run a quick check with Rufus created media - will report back later this evening.

Hi folks,

we don't need reports of what works and what doesn't.

We already know that only live media are affected - installed systems usually don't boot via removable media path - but if they do, they go via fallback loader binary which works around the issue as it does not interpret its arguments.

We even have two approaches to work around the issue that are under discussion upstream.

Feedback we're looking for for fixing this better would be output of efibootmgr -v with a tarball of /sys/firmware/efi/efivars/Boot* files, on those systems where you can't boot live media. And which of those boot entries did not work.

What happens here is that the bootloader entries in UEFI contain arguments that get passed to shim. Shim tries to parse them, as it wants to treat the first argument as the bootloader to boot next - whcih is used for fwupd. Some firmware simply contains garbage in there, causing things to fail. We'd like to know what this garbage this such that we can safely ignore it and avoid even the workarounds.

A USB drive with Impish made by Rufus 'UEFI only' & GPT fails in my Dell Latitude E7240 with the same message as a cloned drive.

@juliank,

Where (in which operating system) and when (at what stage) should we run

efibootmgr -v
tar -cvf boot-debug,tar /sys/firmware/efi/efivars/Boot*

Maybe I'm stupid, but I ask because what we want to run does not boot.

Also tested Rufus "UEFI only" & GPT and fails in Dell Optiplex 7060

I also have no idea (asked about this earlier) as to how to run commands on a machine that does not boot?

What am I missing?

output of `efibootmgr -v` on the sony crapbook
- sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)
https://paste.ubuntu.com/p/z9rn6Kg625/
FYI: the only OS on it is lubuntu; last focal.3 daily I installed
(these commands were operated from that installed focal.3 system)
---
BootNext: 0005
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0005,0006,0007
Boot0005* Sony Original VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0006* Sony Original VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0007* Windows Boot Manager HD(1,GPT,6936f223-1e91-eb4e-8498-0ab5af7b9347,0x1000,0x96000)/File(\EFI\Boot\bootx64.efi)
---

sudo tar -zcvf sony_crap.gz /sys/firmware/efi/efivars/Boot*

got the attached results (hopefully no typos)

This is another "what works, what doesn't" Sorry (made b/c of focal status at top)

But the
- sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)
boots the focal daily without issue, even current (20210729).

I've have only had issues with the impish daily.
(the install the prior comment was made from looks like daily 20210716 according to https://phab.lubuntu.me/w/release-team/testing-checklist/ though I'll likely change that shortly)

Booted the current Ubuntu iso files from the iso testing web-site

-rw------- 2,9G 2021-08-16 08:21 "focal-desktop-amd64.iso"
-rw------- 2,9G 2021-08-16 08:30 "impish-desktop-amd64.iso"

in a Dell Latitude E7240 in UEFI mode.

The impish iso file fails :-(

Then I read the latest posts by you developers, so I zsynced the focal iso file and it boots :-)

Daily build 20210816.iso REJECT The Header, Kernel, Modules & Extra Modules UNSUPPORTED! For UEFI Install using USB.. Latest FIX is a FAILURE. COMPLETE FAIL< WILL NOT BOOT...
Latest Kernel I have tested that works is 5.13.11 @ kernel.org. Works Awesome for this Version of Ubuntu impish.
Tested 4 times.

KERNEL FAILED ON UEFI BOOT Not Fixed...!!!
UPDATE KERNEL Please!
Daily build 20210816.iso REJECT The Header, Kernel, Modules & Extra Modules UNSUPPORTED! For UEFI Install using USB.. Latest FIX is a FAILURE. COMPLETE FAIL< WILL NOT BOOT...
Latest Kernel I have tested that works is 5.10.60 @ kernel.org. Works Awesome for this Version of Ubuntu Impish.
Tested 4 times. With new current Kernel

Both Lubuntu & Ubuntu(desktop) focal dailies (2021-08-16) boot on
- sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)

(the only box I have that was impacted by this bug)

The daily images from 20210817 should have the latest version of shim on them now so feel free to test that.

Tested Kubuntu daily ISO 170821 no boot errors

see: http://iso.qa.ubuntu.com/qatracker/milestones/424/builds/235402/testcases/1300/results

for details.

Tested the current Lubuntu Impish iso file dated

2021-08-17 17:22 "impish-desktop-amd64.iso"

Booting a cloned USB drive works [not only in BIOS mode but also] in UEFI mode in a Dell Latitude E7240 :-)

So I can confirm that the bugfix works also to boot Lubuntu Impish in my Dell.

I tested the current Lubuntu Impish live also in a Dell Precision M4800. It works in UEFI mode too.

Another confirm that bux fix good in Lubuntu

Tested Lubuntu Impish daily ISO 17-08-2021

Results here = http://iso.qa.ubuntu.com/qatracker/milestones/424/builds/235442/testcases/1701/results

InWin BL641 BIOS mode in VirtBox - success
Dell optiplex 7040 in UEFI mode - success
Dell optiplex 7060 in UEFI+ secure boot mode - success

Thanks, this is a generic fix that has been confirmed, verified for focal and released for impish. No further tests/reports needed.

Thank you for all the verification! I also confirmed this shim is working correctly on physical hardware - let me release it into focal-updates in a few moments.

This bug was fixed in the package shim - 15.4-0ubuntu9

---------------
shim (15.4-0ubuntu9) hirsute; urgency=medium

  * Fix booting installer media on some machines (LP: #1937115)
    - Always fallback to the default loader (PR #393)
    - Dump load options parsed (PR #393)
    - Disable load option parsing on removable media path (PR #399)
  * trivial: Fix a minor overflow in the mok importing code (PR #365)
  * Fix fall back loader to find the correct boot entry, avoiding potential
    corruption of firmware (PR #396).

 -- Julian Andres Klode <email address hidden> Fri, 06 Aug 2021 13:16:33 +0200

This bug was fixed in the package shim-signed - 1.40.7

---------------
shim-signed (1.40.7) focal; urgency=medium

  * Update to shim 15.4-0ubuntu9
    - Fix booting installer media on some machines (LP: #1937115)
      + Always fallback to the default loader (PR #393)
      + Dump load options parsed (PR #393)
      + Disable load option parsing on removable media path (PR #399)
    - trivial: Fix a minor overflow in the mok importing code (PR #365)
    - Fix fall back loader to find the correct boot entry, avoiding potential
      corruption of firmware (PR #396).

 -- Julian Andres Klode <email address hidden> Fri, 13 Aug 2021 18:07:24 +0200

The verification of the Stable Release Update for shim has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

QA Testing of Live daily build 20210819. UEFI boots properly flashed to USB key with Etcher.
This Bug Report is sufficiently satisfied.

@ Julian Andres Klode (juliank),

Please explain:

How does this bug affect the old versions Xenial and Bionic?

And how should we test that our computers are affected?

recently... while booting the ISO image for the Impish live build
the following error lines are displayed:

[ 1.501001] gpio gpiochip: (gpio_aaeon): tried to insert a GPIO chip with zero lines
[ 1.501013] gpiochip_add_data_with_key: GPIOs O..-1 (gpio_aaeon) failed to register. -22
[ 0.197133] gpio gpiochip: (gpio_aaeon): tried to insert a GPIO chip with zero lines
[ 0.197161] gpiochip_add_data_with_key: GPIOs O..-1 (gpio_aaeon) failed to register. -22

After a pause the iso then continues to boot and a successful installation proceeds without any signs of further error.

this first occurred at 20210820 (since fix released)

I have an own build PC with nVidia graphics and use 'safe graphics' to boot the iso
Prior to this I was not experiencing the problems that had been occurring with Dell laptops.

The matter reported in post #92 appears to be in process of being dealt with in Bug#1937897

Hello Leó, or anyone else affected,

Accepted shim into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/shim/15.4-0ubuntu9 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Leó, or anyone else affected,

Accepted shim-signed into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/shim-signed/1.51 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Leó, or anyone else affected,

Accepted shim into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/shim/15.4-0ubuntu9 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Leó, or anyone else affected,

Accepted shim-signed into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/shim-signed/1.37~18.04.11 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Marking as verified as per

"Verification is not necessary for individual SRU releases."

We did not touch any code paths involving shim-grub interaction, the fix here for disabling boot option parsing on removable media paths is valid across all releases, since the binary is the same.

This bug was fixed in the package shim - 15.4-0ubuntu9

---------------
shim (15.4-0ubuntu9) hirsute; urgency=medium

  * Fix booting installer media on some machines (LP: #1937115)
    - Always fallback to the default loader (PR #393)
    - Dump load options parsed (PR #393)
    - Disable load option parsing on removable media path (PR #399)
  * trivial: Fix a minor overflow in the mok importing code (PR #365)
  * Fix fall back loader to find the correct boot entry, avoiding potential
    corruption of firmware (PR #396).

 -- Julian Andres Klode <email address hidden> Fri, 06 Aug 2021 13:16:33 +0200

This bug was fixed in the package shim-signed - 1.51

---------------
shim-signed (1.51) impish; urgency=medium

  * Update to shim 15.4-0ubuntu9
    - Fix booting installer media on some machines (LP: #1937115)
      + Always fallback to the default loader (PR #393)
      + Dump load options parsed (PR #393)
      + Disable load option parsing on removable media path (PR #399)
    - trivial: Fix a minor overflow in the mok importing code (PR #365)
    - Fix fall back loader to find the correct boot entry, avoiding potential
      corruption of firmware (PR #396).

 -- Julian Andres Klode <email address hidden> Fri, 13 Aug 2021 18:00:15 +0200

This bug was fixed in the package shim-signed - 1.37~18.04.11

---------------
shim-signed (1.37~18.04.11) bionic; urgency=medium

  * Update to shim 15.4-0ubuntu9
    - Fix booting installer media on some machines (LP: #1937115)
      + Always fallback to the default loader (PR #393)
      + Dump load options parsed (PR #393)
      + Disable load option parsing on removable media path (PR #399)
    - trivial: Fix a minor overflow in the mok importing code (PR #365)
    - Fix fall back loader to find the correct boot entry, avoiding potential
      corruption of firmware (PR #396).

 -- Julian Andres Klode <email address hidden> Tue, 07 Sep 2021 12:03:11 +0200

This bug was fixed in the package shim - 15.4-0ubuntu9

---------------
shim (15.4-0ubuntu9) hirsute; urgency=medium

  * Fix booting installer media on some machines (LP: #1937115)
    - Always fallback to the default loader (PR #393)
    - Dump load options parsed (PR #393)
    - Disable load option parsing on removable media path (PR #399)
  * trivial: Fix a minor overflow in the mok importing code (PR #365)
  * Fix fall back loader to find the correct boot entry, avoiding potential
    corruption of firmware (PR #396).

 -- Julian Andres Klode <email address hidden> Fri, 06 Aug 2021 13:16:33 +0200

This has been reported in the ISO tracker as affecting the 18.04.6 candidate images (20210913):

http://iso.qa.ubuntu.com/qatracker/milestones/426/builds/236713/testcases

The reported issue happens on bare metal. In QEMU/KVM the 20210913 bionic-live-server-amd64 images work fine with secureboot enabled (checked via `mokutil --sb-state` in both the installer and installed systems).

This has also been reported in the ISO tracker as affecting the 18.04.6 candidate images Ubuntu Desktop (20210913):

http://iso.qa.ubuntu.com/qatracker/milestones/426/builds/236704/testcases/1300/results

These tests on bare metal machines as were the server tests in comment # 103 above.

This is because debian-installer somehow was uploaded for 18.04.6 built against shim-signed 1.37~18.04.10+15.4-0ubuntu7 instead of shim-signed 1.37~18.04.11+15.4-0ubuntu9. Not sure how or why this happened, but shim-signed has been released to bionic-updates now, so I'll rebuild debian-installer for the fix.

Hello Leó, or anyone else affected,

Accepted debian-installer into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu543.19 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

failure to boot 18.04.6 ISO (20210913.1) on
- sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)

Can't add -proposed (easily) to a system that fails to boot :(

4 error lines briefly appear on screen before box moves to next boot device; which is SSD & lubuntu impish GPG key is requested..

@Steve I'm still a bit puzzled by the reported failure [1], which is against the live-server (subiquity) image, and not against the d-i image, but according to the problem description the failure mode is similar (image fails to boot).

Could it be that some other component in the live-server image was built against the old shim, as it happened for debian-installer?

[1] http://iso.qa.ubuntu.com/qatracker/milestones/426/builds/236713/testcases

The boot bits of all the hybrid images are laid down by debian-cd, which for bionic takes those bits from the debian-installer build, and not from the archive directly.

That's reassuring, thanks Steve. Now waiting for a respin to proceed with the tests.

@Paride So I don't know these 'legacy' boot bits, but quoting Steve from yesterday:

"vorlon: yes, the boot bits for both images are copied from debian-installer output. In later releases this is done via xnox's cd-boot-images instead"

So possibly this might also cause issues for all isos?

This bug was fixed in the package debian-installer - 20101020ubuntu543.19

---------------
debian-installer (20101020ubuntu543.19) bionic; urgency=medium

  * Fix Vcs-Bzr branch target.
  * Rebuild against shim-signed 1.37~18.04.11+15.4-0ubuntu9. LP: #1937115.

 -- Steve Langasek <email address hidden> Tue, 14 Sep 2021 14:36:54 -0700

Ubuntu 18.04.6 Desktop ISO (20210915) now boots on
- sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)

(failure in comment #107)

I can also confirm that Ubuntu 18.04.06 desktop and server ISO's (29210915) boot on boxes that previously failed - see my comments # 103 and 104 above.

Test results on QA tracking site here:

1. Desktop tests = http://iso.qa.ubuntu.com/qatracker/milestones/426/builds/236832/testcases/1303/results

2. Server tests = http://iso.qa.ubuntu.com/qatracker/milestones/426/builds/236831/testcases/1697/results/

I assume we're not going to fix this for Xenial?