Dear Maintainer,

summary:  unable to install debian trixie onto a loop-mounted image file, due to update-grub not creating grub.cfg

use-case: building a disk image for use as a xen domu

steps:  create 4G file with dd; 'mount -o loop /opt/vdisk/disk0.img /mnt/disk0' ; debootstrap trixie /mnt.disk0 ...
        mount --bind /dev /mnt/disk0/dev ; mount --bind /proc /dev/disk0/proc
        chroot /mnt/disk0 ; update-grub

the intent is to create a grub.cfg that 'pygrub' (running on dom0) can boot to.  do not require a bootloader to be added to the disk image

running 'grub-mkconfig -o grub.cfg' is an easier way to see the problem.

versions:
=========
the above process worked on bookworm.
if failed on trixie (13.3).  the grub-mkconfig was part of grub-common 2.12-9 ; grub-common was installed from 'apt install grub-pc'
upgrading 'apt upgrade grub-common/testing' installed 'grub-common' 2.14~git20250718.0e36779-2 & added 'grub2-common' 2.14~git20250718.0e36779-2
after upgrading the package, 'grub-mkconfig' is now part of 'grub2-common'

cause and effect:
=========
grub-mkconfig uses helper script /usr/share/grub/grub-mkconfig_lib
the version in 12-9 tests the root device against a pattern of 'loop[0-9]'.  if the disk image is mounted on loop0..loop9 then it returns the file path /opt/vdisk/disk0.img
this cannot be resolved further, and results ultimately in '${grub_probe}" --target=device "${loop_file}' returning blank
the workaround to this is to deliberately use /dev/loop10 or above

the version testing (2.14~git20250718.0e36779-2) runs through and generates a grub.cfg
however, if using loop0..loop9, it remaps the device to /opt/vdisk/disk0.img
if using loop10+, it doesn't remap, and just displays /dev/loop10 in the grub.cfg

workaround:
===========
1) the tidiest workaround appears to be to use a specific loop device (e.g. /dev/loop15) in this cases

2) copy a dummy grub.cfg file from a working system.  then boot the domu in xen, where the root device is then detected as /dev/xvda1


comments:
=========
this is corner-case for users that create images manually or from a script

I cannot understand why grub-mkconfig and helper scripts should treat loop10+ differently that loop0-loop9
it would be beneficial to have a way of telling grub-mkconfig to ignore loop devices