failure to boot groovy daily

Bug #1886148 reported by Chris Guiver
70
This bug affects 10 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
New
Low
Rex Tsai
Ubuntu CD Images
Fix Released
Undecided
Unassigned
casper (Ubuntu)
Invalid
Critical
Unassigned
cd-boot-images-amd64 (Ubuntu)
Fix Released
Undecided
Unassigned
cd-boot-images-arm64 (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

When reported the groovy daily was failing on most boxes..

Originally occurred if ISO is written via `dd`, `mkusb`, `Startup Disk Creator`, or `gnome-disks` (Restore disk image)

Box still impacted are (owned by sudodus/nio-wiklund)

* Lenovo V130

and owned by Leó Kolbeinsson

* Lenovo V14 IIL,Intel Core i3-1005G!,8GB,256GB SSD

---
Original detail follows
(with minimal edits; these boxes now boot groovy ISOs)

This is very similar to https://bugs.launchpad.net/bugs/1883040

Boxes that have failed to boot it are

dell [optiplex] 755 (c2d-e8300, 8gb, amd/ati radeon rv610/radeon hd2400 pro/xt)
dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
dell [optiplex] 780 (c2q-q9400, 4gb, amd/ati cedar radeon hd 5000/6000/7350/8350)
hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)
sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)

-- sudodus' boxes
dell Precision M4800
dell Latitude E7240
Toshiba Satellite Pro C850-19w
HP Probook 6450b - works now

-- leok's boxes
Acer [Aspire] E3-111-P60S (Pent.N3530, 4GB, Intel HD Graphics, Realtek RTL8111/81681/8411 GB Ethernet, Qualcomm Atheros AR9462 Wireless, Bluetooth Atheros A315-53, 500 GB hd)

Dell [Optiplex] 7010 ( i5-3470 , 16 GB, Intel Graphics 2500, Intel 82579LM GB Ethernet ,1TB hd) VirtualBox

Dell [Inspiron] 3521, (i3-3217U, 4GB, Intel HD Graphics 4000, Intel HM76 chipset 10/100 Mbps ethernet controller integrated on system board, WiFi 802.11 b/g/N, Bluetooth 4.0, 500 GB hd)
--

The ISO was written twice to two different thumb-drives. Same issue each time on same boxes.

On a number of boxes it’s wanting me to download aka https://bugs.launchpad.net/ubuntu-cdimage/+bug/1883040 however it’s done that on boxes not impacted by that bug, which makes me think thumb-drive/squashfs errs related. Also results of boot appeared different on varying boxes (inconsistent; dc7700 reported no thumb-drive; d755-5 also did that sometimes, sometimes it got to wanting to download - those two boxes were impacted by prior report; the remaining boxes were more consistent in response..; but if trouble reading data on thumb-drive then the slower boxes (dc7700/d755-5) may have more issues & thus be less consistent?)

I'll file this as a bug report so I can close my failed QA-tests, but I'm considering changing the status to 'incomplete', and re-testing tomorrow, OR it needs me to re-write ISO from a different box to a third-thumb-drive as I don't think I've ruled out media issues given Leok's report.

Related branches

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

Decided to mark incomplete, I'll re-test tomorrow, and will revive this report if I have troubles again... Leok's successful QA-test report is reason for the change..

Changed in ubuntu-cdimage:
status: New → Incomplete
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/1886148

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

Next day & updated ISO [2020-06-03 now] and same issue.
have tried 2x thumb-drives, one from yesterday & a new one.
thumb-drives were written firstly by primary d960 (tested on listed boxes), then one was re-written using sonycrap

sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)
hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)
dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)

I've mentioned on #lubuntu-devel my issues, kc2bez will hopefully test..
I've re-ran zsync script & it reports my ISO is 100% complete, so will write a new (fifth) thumb-drive & re-test...

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

Another thumb-drive written on sony crapbook has failed too.
stdin: Not a typewriter
/init: line 49: can't open /dev/sr0: No medium failed
/init: line 49: can't open /dev/sr0: No medium failed
Unable to find a medium container a live file system
Attempt interactive netboot from a URL?
yes no (default yes):

which is acting like a squashfs error/bad thumb-drive, but five thumb drives written by two boxes? sha256sum is expected so I don't see the issue

Changed in ubuntu-cdimage:
status: Incomplete → New
Revision history for this message
sudodus (nio-wiklund) wrote :

Things are happening to the boot structure. It seems grub is used also in BIOS mode (which is OK for me).

But it is far from ready to use in this daily iso file.

Cloned drive: both UEFI and BIOS mode: Failed in my Dell Precision M4800. This computer is getting old, but it is not a low end computer.

/init: line 49: can't open /dev/sr0: No medium found
Unable to find a medium container a live file system
Attempt to interactive netboot from a URL?
yes no (default yes):

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

Furthermore, I tried to make a persistent live drive with mkusb (mkusb-dus) using the default settings, which has been working for years (until a few days ago also in Lubuntu Groovy).

