★★★★★≤澳門銀河116948點com精準資料＜一碼中特＞註冊即送38｜釦釦：330081906｜≥qerw
___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: 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/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: 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: USEC_INITIALIZED=1303173510442
Re: 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/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: 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 ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: 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/
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
[bts-link] source package systemd
# # bts-link upstream status pull for source package systemd # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #852534 (http://bugs.debian.org/852534) # Bug title: systemd: cryptsetup-generator does not support LUKS on network devices # * https://github.com/systemd/systemd/issues/4642 # * remote status changed: open -> closed # * closed upstream tags 852534 + fixed-upstream usertags 852534 - status-open usertags 852534 + status-closed thanks ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: [bts-link] source package systemd
Processing commands for cont...@bugs.debian.org: > # > # bts-link upstream status pull for source package systemd > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # > user bts-link-upstr...@lists.alioth.debian.org Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). > # remote status report for #852534 (http://bugs.debian.org/852534) > # Bug title: systemd: cryptsetup-generator does not support LUKS on network > devices > # * https://github.com/systemd/systemd/issues/4642 > # * remote status changed: open -> closed > # * closed upstream > tags 852534 + fixed-upstream Bug #852534 [systemd] systemd: cryptsetup-generator does not support LUKS on network devices Added tag(s) fixed-upstream. > usertags 852534 - status-open Usertags were: status-open. Usertags are now: . > usertags 852534 + status-closed There were no usertags set. Usertags are now: status-closed. > thanks Stopping processing here. Please contact me if you need assistance. -- 852534: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852534 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
