Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #58908
| From | Raphael Hertzog <hertzog@debian.org> |
|---|---|
| Newsgroups | linux.debian.bugs.dist, linux.debian.kernel |
| Subject | Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter |
| Date | 2017-09-12 09:40 +0200 |
| Message-ID | <uoNNT-6JC-7@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <uoCfM-7sQ-21@gated-at.bofh.it> <uoCSt-7IE-1@gated-at.bofh.it> <uoG9H-1yX-5@gated-at.bofh.it> <uhEcH-1bd-31@gated-at.bofh.it> <uoG9H-1yX-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Cross-posted to 2 groups.
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/
Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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