Launch installer from GRUB

I have a computer that already has Linux on it, and I’d like to put installer files on the spare space on the hard drive, and then boot into the installer without doing boot-from-USB (or netboot, or optical media).

I tried following the instructions found on Installation/FromLinux - Community Help Wiki

It booted, but then got into what appeared to be an infinite loop of searching for /dev/sr0 and /dev/sdb (IIRC).

So, my questions are:
Should I expect this to work with 24.04 (and do more troubleshooting) or is that page outdated?
Is there another document I should be reading?
Can anyone here report a “I’ve done this recently; this worked for me”?
Which installer image is most likely to work with this install method? (I’m aiming for a minimal install – I used one of the server ISOs)

You have a couple of issues, with one drive.

You cannot edit partitions from working system. How are you going to modify partitions, or are you just wanting to install into existing partition. Even then if install fails for any reason, you have an unbootable system and no way to repair it. Always have a live installer, just for repairs, if needed.

If you boot using grub, the partitions you boot from cannot be changed by installer. And if grub install fails you have a non-bootable system.

I always have multiple repair/recovery flash drives like this:
https://discourse.ubuntu.com/t/beyond-grub-usb-stick-with-refind/67747
or
https://discourse.ubuntu.com/t/emergency-repair-disk/67791

You can use grub to boot ISO directly, or boot an extracted ISO.
You can create a FAT32 file as new ESP - efi system partition and directly boot using UEFI one time boot, an extracted ISO from that partition. But if issues with install & changing ESP back to the one you really want is often an issue, requiring terminal to unmount & remount correct ESP for new install.

I use grub to boot ISO on another drive, originally one of my many flash drive, but sometimes from HDD to install into SSD or from SSD to install into HDD as test install.

I have a folder /ISO where I store all my ISO and a file with boot stanzas that I call (configfile) from my standard grub to boot any of my ISO. Have not yet updated to latest ISO. The toram parameter may allow you to manually unmount partitions, but again any failure will require a repair flash drive.

menuentry "Kubuntu 24.04.2 Noble ISO" {
	set isofile="/ISO/kubuntu-24.04.2-desktop-amd64.iso"
	loopback loop (hd1,5)$isofile
	    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile toram noeject
	    initrd (loop)/casper/initrd
}

more examples:
https://help.ubuntu.com/community/Grub2/ISOBoot
https://help.ubuntu.com/community/Grub2/ISOBoot/Examples

1 Like

Just to give an idea of my experience level:

I have done this sort of thing many times with other distros. I am well aware of the not-ubuntu-specific issues that can arise.

I think you mean should not here.

You definitely can edit partitions from a working system, with certain limitations – I’ve done it many times – it’s not even a hacker-level task. If you have unpartitioned space on your hard drive (on the computer I started this thread for, I do), fdisk or parted will easily add partitions to that unpartitioned space. The majority of my experience is with MBR-style partition tables and usually the unpartitioned space was inside an extended partition. The computer that is the subject of this thread happens to fit that description.

I’ve also modified unmounted partitions living on the same HD as my currently mounted root partition.

Warnings such as “don’t do this if uptime is important or you have valuable not-backed-up data on the hard drive” apply, and are sometimes emitted by partitioning tools when I do this.

Hmm… this is some interesting info – rather different method than the one suggested in the page I referred to in the original link. I’ll have to give them a try.

Okay, tried again, this time with a menuentry modeled after the one oldfred posted, and got the same problem.

grub entry:

menuentry "Ubuntu Installer2" {
        load_video
        gfxmode $linux_gfx_mode
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root=(hd0,10)  # partition just for ISOs
        loopback loop /ubuntu-24.04.3-live-server-amd64.iso
        linux (loop)/casper/vmlinuz boot=casper ignore_uuid
        initrd (loop)/casper/initrd
}

grub successfully boots the kernel, and after a few pages of bootup message scroll, the following messages keep repeating (not always in the same order):

/init: line 38: can't open /dev/sdb
/init: line 38: can't open /dev/sr0

Correction/Oops: the problem was in my grub config file. I had omitted the “iso-scan” kernel argument. Adding it in made the problem go away, and the installer booted successfully.

I should go update some wiki pages.

You may use grml-rescueboot. Install with sudo apt install grml-rescueboot
Put the ISO on your disk /boot/grml/ do update-grub and at next boot you will find an entry in your grub menu.
You may also edit /etc/default/grml-rescueboot to use your Download folder:

## Configuration file for Debian package grml-rescueboot.

# Location of ISOs:
# ISO_LOCATION="/boot/grml/"
ISO_LOCATION="/home/corrado/Downloads/"
....

