Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
hertzog at debian.org
Tue Sep 12 08:24:39 BST 2017
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.
> > 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.
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/
More information about the Pkg-systemd-maintainers