Description of problem: As part of the Secure Boot feature, a new utility called mokutil is being provided to allow enrolling of user certificates into UEFI. This utility relies on the efivarfs filesystem to create and modify UEFI variables. The f18 and rawhide kernels have carried a backport of efivarfs for a few versions now. This is mountable manually, but systemd should mount it by default on machines booting from UEFI (regardless of Secure Boot status). Version-Release number of selected component (if applicable): systemd-195-10.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot a UEFI machine 2. Look at /sys/firmware/efi/efivars and notice it is empty 3. mount it manually with sudo mount -t efivarfs none /sys/firmware/efi/efivars Actual results: Filesystem needs to be manually mounted Expected results: systemd should mount it automatically for UEFI machines Additional info: The proper mount point is /sys/firmware/efi/efivars A brief discussion with Peter Jones and Matthew Garrett lead to two possibilities. 1) Create a systemd service/target file to do this or 2) have systemd do this internally. Matthew seems to think systemd should do this internally by default for UEFI machines. The efivarfs filesystem is scheduled to go upstream with the 3.8 kernel, but Fedora is carrying a backport of it in both F18 and rawhide.
Proposing this as an F18 NTH bug.
Already implemented in upstream v196. There will be a rebase of systemd in F18 to at least this upstream version after the F18 release. Related upstream commits: http://cgit.freedesktop.org/systemd/systemd/commit/?id=f271dd97622b656c1c013d181ea615c671cc2438 systemd: mount the EFI variable filesystem http://cgit.freedesktop.org/systemd/systemd/commit/?id=3dfb265083347cb5700dc38f7cc0f479f378e6e9 kmod-setup: mounting efivarfs, *after* we tried to mount it, is pointless http://cgit.freedesktop.org/systemd/systemd/commit/?id=6aa220e019f9dffd96590b06b68f937985204109 mount-setup: try mounting 'efivarfs' only if the system bootet with EFI
(In reply to comment #1) > Proposing this as an F18 NTH bug. I take it that a post-GA fix is not enough and you want me to backport the upstream commits for F18 GA. Is that right?
(In reply to comment #3) > (In reply to comment #1) > > Proposing this as an F18 NTH bug. > > I take it that a post-GA fix is not enough and you want me to backport the > upstream commits for F18 GA. Is that right? Theoretically this could go out as a zero-day F18 update without too much issue. That's why I proposed it as NTH instead of blocker. I'll leave it to the systemd developers to decide how invasive those changes are and whether or not to include them in GA.
Discussed at 2012-12-19 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-19/f18final-blocker-review-6.2012-12-19-17.02.log.txt . Rejected as NTH on the grounds there's no indication this can't just go out as a 0-day perfectly well. We note this is a bit inconsistent with our decision to take https://bugzilla.redhat.com/show_bug.cgi?id=886199 as NTH, but it is now later in the process (NTH bar gets higher the later we get) and on that bug we had input from pjones that he wasn't totally sure it was safe to go out as a 0-day.
systemd-197-1.fc18.1 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2013-0655/systemd-197-1.fc18.1
systemd-197-1.fc18.1 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.