It failed completely in BIOS mode at the grub rescue prompt :-(

It reached a live-only working desktop in UEFI mode :-/

It does not work at all using mkusb with 'usb-pack-efi', another strong indicator that the boot structure is not what it has been for a long time.

So it seems that either the boot structure has changed a lot by intention, or there is some severe bug. I think we an explanation from a developer at Canonical. I would guess that there are big changed in the package casper. (I don't think that the Lubuntu team is responsible for this bug.)

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

typo fix:
I think we an explanation from a developer at Canonical.
-->
I think we need an explanation from a developer at Canonical.

Revision history for this message
Leó Kolbeinsson (leok) wrote :

I can confirm this boot failure occurring in Kubuntu as well as Lubuntu (i.e. installers ubiquity and calamares). Failed machines :

Acer [Aspire] E3-111-P60S (Pent.N3530, 4GB, Intel HD Graphics, Realtek RTL8111/81681/8411 GB Ethernet, Qualcomm Atheros AR9462 Wireless, Bluetooth Atheros A315-53, 500 GB hd)

Dell [Optiplex] 7010 ( i5-3470 , 16 GB, Intel Graphics 2500, Intel 82579LM GB Ethernet ,1TB hd) VirtualBox

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

I tested in standard Ubuntu Desktop and in Xubuntu. These are affected in the same way, so I think this bug affects all desktop flavours.

Revision history for this message
Steve Langasek (vorlon) wrote :

Does the image boot as expected when being copied to the USB stick, instead of being modified by a tool such as mkusb?

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

No, when cloned, it does not work at all. This is described in comment #5.

The attempt with mkusb to create a persistent live drive gave me a drive that worked live (only live, no persisence) in UEFI mode.

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

I continued testing, this time with the newest computer, that I have access to, a consumer class Lenovo V130 with an nvme drive that boots in UEFI mode with secure boot,

https://dustinweb.azureedge.net/media/494085/v130.pdf

This computer failed with a similar but slightly different output.

This time I tested Ubuntu Desktop Groovy

#perms size date time file-name
-rw------- 2,6G 2020-07-04 08:21 "groovy-desktop-amd64.iso"

and the output on the screen was

[0.460294] Initramfs unpacking failed: Decoding failed
stdin: Invalid argument
cat: read error Input/output error
stdin: Invalid argument [repeated many times, almost filling the whole screen]
Unable to find a medium container a live file system
Attempt to interactive netboot from a URL?
yes no (default yes):

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

I should add that I downloaded the iso file via zsync, so the checksum should be OK, and it was cloned to the USB drive. Maybe it helps you to see

'Initramfs unpacking failed: Decoding failed'

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

Lubuntu daily [2020-07-04] fails again on
hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)

stdin: Not a typewriter
/init: line 49: can't open /dev/sr0: No medium failed
/init: line 49: can't open /dev/sr0: No medium failed
Unable to find a medium container a live file system
Attempt interactive netboot from a URL?
yes no (default yes):

Written to thumb-drive with

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

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

The current daily Ubuntu Server Groovy iso file fails in the same or very similar way and the desktop iso files, so it is also affected by this bug (tested from a cloned USB pendrive).

#perms size date time file-name
-rw------- 960M 2020-07-05 07:27 "groovy-live-server-amd64.iso"

And there is no improvement in the current daily Ubuntu Desktop Groovy iso file

-rw------- 2,6G 2020-07-05 08:20 "groovy-desktop-amd64.iso"

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

I could find a working version of Ubuntu Desktop for PC computers at this link

http://cdimage.ubuntu.com/daily-live/20200629/

So June 29 the daily iso file

#perms size date time file-name
-rw------- 2,6G 2020-06-29 08:27 "groovy-desktop-amd64.iso"

was still good, a cloned USB drive booted both in UEFI and BIOS mode in my Dell Precision M4800 (with the default main menu entry, no tweaks were necessary).

But I noticed, that the automatically created third partition was shown without a label and without file system by

lsblk -fm

which indicates, that something fishy has started a that date. (I expected an ext4 file system with the label 'writable'.)

Revision history for this message
Leó Kolbeinsson (leok) wrote :

Lubuntu daily [2020-07-05]

Successful boot and good install on UEFI (no secure boot) :

InWin BL641 i5-10400,16GB,Intel UHD Graphics 630,Ethernet,Intel 660p 512GB M.2 NVMe hd

Successful boot and good install in VirtualBox :

Dell [Optiplex] 7010 ( i5-3470 , 16 GB, Intel Graphics 2500, Intel 82579LM GB Ethernet ,1TB hd)

Failed to boot on older laptop:

Dell [Inspiron] 3521, (i3-3217U, 4GB, Intel HD Graphics 4000, Intel HM76 chipset 10/100 Mbps ethernet controller integrated on system board, WiFi 802.11 b/g/N, Bluetooth 4.0, 500 GB hd)

1 comments hidden view all 203 comments
Revision history for this message
sudodus (nio-wiklund) wrote :

@leok,

Please tell us what method/tool that you used when you created the boot drive, that booted in UEFI mode.

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

Fails to boot with Lubuntu groovy daily [2020-07-06] on

- uefi
sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)
hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)
- bios
dell [optiplex] 780 (c2q-q9400, 4gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

written via my usual `dus` & live-only

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

@vorlon,

Please explain exactly what you mean by

'Does the image boot as expected when being copied to the USB stick?'

Can *you* boot from a USB drive with an Ubuntu live system created from a current daily groovy amd64 iso file? In that case please explain how you create that USB system, what computer it is and other relevant details.

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

The current daily Ubuntu Groovy Desktop file (2020-07-07) works for me in VirtualBox, when booted from the iso file seen as a virtual optical drive.

But it does not work in the same computer (Dell Precision M4800) on real metal, neither in UEFI mode nor BIOS mode, when cloned from the iso file to a USB drive.

Revision history for this message
Steve Langasek (vorlon) wrote :

This problem is also perfectly reproducible in a VM, when attaching the image as a disk instead of as a CDROM device. Tested under qemu as both a virtio disk and an ide disk.

Changed in casper (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Preeeeetty sure this is a problem with debian-cd not casper.

Changed in ubuntu-cdimage:
status: New → Confirmed
Changed in casper (Ubuntu):
status: Triaged → Invalid
Changed in ubuntu-cdimage:
status: Confirmed → In Progress
Revision history for this message
sudodus (nio-wiklund) wrote :

I'm glad that there is work in progress, and I am willing to help testing, whenever you have something to test :-)

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

I found another mode in which the current groovy iso files make bootable drives: 'grub-n-iso' alias isoboot. I can make a bootable USB drive that boots

- both in UEFI and BIOS mode
- both live-only and persistent live

when booting into a 'grub template' and then into an iso file according to the following link,

https://help.ubuntu.com/community/Installation/iso2usb/isoboot

So this 'grub-n-iso' method works, but a cloned drive from the sane iso file fails (when tested in the same Dell Precision M4800 as used for the tests described above).

Revision history for this message
Steve Langasek (vorlon) wrote :

A new image is available now with a partial solution for this issue; please test http://cdimage.ubuntu.com/lubuntu/daily-live/20200708.1/

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

:)

20200708.1 boots on sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)

I'll test on other boxes as I can.

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

Lubuntu groovy daily [20200708.1] boots on

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)
hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)
and already mentioned sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)

I had issues with

hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)

That box kept very quickly booting HDD even if I told it to boot thumb-drive. I could however boot an Xubuntu groovy ISO dated 2020-07-01 (picked at random) on it, so maybe this does mean this machine is still impacted !!??

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

Of note on 20200708.1 booting on hp dc7700

The thumb-drive used has an orange LED, and it looks like it's read (LED flashing) before it goes to HDD & shows hdd's grub options. It's brief though as mentioned in comment #29

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

Cloned Groovy USB drives boot again, at least in some of my computers :-)

+ I tested in my Dell Precision M4800 and it works as usual in UEFI mode (and via grub) in BIOS mode.

- But the Lenovo V130 does not boot in UEFI mode and secure boot - When I select the USB drive from the temporary menu, it skips to the internal drive. This is a different failure mode compared to the previous iso files. (This computer is willing to boot from the grub-n-iso system of comment #26 and from cloned drives made from groovy iso files from June.)

https://dustinweb.azureedge.net/media/494085/v130.pdf

+ I tested in my Toshiba laptop, and it works as usual in UEFI mode with and without secure boot (and via grub) in BIOS.

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

+ It works in a HP Probook 6450b with an Intel i5 M520 CPU, tested only in BIOS mode.

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

I also had Lubuntu groovy daily [20200708.1] boot on

lenovo thinkpad sl510 (c2d-t6570, 2gb ram, i915)
lenovo thinkpad x201 (i5-m520, 4gb, i915)

but it failed to boot on

hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915)

(same reaction as hp dc7700; I see the LED flash then it quickly proceeds to boot the hdd-installed OS on selecting to boot USB device)

Revision history for this message
Leó Kolbeinsson (leok) wrote :

Further tests on Lubuntu and Xubuntu Groovy daily [20200708.1]

Dell [Inspiron] 3521, (i3-3217U, 4GB, Intel HD Graphics 4000, Intel HM76 chipset 10/100 Mbps ethernet controller integrated on system board, WiFi 802.11 b/g/N, Bluetooth 4.0, 500 GB hd)

Acer [Aspire] E3-111-P60S (Pent.N3530, 4GB, Intel HD Graphics, Realtek RTL8111/81681/8411 GB Ethernet, Qualcomm Atheros AR9462 Wireless, Bluetooth Atheros A315-53, 500 GB hd)

Both machines fail to boot in BIOS mode but can boot successfully in UEFI+secure boot mode.

Also tested :
Dell [Optiplex] 7010 ( i5-3470 , 16 GB, Intel Graphics 2500, Intel 82579LM GB Ethernet ,1TB hd)
in a VirtualBox (BIOS) and this booted successfully

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

Hmm, interesting. I don't have any idea myself how to debug a boot failure like this I'm afraid. I do have another change queued up that makes the images more like the ones from June: https://code.launchpad.net/~mwhudson/debian-cd/half-the-grubs/+merge/387085 -- but I don't at all understand why this would affect bootability. I guess we'll see if it helps...

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

Let us continue like this: *You* make the images 'more like the ones from June', and *we* (iso-testers) test how it works in our computers.

I have a good experience from booting USB drives via grub also in BIOS mode, so I think and hope that we can keep that feature. Via the link in comment #26 you can see a configuration that works (both in UEFI mode and BIOS mode).

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

My Lenovo V130 does not boot from a cloned drive, and did not boot from a persistent live drive by mkusb-dus. But with today's iso file, there is progress. It boots into a persistent live system with the boot option 'upefi', usb-pack-efi, (and there is persistence). So another way to see what works is to look at

- a persistent live drive, and particularly the boot partition,

- the tool that creates it, the bash shellscript 'dus-persistent'

There are details at

https://askubuntu.com/questions/1184161/what-script-is-used-for-creating-usbboot-partition-and-installing-grub-in-mkusb/1184175#1184175

When things have improved further and also the problematic computers boot from cloned iso files, they will probably also boot when mkusb used the default settings, where the system is created instead of extracted from the usb-pack-efi file.

Revision history for this message
Leó Kolbeinsson (leok) wrote :

Interesting indeed...and remember we also have users that create USB drives in Windows or macOS.

2 comments hidden view all 203 comments
Revision history for this message
sudodus (nio-wiklund) wrote :

The boot performance of the Ubuntu Groovy iso file on my computers are the same with today's daily iso file,

#perms size date time file-name
-rw------- 2,6G 2020-07-10 08:27 "groovy-desktop-amd64.iso"

as with yesterday's iso file. At least, I could not see any difference. Most of my computers boot from a USB drive when cloned, but there are still problems with the Lenovo V130.

This Lenovo computer is set to boot in UEFI mode with secure boot.

- The problem is that it cannot boot from a USB drive *cloned* from the current Ubuntu Groovy iso file dated 2020-07-10 08:27. Instead it skips to the internal drive and its grub menu (even when I select the USB drive from a temporary menu). This is the same problem as with the previous daily iso file.

- It works as intended when mkusb uses usb-pack-efi to create a persistent live drive.

