Yes, you are right, thanks.
When booted from /sdb, it becomes hd0.
The configuration of one of my computers is the same as yours, so I made sure in practice.

Regards.

@dev-1-dash-1
Maybe I'm wrong, but there is a mistake in your very first post.

Thank you for trying to help.
But you are wrong indeed.
See post #5 from this thread.
Problem is not in my grub entry, it works exactly as it needs to.

You can try booting the iso from hdd yourself, with or without "apparmor=0" parameter, and report your experiences.

This thread is marked solved for now, will keep an eye out for future versions.

set root="hd1,9"

is the /sdb drive and you are looking for the image
to

fromiso=/dev/sda9

, this is the /sda drive.
  Here's another working version. For other distributions, the path to the bootloader and initrd files may differ.

menuentry "openSUSE" {
  set isofile=/openSUSE.iso
  set root=(hd0,1)
  loopback loop $isofile
  linux (loop)/boot/x86_64/loader/linux install=hd:$isofile
  initrd (loop)/boot/x86_64/loader/initrd
}

PS. With such a record, this error is excluded.

? It boots here with or without "apparmor=0" ..

It most certainly doesn't boot here without "apparmor=0". I just tried it again.

Irrelevant. Tried both. Makes no difference, unlike apparmor parameter.

If you'd like to kick the thread a little bit more, we can try and find the difference that makes the difference. On first glance:
1) You have gpt partition table, I have msdos.
2) I don't have tzdata param

But I consider this "solved" because a real live image, when burned to usb/dvd, will use apparmor=0 param. Thus I am replicating  a real live boot with this, and since it seems to work as intended, case should be closed for now.

I always found "findiso" simpler to configure than "fromiso".. here's my grub.d/40_custom entry:

menuentry "devuan5 preview" {
	insmod part_gpt
	set isofile='(hd0,gpt7)/devuan_daedalus_5.0.preview_20221022_amd64_desktop-live.iso'
	loopback loop $isofile
	linux (loop)/live/vmlinuz boot=live tzdata=Europe/London locales=en_GB.UTF-8 username=devuan findiso=/devuan_daedalus_5.0.preview_20221022_amd64_desktop-live.iso
	initrd (loop)/live/initrd.img
	}

In jessie and all the way up to chimaera, this wasn't neccessary, but it is now.

And why don't you try your own remedy before recommending it to me?

Because I couldn't be bothered. sorry to waste your time.

EDIT: btw hd1,9 in GRUB translates to /dev/sdb9. hd0,9 would be better but the UUID is the best approach IMO.

Nice try. :-D

I boot from sdb by default (set in bios).
Thus hd1,9 becomes "the other hd". It works for all other distros, I've tested it extensively . Also, like I've said grub can get the the kernel and initrd from within the iso image.
I've tested also the "findiso=$isofile" option, which means, as far as I know, to look thru all partitions looking for iso with the given name.

Try

menuentry "devuan5 preview" {
   search.fs_uuid=$uuid
   set isofile="/devuan_daedalus_5.0.preview_20221022_amd64_desktop-live.iso"
   loopback loop ($root)$isofile
   linux (loop)/live/vmlinuz boot=live fromiso=/dev/disk/by-uuid/$uuid$isofile username=devuan
   initrd (loop)/live/initrd.img
}

Replace both $uuid instances with the actual (filesystem) UUID for /dev/sda9.

EDIT: btw hd1,9 in GRUB translates to /dev/sdb9. hd0,9 would be better but the UUID is the best approach IMO.

And why don't you try your own remedy before recommending it to me? :-D

Your approach changes the grub's behaviour, while the problem is clearly happening later. Grub is fine, because it can get the kernel and initrd from within the iso.

As for a workaround, I've already said I have one - just mount the fs manually to alternative location using "break=premount".

Besides, the exact same grub entry (with only the iso filename changed) works for all other devuan's, from jessie to chimaera. So it should work here.

The big question is:
Is there some more serious problem lurking deep beneath the surface, that will rear it's head when we least expect.

menuentry "devuan5 preview" {
   search.fs_uuid=$uuid
   set isofile="/devuan_daedalus_5.0.preview_20221022_amd64_desktop-live.iso"
   loopback loop ($root)$isofile
   linux (loop)/live/vmlinuz boot=live fromiso=/dev/disk/by-uuid/$uuid$isofile username=devuan
   initrd (loop)/live/initrd.img
}

Replace both $uuid instances with the actual (filesystem) UUID for /dev/sda9.

EDIT: btw hd1,9 in GRUB translates to /dev/sdb9. hd0,9 would be better but the UUID is the best approach IMO.

Also: in the beginning, when udev runs detection, the font on-screen doesn't change after the resolution changes, this might indicate that there are problems with udev, if so, that could be the root cause.

grub entry:

menuentry "devuan5 preview" {
            set root="hd1,9"
            set isofile="/devuan_daedalus_5.0.preview_20221022_amd64_desktop-live.iso"
            loopback loop ($root)$isofile
            linux (loop)/live/vmlinuz boot=live fromiso=/dev/sda9$isofile username=devuan
            initrd (loop)/live/initrd.img
        }

The same type of entry works for everything from jessie to chimaera.

On boot, I see can't mount /dev/sda, can't mount /dev/sdb repeated entries,
also I see fs mounted, but then unmounted.

When booting with break=premount and then mounting the partition (sda9, that contains the isos) to an alternative location, say "/alternate_mounts/sda9", and then ^D to continue boot and everything works, I get to desktop. But, it doesn't work without this manual step, always the same error.

To reproduce: just put preview iso on hd, and create grub entry like the one I posted.