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

[Raphael Hertzog]

On Tue, 12 Sep 2017, Ben Hutchings wrote:
> > This is strange because schroot does bind-mount /dev in the default
> > profile that I used:
> 
> Then I don't know what's going wrong in your chroot environment.

Me neither.

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

I would have expected something like this too... but that does not seem
to be the case. At least it's not the reason why that call works here
because /run is not shared:
$ grep /run /etc/schroot/default/fstab
# It may be desirable to have access to /run, especially if you wish
#/run           /run            none    rw,bind         0       0
#/run/lock      /run/lock       none    rw,bind         0       0
#/run/shm       /run/shm        none    rw,bind         0       0

So maybe "udevadm trigger" is re-opening and re-closing the device
in write mode and this leads the kernel to emit a new uevent and
udev outside the chroot then reprocesses the device?

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

Or maybe update-grub should have a FORCE_USE_OF_UUID flag or something
like that. vmdebootstrap does not really care about the by-uuid symlink,
only grub insists on seeing it before accepting to use the UUID as
"root" kernel parameter.

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/