Re: EFI loader partition unknown

[Chris Murphy <lists@xxxxxxxxxxxxxxxxx>]

On Wed, May 8, 2019 at 3:52 AM Lennart Poettering
<lennart@xxxxxxxxxxxxxx> wrote:
>
> 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

GRUB which I think is mainly as a bootmanager and to support Secure
Boot, and EFI STUB as the actual bootloader.

> 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

I'm willing to bet 99% of the world's computers have one ESP. In fact
I'd be surprised if it's even 1% that have 2 or more. I'm not
convinced the UEFI spec really sanctions 2 or more ESPs even if it's
not outright proscribed. The language of the spec consistently says
there's one.

> 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.


OK requiring a specific bootloader really isn't consistent with the
language used in the discoverable partitions specification. If in
reality what's needed to automatically mount to /efi is not only a
partition type GUID but some bootloader specific metadata inserted
into memory at boot time, that's not a generic solution like the other
discoverable partition types.
https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/



-- 
Chris Murphy
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel