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

Ben Hutchings ben at decadent.org.uk
Tue Sep 12 00:13:38 BST 2017

On Mon, 2017-09-11 at 21:47 +0200, Raphael Hertzog wrote:
> 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)

Then I don't know what's going wrong in your chroot environment.

> > 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?

I think that's right... except now I wonder whether it's reasonable to
assume udevadm in a chroot can talk to udev on the outside.  It looks
like they would have to share /run/udev/control.

It seems like maybe vmdebootstrap shouldn't be used in a chroot.


> 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!

Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it in
your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20170912/16c0caf5/attachment-0002.sig>

More information about the Pkg-systemd-maintainers mailing list