Grub used to mount and test isos not working in eoan

OK, I am sure mine is a non-typical use case, but here goes anyways: I use grub to mount and test iso files all the time. This saves me writing multiple usb sticks over and over again, and is a very efficient method, in my opinion.

When I try to mount these iso files from the UM 19.10 beta grub menu, all I get is a blank grey screen.

When mounting these from within the grub menus of other distros, e.g. MX or Arch, the iso files boot up without a problem.

Any ideas?

I do the same Tstechy and altered my live cd to get eoan-desktop-amd64.iso to boot. It did not and instead gave me the following error message:

error: file '/casper/vmlinuz.efi' not found.
error: you need to load the kernel first.
Press any key to continue...

Looking at the 19.10 boot menu, I see it has several files that 18.04 and 16.04 do not have. This may be a beta issue and it may be some improvement in grub.

Maybe you can download and pre-install Casper into your live cd ???

Hi, mdooley,

Actually for me, the issue is trying to boot any iso from grub. I can do it successfully from the grub menu of older ubuntu releases, including being able to boot the beta iso from the grub generated from within 19.04, e.g.

I’ve also discovered the same problem with kubuntu 19.10 beta.

Running Ubuntu-MATE 19.10 beta. I just changed the live cd iso to 16.04.1, rebooted and it apparently works. Here is what I have as that part of my custom grub -

menuentry "live CD (on /dev/sda6)" {
set isofile="/Iso/-amd64/ubuntu-mate-16.04.1-desktop-amd64.iso"
loopback loop (hd0,6)$isofile
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile quiet splash video=SVIDEO-1:d
initrd (loop)/casper/initrd.lz
}

Good luck Tstechy.

Edit: A little testing showed me that I was able to change the live cd iso names on the fly and boot into them. Sometimes I had to edit the vmlinuz.efi to just vmlinuz and the live boot would proceed.

However, nothing I could do would get grub to mount either the eoan-desktop-amd64.iso or the ubuntu-mate-19.10-beta-desktop-amd64.iso appeared to work. Sometimes I would get a kernel panic using the vmlinuz edit when I pressed any key. See below as an example:

menuentry "live CD (on /dev/sda6)" {
set isofile="/Iso/-amd64/eoan-desktop-amd64.iso"
loopback loop (hd0,6)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet splash
initrd (loop)/casper/initrd.lz
}

Kernel panic...

1 Like

Hey, @mdooley, thanks for the responses.

My problem is when I am using the grub menu that is generated by eoan, not when I am trying to boot into eoan.

  1. I install eoan, no problem.
  2. In eoan, I customize the 40_custom file located in /etc/grub.d/ using the syntax you described.

in my case, it looks like this (as an example. I could use any other distro to boot, such as Arch or something else):

menuentry "My Newest Ubuntu Daily Build" {
set isofile="/home/<myusername>/Downloads/eoan-desktop-amd64.iso"
loopback loop (hd0,1)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=/home/todd/Downloads/eoan-desktop-amd64.iso noprompt noeject quiet splash
initrd (loop)/casper/initrd
}
  1. I reboot and try to boot into this iso (or any other iso, for that matter).
  2. Screen is blank. No error, no grub prompt, unable to change to other TTY, nothing. Only option is to Ctrl+Alt+Delete to restart.
  3. My conclusion is that there is something with the way eoan boots different iso files from grub. Not the entries themselves, because they boot fine when I start with any other distro.

I hope what I am describing makes sense.

Yes, you do make sense. In my case I mount the isofile from a separate data partition as you might see from my post above - /dev/sda6 instead of from a eoan installation. I will try your initrd line next (omitting the .lz) and report back.

OK, this time I tried something a little different and was able to boot the 19.10 live CD.

menuentry "live CD (on /dev/sda6)" {
set isofile="/Iso/-amd64/eoan-desktop-amd64.iso"
loopback loop (hd0,6)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet splash
initrd (loop)/casper/initrd
}

Please note that I booted the 19.10 iso from my data partition. Rebooting from this iso appeared to take more time that other ubuntu MATE isos.

This morning I booted into the eoan live CD thusly:

menuentry "live CD (on /dev/sda8)" {
set isofile="/home/michael/Public/eoan-desktop-amd64.iso"
loopback loop (hd0,8)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet splash
initrd (loop)/casper/initrd
}

I think your problems stem from your fourth line where you specify the filename with no quotes around /home/todd/Downloads etc. Or you could just substitute my fourth line.

Either way, grub does work to mount isos irregardless of where they are mounted from.

No, I have no problem booting into eoan from grub...as long as I start from a different distro.

Steps to reproduce my problem:

  1. Install any version of 19.10.
  2. Once in 19.10, create the boot entry for another iso. I have created entries for ubuntu, arch, and mx iso files. sudo update-grub.
  3. In 19.10, reboot.
  4. Once grub appears, none of the iso entries will boot. Not ubuntu, not arch, not mx.

Interestingly, it works in virtualbox. Strange.

Strange indeed. I boot into UM 16.04, UM 18.04, eoan live CD, Partition Magic and Windows all from 19.10. YMMV.

19.10 can't loop mount an ISO and boot it in UEFI mode.

Bug report: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1851311

Glad to see I am not the only one experiencing this problem. I hope the devs can look into this.

Today I booted an ISO from 20.04 focal.

menuentry "live CD (on /dev/sda6)" {
set isofile="/Iso/-amd64/focal-desktop-amd64.iso"
loopback loop (hd0,6)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet splash
initrd (loop)/casper/initrd
}

I realize this is from focal and not eoan but my ISOs seem to work.
Good luck @Tstechy.

So you installed focal, then generated this grub entry from within focal?

Just the same as I previously did with eoan Tstechy.

MBR, or UEFI? I am trying it in UEFI.

MBR if I remember correctly. I’ll check it in UEFI in the New Year.

Edit: January 10, 2020. My potential UEFI machines were set to legacy boot (MBR) and are therefore useless to check out in UEFI. Sorry Tstechy.

Just to make sure I'm tracking this correctly: MBR and GPT are drive partitioning options. Legacy and UEFI are booting options.

19.10 can boot a mounted ISO when booted in legacy mode but not UEFI mode in my admittedly limited experience.

Is MBR also part of the equation?

Just confirming this is still a bug as of April 15, 2020, using daily releases.