Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #58906

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

Cross-posted to 2 groups.

Show key headers only | View raw

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/

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter Raphael Hertzog <hertzog@debian.org> - 2017-09-07 12:20 +0200
  Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter Raphael Hertzog <hertzog@debian.org> - 2017-09-07 13:00 +0200
    Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter Ben Hutchings <ben@decadent.org.uk> - 2017-09-07 17:00 +0200
      Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter Raphael Hertzog <hertzog@debian.org> - 2017-09-07 18:00 +0200
        Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter Ben Hutchings <ben@decadent.org.uk> - 2017-09-11 21:10 +0200
          Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter Raphael Hertzog <hertzog@debian.org> - 2017-09-11 21:50 +0200
            Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter Ben Hutchings <ben@decadent.org.uk> - 2017-09-12 01:20 +0200
              Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter Raphael Hertzog <hertzog@debian.org> - 2017-09-12 09:40 +0200
  Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter Raphael Hertzog <hertzog@debian.org> - 2017-09-07 16:00 +0200

csiph-web