eOn Mo, 06.05.19 10:26, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > Waiting for device (parent + 2 partitions) to appear... > Found writable 'root' partition (UUID > 87d5a92987174be9ad216482074d1409) of type xfs without verity on > partition #2 (/dev/vda2) > Found writable 'esp' partition (UUID b5aa8c29b4ab4021b2b22326860bda97) > of type vfat on partition #1 (/dev/vda1) > [Detaching after fork from child process 8612] > Successfully forked off '(sd-dissect)' as PID 8612. > Mounting xfs on /tmp/dissect-h21Wp5 (MS_RDONLY|MS_NODEV "")... > Failed to mount /dev/vda2 (type xfs) on /tmp/dissect-h21Wp5 > (MS_RDONLY|MS_NODEV ""): Device or resource busy > Failed to mount dissected image: Device or resource busy > Failed to read /etc/hostname: No such file or directory > /etc/machine-id file is empty. > (sd-dissect) failed with exit status 1. > Failed to acquire image metadata: Protocol error > [Inferior 1 (process 8608) exited with code 01] > (gdb) quit > > > Looks like it wants to mount root, but it's already mounted and hence > busy. Btrfs lets you do that, ext4 and XFS don't, they need to be bind > mounted instead. Just a guess. OK, so this is misleading. "systemd-dissect" does two things: first it tries to make sense of the partition table and what to do with it. Then it tries to extract OS metadata from the file systems itself (i.e. read /etc/machine-id + /etc/os-release). The latter part fails for some reason (probably because the mount options are different than what is already mounted, some file systems are more allergic to that than others), but that shouldn't really matter, as that is not used by systemd-gpt-generator. Hmm, one question, which boot loader are you using? Note that the ESP mounting logic only works if the boot loader tells us which partition it was booted from. This is an extra check to ensure that we only mount the correct ESP, the one that was actually used. In other words, this only works with a boot loader that implements the relevant part of https://systemd.io/BOOT_LOADER_INTERFACE.html i.e. the LoaderDevicePartUUID efi var. We probably should document that better in systemd-gpt-generator(8) though, could you please file a bug about that? In other words: use sd-boot, and all that stuff just works. With grub it doesn't, it doesn't let us know any of the bits we want to know. Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel