Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter

[Raphael Hertzog]

Hi Ben,

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
> watching.

This is strange because schroot does bind-mount /dev in the default
profile that I used:
$ grep profile /etc/schroot/chroot.d/sid-amd64
profile=default
profile=default
$ 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!

Cheers,
-- 
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/