[systemd-devel] EFI loader partition unknown

Lennart Poettering lennart at poettering.net
Wed May 8 09:52:17 UTC 2019


eOn Mo, 06.05.19 10:26, Chris Murphy (lists at colorremedies.com) 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


More information about the systemd-devel mailing list