Chris Guiver (guiverc)
description: updated
Chris Guiver (guiverc)
description: updated
Chris Guiver (guiverc)
description: updated
Chris Guiver (guiverc)
description: updated
Chris Guiver (guiverc)
description: updated
Chris Guiver (guiverc)
description: updated
Chris Guiver (guiverc)
description: updated
Changed in cd-boot-images-amd64 (Ubuntu):
status: New → In Progress
Changed in cd-boot-images-amd64 (Ubuntu):
status: In Progress → Fix Released
Changed in cd-boot-images-arm64 (Ubuntu):
status: New → Confirmed
Changed in cd-boot-images-arm64 (Ubuntu):
status: Confirmed → In Progress
Changed in cd-boot-images-arm64 (Ubuntu):
status: In Progress → Fix Released
123 comments hidden view all 203 comments
Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1886148] Re: failure to boot groovy daily

On Thu, Oct 08, 2020 at 01:10:12PM -0000, sudodus wrote:
> @ Steve Langasek (vorlon),

> Would you be able to ask the manufacturer, either Lenovo or InsydeH2O,
> what they are looking for in their "Linpus Lite" boot option (in order
> to boot in UEFI mode)?

Potentially, but this would take some time to work through channels.
Hopefully the latest image Just Works™ and it will be irrelevant to pursue
this.

Revision history for this message
Steve Langasek (vorlon) wrote :

On Thu, Oct 08, 2020 at 01:35:08PM -0000, sudodus wrote:
> So you want us to test only USB boot drives with the live system
> *cloned* from the iso file?

Yes, please.

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

If the Ubuntu iso file according to comment #163 is the one you want us to test, I'm sorry, but it is still failing when cloned.

Revision history for this message
Leó Kolbeinsson (leok) wrote :

Just tested my Lenovo V14 IIL pn the daily suggested in comment #163 - fails to boot in UEFI with/without secure boot. I am also convinced that the BIOS in the machine is the cause of the failures my USB media is also shown as #Linpus Lite" unless I boot in BIOS mode.

BIOS version DKCN48WW
EC version DKEC48WW
MTM 82C400UUMX
Lenovo SN PF1CY8F4

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

Hi,

has it already been tested whether a grub-mkrescue ISO boots to a
GRUB prompt ?

To try it, install

  grub-common grub-pc-bin grub-efi-amd64-bin

run

  mkdir minimal
  touch minimal/empty-file.txt
  grub-mkrescue -o output.iso minimal

and use output.iso like groovy-desktop-amd64.iso.

No menu or so is to be expected. Only "grub> _".
  https://i.stack.imgur.com/DEL0D.jpg

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

I really doubt that it makes a difference, but if a grub-mkrescue ISO
boots, we could try its pure GPT partition table by xorriso -as mkisofs
option

  -appended_part_as_gpt

which produces a "Protective MBR" partition table which indicates a
valid GPT.

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

If GPT does not boot either, then the difference must be in the EFI
partition. Either its storage location or its content.

The location could be tested by a stripped-down groovy-desktop-amd64.iso
with fewer payload but full boot equipment.

About the content of the EFI partition i cannot say much.

Have a nice day :)

Thomas

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

Hi Thomas,

I tried to make a minimal grub iso file, but failed. After installing xorriso too, I had the following error:

$ sudo grub-mkrescue -o output.iso minimal
grub-mkrescue: error: `mformat` invocation failed
.

I tried in an Ubuntu Groovy system. What is mformat? What should I add to make it work? Or would it be easy for you to upload a minimal iso somewhere, so that we (Leo and I) can download and test it?

Revision history for this message
Steve Langasek (vorlon) wrote :

On Thu, Oct 08, 2020 at 06:13:56PM -0000, sudodus wrote:
> Hi Thomas,

> I tried to make a minimal grub iso file, but failed. After installing
> xorriso too, I had the following error:

> $ sudo grub-mkrescue -o output.iso minimal
> grub-mkrescue: error: `mformat` invocation failed
> .

> I tried in an Ubuntu Groovy system. What is mformat? What should I add
> to make it work? Or would it be easy for you to upload a minimal iso
> somewhere, so that we (Leo and I) can download and test it?

mformat is from the mtools package, not installed by default.

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

Thanks Steve :-)

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

Booting this minimal device behaves differently in the Lenovo V130 in UEFI mode. Linpus Lite is *not* activated, but in the temporary menu there is an entry

EFI USB device (<name of the USB pendrive>)

1. Secure boot stops further booting, so the Lenovo will not reach to a grub prompt.

2. When I turn off secure boot, the Lenovo boots to the grub prompt :-)

3. The Dell boots to the grub prompt both in BIOS mode and UEFI mode.

Success :-) What's next :-P

Revision history for this message
Leó Kolbeinsson (leok) wrote :

@sudodus

Can you send me a link to the iso so I cn test it as well?

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

Hi,

> 3. The Dell boots to the grub prompt both in BIOS mode and UEFI mode.
> Success :-) What's next :-P

You could try a GPT partitioned groovy.iso.

In the hope that the automat knows best:

  test -f test.iso && rm test.iso

  xorriso \
    -indev groovy-desktop-amd64.iso \
    -outdev test.iso \
    -boot_image any replay \
    -boot_image any appended_part_as=gpt \
    -boot_image any mbr_force_bootable=off

The "replay" command is supposed to apply the commands to set up the
same boot equipment as the original ISO has. The two following commands
-boot_image switch from MBR partition table to GPT and disable the
forced boot flag, which was inherited from the original's boot flag.

Partition editors should then report GPT in test.iso . Like

  $ /sbin/gdisk -l test.iso
  ...
  Found valid GPT with protective MBR; using GPT.
  ...
  Number Start (sector) End (sector) Size Code Name
     1 64 5714919 2.7 GiB 0700 ISO9660
     2 5714920 5724871 4.9 MiB EF00 Appended2

