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/
