[Bug 1993541] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface

[Andreas Hasenack]

Writing up a summary, mostly for my own understanding, and then some
questions at the end.

Old mechanism: /sys/firmware/efi/vars <-- NOT a mount point: normal
sysfs interface for kernel < 6.x. GONE in kernel 6.x

New mechanism: /sys/firmware/efi/efivars <-- efivarfs mountpoint.
Required for kernel >= 6.x. Unsure if there is another way to get efi
variables in /sys without this mountpoint on kernel 6.x. Apparently not.

I have a kinetic box that has both of the above, and it's running kernel
5.x (but after boot: I didn't check the initramfs env). So userspace,
after boot at least, on kinetic/kernel 5.x, is already exposed to the
new efivarfs mountpoint.

Lunar obviously only has the efivarfs mountpoint mechanism available
(kernel 6.x) after boot.

The two mechanisms are different interfaces indeed, it's not just a path
change.

mdadm tries both[1]: first the new, then the old. So it's an example of
software that could behave differently once the new mountpoint is
available in the initramfs environment.

What we need here is for the new mechanism to be mounted in the
initramfs environment under kernel 6.x (which is the "if [ -d
/sys/<newpath> ]" check in the initramfs script snippet provided in this
update). This is not "mounting every deprecated filesystem", but the
opposite: it's mounting the "new" filesystem inside the initramfs.
Before, with kernel 5.x, we would have the sysfs interface present,
whether we needed it or not. It just comes with /sys mounted. Now we
would be just continuing that behavior if we always mounted efivarfs in
the initramfs all the time.

For SRUs, what this change would do is to mount the new pseudo
filesystem, so apps would have two ways to check the efi variables: the
old sysfs-interface one, or the new efivarfs one. And as shown above,
those two are already avaiable in a kinetic box at runtime. But not in
the initramfs environment.

The change the SRU would introduce is that an application like mdadm
that checks first for the new efivarfs mountpoint, and if that fails,
falls back to the old sysfs interface, would from now on actually find
something in that first attempt, and could then change behavior, and run
new code paths that would have bugs we haven't seen yet. So maybe that's
an argument for making this change only in mdadm for SRUs, instead of in
initramfs.

So, I pose these questions:
- for lunar, which is kernel 6.x only, shouldn't this change be in initramfs indeed, as proposed earlier?
- for non-lunar stable releases, right now there is nothing broken, is there? It will be broken once a 6.x hwe kernel starts becoming available (unless it is already) and users install and boot into it. And a non-bootable system is a bad thing, so I can see us trying to prepare for it in advance
- are there other packages besides mdadm which would need efi vars available in the initramfs environment? Perhaps lvm?


1. https://git.launchpad.net/ubuntu/+source/mdadm/tree/platform-intel.c?h=applied/ubuntu/lunar-devel#n560

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1993541

Title:
  initramfs need to mount efivarfs because kernel 6.0 deprecated
  'efivars' sysfs interface

Status in OEM Priority Project:
  In Progress
Status in mdadm package in Ubuntu:
  In Progress
Status in mdadm source package in Jammy:
  In Progress
Status in mdadm source package in Kinetic:
  In Progress
Status in mdadm package in Debian:
  Fix Released

Bug description:
  [ Impact ]

  kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC
  RAID, mdadm needs initramfs to mount efivarfs instead.

  [1] The commit:
  commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741
  Author: Ard Biesheuvel <ardb at kernel.org>
  Date: Mon Jun 20 13:34:03 2022 +0200

      efi: vars: Remove deprecated 'efivars' sysfs interface

  [ Test Plan ]

  1. Install initramfs-tools
  2. update-initramfs -u
  3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs
  4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/
  5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev.

  [ Where problems could occur ]

  Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low.
  Also, there are no impact mounting efivarfs multiple times.
  mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars.

  [ Scope ]

  Jammy

  [ Other Info ]

  The private bug link
  https://bugs.launchpad.net/somerville/+bug/1990231

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1993541/+subscriptions