(The alternative to above replay automat would be what i show in
   https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1895131/comments/22
 with other numbers. For
   0ca0a6242caffcb7c67497fc659f2b8c groovy-desktop-amd64.iso
 they would be 5715916 and 9952.)

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

About the theory that the position of the EFI partition is too far up:

  test -f test.iso && rm test.iso

  xorriso \
    -indev groovy-desktop-amd64.iso.1 \
    -outdev test.iso \
    -boot_image any replay \
    -rm_r /pool /casper/filesystem.squashfs --

This produces a much smaller ISO with MBR partition table (add above
-boot_image commands to get GPT):

  $ /sbin/fdisk -l test.iso
  ...
  Disklabel type: dos
  ...
  Device Boot Start End Sectors Size Id Type
  test.iso1 * 64 238375 238312 116.4M cd unknown
  test.iso2 238376 248327 9952 4.9M ef EFI (FAT-12/16/32)

It will probably not boot successfully beyond GRUB, because the ~2 GB of
filesystem.squashfs will be painfully missed as soon as the kernel is up.

But if it gets to the Ubuntu GRUB menu then this would indicate that
the start address of the EFI partition matters.

(Another test could be to move the EFI partition of a working USB stick
 high up and to check whether it then does not boot any more.)

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

I refrain for now from proposing to try a partition table layout like
with the older ubuntu ISOs (the barely legal one).

Have a nice day :)

Thomas

Rex Tsai (chihchun)
Changed in oem-priority:
importance: Undecided → Low
assignee: nobody → Rex Tsai (chihchun)
Revision history for this message
Leó Kolbeinsson (leok) wrote :

Booting in minimal device on Lenovo V14 fails in all modes - media not even recognized by BIOS
Tested on Acer machine - media recognized and boots to grub prompt in all modes/BIOS/UEFI/UEFI+secure boot.

Revision history for this message
Leó Kolbeinsson (leok) wrote :

Did some more testing on the Lenovo V14 IIL box and thought it might prove interesting to try other
Linux distro´s - Manjaro KDE Minimal and openSUSE Leap KDE - both fail to boot in all boot modes.
Also in these tests the media is also called "Linpus Lite".

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

@ Leó Kolbeinsson (leok),

I am not sure what test you reported in comment #175. Maybe I am too late, but this morning I uploaded my minimal iso file and the corresponding md5sum to

https://phillw.net/isos/linux-tools/alpha-beta/groovy/

$ md5sum -c bug-1886148_comment-172-173.iso.md5
bug-1886148_comment-172-173.iso: OK

Revision history for this message
Leó Kolbeinsson (leok) wrote :

@ sudodus

Re comment # 175

Sorry for not being more specific (I made and tested a minimal iso file). that is what I tested - should have let you know -thanks for sending the link.

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

@ Leó Kolbeinsson (leok),

I am surprised, that what works in my Lenovo does not work in yours. But the computers are different, and we can only guess what works before we have tested.

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

Hi,

Leó Kolbeinsson wrote:
> Booting in minimal device on Lenovo V14 fails in all modes [...]
> Tested on Acer machine - media recognized and boots to grub prompt in all
> modes/BIOS/UEFI/UEFI+secure boot.

I assume that this was the grub-mkrescue ISO. Right ?

It is a bit a surprise that Secure Boot works on the Acer.
But that it absolutely does not work on the Lenovo V14 indicates a general
problem with GRUB.
If my assumption about the ISO being an unaltered grub-mkrescue ISO, then
we should consider to forward this info to GRUB's Ubuntu maintainers and
in the end to grub-devel mailing list.

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

> [...] on the Lenovo V14 IIL box [...]
> Manjaro KDE Minimal and openSUSE Leap KDE - both fail to
> boot in all boot modes.

And what about
  https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.6.0-amd64-netinst.iso
(~ 350 MB, ISOLINUX for PC-BIOS, GRUB2 for EFI, barely legal partition
 table with low address of EFI partition.)

Inspection results:

manjaro-kde-20.1.1-201001-linux58.iso :
Uses GRUB2 for PC-BIOS and EFI. The EFI partition is appended after ~ 3 GB.
Much like what 20201008/groovy-desktop-amd64.iso has.

openSUSE-Leap-15.0-KDE-Live-x86_64-Current.iso:
ISOLINUX for PC-BIOS, GRUB2 for EFI, The EFI partition is appended after
~ 900 MB. Except the ISOLINUX stuff it is like 20201008/groovy.

openSUSE-Leap-15.2-KDE-Live-x86_64-Media.iso:
GRUB2 for PC-BIOS and EFI. Elsewise like 15.0 and 20201008/groovy.

openSUSE-13.1-NET-x86_64.iso would be interesting. It has an EFI partition
with very low start address. (Kiwi's swallow-your-brother stunt.)

Have a nice day :)

Thomas

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

Hi Thomas,

I failed according to your instructions at comment #174.

$ xorriso \
> -indev groovy-desktop-amd64.iso \
> -outdev test.iso \
> -boot_image any replay \
> -boot_image any appended_part_as=gpt \
> -boot_image any mbr_force_bootable=off
xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project.

Drive current: -indev 'groovy-desktop-amd64.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 46.5g free
Drive current: -outdev 'test.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 46.5g free
xorriso : NOTE : No proposals available for boot related commands

Nothing was processed, the window returned to prompt at once after printing the above list.

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

@ Thomas,

There was a problem with permissions. I fixed it ...

@ everybody,

This test.iso file modified according to comment #181, when cloned, makes USB drive that can boot the Lenovo V130 in UEFI mode with secure boot.

Now there is a temporary boot option 'Linpus Lite' again (and it works).

The Dell boots both in BIOS mode and UEFI mode.

Success :-)

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

Hi,

> $ xorriso \
> -indev groovy-desktop-amd64.iso \
> ...
> -boot_image any replay \
> ...
> xorriso : NOTE : No proposals available for boot related commands

