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
Mon Sep 11 23:13:38 UTC 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.
Ben.
> 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://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20170912/16c0caf5/attachment.sig>
More information about the Pkg-grub-devel
mailing list