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/ _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