This means that xorriso did not recognize any boot equipment in
groovy-desktop-amd64.iso .

> Drive current: -indev 'groovy-desktop-amd64.iso'
> Media current: stdio file, overwriteable
> Media status : is blank
> Media summary: 0 sessions, 0 data blocks, 0 data, 46.5g free

This looks like the input ISO is not accessible by path
groovy-desktop-amd64.iso, or is an empty file, or a file which begins by
64 KiB of zeros, or a file which has a specially devalued PVD in block 16.
Such files count as "blank medium in the drive".
(xorriso is a CD/DVD/BD burn program with the second job of making images.)

I just tested with xorriso-1.5.2 (newest release, i normally use the
development version) and got test.iso with GPT. So i expect that it will
work for you if you give it the ISO file.
The first "Media summary:" line of the run is for -outdev and should say

  Media summary: 1 session, 1431617 data blocks, 2796m data, ... free

The second line is for the -indev and should really say

  Media summary: 0 sessions, 0 data blocks, 0 data, ... free

because test.iso must not exist before this run.

Have a nice day :)

Thomas

Revision history for this message
Leó Kolbeinsson (leok) wrote :

@sudodus

Can you send me a link to test.iso so I can test exactly the same iso om V14?

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

Hi,

> There was a problem with permissions.

Hm. I should make xorriso report this. No read permission should not
count as blank pseudo-medium.
What kind of permission was missing and which change fixed it ?

> This test.iso file modified according to comment #181, when cloned,
> makes USB drive that can boot the Lenovo V130 in UEFI mode with secure
> boot.
> > -boot_image any replay \
> > -boot_image any appended_part_as=gpt \
> > -boot_image any mbr_force_bootable=off

So it wants to see a valid GPT.
grub-mkrescue produces this by default.
Does installation to the stick by usb-pack-efi produce GPT ?

There remains the riddle why the V130 booted with older Ubuntus which
have an invalid GPT. (I assume that it does. Does it ?)
Even the 20201007.1 ISO had an invalid GPT, much like older Ubuntus.

Whatever, this success will probably not happen with Leó Kolbeinsson's
Lenovo V14 IIL, as it does not boot by grub-mkreascue.
Nevertheless, it would be worth a try. Just to be sure.

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

I am running out of ideas. Open questions are:

- does Lenovo V14 IIL boot with
    https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.6.0-amd64-netinst.iso
  which has an old Fedora/Debian/Ubunto partition layout ?

- with which publicly downloadable ISO does V14 IIL boot at all ?

Do i get it right that the problems currently only affect sudodus'
Lenovo V130 and Leó Kolbeinsson's Lenovo V14 IIL ?
Any other machines which do not boot by the newest Ubuntu ISOs ?
(E.g. 20201008, MD5 0ca0a6242caffcb7c67497fc659f2b8c).

Have a nice day :)

Thomas

Revision history for this message
Leó Kolbeinsson (leok) wrote :

@scdbackup - Thomas Schmitt

I can confirm that the only box not booting for me is the V14 IIL .

all of my other Dell,Lenovo and MacMini machines boot as normal

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

Hi Thomas,

1. There was a name error, wrong name of the input iso file - easy to understand and fix, but I asked before thinking twice. There was also an ownership/permission error, the file was owned by root and there were not enough permissions for the standard user (because I had copied it from my main computer to the test drive with Groovy persistent live, where I installed programs and ran commands according to your advice).

2. mkusb creates a GPT by default, when making a persistent live drive. This can be modified in the settings menu. The default is not to use usb-pack-efi, and it has not been necessary with previous versions of Ubuntu (including 20.04.x LTS), it has worked to use 'grub-install command lines' (in the script dus-persistent).

After the big modification of the boot structure is has been necessary to use usb-pack-efi (selected in the settings menu) to make persistent live drives from Groovy iso files. I have not yet tested how mkusb can create persistent live drives with your modifications with the xorriso command line.

3. And yes, previous Ubuntu versions from when UEFI mode and cloning were established (I think around 12.10 or 13.04) it has worked to clone to USB drives, and these USB drives can boot both in BIOS and UEFI mode (including 20.04.x LTS and Groovy until the beginning of June and the big modification of the boot structure.

4. I am afraid, that there are several other new and fairly new Lenovo computers that are affected by this bug.

4.1 One of them is reported here by @RussianNeuroMancer in comment #151:

Lenovo Yoga C630 WOS with arm architecture

If I understand correctly, it can boot (in UEFI mode) from a USB drive with the content of the current Groovy iso file *extracted* to a FAT32 partition.

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

@ Leó Kolbeinsson (leok),

Now I have uploaded my modified Groovy iso file and the corresponding md5sum to

https://phillw.net/isos/linux-tools/alpha-beta/groovy/

$md5sum -c groovy-desktop-amd64_2020-10-08_fixed-by-xorriso.iso.md5
groovy-desktop-amd64_2020-10-08_fixed-by-xorriso.iso: OK

Good luck testing it :-)

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

Now I have tested how mkusb can create persistent live drives with Thomas Schmitt's modifications with the xorriso command line.

It is still working when using usb-pack-efi (and the default GPT)

- in the Lenovo V130 in UEFI mode with secure boot and

- in the Dell Precision M4800 both in BIOS mode and UEFI mode

-o-

With default settings (not using usb-pack-efi), a persistent live drive by mkusb works in UEFI mode (both in the Lenovo V130 and the Dell Precision M4800). But it does not work in BIOS mode. (This may be a headache for me, but not for the Ubuntu developers, and I mention it only for information.)

Revision history for this message
Leó Kolbeinsson (leok) wrote :

