fwupdmgr - UEFI ESP partition not detected or configured #1623
Comments
travier
added
kind/bug
fallout/f39
F39-Changes
area/platforms
platform/metal
meeting
|
This is tricky. We likely need to add support to fwupd to understand how FCOS is setup to mount the partition on demand. |
|
Hi all. I'm a bit confused what the issue is -- we do mount the EFI partition on demand as needed... |
|
even with me manually mounting the ESP under NOTE: this is in a VM so it might be an invalid test? |
|
@dustymabe can you attach |
Heh, was just about to post related to this. Naively perusing the fwupd source, it seems like fwupd actually relies on UDisks2 being installed and activated but we don't ship udisks2 in FCOS. Is the expectation that we set e.g. |
|
This is related: coreos/bootupd#132 We also need to support possibly updating multiple ESPs. |
According to https://github.com/fwupd/fwupd/wiki/PluginFlag:esp-not-found
|
|
though I think that wiki page might be out of date. According to ?? |
|
With but with |
|
We discussed this in the community meeting today: |
Then it either needs to be hardcoded or you need to use udisks so that we can use a heuristic to guess the correct device. e.g. ignore
So how is fwupd supposed to mount the partition on demand? |
can you do something like |
This would have helped in coreos/fedora-coreos-tracker#1623
This would have helped in coreos/fedora-coreos-tracker#1623
|
Maybe a dumb question; but why can't FCOS add udisks2? There is a real use case here for mounting a partition dynamically. Isn't the space trade off worth it? |
We don't have but after I layered it on top here is what it shows: Maybe it's because it's |
That's something that would have to be evaluated. |
Maybe! What's the "Type" on the UDisk |
|
Here's as much info that The EFI partition is set to |
Ya, that's what we're looking for. I think the issue now is that we don't have the mechanism in place to mount and unmount the ESP. |
But in the second half of #1623 (comment) I had it already mounted and |
Yeah, adding udisks2 can certainly be discussed. One alternative I think is to have fwupd have a built-in fallback where it does a simpler scan for ESPs, which I understand might not be desirable. Has something like that come up in fwupd already? Another option is enhancing |
Using libparted? I'm not hugely enamoured about adding additional library deps -- and I'm wondering if that package is in FCOS already either! :) |
Furthermore we went through a lot of effort recently to remove extra libraries from fwupd to drop attack surface. It's not the right direction for us to add them back in.
The problem with this is that fwupd still can't mount it if you told it a character device. It uses udisks to do the detection and mounting. A 3rd option is to teach |
Yes, that's an interesting idea. That would ensure bootupd and fwupd are consistent in how the ESPs are found.
OK, I didn't realize udisks2 also took care of the mounting part there. One thing to note though is that we don't want to mount the EFI partition in the global namespace. Hmm, looks like both |
|
We only want one ESP mounted. I like this though, no changes to fwupd. The conffile would just specify /var/tmp/efi or so as ESP location. |
|
One thing of note is that eventually I'd still like to do coreos/bootupd#132 - in which case, bootupd really needs to own mounting the ESP as there could be multiple, and we'd want to ensure synchronization. So we could perhaps add As far as mounting it today, by far the simplest is to assume the ESP is co-located with the root device; situations where it's not seem like they'd be really rare. So scanning the root block device for filesystems with part UUID |
OK, this doesn't quite work actually. It looks like even with
I think the term synchronization here can be misleading so I'll clear some things up just in case. Note that the ESP partitions in the CoreOS RAID1 setup are not RAIDed. See coreos/butane#178 and coreos/fedora-coreos-config#794. But yes, they do need to be "manually synchronized" by ensuring that whatever we do to one is done to the other (coreos/bootupd#132 is about teaching that to bootupd). We could have bootupd abstract over this (I found coreos/bootupd#1 (comment) which suggested this) if we don't want to teach it to fwupd too. But OTOH, I would expect fwupd to also be interested in understanding this setup natively.
I think we can set it aside for now, but I agree with Colin, we really should address this eventually (for bootupd and also for fwupd). Otherwise, it's not well-defined how well fwupd works in such a RAID1 setup. |
|
I think this might be worth a high-bandwidth meeting to discuss the path forward. |
FYI - I'm not against a fwupd change that uses whatever you guys decide (if it's not adding udisks2 to your image). Feel free to open a PR upstream with the outcome. |
This would have helped in coreos/fedora-coreos-tracker#1623
|
What adding udisks2 would mean for FCOS: Edit: A lot of those are recommends that would not be included. Will do a full build to check. |
|
Well, this pulls-in Python: udisks2 -> libblockdev-crypto -> nss -> crypto-policies-scripts -> /usr/bin/python3 |
|
This is udisks2 -> libblockdev-crypto -> nss -> crypto-policies-scripts -> python3 so this is not just about Python but also adding another cryptographic stack (nss) to Fedora CoreOS on top of what we already have (openssl). |
|
So assuming we could hardcode the ESP location in FCOS -- how would fwupd mount it? system("mount /dev/foo") is pretty terrible. How does FCOS deal with disks right now? |
But isn't this a packaging problem? Why do a bunch of scripts get pulled in? |
Mount points are managed by systemd mount units for all normal partitions. We don't have a In previous changes, we removed the mount unit for the ESP:
So ideally, fwupd should unshare the mount namespace and then mount the EFI partition to How it's done in bootupd: We are still missing support for the RAID case however: coreos/bootupd#132 |
Can we ask bootupd to do that for us? I thought that was the thing controlling access to the ESP now? |
|
It's not really controlling access to the ESP but it's the only one besides fwupd that should need access to it. We could extend bootupd to allow fwupd to run a command in a namespace with the ESP mounted for example so that fwupd does not have to "learn how to do it". |
|
fwupd expects that the daemon is mountable/umountable at runtime, not so much a "command". Can we have a dbus interface to let fwupd mount/umount? |
|
Well, kinda -- we could say "write this file descriptor to $ESP/fedora/fw/foo.cap` for example. |
|
Maybe how it should work is that bootupd just offers an API to mount to a specified empty dir, and in the future when we do RAID we'd make it a FUSE mount or so, and synchronize the changes. Or it could be one of the real underlying dirs, but we e.g. always bump the root timestamp, and then know we need to synchronize other copies to the one with the newest timestamp. |
|
Forgive my ignorance, is fwudmgr unsupported at this time? Is there a workaround? |
This comment was marked as off-topic.
This comment was marked as off-topic.
Describe the bug
fwupd is unable to update firmwares as the EFI partition is not mounted anymore in FCOS: #694
See: https://discussion.fedoraproject.org/t/coreos-fwupdmgr-uefi-esp-partition-not-detected-or-configured/97522
Reproduction steps
Expected behavior
Able to update firmwares
Actual behavior
Unable to update firmwares
System details
Bare metal
Butane or Ignition config
N/AAdditional information
The text was updated successfully, but these errors were encountered: