Bug 886208

Summary:	systemd should mount efivarfs by default on UEFI machines
Product:	[Fedora] Fedora	Reporter:	Josh Boyer <jwboyer>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	18	CC:	awilliam, johannbg, lnykryn, metherid, mjg59, mschmidt, msekleta, notting, pjones, plautrba, systemd-maint, vpavlin
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-01-20 03:32:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Josh Boyer 2012-12-11 18:59:45 UTC

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.

Comment 1 Josh Boyer 2012-12-11 19:01:42 UTC

Proposing this as an F18 NTH bug.

Comment 2 Michal Schmidt 2012-12-11 19:03:57 UTC

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

Comment 3 Michal Schmidt 2012-12-11 19:06:22 UTC

(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?

Comment 4 Josh Boyer 2012-12-11 19:10:52 UTC

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

Comment 5 Adam Williamson 2012-12-19 20:54:17 UTC

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.

Comment 6 Fedora Update System 2013-01-14 14:08:59 UTC

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

Comment 7 Fedora Update System 2013-01-20 03:32:28 UTC

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.