Bug#1126621: grub2-common: update-grub / grub-mkconfig will not generate grub.cfg when on a loop-mounted disk image

[anon]

Package: grub2-common
Version: 2.14~git20250718.0e36779-2
Severity: normal
X-Debbugs-Cc: anon-user at zzz.com

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


-- System Information:
Debian Release: 13.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.63+deb13-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages grub2-common depends on:
ii  gettext-base        0.23.1-2
ii  libc6               2.41-12+deb13u1
ii  libdevmapper1.02.1  2:1.02.205-2
ii  libefiboot1t64      39-2+b1
ii  libefivar1t64       39-2+b1
ii  libfreetype6        2.13.3+dfsg-1
ii  libfuse3-4          3.17.2-3
ii  liblzma5            5.8.1-1

-- debconf information excluded