Dear Maintainer,

    * What led up to the situation?
      export DPKG_FORCE="breaks"
      (Just necessary with grml-debootstrap, manually, you have to run dpkg -i
       2 or 3 times to resolve it correctly)
      Bootstrapping Debian 12 with following packages in config/extrapackages/:
        cryptsetup_2%3a2.6.1-4~deb12u2_amd64.deb
        cryptsetup-initramfs_2%3a2.6.1-4~deb12u2_all.deb
        libnss-systemd_254.22-1~bpo12+1_amd64.deb
        libpam-systemd_254.22-1~bpo12+1_amd64.deb
        libsystemd0_254.22-1~bpo12+1_amd64.deb
        libsystemd-shared_254.22-1~bpo12+1_amd64.deb
        libudev1_254.22-1~bpo12+1_amd64.deb
        systemd_254.22-1~bpo12+1_amd64.deb
        systemd-boot-efi_254.22-1~bpo12+1_amd64.deb
        systemd-dev_254.22-1~bpo12+1_all.deb
        systemd-resolved_254.22-1~bpo12+1_amd64.deb
        udev_254.22-1~bpo12+1_amd64.deb

      Relevant groups on the host:
        systemd-resolve:x:104:
        kvm:x:124:

      Relevant groups on the bootstrapped system:
        systemd-resolve:x:997:
        kvm:x:104:

    * What was the outcome of this action?
      Modified ownership on the host in /dev:
        crw-rw---- root systemd-resolve /dev/kvm
        crw-rw---- root systemd-resolve /dev/vhost-net
        crw-rw---- root systemd-resolve /dev/vhost-vsock

    * What outcome did you expect instead?
      An unmodified host system.



The issue was that the package udev was modifying the files in chroot
during the setup and obviously, any package could do that but it should
not modify the host system, which in the worst could crash the host system.

This is caused by mounting rw in line 2016: mount -t devtmpfs udev "${MNTPOINT}"/dev
which allows then in chroot to modify files in /dev.

Therefore it would be good to mount "${MNTPOINT}"/dev read-only, e.g.:
mount -t devtmpfs udev "${MNTPOINT}"/dev -o ro

I also verified the upstream version, which has no change in this
matter.

A test run with "${MNTPOINT}"/dev mounted read-only was successful.


Best regards,
Wolf

Sorry, I have to correct myself:
This does not work, because it will mount /dev on the host read-only as well.

Actually the test was done with:
   mount --bind /dev "${MNTPOINT}"/dev
   mount -o remount,bind,ro "${MNTPOINT}"/dev


Best regards,
Wolf

Control: tags -1 + upstream
Control: forwarded -1 https://github.com/grml/grml-debootstrap/pull/347

I tried working on this in https://github.com/grml/grml-debootstrap/pull/347

Unfortunately making the chroot /dev readonly makes resulting VM
images unbootable. update-grub should put root=UUID=... into
grub.cfg (as before), but now puts root=/dev/mapper/loop..., which
cannot work for obvious reasons.

Ideas welcome.

Chris

Thanks a lot for looking at it and obviously, this is absolutely clear that
root=/dev/mapper/loop.. cannot work.

Maybe I should have mentioned, that I bootstraped with grub disable to a mounted image
file with UKI images for a Secure Boot environment, which can run in VM and on real
hardware.
I'll have a closer look at this issue next week because I'm really interested in solving
this issue due to the fact that I use grml-debootstrap a lot and maybe sometime in the
future even with a grub loader.

I'll inform you as soon as I have an idea.

Wolf

I had a look at it and actually I cannot reproduce root=/dev/mapper/loop.. in grub.cfg,
but maybe I did something wrong or I utilise a different scenario.

Anyway, the following I did which was working flawless and I could start it with qemu
without issues:

Test with grml-debootstrap on Debian 12:
grml-debootstrap version 0.103 with unmodified default configuration