You may put many ISO in your folder ans select from grub menu

corrado@corrado-n3-qq-0918:~$ sudo update-grub

Found Ubuntu 24.04.2 LTS (24.04) on /dev/sda2
Adding boot menu entry for UEFI Firmware Settings …
Found grml-rescueboot ISO image: /home/corrado/Downloads//qq-0926.iso
done
corrado@corrado-n3-qq-0918:~$

2 Likes

So… I solved my problem yesterday, but I still find this interesting, and others may find it useful.

I’ve never heard of Grml (not an acronym (“GRUB Rescue Markup Language”?), apparently) or grml-rescueboot before.

So will grml-rescueboot include all ISOs in the directory when generating the GRUB config, or does it look specifically for grml ISOs ?

I did not find the answer in a quick survey of the grml-rescueboot webpage.

But on further exploration, I did find this issue requesting support for fedora ISOs, which suggests that supporting non-grml ISOs is a non-trivial feature.

It will indeed. I just used it for all of the beta .iso images and put them in a partition that mounts to /boot/grml.

1 Like

Yes, you may put many ISOs in the directory you want, this is the reason i renamed the iso as qq-0926.iso to remember is the ISO dated 0926.
I’m using grml-rescueboot to install all the ISO during the development
https://iso.qa.ubuntu.com/qatracker/milestones/474/builds/340594/testcases/1761/results
I prefer to modify the /etc/default/grml-rescueboot to use my Dowload folder so i download the image and can boot directly avoiding copy to /boot/grml/

But, according to the bug report I linked above, it doesn’t work for Fedora ISOs.

Which suggests that it will attempt to add every ISO it finds, but doesn’t do anything different for different ISOs ? Trying to boot all of them as if they boot the same way as grml ISOs?

But you’ve found that they work just fine for Ubuntu ISOs?

Can anyone (with minimal effort, because with a half-hour effort I could probably figure it out myself) provide a sample/example of a grml-rescueboot -generated GRUB stanza ?

see: https://discourse.ubuntu.com/t/booting-iso-from-dasd/68234/4

I used grml-rescueboot for all the Ubuntu ISOs from 24.04 and also for Debian, Xubuntu and Lubuntu. Yesterday also for an ISO from Index of /daily-dangerous

Okay… if I follow your link from there, it appears that the GRUB stanza generated is

menuentry "Ubuntu 25.10 amd64 (qq-daily-0905.iso)" {
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root 71efd792-74b7-41d1-ad3a-8d9004fd3cda
        iso_path="/home/corrado/Downloads/qq-daily-0905.iso"
        export iso_path
        kernelopts="   "
        export kernelopts
        # support booting recent GRUB versions on UEFI systems
        # (see bugs.debian.org/959425)
        rmmod tpm
        loopback loop "$iso_path"
        set root=(loop)
        configfile /boot/grub/loopback.cfg
        unset root
        loopback -d loop
        unset iso_path
        unset kernelopts
}

And there’s probably some key details in /boot/grub/loopback.cfg – which is a file I’m not familiar with.

It sounds like this grml uses the same general iso-booting system as the suggestion that oldfred posted earlier in this thread:

  1. Mount the ISO as a loopback filesystem
  2. read the filesystem and find the kernel and ramdisk image in there
  3. load the kernel it found, and pass it the appropriate kernel command-line options

The challenges that I imagine are knowing where to find the kernel and ramdisk, and knowing if the kernel needs any special command-line options. I’m guessing that Ubuntu and Grml are similar enough that the same answers apply in both instances. But apparently that’s not the case for Fedora. And definitely wouldn’t work for a non-linux ISO.

I was wondering if it was going to be something like:

  1. Search the ISO for a standard El-Torito section
  2. Run (“chainload”?) the standard El-Torito section

That would be cool because then it would work for any ISO that uses an El-Torito boot system (is El-Torito still as ubiquitous as it used to be?) no matter what OS it booted.

You may use also /etc/grub.d/40_custom as explained in Grub2/ISOBoot - Community Help Wiki

The grub2 loopmount stanza I use does not use the /boot/grub/loopback.cfg which is a file inside the ISO. Probably a better way.
I sometimes have had to open ISO to find boot parameters to get grub boot stanza parameters or details to get it to work.
I have used grub2 to boot Debian & Fedora.

For newer users I find the set up of Ventoy to be easier and it boots just about anything. I still use grub2, but created a Ventoy flash drive which also boots Windows.

https://discourse.ubuntu.com/t/emergency-repair-disk/67791

This topic was automatically closed after 30 days. New replies are no longer allowed.