You are not logged in.
I am tried to boot iso image from hard drive via grub but got error: disk /loopback.c: delete_loopback:67: device not found. Prev i just downgrade grub package and all works. But now i dont remember what old package version was working. How to fix it without downgrading grub package?
Offline
Same issue on eos, debian-testing
Offline
Prev i just downgrade grub package and all works. But now i dont remember what old package version was working.
/var/log/pacman.log knows
If the downgrade helps, please record the functional version. Otherwise
I am tried to boot iso image from hard drive via grub
please post your grub.cfg
Offline
Prev i just downgrade grub package and all works. But now i dont remember what old package version was working.
/var/log/pacman.log knows
If the downgrade helps, please record the functional version. Otherwise
I am tried to boot iso image from hard drive via grub
please post your grub.cfg
Can you boot any iso image from grub with loopback from hard drive?
Offline
grub 2:2.14-1
Infos: Myself use btrfs AND my /boot folder is on the btrfs root device. My small ESP contains only the grub efi binary.
So my path entries contain /@/path_to.
Modify for your setup.
My iso images are in /boot-isos on btrfs root, so you may have to modify your paths according your setup
I try according like https://wiki.archlinux.org/title/Multib … ot_entries
I boot 2 iso images:
a) grml
https://download.grml.org/grml-full-2025.12-amd64.iso
/boot/grub/grub.cfg
menuentry "Grml Rescue System (grml-full 2025.12)" {
insmod part_gpt
insmod btrfs
iso_path="/@/boot-isos/grml-full-2025.12-amd64.iso"
export iso_path
search --no-floppy --set root --file "$iso_path"
kernelopts=" ssh=password toram "
export kernelopts
loopback loop "$iso_path"
set root=(loop)
configfile /boot/grub/loopback.cfg
}This boots perfectly and is usable
b) Archlinux install iso
menuentry '[loopback]archlinux-2026.03.01-x86_64.iso' {
insmod part_gpt
insmod btrfs
set iso_path='/@/boot-isos/archlinux-2026.03.01-x86_64.iso'
export iso_path
search --set=root --file "$iso_path"
loopback loop "$iso_path"
set root=(loop)
configfile /boot/grub/loopback.cfg
#loopback --delete loop
}This iso image boots perfectly (I see the uefi grub(?) menu) and could use ex. the memtest86
But: if i select to boot the archlinux setup entry it starts but break, see this picture:
https://paste.c-net.org/FlushLeukemia
But it seems (in an "own" hook ?) to setup another loopback device instead using the provided from main grub???
I work on this, the /boot/grub/loopback.cfg on the iso looks IMHO ok... Currently not my main project, i have not looked further now.
But you may get a inspiration...
Last edited by GerBra (2026-04-22 13:39:57)
My avatar: "It's not just a toilet... a FERGUSON. The King of bowls. Sit down and give me your best shot." Al Bundy
Offline
grub 2:2.14-1
Infos: Myself use btrfs AND my /boot folder is on the btrfs root device. My small ESP contains only the grub efi binary.
So my path entries contain /@/path_to.
Modify for your setup.
My iso images are in /boot-isos on btrfs root, so you may have to modify your paths according your setup
I try according like https://wiki.archlinux.org/title/Multib … ot_entriesI boot 2 iso images:
a) grml
https://download.grml.org/grml-full-2025.12-amd64.iso
/boot/grub/grub.cfgmenuentry "Grml Rescue System (grml-full 2025.12)" { insmod part_gpt insmod btrfs iso_path="/@/boot-isos/grml-full-2025.12-amd64.iso" export iso_path search --no-floppy --set root --file "$iso_path" kernelopts=" ssh=password toram " export kernelopts loopback loop "$iso_path" set root=(loop) configfile /boot/grub/loopback.cfg }This boots perfectly and is usable
b) Archlinux install iso
menuentry '[loopback]archlinux-2026.03.01-x86_64.iso' { insmod part_gpt insmod btrfs set iso_path='/@/boot-isos/archlinux-2026.03.01-x86_64.iso' export iso_path search --set=root --file "$iso_path" loopback loop "$iso_path" set root=(loop) configfile /boot/grub/loopback.cfg #loopback --delete loop }This iso image boots perfectly (I see the uefi grub(?) menu) and could use ex. the memtest86
But: if i select to boot the archlinux setup entry it starts but break, see this picture:
https://paste.c-net.org/FlushLeukemia
But it seems (in an "own" hook ?) to setup another loopback device instead using the provided from main grub???
I work on this, the /boot/grub/loopback.cfg on the iso looks IMHO ok... Currently not my main project, i have not looked further now.But you may get a inspiration...
downgrading package grub (2:2.14-1 => 2:2.12.r292.g73d1c959-1)
Iso images are located on separate ssd with ext4. Now i can boot any iso image via grub from hard drive with loopback.cfg
for linux mint:
menuentry "linuxmint" {
iso_path="/linux/linuxmint23/linuxmint-22.3-xfce-64bit.iso"
export iso_path
search --set=root --file $iso_path
loopback loop $iso_path
root=(loop)
configfile /boot/grub/grub.cfg
loopback --delete loop
}
Offline
When maintainers will fix it?
Offline
when someone has reported a proper issue: https://gitlab.freedesktop.org/gnu-grub … work_items
Offline
Iso images are located on separate ssd with ext4.
Does booting images (eg. tinycore will likely not be a problem itr) from the boot partition work and does it help to explicitly insmod part_gpt/ext4?
Is the separate disk SATA or USB?
Then that's not your grub.cfg but some random snippet and on a formal note, please use [code][/code] tags and avoid bloating the thread with mindless full-quotes of previous posts.
Offline
FTR.
This menuentry now boots also perfectly the current archlinux iso:
menuentry '[loopback]archlinux-2026.03.01-x86_64.iso' {
insmod part_gpt
insmod btrfs
set iso_path='/@/boot-isos/archlinux-2026.03.01-x86_64.iso'
export iso_path
search --set=root --file "$iso_path"
probe -u --set=archiso_img_dev_uuid $root
export archiso_img_dev_uuid
loopback loop "$iso_path"
set root=(loop)
configfile /boot/grub/loopback.cfg
}Now i could not even boot the iso from system-grub, i also could start (via iso-grub) the archlinux iso (install) system.
The (iso) grub boot entry expects two variables:
iso_path : path to the archlinux.iso
archiso_img_dev_uuid : the UUID of the device where $iso_path gets found.
With these exported values the (iso)grub boot entry will generate the correct linux <options> line, the (iso) hooks then setup their own loopback.
This differs a bit from mentioned wiki page https://wiki.archlinux.org/title/Multib … ot_entries
Maybe because the archiso releng structure are now different?
And: All my mentioned iso boots works with current grub package 2:2.14-1. I don't have to downgrade something.
//Edit: @pure71453
You say you have to downgrade grub package. Have you checked what version is currently installed as your grub bootloader (on the device!). Look at the top version string of your bootloader. Maybe the installed one is too old (not compatible ?) with the current grub package version...
Last edited by GerBra (2026-04-23 10:48:46)
My avatar: "It's not just a toilet... a FERGUSON. The King of bowls. Sit down and give me your best shot." Al Bundy
Offline
FTR.
This menuentry now boots also perfectly the current archlinux iso:
menuentry '[loopback]archlinux-2026.03.01-x86_64.iso' { insmod part_gpt insmod btrfs set iso_path='/@/boot-isos/archlinux-2026.03.01-x86_64.iso' export iso_path search --set=root --file "$iso_path" probe -u --set=archiso_img_dev_uuid $root export archiso_img_dev_uuid loopback loop "$iso_path" set root=(loop) configfile /boot/grub/loopback.cfg }Now i could not even boot the iso from system-grub, i also could start (via iso-grub) the archlinux iso (install) system.
The (iso) grub boot entry expects two variables:
iso_path : path to the archlinux.iso
archiso_img_dev_uuid : the UUID of the device where $iso_path gets found.
With these exported values the (iso)grub boot entry will generate the correct linux <options> line, the (iso) hooks then setup their own loopback.This differs a bit from mentioned wiki page https://wiki.archlinux.org/title/Multib … ot_entries
Maybe because the archiso releng structure are now different?And: All my mentioned iso boots works with current grub package 2:2.14-1. I don't have to downgrade something.
//Edit: @pure71453
You say you have to downgrade grub package. Have you checked what version is currently installed as your grub bootloader (on the device!). Look at the top version string of your bootloader. Maybe the installed one is too old (not compatible ?) with the current grub package version...
Grub version was latest 2.14-1 (arch/eos) and grub 2.14 was on debian testing and also latest. I even format uefi partitons(each my linux systems got own partiton) for arch/eos/debian-testing. Then i boot from live iso, chroot into system, reinstall latest grub package, install grub bootloader, generate grub configfile, set correct new uuid for each efi partitions in fstab. But it didnt help anyway. Just for testing i wiped debian-testing and install mint 22.3. Linux mint allow me to boot from loopback cuz it use grub 2.12 package.
Offline
@pure71453
//Edit: PLEASE: (as others mentioned also!) use code-tags for outputs AND don't do full quotes of previous postings. Quote only parts to which you want to answer something (in context)!
There is definitely something wrong with grub's search function when used to search for files (search --files or search.files).
I tried the linuxmint-22.3-xfce-64bit.iso myself with different grub versions:
- grub 2.14.1
- grub 2_2.12.r418.g6b5c671d-2
Myself could start the mint iso on BOTH grub versions ONCE, directly after a fresh boot. Same menuentry, using search --file.
But: using the grub command shell to modify/test things i found that the search function fail most times when searching for (the iso) files.
Sometimes it found (as test) the archlinux iso in the session, then not (device not found), same session. I never could found the linuxmint iso again if the first attempt fails.
First i thought it could be the pure size of the iso (mint is 2.9G, archlinux 1.5G. But using file search with archlinux iso it also failed for further tries. And i always unset the root variable.
//Edit2: This happens both in 2.12 and 2.14 for me.
The reason for using this search function is to find the grub device notation where our iso files reside (ex. (hd0,gpt1). Even when the device order is not persistent.
Cause in my research the search for files in grub often fails i would prefer a search on labels or uuids. This always works. It needs a second variable set in menuentry (iso_dev_label or iso_dev_uuid)
Booting a iso via loopback in grub works like this:
- set an iso_path to the iso file
- grub needs a variable named root point to the grub device where the iso_path file is found.
- We set this root variable with grub's search function (either by --file (which fails) or --label or --fs-uuid)
- the loopback function **needs** the correctly initialized root variable to set its named loop device to the file iso_path!
- we have to set now the new root to the (loop) device
- configfile /boot/grub/loopback.cfg starts the iso real on (loop)/boot/grub/loopback.cfg (which is real (hdX,Y)/iso_path(loop)/boot/grub/loopback.cfg)
So you have to get either the label or uuid of your blockdevice where your directory with iso images is saved. Look with:
lsblk -fto get these values.
Then modify/set your grub menuentry like this:
(I use YOUR provided example from above as base)
menuentry "linuxmint" {
iso_path="/linux/linuxmint23/linuxmint-22.3-xfce-64bit.iso"
export iso_path
# set both variables according what lsblk -f shows you. Use either the label or uuid method.
# Here the label mehod is active (not commented)
iso_dev_label="the_label"
search --no-floppy --set root --label $iso_dev_label
# uuid method: currently disabled
#iso_dev_uuid="12345-the_uuid"
#search --no-floppy --set root --fs-uuid $iso_dev_uuid
loopback loop $iso_path
set root=(loop)
configfile /boot/grub/grub.cfg
loopback --delete loop
}This approach should work on grub 2.14 and 2.12. You could start the ISO-Boots now often from your system grub, means: start linuxmint entry you see the linuxmint grub. ESC brings you back to the system grub. You could start it again now. Or something other.
tl;dr
Don't rely on grub's search --file <name> function. It fails often, maybe a memory allocating thing. The bigger the file you want to "find" the often it failed.
Use search --label or --uuid instead.
Last edited by GerBra (Today 16:15:57)
My avatar: "It's not just a toilet... a FERGUSON. The King of bowls. Sit down and give me your best shot." Al Bundy
Offline
just to: if you want to search for a file don't search for 1gb+ iso directly but place an empty marker file instead - haven't tested myself but if the file size matter for some reason this could be as reliable as search for label or uuid
Offline
but place an empty marker file instead
This is worth to test it, thanks. It would be better than evolving new variables to set by the user....
//Edit: This works also, eg. we could use the search --file approach (again) also
touch /boot-isos/boot_iso_dirI modified my /etc/grub.d/40_custom like this:
iso_dir_marker_file="/@/boot-isos/boot_iso_dir"
export iso_dir_marker_file
menuentry "foo" {
....
set iso_path='/my_path_to/foo.iso'
....
search --no-floppy --set root --file $iso_dir_marker_file
...
}
menuentry "bar" {
....
set iso_path='/my_path_to/bar.iso'
....
search --no-floppy --set root --file $iso_dir_marker_file
...
}With this i have to set iso_dir_marker_file var only one (and could use it in every menuentry where i have to --set=root via grub's search function)
Otherwise i could also set/export iso_dev_label or iso_dev_uuid this way. Give cleaner menuentry sections...
Thanks
Last edited by GerBra (Today 17:31:16)
My avatar: "It's not just a toilet... a FERGUSON. The King of bowls. Sit down and give me your best shot." Al Bundy
Offline