Tested the iso from sudodus (see comment #189) on the V14IIL Lenovo in all 3 modes- Legacy BIOS,UEFI,and UEFI+secure boot- success rate 100%. All 3 modes boot as normal.

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

Hi Leo,

This sounds good, but please tell us if you tested a system

- cloned or

- persistent live made by mkusb or

- made some other way.

Revision history for this message
Leó Kolbeinsson (leok) wrote :

@sudodus

re: comment 190/191

I used and tested the iso with 3 different methods none of them with persistent - all with the same results.

1. mkusb (live only or linux installer from iso file)
2. mkusb cloning iso file
3. rufus in Windows 10 (dd mode)

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

Hi,

> on the V14IIL Lenovo in
> all 3 modes- Legacy BIOS,UEFI,and UEFI+secure boot- success rate 100%.
> 2. mkusb cloning iso file
> 3. rufus in Windows 10 (dd mode)

So now it looks like valid GPT does the trick for Ubuntu ISOs on Lenovo.

There remain riddles:

Why does the grub-mkrescue ISO not boot on V14IIL ?
(I still wonder which other ISOs boot on that machine.)

Why did the old Ubuntu ISOs with their invalid GPT boot on sudodus' V130
whereas a similarly invalid GPT did not help with the 20201007.1 ISO ?

Maybe Canonical Ltd. should ask Lenovo Group Limited for enlightenment.

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

The xorrisofs option to cause GPT during the production of an Ubuntu ISO
would be

  -appended_part_as_gpt

With GPT it is crucial for mountability of partition 1 (the ISO) to use
option

  -partition_offset 16

GPT partition 1 may start only after the GPT array. So it cannot start at
LBA 0. The best non-0 value for the partition start is ISO LBA 16 (GPT
LBA 64). Lower is not possible, higher is waste.

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

Valid GPT is fewly tested with popular ISOs.

If Ubuntu ISOs switch from MBR partition table to GPT, then it will become
interesting to see whether there are any EFIs which hate it (and why they
do).

Have a nice day :)

Thomas

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

Thanks Thomas for your insight in booting from a cloned image of an iso file and the efficient method to find how to squash this bug :-)

Revision history for this message
Steve Langasek (vorlon) wrote :

Thanks very much for the analysis, Thomas!

> There remain riddles:

> Why does the grub-mkrescue ISO not boot on V14IIL ?
> (I still wonder which other ISOs boot on that machine.)

> Why did the old Ubuntu ISOs with their invalid GPT boot on sudodus' V130
> whereas a similarly invalid GPT did not help with the 20201007.1 ISO ?

Yes, that is puzzling.

> Maybe Canonical Ltd. should ask Lenovo Group Limited for enlightenment.

I've escalated it internally to the right team, and they will follow up, but
no guarantees we'll get a meaningful answer :)

> -------------------------------------------------------------------------

> The xorrisofs option to cause GPT during the production of an Ubuntu ISO
> would be

> -appended_part_as_gpt

Thinking it through, I am happy for us to make this change from MBR to GPT.

- optical media don't care about the partition table, only the El-Torito
  boot image.
- BIOS boot of USB doesn't care about the partition table, only the MBR
- UEFI 2.0 requires systems to understand GPT
- pre-2.0 UEFI systems are mostly not guaranteed to work anyway.

I've made this switch now and confirmed the result at
<http://cdimage.ubuntu.com/ubuntu/daily-live/20201009.1>.

I do see that the GPT has an extra partition at the end; is this required
for alignment? I haven't seen such partition entries when using MBR.

$ gdisk -l ~/devel/iso/groovy-desktop-amd64.iso
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /home/vorlon/devel/iso/groovy-desktop-amd64.iso: 5736268 sectors, 2.7 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 8897A8AA-43A3-4BD4-A4AA-C472E4376703
Partition table holds up to 248 entries
Main partition table begins at sector 2 and ends at sector 63
First usable sector is 64, last usable sector is 5736204
Partitions will be aligned on 4-sector boundaries
Total free space is 1 sectors (512 bytes)

Number Start (sector) End (sector) Size Code Name
   1 64 5725651 2.7 GiB 0700 ISO9660
   2 5725652 5735603 4.9 MiB EF00 Appended2
   3 5735604 5736203 300.0 KiB 0700 Gap1
$

Here is the full commandline used to construct this image.

xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1 -V Ubuntu\ 20.10\ amd64 -o /srv/cdimage.ubuntu.com/scratch/ubuntu/groovy/daily-live/debian-cd/amd64/groovy-desktop-amd64.raw -J -joliet-long -l -b boot/grub/i386-pc/eltorito.img -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info --grub2-mbr cd-boot-images/usr/share/cd-boot-images-amd64/images/boot/grub/i386-pc/boot_hybrid.img -append_partition 2 0xef cd-boot-images/usr/share/cd-boot-images-amd64/images/boot/grub/efi.img -appended_part_as_gpt -eltorito-alt-boot -e --interval\:appended_partition_2\:all\:\: -no-emul-boot -partition_offset 16 cd-boot-images/usr/share/cd-boot-images-amd64/tree CD1

Revision history for this message
Marcos Nascimento (wstlmn) wrote :

With the 2020-10-09 - 9:15 p.m. update, it started in efi mode on lenovo ideapad 330-15IKB. :)

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

I can report *success* from testing with the current daily Ubuntu Groovy iso file

$ ls -l groovy-desktop-amd64.iso
-rw------- 1 sudodus sudodus 2936969216 okt 9 21:15 groovy-desktop-amd64.iso

$ md5sum groovy-desktop-amd64.iso
00cbcce8855c00dd2231077e3a01aebc groovy-desktop-amd64.iso

After cloning to a USB drive, it can boot the problematic Lenovo V130 in UEFI mode with secure boot :-)

I checked also with a Dell Precision M4800, and this computer boots nicely both in BIOS mode and UEFI mode. In the near future I will test also in other computers, that are available, and I will blow the whistle if necessary.

See also the attached text file.

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

