Boot iso from hard drive

I am trying to boot a Rocky iso from a hard drive. I have been using Rocky-9-Workstation-d86_64-latest.iso. The iso file is installed in the root of the third partition. This is a regular linux partition with an ext4 file system. It has no other files. My grub2 menuentry is:

menuentry ‘Rocky Linux’{
set isofile=“/Rocky-9-Workstation-x86_64-latest.iso”
insmod ext2
insmod loopback
insmod iso9660
loopback loop (hd0,gpt3)$isofile
set root=(hd0,gpt3)
search --no-floppy --fs-uuid --set=root f35ce20e-813e-4caf-8e7c-d86124d9a637
linux (loop)/isolinux/vmlinuz noconfig=sudo username=root hostname=GraceDev4
initrd (loop)/isolinux/initrd.img

The system goes through the first part of the boot and then complains that “Switch Root” failed.

The uuid belongs to /dev/sda3 (the disk that holds the iso) as shown by blkid.

If I burn the iso to a usb stick then it boots successfully. Any suggestions would be most welcome.

I don’t understand how an iso file can be buried in an ext4 partition, other than as a huge regular file, or do you mean as individual files within the ext4 system? Did you perhaps use image restore to place the iso? Is this supposed to be BIOS boot or UEFI? If UEFI, the Rocky iso might use a second partition (inside the iso). Check the usb version you created to see if there’s a partition table, what type is it, and how many partitions are there?

1 Like

Hi Gerry, I’m afraid I’m much too ignorant. I downloaded the iso file from Rocky’s website (using a Windows machine). I then used parted to create an empty partition and installed an ext4 file system on it. Then I transferred the downloaded file to the new partition using scp. The file is about two GB.

I can issue all of the commands in my menuentry from the Grub console and get no errors but when I boot I fail at the point where it is trying to Switch Root.

I’m using an EFI boot.

I’ve edited my first answer, please re-check.

What is the reason for doing this? The bootable Rocky iso is usually for installing a new o/s, or for troubleshooting, but I can’t think what you would do booting into this from a hard drive? Is it going to be a “live cd” with some kind of persistence?

I’m doing this because I want to install Rocky 9 on a server that is currently running Rocky 8. The server is several hundred miles away and I can access it via SSH and I can get a terminal to control the boot process but I do not have any easy physical access. In other words it would be very inconvenient to physically install a USB stick. Thus I want to boot from an ISO file on a hard drive.

I have issued all of the commands in my menu entry except that I substituted “set root=bill” for “set root=(hd0,gpt3)”.

After the search command I found that “echo $root” gave me “hd0,gpt3”, which seems correct?

The iso file has a directory LiveOS, which contains a single file squashfs.img. I suspect that that is the one I ought to be finding with the search command. Is there some other way to identify this file to grub?

Your grub entry looks incorrect. Identifying the squashfs.img is also not going to lead you to the result that you’re expecting. Perhaps consider something like the below.

menuentry 'Rocky Linux 9 Workstation' --class fedora --class gnu-linux --class gnu --class os {
  insmod ext2
  insmod loopback
  insmod iso9660
  set isofile="/Rocky-9-Workstation-x86_64-latest.iso"
  loopback loop (hd0,gpt3)$isofile
  linux (loop)/isolinux/vmlinuz root=live:CDLABEL=Rocky-9-3-Workstation verbose iso-scan/filename=$isofile
  initrd (loop)/isolinux/initrd.img

No Joy. I’m going to try to extract squashfs.img and place it in the root of hd0,gpt3, and then set root accofdingly. I’ll report back if that works.

KVM over ethernet? (Wish I had one, but Dell servers [can] have iDRAC for similar use.)

I have occasionally considered copying vmlinuz and initrd from install media to running system and adding a new entry to grub menu. (I have more than one machine though and PXEboot as an option.)

One needs the packages too, which one could expand to that ext4 filesystem, so there would be no need for the loop mount. Alternatively, use nearest Rocky mirror from network. That is what the small install image does anyway.

Lets play what if?:
You manage boot and start installation. Installation writes new /boot (and /boot/efi or sector 0). But something goes wrong – there is always a chance for that. Can you still boot the installation, again?

First the what if?: I have a supposedly identical machine at home that I’m using for testing. If all else fails, I’ll have to get somebody to insert a USB stick for me and start over! This is my fifth iteration installing a new operating system and it has NEVER gone smoothly :slightly_smiling_face:

I extracted the squashfs.img file from the ISO and put it in the root of a partition. “search” found the right partition but the system still wouldn’t boot.

I found some other instructions for a different approach to booting from an ISO and I’m going to try them. If all else fails, I’ll switch to Debian and try their ISO!

Oh, and you are quite right; IDRAC and a Dell server. I couldn’t find any way to use the PXEboot. Probably I gave up too easily.

Take a look at this post on Fedora.

It discusses some options for remote install that may or may not be useful.

Look at the Ventoy project. Ventoy
It search for .iso and other images on flash or hdd/ssd drive and boot it. It is based on grub2 and might you’ll find anything useful.

I did successfully boot iso from hard drive
ISO stored at the root of /dev/sda5
I have removed execution from /etc/grub.d/30_os-prober (I don’t need to search installed OSes on disk)
added menuentry to 40_custom. Updated config with grub2-mkconfig -o /boot/efi/EFI/rocky/grub.cfg

For Rocky Linux menu entry is

menuentry "Rocky 8.9" {
  insmod part_gpt
  insmod ext2
  insmod loopback
  set isofile="/Rocky-8.9-x86_64-minimal.iso"
  loopback loop (hd0,gpt5)$isofile
  linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:/dev/sda5:$isofile
  initrd (loop)/isolinux/initrd.img

Fedora Live
first I have mounted iso to get correct label and path to vmlinuz/initrd.img

blkid|grep loop
/dev/loop0p1: BLOCK_SIZE="2048" UUID="2023-11-01-01-22-57-00" LABEL="Fedora-Xfce-Live-39-1-5" TYPE="iso9660" PARTLABEL="ISO9660" PARTUUID="ac768486-64a1-4ea9-a3f6-e81c65a76afd"
/dev/loop0p2: SEC_TYPE="msdos" LABEL_FATBOOT="ANACONDA" LABEL="ANACONDA" UUID="870D-0C07" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Appended2" PARTUUID="ac768486-64a1-4ea9-a3f5-e81c65a76afd"
/dev/loop0p3: PARTLABEL="Gap1" PARTUUID="ac768486-64a1-4ea9-a3f4-e81c65a76afd"

find -type f|grep 'vmlinuz\|initrd.img'
menuentry 'Fedora Live' {
  insmod part_gpt
  insmod ext2
  insmod loopback
  set isofile="/Fedora-Xfce-Live-x86_64-39-1.5.iso"
  loopback loop (hd0,gpt5)$isofile
  linux (loop)/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-Xfce-Live-39-1-5 verbose iso-scan/filename=$isofile
  initrd (loop)/images/pxeboot/initrd.img
1 Like

Thank you, thank you, thank you. That worked. I have been trying to do this for close to a month now and I tried all sorts of menuentries. I suspect that the key was inst.stage2=hd:/dev/sda1:$isofile. I have learned a lot but I still don’t really understand what’s going on :slight_smile:

I think those vmlinuz options are distro specific. For RHEL tree info is here Chapter 23. Boot Options Red Hat Enterprise Linux 7 | Red Hat Customer Portal
Yesterday just for fun I tried inst.vnc inst.vncconnect=ip:port - it works :slightly_smiling_face:

The kernel is not the only one that may “consume” cmdline options. Dracut, systemd, and (in case of install media) the installer application read them too. What syntax each of them looks for to spot “this option is for me” is evolving.

Thanks to borispr I can now boot from a Rocky iso. Now I am trying to add a kickstart file. I used the kickstart file in /root and added it to my iso using the following command:

mkksiso /path/to/kickstart /path/to/iso /path/to/output.iso

This seemed to work properly, but when I boot from the new iso I get the error message:

"error: …/…/grub-core/script/function.c:119: can’t find command ‘Anaconda’. That seems peculiar since the boot without the kickstart file works ok. Any suggestions?

Oops. To quick. The “can’t find command ‘Anaconda’” error was due to a typo. Now the boot proceeds normally but the kickstart file isn’t effective. Do I have to follow some other procedure to incorporate it in the iso?