Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
hertzog at debian.org
Mon Sep 11 20:47:24 BST 2017
On Mon, 11 Sep 2017, Ben Hutchings wrote:
> The answer seems to be that udev doesn't just listen for device events,
> but also uses inotify to watch block devices. But inotify operates on
> inodes, not the underlying devices. The chroot has a separate /dev
> directory and inodes, so writing to a block device through one of those
> inodes doesn't trigger the inotify watch.
> If I bind-mount /dev into the chroot before running mkfs there, udev
> does see the change events because mkfs opens the inodes that it's
This is strange because schroot does bind-mount /dev in the default
profile that I used:
$ grep profile /etc/schroot/chroot.d/sid-amd64
$ grep /dev /etc/schroot/default/fstab
/dev /dev none rw,bind 0 0
/dev/pts /dev/pts none rw,bind 0 0
/dev/shm /dev/shm none rw,bind 0 0
(and a stat call inside the chroot and outside of it returns the same inode
number and the same device number)
> So this is a limitation of udev and of the kernel's inotify interface,
> but I don't think it's a bug in either of them. vmdebootstrap should
> not assume that udev will notice changes made by mkfs unless they are
> operating on the same /dev filesystem (and even then, it should use
> 'udevadm settle' to avoid races).
Assuming your analysis is right, what would be the right course of action?
Calling "udevadm trigger <block-device>" after the mkfs call?
FWIW, this udevadm trigger call does work (as in the missing symlink gets
created)... and it works when called outside of the chroot but also when called
within the chroot.
And thanks for the investigation you made!
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
More information about the Pkg-systemd-maintainers