loopback command hangs in 2.04 under UEFI

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

During bootup, I enter the grub2 command-line by pressing c on the Grub menu.

When I type the following command...

loopback loop (hd0,gpt2)/ubuntu-19.10-desktop-amd64.iso

...grub hangs, there is no more output or activity on the terminal, and eventually the laptop fans spin up because the laptop gets hot.

The path (hd0,gpt2)/ubuntu-19.10-desktop-amd64.iso is valid on my system.

I am experiencing this in Ubuntu 19.10 and did not have this issue in prior Ubuntu releases.

The version of grub2 and grub2-common I have is 2.04-1ubuntu12.

I have not had problem Booting ISO files in BIOS mode in 19.10.

When booting my grub menu shows grub 2.02 at the top.

When I tried upgrading grub it tells me grub 2.04 is already installed.

I can confirm that Booting ISO files from BIOS in Ubuntu 19.10 works fine.
UEFI seems to have the issue.

One reason I did not have problems booting a 19.10 ISO was because I used mkusb installed in 18.04 to create the foundation for the boot disk. This used grub 2.02 to boot 19.10.

I can also confirm this bug. I have an UEFI system and latest Ubuntu 19.10 installed with updated packages. Grub2 shows these errors when trying to list an ISO with ls command from Command line in the grub2 environment. It doesn't show any error if I list a pdf it any other files. Problem seems to be in the iso9660 module.

I am trying to boot ISO directly from my system rather than from an USB. Just for an info.

Does anyone know which package contains the iso9660 module for grub?

Would it be possible to copy the iso9660 module from the the 19.04 or 18.04 Ubuntu releases (e.g. grub 2.02), and explicitly load it before executing the loopback command?

I tried iso9660.mod from grub-efi-amd64-bin 2.00 from snapshot.debian.org and that hung as well.

I also tried installing grub-efi-ia32 instead of grub-efi-amd64 but that also hung.

Coming,

This is good research.
Thanks for testing.
Perhaps the cause is a secondary library or dependency that iso9660.mod is using?

* Ximin, apologies for the misspelling of your name; the spellcheck override what I had typed.

Workaround
I used mkusb installed in 18.04, (grub 2.02), to make the foundation of an ISO booter.
ISO's in an ISO folder on usbdata partition, with casper-rw partition for persistence, (one distro only).
Usbboot partition has loop mounting grub.cfg.
Boots 18.04 and 19.10, both UEFI and BIOS, (I got a new power brick for my UEFI computer).

UEFI boot fails using mkusb installed in 19.10, (grub 2.04). whether 18.04 or 19.10.

I think the problem is grub 2.04 myself.

mkusb can boot from grub 2.04 when pointing to a partition, into which you have cloned from the iso file (so with an iso 9660 file system). The problem is specifically that it does not work in UEFI mode, when grub points to an iso file.

But only when mkusb is installed in Ubuntu 19.10 or later, ie grub 2.04 the ISOs don't boot.
When mkusb is installed in 18.04, grub 2.02, the ISOs on the USBs it makes boot fine.