-------------------------------
diff -Nup /usr/sbin/grml-debootstrap.orig /usr/sbin/grml-debootstrap
--- /usr/sbin/grml-debootstrap.orig	2023-02-20 11:40:07.000000000 +0100
+++ /usr/sbin/grml-debootstrap	2025-07-03 09:10:49.906989258 +0200
@@ -2014,6 +2014,7 @@ chrootscript() {
    else
      einfo "Executing chroot-script now"
      mount -t devtmpfs udev "${MNTPOINT}"/dev
+    mount -o remount,bind,ro "${MNTPOINT}"/dev
      mount -t devpts devpts "${MNTPOINT}"/dev/pts
      if [ "$DEBUG" = "true" ] ; then
        chroot "$MNTPOINT" /bin/bash -x /bin/chroot-script ; RC=$?
-------------------------------



# truncate -s 8G test-image-mbr.img
# fdisk -l test-image-mbr.img
Disk test-image-mbr.img: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x11d9d0cb

Device              Boot Start      End  Sectors Size Id Type
test-image-mbr.img1       2048 16777215 16775168   8G 83 Linux

# losetup -P -f test-image-mbr.img
# grml-debootstrap --verbose --password "Have a guess!"  --target /dev/loop0p1 --grub /dev/loop0

Seen on console:
...
Setting up udev (252.38-1~deb12u1) ...
A chroot environment has been detected, udev not started.
fchownat() of /dev/kvm failed: Read-only file system
fchownat() of /dev/vhost-net failed: Read-only file system
fchownat() of /dev/vhost-vsock failed: Read-only file system
...

# mount /dev/loop0p1 mnt
# grep UUID mnt/boot/grub/grub.cfg
	linux	/boot/vmlinuz-6.1.0-37-amd64 root=UUID=e6564375-8c54-4054-a538-b5a95f9627c2 ro  quiet
		linux	/boot/vmlinuz-6.1.0-37-amd64 root=UUID=e6564375-8c54-4054-a538-b5a95f9627c2 ro  quiet
		linux	/boot/vmlinuz-6.1.0-37-amd64 root=UUID=e6564375-8c54-4054-a538-b5a95f9627c2 ro single

# umount mnt
# losetup -D
# qemu-system-x86_64 -m 4096 -drive format=raw,file=test-image-mbr.img


Test with grml-debootstrap from master Debian 12:
grml-debootstrap master eae91811116fbc452efe45c6b80ecc647547ea1f

-------------------------------
diff --git a/grml-debootstrap b/grml-debootstrap
index 37893c6..c61e157 100755
--- a/grml-debootstrap
+++ b/grml-debootstrap
@@ -1880,6 +1880,7 @@ chrootscript() {
    else
      einfo "Executing chroot-script now"
      mount -t devtmpfs udev "${MNTPOINT}"/dev
+    mount -o remount,bind,ro "${MNTPOINT}"/dev
      mount -t devpts devpts "${MNTPOINT}"/dev/pts
      if [ "$DEBUG" = "true" ] ; then
        clean_chroot "$MNTPOINT" /bin/bash -x /bin/chroot-script
-------------------------------

# losetup -P -f test-image-mbr.img
# grml-debootstrap --verbose --password "Have a guess!"  --target /dev/loop0p1 --grub /dev/loop0

No message on console!

# mount /dev/loop0p1 mnt
# grep UUID mnt/boot/grub/grub.cfg
	linux	/boot/vmlinuz-6.12.33+deb13-amd64 root=UUID=965be905-fb3e-40e3-a738-47e6519b7f50 ro  quiet
		linux	/boot/vmlinuz-6.12.33+deb13-amd64 root=UUID=965be905-fb3e-40e3-a738-47e6519b7f50 ro  quiet
		linux	/boot/vmlinuz-6.12.33+deb13-amd64 root=UUID=965be905-fb3e-40e3-a738-47e6519b7f50 ro single
dis_ucode_ldr

# umount mnt
# losetup -D
# qemu-system-x86_64 -m 4096 -drive format=raw,file=test-image-mbr.img

Obviously, this will not cover every scenario, e.g. efi configuration or others, so
please could you let me know which scenario would cause the root=/dev/mapper/loop.. issue.


Cheers,
Wolf

[..]

You can inspect the CI build logs at https://github.com/grml/grml-debootstrap/pull/347

In the meantime we had some discussion in https://github.com/grml/grml-debootstrap/issues/348#issuecomment-3017042208
and further down.

Chris