Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
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 " 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 /runnonerw,bind 0 0 #/run/lock /run/lock nonerw,bind 0 0 #/run/shm /run/shmnonerw,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/
Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Mon, 2017-09-11 at 21:47 +0200, Raphael Hertzog wrote: > 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/devnonerw,bind 0 0 > /dev/pts/dev/ptsnonerw,bind 0 0 > /dev/shm /dev/shmnonerw,bind 0 0 > > (and a stat call inside the chroot and outside of it returns the same inode > number and the same device number) Then I don't know what's going wrong in your chroot environment. > > 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 " 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. It seems like maybe vmdebootstrap shouldn't be used in a chroot. Ben. > 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! -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part
Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
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/devnonerw,bind 0 0 /dev/pts/dev/ptsnonerw,bind 0 0 /dev/shm /dev/shmnonerw,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 " 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/
Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Thu, 2017-09-07 at 17:53 +0200, Raphael Hertzog wrote:
> On Thu, 07 Sep 2017, Ben Hutchings wrote:
> > On Thu, 2017-09-07 at 12:53 +0200, Raphael Hertzog wrote:
> > > On Thu, 07 Sep 2017, Raphael Hertzog wrote:
> > > > What informs udev about the new filesystem?
> > >
> > > Somehow, it's the kernel apparently.
> > >
> > > > Or is this a bug in the kernel really?
> > >
> > > At least "udevadm monitor" shows that the kernel is sending
> > > less uevents when I run the command in the chroot.
> >
> > Which command?
>
> vmdebootstrap (for example as called by "make sid.raw" in that directory):
> https://anonscm.debian.org/cgit/cloud/debian-vm-templates.git/tree/vmdebootstrap-generic-qcow2
>
> The command creates the disk image with commands similar to those shown in
> this log:
> 2017-09-07 16:11:54 DEBUG runcmd: ['qemu-img', 'create', '-f', 'raw',
> '/srv/autopkgtest-images/sid-amd64-new.img', '100'] None {}
> 2017-09-07 16:11:54 INFO Creating partitions
> 2017-09-07 16:11:54 DEBUG runcmd: ['parted', '-s',
> '/srv/autopkgtest-images/sid-amd64-new.img', 'mklabel', 'msdos'] None {}
> 2017-09-07 16:11:54 DEBUG runcmd: ['parted', '-s',
> '/srv/autopkgtest-images/sid-amd64-new.img', 'mkpart', 'primary', '0%',
> '100%'] None {}
> 2017-09-07 16:11:54 DEBUG runcmd: ['parted', '-s',
> '/srv/autopkgtest-images/sid-amd64-new.img', 'set', '1', 'boot', 'on'] None {}
> 2017-09-07 16:11:54 DEBUG runcmd: ['kpartx', '-avs',
> '/srv/autopkgtest-images/sid-amd64-new.img'] None {}
> 2017-09-07 16:11:54 INFO Creating filesystem ext4
> 2017-09-07 16:11:54 DEBUG runcmd: ['mkfs', '-t', 'ext4',
> u'/dev/mapper/loop0p1'] None {}
> 2017-09-07 16:11:55 DEBUG mkdir /tmp/tmpSEWpRs
> 2017-09-07 16:11:55 INFO Mounting /dev/mapper/loop0p1 on /tmp/tmpSEWpRs
> 2017-09-07 16:11:55 DEBUG runcmd: ['mount', u'/dev/mapper/loop0p1',
> '/tmp/tmpSEWpRs'] None {}
>
> Then goes on with debootstrap but at this point already you are past the point
> where the kernel should have emitted the uevent that triggers the by-uuid
> symlink
> creation.
It's the mkfs command that triggers it; specifically the close() call
on the block device. But I can't see why the kernel would send device
events at that time for a device mapper device (or a loop device, which
I tested with because it's simpler to set up).
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.
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).
Ben.
--
Ben Hutchings
All the simple programs have been written, and all the good names
taken.
signature.asc
Description: This is a digitally signed message part
Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Thu, 07 Sep 2017, Ben Hutchings wrote:
> On Thu, 2017-09-07 at 12:53 +0200, Raphael Hertzog wrote:
> > On Thu, 07 Sep 2017, Raphael Hertzog wrote:
> > > What informs udev about the new filesystem?
> >
> > Somehow, it's the kernel apparently.
> >
> > > Or is this a bug in the kernel really?
> >
> > At least "udevadm monitor" shows that the kernel is sending
> > less uevents when I run the command in the chroot.
>
> Which command?
vmdebootstrap (for example as called by "make sid.raw" in that directory):
https://anonscm.debian.org/cgit/cloud/debian-vm-templates.git/tree/vmdebootstrap-generic-qcow2
The command creates the disk image with commands similar to those shown in this
log:
2017-09-07 16:11:54 DEBUG runcmd: ['qemu-img', 'create', '-f', 'raw',
'/srv/autopkgtest-images/sid-amd64-new.img', '100'] None {}
2017-09-07 16:11:54 INFO Creating partitions
2017-09-07 16:11:54 DEBUG runcmd: ['parted', '-s',
'/srv/autopkgtest-images/sid-amd64-new.img', 'mklabel', 'msdos'] None {}
2017-09-07 16:11:54 DEBUG runcmd: ['parted', '-s',
'/srv/autopkgtest-images/sid-amd64-new.img', 'mkpart', 'primary', '0%', '100%']
None {}
2017-09-07 16:11:54 DEBUG runcmd: ['parted', '-s',
'/srv/autopkgtest-images/sid-amd64-new.img', 'set', '1', 'boot', 'on'] None {}
2017-09-07 16:11:54 DEBUG runcmd: ['kpartx', '-avs',
'/srv/autopkgtest-images/sid-amd64-new.img'] None {}
2017-09-07 16:11:54 INFO Creating filesystem ext4
2017-09-07 16:11:54 DEBUG runcmd: ['mkfs', '-t', 'ext4',
u'/dev/mapper/loop0p1'] None {}
2017-09-07 16:11:55 DEBUG mkdir /tmp/tmpSEWpRs
2017-09-07 16:11:55 INFO Mounting /dev/mapper/loop0p1 on /tmp/tmpSEWpRs
2017-09-07 16:11:55 DEBUG runcmd: ['mount', u'/dev/mapper/loop0p1',
'/tmp/tmpSEWpRs'] None {}
Then goes on with debootstrap but at this point already you are past the point
where the kernel should have emitted the uevent that triggers the by-uuid
symlink
creation.
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/
Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Thu, 2017-09-07 at 12:53 +0200, Raphael Hertzog wrote: > On Thu, 07 Sep 2017, Raphael Hertzog wrote: > > What informs udev about the new filesystem? > > Somehow, it's the kernel apparently. > > > Or is this a bug in the kernel really? > > At least "udevadm monitor" shows that the kernel is sending > less uevents when I run the command in the chroot. Which command? Ben. > I attach > two logs of "udevadm monitor -k -u -p", once for the run in > the host, and one for the run in schroot. > > And I also attach a diff of edited logs where I dropped the > timestamps. We can clearly see the lack of a "KERNEL[] change > /devices/virtual/block/dm-4 (block)" with its associated > UDEV rule adding the by-uuid links. > > So this is with 4.12.6-1 (unstable). -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Thu, 07 Sep 2017, Raphael Hertzog wrote: > Is there anything that can be done by vmdebootstrap to force-trigger the > creation of that entry even when chrooted? Yes, "udevadm trigger" or "udevadm trigger /dev/mapper/loop0p1" works well for that. So we have a work-around at least (thanks to Felipe Sateler for the suggestion, thanks also to Mantas Mikulėnas who taught me about the kernel/udev interactions). But I'm clearly not able to go further than that, debugging the kernel would be too time-consuming for me since I'm not a kernel developer... so I'll stop my investigations here. (Somehow I wonder whether this is not the result of some kernel hardening... limiting the impact of things done within a chroot compared to the main host. schroot also uses private bind mounts, can this be related?) 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/
Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Thu, 07 Sep 2017, Raphael Hertzog wrote: > What informs udev about the new filesystem? Somehow, it's the kernel apparently. > Or is this a bug in the kernel really? At least "udevadm monitor" shows that the kernel is sending less uevents when I run the command in the chroot. I attach two logs of "udevadm monitor -k -u -p", once for the run in the host, and one for the run in schroot. And I also attach a diff of edited logs where I dropped the timestamps. We can clearly see the lack of a "KERNEL[] change /devices/virtual/block/dm-4 (block)" with its associated UDEV rule adding the by-uuid links. So this is with 4.12.6-1 (unstable). 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/ KERNEL[1303173.467860] change /devices/virtual/block/loop0 (block) ACTION=change DEVNAME=/dev/loop0 DEVPATH=/devices/virtual/block/loop0 DEVTYPE=disk MAJOR=7 MINOR=0 SEQNUM=4256 SUBSYSTEM=block KERNEL[1303173.492386] add /devices/virtual/bdi/254:4 (bdi) ACTION=add DEVPATH=/devices/virtual/bdi/254:4 SEQNUM=4257 SUBSYSTEM=bdi KERNEL[1303173.492809] add /devices/virtual/block/dm-4 (block) ACTION=add DEVNAME=/dev/dm-4 DEVPATH=/devices/virtual/block/dm-4 DEVTYPE=disk MAJOR=254 MINOR=4 SEQNUM=4258 SUBSYSTEM=block UDEV [1303173.493320] add /devices/virtual/bdi/254:4 (bdi) ACTION=add DEVPATH=/devices/virtual/bdi/254:4 SEQNUM=4257 SUBSYSTEM=bdi USEC_INITIALIZED=1303173493269 UDEV [1303173.495279] change /devices/virtual/block/loop0 (block) .ID_FS_TYPE_NEW= ACTION=change DEVNAME=/dev/loop0 DEVPATH=/devices/virtual/block/loop0 DEVTYPE=disk ID_FS_TYPE= ID_PART_TABLE_TYPE=dos ID_PART_TABLE_UUID=91b643c6 MAJOR=7 MINOR=0 SEQNUM=4256 SUBSYSTEM=block TAGS=:systemd: USEC_INITIALIZED=13952290172 KERNEL[1303173.495444] change /devices/virtual/block/dm-4 (block) ACTION=change DEVNAME=/dev/dm-4 DEVPATH=/devices/virtual/block/dm-4 DEVTYPE=disk DM_COOKIE=4194304 MAJOR=254 MINOR=4 SEQNUM=4259 SUBSYSTEM=block UDEV [1303173.510693] add /devices/virtual/block/dm-4 (block) ACTION=add DEVLINKS=/dev/disk/by-id/raid-loop0p1 DEVNAME=/dev/dm-4 DEVPATH=/devices/virtual/block/dm-4 DEVTYPE=disk DM_NAME=loop0p1 DM_PART=1 DM_STATE=ACTIVE DM_TABLE_STATE=LIVE DM_TYPE=raid DM_UDEV_DISABLE_DISK_RULES_FLAG=1 DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1 DM_UUID=part1-loop0 MAJOR=254 MINOR=4 SEQNUM=4258 SUBSYSTEM=block SYSTEMD_READY=0 TAGS=:systemd: USEC_INITIALIZED=1303173510442 UDEV [1303173.527433] change /devices/virtual/block/dm-4 (block) .ID_FS_TYPE_NEW= ACTION=change DEVLINKS=/dev/disk/by-partuuid/91b643c6-01 /dev/mapper/loop0p1 /dev/disk/by-id/raid-loop0p1 /dev/disk/by-id/dm-uuid-part1-loop0 /dev/disk/by-id/dm-name-loop0p1 DEVNAME=/dev/dm-4 DEVPATH=/devices/virtual/block/dm-4 DEVTYPE=disk DM_ACTIVATION=1 DM_COOKIE=4194304 DM_NAME=loop0p1 DM_PART=1 DM_STATE=ACTIVE DM_SUSPENDED=0 DM_TABLE_STATE=LIVE DM_TYPE=raid DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES=1 DM_UUID=part1-loop0 ID_FS_TYPE= ID_PART_ENTRY_DISK=7:0 ID_PART_ENTRY_FLAGS=0x80 ID_PART_ENTRY_NUMBER=1 ID_PART_ENTRY_OFFSET=2048 ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_SIZE=19527680 ID_PART_ENTRY_TYPE=0x83 ID_PART_ENTRY_UUID=91b643c6-01 MAJOR=254 MINOR=4 SEQNUM=4259 SUBSYSTEM=block TAGS=:systemd: USEC_INITIALIZED=1303173510442 --- debootstrap --- KERNEL[1303301.063685] change /devices/virtual/block/loop0 (block) ACTION=change DEVNAME=/dev/loop0 DEVPATH=/devices/virtual/block/loop0 DEVTYPE=disk MAJOR=7 MINOR=0 SEQNUM=4260 SUBSYSTEM=block UDEV [1303301.069592] change /devices/virtual/block/loop0 (block) .ID_FS_TYPE_NEW= ACTION=change DEVNAME=/dev/loop0 DEVPATH=/devices/virtual/block/loop0 DEVTYPE=disk ID_FS_TYPE= ID_PART_TABLE_TYPE=dos ID_PART_TABLE_UUID=91b643c6 MAJOR=7 MINOR=0 SEQNUM=4260 SUBSYSTEM=block TAGS=:systemd: USEC_INITIALIZED=13952290172 KERNEL[1303303.480902] remove /devices/virtual/block/dm-4 (block) ACTION=remove DEVNAME=/dev/dm-4 DEVPATH=/devices/virtual/block/dm-4 DEVTYPE=disk DM_COOKIE=6291456 MAJOR=254 MINOR=4 SEQNUM=4261 SUBSYSTEM=block UDEV [1303303.497202] remove /devices/virtual/block/dm-4 (block) .ID_FS_TYPE_NEW= ACTION=remove DEVLINKS=/dev/mapper/loop0p1 /dev/disk/by-partuuid/91b643c6-01 /dev/disk/by-id/raid-loop0p1 /dev/disk/by-id/dm-uuid-part1-loop0 /dev/disk/by-id/dm-name-loop0p1 DEVNAME=/dev/dm-4 DEVPATH=/devices/virtual/block/dm-4 DEVTYPE=disk DM_ACTIVATION=1 DM_COOKIE=6291456 DM_NAME=loop0p1 DM_PART=1 DM_STATE=ACTIVE DM_SUSPENDED=0 DM_TABLE_STATE=LIVE DM_TYPE=raid DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1 DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES=1 DM_UUID=part1-loop0 ID_FS_TYPE= ID_PART_ENTRY_DISK=7:0 ID_PART_ENTRY_FLAGS=0x80 ID_PART_ENTRY_NUMBER=1 ID_PART_ENTRY_OFFSET=2048 ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_SIZE=19527680 ID_PART_ENTRY_TYPE=0x83 ID_PART_ENTRY_UUID=91b643c6-01 MAJOR=254 MINOR=4 SEQNUM=4261 SUBSYSTEM=block TAGS=:systemd:
Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
[ Ccing grub, udev, linux maintainers for the questions at the end, I want to understand why some /dev/disk/by-uuid/ entries are not properly created ] Hello, On Wed, 23 Aug 2017, Raphaël Hertzog wrote: > Hello, I'm trying to update my qemu image used for autopkgtest, so I > followed the instructions from man autopkgtest-virt-qemu to create the > image but the resulting image does not boot and thus does not work > for autopkgtest either. > > I believe that the root cause is this error shown in the vmdebootstrap > output: > > /usr/sbin/grub-probe: error: cannot find a device for / (is /dev > mounted?). > WARNING: update-grub failed! > > Maybe the behaviour of update-grub changed recently... vmdebootstrap So this is not the root cause. This is just a problem in the customize script which should mount /dev and /proc just like vmdebootstrap already does when it calls update-grub. Or it should probably get rid of it entirely as vmdebootstrap mostly overwrites the grub configuration anyway. > When I inspect /boot/grub/grub.cfg it does indeed contain > root=/dev/mapper/loop0p1 which we don't want. After a discussion on #debian-cloud, I narrowed the problem a bit more closely. In fact vmdebootstrap works properly when I run it unchrooted on my system, but when I run it in "schroot" (with a default profile which shares with the host the mount for /dev, /proc, /sys and more) then I get this problem. So it looks like that update-grub is behaving differently in each situation. I have added "set -x" to the grub-mkconfig and it looks like grub is perfectly able to find out the UUID associated to device: $ virt-cat -a sid.raw /tmp/update-grub-log |grep -i uuid + /usr/sbin/grub-probe --device /dev/mapper/loop0p1 --target=fs_uuid + GRUB_DEVICE_UUID=600ae34d-dceb-4250-a832-f07fa0c932db + /usr/sbin/grub-probe --device /dev/mapper/loop0p1 --target=fs_uuid + GRUB_DEVICE_BOOT_UUID=600ae34d-dceb-4250-a832-f07fa0c932db [...] Then I added "set -x" to /etc/grub.d/10_linux to find out why this script decided to not use the UUID even though it was available in the environment. It boils down to /dev/disk/by-uuid/600ae34d-dceb-4250-a832-f07fa0c932db does not exist. The loop partition device is /dev/dm-4 and at the time when the customize script runs, I have this output (it exists in by-partuuid, but not in by-uuid): $ ls -al /dev/disk/by-uuid/ total 0 drwxr-xr-x 2 root root 140 sept. 5 15:42 . drwxr-xr-x 7 root root 140 août 23 08:34 .. lrwxrwxrwx 1 root root 10 sept. 1 08:54 51d0-3c3e-49f5-adf6-6d53e7c0a8d6 -> ../../dm-0 lrwxrwxrwx 1 root root 10 sept. 1 08:54 5b668fa1-c4c5-44f7-bbec-ed5edfc33c0d -> ../../dm-3 lrwxrwxrwx 1 root root 10 sept. 1 08:54 92a990ff-52c2-4766-b865-a78cceb7e293 -> ../../dm-2 lrwxrwxrwx 1 root root 10 sept. 1 08:54 b3816590-a760-4815-9f43-0c2f4a362abc -> ../../sda2 lrwxrwxrwx 1 root root 10 sept. 1 08:54 BF87-23E5 -> ../../sda1 $ ls -al /dev/disk/by-partuuid/ total 0 drwxr-xr-x 2 root root 200 sept. 7 09:04 . drwxr-xr-x 7 root root 140 août 23 08:34 .. lrwxrwxrwx 1 root root 10 sept. 1 08:54 01f46df3-eb66-47b9-b0ea-a667e4a02020 -> ../../sda5 lrwxrwxrwx 1 root root 10 sept. 1 08:54 1dd56def-bfb8-423e-8ea5-d03ca1f2ff75 -> ../../sda6 lrwxrwxrwx 1 root root 10 sept. 7 09:04 3dfece35-01 -> ../../dm-4 lrwxrwxrwx 1 root root 10 sept. 1 08:54 426ccd8e-0ccd-4864-9152-31fc831ae98a -> ../../sda4 lrwxrwxrwx 1 root root 10 sept. 1 08:54 525345f4-e509-4283-8489-a6c1e7625975 -> ../../sda3 lrwxrwxrwx 1 root root 10 sept. 1 08:54 6ce3844f-39e8-4a7f-8e37-05b6bb9efe2f -> ../../sda1 lrwxrwxrwx 1 root root 10 sept. 1 08:54 caff8cf5-b264-498e-b6be-e6160fcf2085 -> ../../sda7 lrwxrwxrwx 1 root root 10 sept. 1 08:54 d67d853a-592f-4e21-9ed7-5992359aaa7d -> ../../sda2 $ ls -al /dev/mapper/loop0p1 brw-rw 1 root disk 254, 4 sept. 7 09:04 /dev/mapper/loop0p1 And when I run it outside from my schroot, then I have the entry in /dev/disk/by-uuid/. What is responsible of creating that entry? I guess it's udev. udev is not running in the chroot, obviously. But the underlying device (and the mount point) is seen by the host so I wonder why it's not created. What informs udev about the new filesystem? Is there anything that can be done by vmdebootstrap to force-trigger the creation of that entry even when chrooted? Should update-grub not try to be too smart and just trust the value obtained by grub-probe instead even if /dev/disk/by-uuid/$foo does not exist? Or is this a bug in the kernel really? 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/
Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
Package: vmdebootstrap Version: 1.7-1+nmu1 Severity: important User: de...@kali.org Usertags: origin-kali Hello, I'm trying to update my qemu image used for autopkgtest, so I followed the instructions from man autopkgtest-virt-qemu to create the image but the resulting image does not boot and thus does not work for autopkgtest either. I believe that the root cause is this error shown in the vmdebootstrap output: /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?). WARNING: update-grub failed! Maybe the behaviour of update-grub changed recently... vmdebootstrap has not changed recently and yet this worked on my laptop a few weeks ago (I can't verify whether we had this warning or not, but the built VM was definitely booting). In any case, the problem shown in the serial console of the virtual machine is this one: [...] Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. done. Gave up waiting for root file system device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/mapper/loop0p1 does not exist. Dropping to a shell! When I inspect /boot/grub/grub.cfg it does indeed contain root=/dev/mapper/loop0p1 which we don't want. I manually modified the file to put root=/dev/sda1 and with this I can get it to boot with a simple command like this: qemu -serial stdio /srv/autopkgtest-images/kali-rolling.img Unfortunately, autopkgtest is still not happy with the image, I get this: $ autopkgtest -B ./cpputest_3.8-5.dsc -- qemu /srv/autopkgtest-images/kali-rolling.img autopkgtest [15:23:50]: version 4.4 autopkgtest [15:23:50]: host x260-buxy; command line: /usr/bin/autopkgtest -B ./cpputest_3.8-5.dsc -- qemu /srv/autopkgtest-images/kali-rolling.img qemu-system-x86_64: terminating on signal 15 from pid 20284 (/usr/bin/python3) : failure: timed out waiting for "login prompt on ttyS0" autopkgtest [15:24:50]: ERROR: testbed failure: cannot send to testbed: ['BrokenPipeError: [Errno 32] Broken pipe\n'] And even with -ddd, you don't get any detail about what autopkgtest does see (or not) on the serial console so I have no clue what's going on really. Cheers, -- System Information: Debian Release: buster/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vmdebootstrap depends on: ii debootstrap 1.0.91 ii kpartx 0.6.4-5+b1 ii libjs-sphinxdoc 1.5.6-2 ii parted 3.2-17 ii python 2.7.13-2 ii python-cliapp 1.20160724-2 ii python-distro-info 0.17 ii python2.7 2.7.13-4 ii qemu-utils 1:2.8+dfsg-7 Versions of packages vmdebootstrap recommends: ii dosfstools4.1-1 ii extlinux 3:6.03+dfsg-14.1 ii grub2-common 2.02-2 ii python-guestfs1:1.34.6-5 pn qemu-system pn qemu-user-static pn squashfs-tools Versions of packages vmdebootstrap suggests: pn cmdtest pn mbr pn pandoc pn u-boot -- no debconf information