You are right (and you were right also in comment #12). I only wanted to make it clear for the developers what works and what does not work.

To clarify, if I install mkusb in 18.04 the USBs it makes boot with grub 2.02.
If I install mkusb in 19.10 the USBs it makes boot with grub 2.04.
Grub 2.02 boots ISOs, grub 2.04 does not boot ISOs.

Oops, After a little more experimenting, it appears that it is the version of Ubuntu that mkusb uses to create the persistent drive that determines the version of grub, not the version of Ubuntu mkusb is installed in. I guess that this should have been obvious.
I created an ISO booter foundation using mkusb installed in 18.04 using a 19.10 ISO. I added both 18.04 and 19.10 ISOs to the ISO folder on the usbdata NTFS partition. Both had problems booting in UEFI as mentioned above, they uses grub 2.04
I then created another ISO booter foundation using mkusb installed in 19.10 using a 18.04 ISO. I added both 18.04 and 19.10 ISOs to the ISO folder. Both booted fine in UEFI mode, they used grub 2.02.
I will try duplicate my findings tomorrow.

@ C.S.Cameron,

While you are testing, please try with usb-pack-efi too. I think it should make things work, where there are problems now.

(It is still important to squash this bug, but usb-pack-efi might be a workaround for people using mkusb as a foundation for iso booting.)

@sudodus, I tried a fresh install or two yesterday, I ran sudo apt-get install usb-pack-efi (# for persistent live drives that work in UEFI and BIOS mode with 32-bit iso files). when installing.
Is that enough?

Will try again today.

@ C.S.Cameron,

Yes, I think it is enough with a single test. Please tell us the result of your test when usb-pack-efi is selected in the settings menu of mkusb. Will it make a difference in order to make it possible to boot into an iso file?

@sudodus:

Made a persistent 4GB flash drive using mkusb menu item usb-pack-efi with
19.10.
Used this drive to make a second 4GB flash drive using mkusb menu item
usb-pack-efi with 19.10.
(Just to make sure grub 2.02 had no way to sneak in).
Deleted ISO9660 partiton #4, stretched Casper-rw partition #5 into place
and expanded usbdata NTFS partition #1.
Dropped 19.10 ISO into iso folder on NTFS partition.
Updated grub.cfg on usbboot partition #2 to loopmount the 19.10 ISO.
Booted in BIOS using grub 2.04
Booted in UEFI using grub 2.02~Beta2

This solution works for me. I am impressed.

Is there way to retro fit this to a working system so sundar-ima can use it
to boot ISOs from his internal dive? I wonder how Qemu is doing with this
bug?
Mkusb would work fine for setting up a small SSD, as either Full or
Persistent install for booting ISOs, but my SSD booting option seems to be
missing?

On Sun, Nov 17, 2019 at 11:30 PM sudodus <email address hidden> wrote:

> @ C.S.Cameron,
>
> Yes, I think it is enough with a single test. Please tell us the result
> of your test when usb-pack-efi is selected in the settings menu of
> mkusb. Will it make a difference in order to make it possible to boot
> into an iso file?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1851311
>
> Title:
> Grub 2.04 Out of memory error, No server error
>
> Status in grub2 package in Ubuntu:
> Confirmed
>
> Bug description:
> Trying to loop mount ISO.
>
> Installed grub 2.04 to flash drive in UEFI mode from 19.10
> Flash drive does not boot and gives Out of memory error & no server
> error. Must load kernel first.
>
> Re-installed grub from 18.04 to same flash drive using same boot stanza.
> Booted without issue.
>
> From 18.04
> fred@Bionic-Z170N:~$ grub-install -V
> grub-install (GRUB) 2.02-2ubuntu8.13
>
> from 19.10
> fred@fred-Z170N-eoan:~$ grub-install -V
> grub-install (GRUB) 2.04-1ubuntu12
>
> Boot stanza that works in 2.02 but not in 2.04
>
> menuentry "Focal Live ISO" {
> set isofile="/ISO/focal-desktop-amd64.iso"
> loopback loop (hd0,1)$isofile
> linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile
> toram noeject
> initrd (loop)/casper/initrd
> }
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1851311/+subscriptions
>

This is actually going back to my original usage of usb-pack-efi, that is described in post #6 and the following posts of this thread at the Ubuntu Forums,

https://ubuntuforums.org/showthread.php?t=2259682&p=13300523#post13300523

This grub system works in UEFI and BIOS mode. It is developed from a multiboot system for UEFI by Andre Rodovalho.

I will think about including such an option in mkusb. Please consider that you and Sundar are welcome to use this piece of FOSS software in tools that you create and maintain :-)

I rely on being able to boot iso files directly from an internal drive (not using an external usb pen drive). As others have mentioned, if I generate the grub menu from within 19.10, (i.e. using grub 2.04), then mounting iso files fails, and system hangs. Currently I am using Arch as my main system, and it uses grub 2.04, and it is able to boot from iso files of various distros with no problem.

My conclusion would be that it is not a problem of the grub version, but somehow a problem with this particular iteration of ubuntu (i.e. 19.10)

@tsger:
You did not mention if you are booting in BIOS or UEFI mode.
I have only had problem when using both UEFI and Grub 2.04.

@cscameron:

I am booting in UEFI mode.

Also ran into this bug. Only happens when UEFI booting - it works fine when booting via BIOS.

I've got a flash drive I've configured to boot via both BIOS and UEFI mode for booting multiple Linux isos.

Same issue is blocking my work since some weeks now...

Isn't there at least some workaround, e.g. downgrading grub? I urgently need to work around it somehow. If it isn't at least possible to get such things fixed early, Ubuntu is maybe the wrong distribution for real usage...

What additional information do you need? I can even reproduce it easily in my VMs...

@Pino:
Sudodus fix worked for me.
See posts 17 to 21 for workaround.
If you want instructions turning mkusb into an ISO booter let me know.

On Thu, Dec 26, 2019 at 3:00 PM pino <email address hidden> wrote:

> Isn't there at least some workaround, e.g. downgrading grub? I urgently
> need to work around it somehow. If it isn't at least possible to get
> such things fixed early, Ubuntu is maybe the wrong distribution for real
> usage...
>
> What additional information do you need? I can even reproduce it easily
> in my VMs...
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1851311
>
> Title:
> Grub 2.04 Out of memory error, No server error
>
> Status in grub2 package in Ubuntu:
> Confirmed
>
> Bug description:
> Trying to loop mount ISO.
>
> Installed grub 2.04 to flash drive in UEFI mode from 19.10
> Flash drive does not boot and gives Out of memory error & no server
> error. Must load kernel first.
>
> Re-installed grub from 18.04 to same flash drive using same boot stanza.
> Booted without issue.
>
> From 18.04
> fred@Bionic-Z170N:~$ grub-install -V
> grub-install (GRUB) 2.02-2ubuntu8.13
>
> from 19.10
> fred@fred-Z170N-eoan:~$ grub-install -V
> grub-install (GRUB) 2.04-1ubuntu12
>
> Boot stanza that works in 2.02 but not in 2.04
>
> menuentry "Focal Live ISO" {
> set isofile="/ISO/focal-desktop-amd64.iso"
> loopback loop (hd0,1)$isofile
> linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile
> toram noeject
> initrd (loop)/casper/initrd
> }
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1851311/+subscriptions
>

@cscameron:
Yes, I would love to have the instructions for turning mkusb into an ISO booter. I tried to follow your post #21 above, but it wasn't clear. Thank you!

Simple ISO Booter using mkusb.

https://askubuntu.com/questions/1075755/create-bootable-ubuntu-usb-on-a-partition-instead-of-overwriting-the-entire-usb/1080749#1080749

When setting up mkusb select "usb-pack-efi" per post #18 above. It should insure the use of grub 2.02.

More Complex ISO Booter using mkusb

If you wish to add up to 8GB of persistence to each ISO using casper-rw and home-rw files with persistent-path see:

https://askubuntu.com/questions/1183191/handmade-live-usb-multisystem/1184111

https://savannah.gnu.org/bugs/?57322 is the bug on the development team site..

This menu works for me
menuentry "... Gparted live" {
 set isofile="/isos/gparted-live-0.33.0-1-amd64.iso"
 search --set=root --file $isofile
 loopback loop $isofile
 linux (loop)/live/vmlinuz boot='live' union='overlay' username='user' config locales='fr_FR.UTF-8' keyboard-layouts='fr' components noswap noeject toram='filesystem.squashfs' ip='' findiso="${isofile}"
 initrd (loop)/live/initrd.img
}

but the xubuntu's ones don't..

Have a look in casper on the xubuntu ISO.
Confirm your menuentry uses the same as ISO:
vmlinuz or vmlinuz.efi
initrd or initrd.lz

The problem doesn't come from the casper package. The problem is in the grub-efi-amd64-bin package (latest version tested:2.04-1ubuntu16). Actually, it's the file grubx64.efi inside this package (/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi).

menuentry ".. Xubuntu .... test daily" {
 set isofile="/isos/focal-desktop-amd64.iso"
 search --set=root --file $isofile
 loopback loop $isofile
 linux (loop)/casper/vmlinuz iso-scan/filename=$isofile boot=casper noprompt quiet splash --
 initrd (loop)/casper/initrd
}

menuentry ".. Xubuntu Default cd Menu" {
 iso_path="/isos/focal-desktop-amd64.iso"
 export iso_path
 search --set=root --file $iso_path
 loopback loop $iso_path
 root=(loop)
 configfile /boot/grub/loopback.cfg
 loopback --delete loop
}

It doesn't work in 2.04 grub version. So I experienced something.

1- I downloaded the 2.02 grub-efi-amd64-bin package from here:
 https://packages.ubuntu.com/disco-updates/amd64/grub-efi-amd64-bin/download

2- I opened the deb package with my archive manager

3- I extracted the file: grubx64.efi
 (from /usr/lib/grub/x86_64-efi/monolithic/)

4- I launched efibootmgr in a terminal to be sure where to copy it

5- I copied it in the right folder in /boot/efi
 sudo cp grubx64.efi /boot/efi/EFI/xubuntu/.

After that, both menus worked fine (in a 2.02 grub)!

I see some comments here about creating bootable USBs and ways to get around this issue when creating a USB.

However, please note, this also affects booting an ISO directly from disk.

Benoit THIBAUD's suggestion didn't quite work for me.
(See comment 34, https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1851311/comments/34).

However, the boot process did seem to progress a bit further: I was able to see scrolling boot messages printed to the terminal. Previously, I never saw any messages, just a black screen, with the computer completely frozen.

Unfortunately, the boot process eventually ended with the following "BusyBox" error.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      .
      .
      .
    BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu4) built-in shell(ash)
    Enter 'help' for a list of built-in commands.

    (initramfs) Begin: Running /scripts/casper-premount... done.
    Begin: ...waiting for devs... ... done.
    touch: /dev/.initramfs/lupin-waited-for-devs: No such file of directory
    stdin: Invalid argument
    done.
    loop: cant get info on device /dev/loop1: No such device or address
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Although, I couldn't get my computer to boot an ISO located on my disk drive using the file from grub-efi-amd64-bin_2.02, perhaps there is an issue in grubx64.efi, since the boot process did progress further this time.