Hi,

> Thinking it through, I am happy for us to make this change from MBR to
> GPT.

Me not so much. GPT has that backup at the end of the device. But when
an image is made, the size of the storage device is not known. So after
putting (cloning) the image onto the USB stick, the backup GPT is
misplaced.

So we'd actually need an adjustment step after cloning, although the boot
firmwares don't care for that flaw. But partition editors do.
(Modern versions of program sfdisk fix the problem silently when any
 manipulation of GPT is done. E.g.:
   echo 'name=DATA' | sudo sfdisk -a /dev/sdc
)

But if more machines boot by GPT than by MBR partition table, i can hardly
be against it. Let's see what problems this causes ...

> I do see that the GPT has an extra partition at the end; is this required
> for alignment?

It's the padding against the TAO CD Read-Ahead Bug. This bug is caused by
an ambiguity in SCSI MMC specs about command READ CAPACITY when the last
track ends by two TAO Run-out blocks. About 80 percent of CD capable drives
count them as readable, which they are not for data read command READ(10).

By a cargo cult theory of last century, ISO 9660 producers and most burn
programs add 300 KiB of padding to keep legitimate read operations away
from the dangerous end of the device.
Actually it would have to be the buffer size of Linux when reading ahead
of the block range that is requested by the ISO 9660 filesystem driver.

(If i had a better standing at linux-scsi it would already be fixed for
 single session by testing the last two blocks for readability and
 adjusting the device size perception of the kernel if they are not
 readable by READ(10). I have made me a kernel which does this.)

With ISO images which never end up on a CD you can safely suppress this
padding by xorriso -as mkisofs option

  -no-pad

Even then most CD burn programs will add their own padding by default or
use write type SAO which produces no Run-out blocks.

> I haven't seen such partition entries when using MBR.

With MBR partition table the padding is either counted as part of
partition 1 (old Fedora/Debian/Ubuntu layout) or not marked as partition
(with appended partition).

The reason for that GPT partition is probably in my discussions with
Vladimir Serbinenko when i made xorriso ready for serving under
grub-mkrescue. If we find compelling reasons not to create it, i could
try to suppress this.
(The boot preparation code in libisofs is quite entangled by the many
 variations and little stunts which it accumulated over time.)

Have a nice day :)

Thomas

Revision history for this message
Leó Kolbeinsson (leok) wrote :

I can also confirm support testing current daily Ubuntu Groovy iso file
http://cdimage.ubuntu.com/daily-live/20201009.1/groovy-desktop-amd64.iso

Tested 3 machines with USB media created with "startup disk creator"

1. Dell 3521 Inspirion
2. Lenovo V14 IIL
3. Leonovo x230i

All booted in BIOS and UEFI + secure boot.

Revision history for this message
Leó Kolbeinsson (leok) wrote :

Correction to comment #199

I can also confirm success testing current daily Ubuntu Groovy iso file
http://cdimage.ubuntu.com/daily-live/20201009.1/groovy-desktop-amd64.iso

Tested 3 machines with USB media created with "startup disk creator"

1. Dell 3521 Inspirion
2. Lenovo V14 IIL
3. Leonovo x230i

All booted successfully in BIOS and UEFI + secure boot modes.

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

More tests - here is a list of all computers tested by me with the Ubuntu Groovy system

$ ls -l groovy-desktop-amd64.iso
-rw------- 1 sudodus sudodus 2936969216 okt 9 21:15 groovy-desktop-amd64.iso

$ md5sum groovy-desktop-amd64.iso
00cbcce8855c00dd2231077e3a01aebc groovy-desktop-amd64.iso

cloned from the iso file to a USB drive (except for VirtualBox). Please note that tested mode shows what is tested, and a missing mode does not indicate failure, only that is was not tested. Booting was successful in all these tests performed today, 2020-10-10.

Computer spec - tested mode
----------------------------------------
Lenovo V130 - UEFI mode secure boot
Lenovo X131e - UEFI mode
Dell Precision M4800 - BIOS & UEFI modes
Dell Latitude E7240 - BIOS & UEFI modes
HP Probook 6450b - BIOS mode
Toshiba Satellite Pro C850-19W - BIOS & UEFI modes (also with secure boot)
VirtualBox 6.1.10_Ubuntu r138449 - iso file emulating optical disk - BIOS mode

Revision history for this message
Leó Kolbeinsson (leok) wrote :

Updated test list current daily Ubuntu Groovy iso file
http://cdimage.ubuntu.com/daily-live/20201009.1/groovy-desktop-amd64.iso

Tested machines with USB media created with "startup disk creator"

Booting successful in all tests

Computer spec - tested mode
----------------------------------------
Dell 3521 Inspirion - BIOS + UEFI & UEFI + secure boot
Lenovo V14 IIL - BIOS + UEFI & UEFI + secure boot
Leonovo x230i - BIOS + UEFI & UEFI + secure boot
Lenovo L450 - BIOS + UEFI & UEFI + secure boot
Lenovo T430i - BIOS + UEFI (secure boot not supported by BIOS)
Acer E3-111-P60S - BIOS + UEFI+ secure boot
Dell Latitude 7280 - BIOS + UEFI+ secure boot
Lenovo M72e - BIOS + UEFI+ secure boot
QEMU virtual machine running in Dell 7040 - BIOS mode

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

I have tested the current daily (2020-10-10) Xubuntu and Lubuntu iso files too. When cloned to a USB drive, they can also boot the Lenovo V130 in UEFI mode (and secure boot). It seems that bug #1895329 is squashed too.

Steve Langasek (vorlon)
Changed in ubuntu-cdimage:
status: In Progress → Fix Released
tags: added: fr-703
Rex Tsai (chihchun)
tags: added: oem-priority
Norbert (nrbrtx)
tags: removed: groovy
Displaying first 40 and last 40 comments. View all 203 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.