You aren't gonna eventually fix that, are you?

Please squash this bug before Ubuntu 20.04 LTS is released.

Affects Focal Beta and current daily iso file (2020-04-07)

Booting from iso file is an important way to try (& promote) Ubuntu 20.04. Please make sure that this bug is fixed before the official version is released. Thanks a whole lot!

I can boot iso's with ubuntu 20.04 in legacy mode, but not in uefi mode.
Pc hanging on bios logo with in upper left corner booting in insecure mode
no error codes shown.

Crap :(

Is there a solution for this? We cannot use this ubuntu version on our oem installs for customers as we use a grub2 entry for recovery/reinstall system. This is not booting now. Only in legacy bios mode. But all notebooks have secure boot.

new daily iso 20/4/2020: still not working

This explains why no iso image boots with grml anymore. It worked on any Ubuntu derivatives and now even the Ubuntu 20.04 iso doesn't boot from any iso placed in /boot/grml

Needs to be resolved or we cannot deliver ubuntu 20.04 preinstalled computers.

I cannot boot up from iso and If I do the upgrade from 18.04 then everything messes up.

I started testing binaries from the release history page:
https://launchpad.net/ubuntu/+source/grub2-signed/+publishinghistory

The last working one is:
https://launchpad.net/ubuntu/+source/grub2-signed/1.116
https://launchpad.net/ubuntu/+source/grub2-signed/1.116/+build/17166212/+files/grub-efi-amd64-signed_1.116+2.02+dfsg1-12ubuntu3_amd64.deb

The first broken one is:
https://launchpad.net/ubuntu/+source/grub2-signed/1.117
https://launchpad.net/ubuntu/+source/grub2-signed/1.117/+build/17277557/+files/grub-efi-amd64-signed_1.117+2.04-1ubuntu1_amd64.deb

So indeed 2.02 works and 2.04 doesn't.
I will check if the problem affects other distributions as well.

Debian is affected as well.

Downloaded: http://ftp.us.debian.org/debian/pool/main/g/grub2/grub-efi-amd64-bin_2.04-7_amd64.deb
Extracted: /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi
Tried the command: loopback loop ubuntu.iso

And it hangs.

Fedora doesn't seem to be affected.

From: https://koji.fedoraproject.org/koji/buildinfo?buildID=1499982
Downloaded: https://kojipkgs.fedoraproject.org//packages/grub2/2.04/15.fc33/x86_64/grub2-efi-x64-2.04-15.fc33.x86_64.rpm
Extracted: /boot/efi/EFI/fedora/grubx64.efi
Tried the command: loopback loop ubuntu.iso

And it didn't hang.

A workaround is to run `rmmod tpm` before `loopback loop some.iso`. See the linked Debian bug for more details.

Fedora isn't affected because it doesn't include tpm.

@alkisg Thank you for the workaround, easier that installing grub 2.02 via mkusb.

I put `rmmod tpm` on it's own line in grub.cfg, above the "loopback loop $isofile" line.

Booting BIOS mode grub 2.02 I get "error: no such module" and then after a bit it boots okay.

Booting UEFI mode grub 2.04 it boots with no error messages.

Both modes go to Disk Check.

Neither mode goes to the Try/Install screen when booting, nor to remove drive and press enter when quitting.

@Alkis Georgopoulos,

Thanks for the suggestion.
I added "rmmod tpm".
Unfortunately, it did not really help my situation...

$ sudo update-grub
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Sourcing file `/etc/default/grub'
    Sourcing file `/etc/default/grub.d/init-select.cfg'
    Generating grub configuration file ...
    Found linux image: /boot/vmlinuz-5.3.0-51-generic
    Found initrd image: /boot/initrd.img-5.3.0-51-generic
    Found linux image: /boot/vmlinuz-5.3.0-46-generic
    Found initrd image: /boot/initrd.img-5.3.0-46-generic
    Adding boot menu entry for EFI firmware configuration
    done
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -

$ sudo nano /etc/grub.d/40_custom
$ sudo update-grub
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Sourcing file `/etc/default/grub'
    Sourcing file `/etc/default/grub.d/init-select.cfg'
    Generating grub configuration file ...
    Found linux image: /boot/vmlinuz-5.3.0-51-generic
    Found initrd image: /boot/initrd.img-5.3.0-51-generic
    Found linux image: /boot/vmlinuz-5.3.0-46-generic
    Found initrd image: /boot/initrd.img-5.3.0-46-generic
    Adding boot menu entry for EFI firmware configuration
    done
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -

$ cat /etc/grub.d/40_custom
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    #!/bin/sh
    exec tail -n +3 $0
    # This file provides an easy way to add custom menu entries. Simply type the
    # menu entries you want to add after this comment. Be careful not to change
    # the 'exec tail' line above.

    menuentry "Install" {
        set isofile="/ubuntu.iso"
        rmmod tpm
        loopback loop (hd0,2)$isofile
        linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
        initrd (loop)/casper/initrd
    }
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Prior to this change, I would get a blank screen with a whirring fan.

With the above change, I do see the boot-up log messages.
But, I get a busy box...
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    BusyBox v1.301 (Ubuntu 1:1.30.1-4ubuntu4) built-in shell (ash)
    Enter 'help' for a list of built-in commands.

    (initramfs) Begin: Running /scripts/casper-premount ... done.
    Begin: waiting for devs... ... done.
    touch /dev/.initramfs/lupin-waited-for-devs: No such file or directory
    stdin: Invalid argument
    done.
    loop: can't get info on device /dev/loop1: No such device or address
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I don't know why it is referencing "loop1" ?

I did additional testing, and I can confirm that adding "rmmod tpm" does indeed work...

See comment number 51 by Alkis (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1851311/comments/51).

    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    menuentry "Install" {
        set isofile="/ubuntu.iso"
        rmmod tpm
        loopback loop (hd0,2)$isofile
        linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
        initrd (loop)/casper/initrd
    }
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The Busy Box error I had experienced was actually due to a bad ISO file.

I tested "rmmod tpm" on a system running Ubuntu 19.10.

I tested two official Ubuntu *.iso files:
- Ubuntu 18.04
- Ubuntu 20.04

In both cases, the system successfully booted the specified *.iso.

I have just noticed that casper-rw persistent files are not working with Ubuntu 20.04 when booted from an ISO file.

Persistent partitions are working, however persistent partitions do not work with persistent-path and only one persistent partition is allowed per USB disk.

This means that a multiboot, multipersistence USB drive is no longer possible using ISO files.

Hopefully someone will point out that I am making an error somewhere.

I will fill out a separate bug report when I get time.

It appears that Persistent casper-rw files are not just working with GRUB booted ISO files in BIOS mode, they do not seem to be working with Syslinux boot drives either.

I have just tested BIOS boot of a Persistent UNetbootin USB drive and there is no persistence.

@ C.S.Cameron,

> I will fill out a separate bug report when I get time.

Please post a link here to that separate bug report.

It appears that the reason casper-rw persistent files are not working for me is that their name has been changed in Ubuntu 20.04 to "writable"

Separate bug report at https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1877222

On a previous post I mentioned that I put `rmmod tpm` on it's own line in grub.cfg menuentry, above the "loopback loop $isofile" line and that I got "error: no such module" when booting in BIOS mode.

I have discovered, (after testing the latest mkusb - unstable), that putting `rmmod tpm` up top just above the fi line allows booting ISO's in UEFI mode without getting the no such module error when booting in BIOS mode.

C.S.Cameron,

Would you please paste your grub lines here so we can get the full context?

if loadfont /boot/grub/font.pf2 ; then
 set gfxmode=auto
 insmod efi_gop
 insmod efi_uga
 insmod gfxterm
 terminal_output gfxterm
 rmmod tpm
fi

set menu_color_normal=white/black
set menu_color_highlight=black/light-gray

set timeout=5
menuentry "ubuntu-20.04 ISO" {
    set root=(hd0,3)
    set isofile="/ubuntu-20.04-desktop-amd64.iso"
        loopback loop $isofile
        linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile fsck.mode=skip persistent persistent-path=/ubuntu-20.04/ splash --
        initrd (loop)/casper/initrd
}

Thanks.
It worked for me when I put "rmmod tpm" inside the menuentry section, but I didn't have anything above that section.

So it seems "rmmod tpm" must be one of the first things in the config file.

I wonder if it would work if you put "rmmod tpm" as the 1st line, above "if loadfont..." ?

I'll try moving it above "menuentry Install" in my config file from comment number 54, https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1851311/comments/54, and see if it still works.

(It makes sense that you would want to remove this module as soon as possible).

I notice that with BIOS mode booting, that if rmmod tpm is put in the body of the menuentry, then there is the message "error: no such module", and "Press any key to continue..."

If it is put anywhere above fi the computer boots without an error message.

If it is put anywhere above the menuentry and below fi, we get scrolling "{FAILED} Failed to start Login Service...", etc. (but I have not tried indenting in these locations.

Booting in UEFI mode it seems that anywhere that "rmmod tpm" works in BIOS mode, works for UEFI also.

Oops!

It looks like my "{FAILED} Failed to start Login Service..." was due to snaps eating up all my casper-rw memory.

The ISO persistent USB is booting without error as long as "rmmod tpm" is anywhere above the menuentry when booting either BIOS or UEFI.

Clean 20.04, I confirm the bug.

There is a very simple way to reproduce the bug, **without even booting an O.S.**

- Set your machine to boot in EFI mode
- From the Grub (2.04) Menu, enter command mode (by pressing the key 'c')
- Set the root to where you have your iso files:

For instance:
root=hd1,msdos5

- Then just list one of your Iso file:

ls /path/to/iso/ubuntu-20.04-desktop-amd64.iso
error out of memory

That's it, just 2 commands on Grub to reproduce the bug.

Obviously, since you cannot even list the iso file, there is no way you can loopback on it or boot it.

I also confirm that "rmmod tpm" did the trick and is a valid workaround until a fix arrives.

I also confirm this bug. I used rufus in windows to create my bootable USB with ubuntu live server 20.04.

I also confirm the work around to "rmmod tpm" and I'm off and running.

Thank you all for making this easy to follow!

I suspect this is a duplicate of bug 1878541

@chrisccoulson: they have the same underlying cause, but bug #1878541 is a bug against snapd, which has nothing to do with the problem.

I run into this intermittently from time to time with my loopback USB stick maintenance scripts [1] - including the `ls` "out of memory" test (comment #6, #66) that triggers for files larger than about 100 MB.

I have found a workaround, which is to pass `--no-uefi-secure-boot` and to allow insecure boot from your BIOS. This is possible whilst still using EFI and a GPT partition table, and thankfully so as it seems newer laptops are ditching support for legacy boot from MS-DOS partition tables.

Using the grubx64.efi from older versions of grub (#34, #49, #50) is not a proper sustainable workaround, this file contains a lot of the core logic of grub, and what you are doing is effectively mixing old core logic with newer modules. It may work "by accident" but likely you will (and I did) get extremely strange (undefined) behaviour such as:

- boot loops
- not automatically loading /grub/grub.cfg
- errors about trying to load non-existent /EFI/grub/grubenv instead of /grub/grubenv
- "probe" command not found
- colours looking not how they should look

[1] https://github.com/infinity0/uberimg

The problem with `ls` (I did not have time to test `loopback`) arises directly or indirectly from verifiers logic - if I `set debug=all` then succeeding cases look like:

~~~~
[..]
kern/verifiers.c:??? trying verifier pgp
kern/verifiers.c:??? trying verifier tpm
disk/efi/efidisk.c:???: reading 0x40 sectors at the sector 0x???? from hd0
disk/efi/efidisk.c:???: reading 0x40 sectors at the sector 0x???? from hd0
[..]
disk/efi/efidisk.c:???: reading 0x40 sectors at the sector 0x???? from hd0
disk/efi/efidisk.c:???: reading 0x40 sectors at the sector 0x???? from hd0
commands/efi/tpm.c:???: log_event, pcr = 9, size = 0x???, <FILE BEING LSed>
kern/disk.c:???: Closing `hd0'.
disk/efi/efidisk.c:???: closing `hd0'.
<OUTPUT OF LS>
~~~~

whereas the failing cases with the big files look like:

~~~~
[..]
kern/verifiers.c:??? trying verifier pgp
kern/verifiers.c:??? trying verifier tpm
kern/disk.c:???: Closing `hd0'.
disk/efi/efidisk.c:???: closing `hd0'.
kern/disk.c:???: Closing `hd0'.
disk/efi/efidisk.c:???: closing `hd0'.
out of memory
~~~~

Unfortunately I'm unable to test further, because booting with an unsigned grub (as per --no-uefi-secure-boot) makes the problem go away, and I don't have the keys to boot with a signed grub.

The whole concept of "UEFI secure boot" seems to have spawned a cancerous mass of overengineered crap around it, the only use case it's good for is against a remote attacker that already has the ability to tell your device to reboot, otherwise a local attacker can just disable it through BIOS. It should be OFF BY DEFAULT, and only users/admins who understand and care about that attack mode can enable it, instead of causing headaches for the rest of us.

This bug is *not* a duplicate of 1878541 and has *NOT* been fixed in the latest release, version 2.06.