Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 23, 2016 18:42 UTC (Sat) by mjg59 (subscriber, #23239)
In reply to: Ubuntu 16.04 LTS (Xenial Xerus) released by linuxrocks123
Parent article: Ubuntu 16.04 LTS (Xenial Xerus) released

efibootmgr (which isn't part of systemd) and mokutil (not part of systemd) at least.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 23, 2016 21:18 UTC (Sat) by linuxrocks123 (subscriber, #34648) [Link] (13 responses)

Those appear to simply be system utilities unlikely to be used in scripts that need the EFI FS to be mounted read-write to do their jobs.

Is your argument that "SystemD mounted efivarfs RW even if it wasn't in fstab, and these utilities need efivarfs mounted r/w?" What of that? The user can just manually remount the FS rw before running that command, right? The Gentoo documentation for efibootmgr explicitly includes the mount command to do exactly that: https://wiki.gentoo.org/wiki/Efibootmgr

SystemD randomly mounting some pseudo-fs not in fstab on its own is not part of any API, and that is not a behavior that it must preserve. I'm sure if Lennart ever decides he doesn't want to mount efivarfs rw, or at all, unless it's in fstab, he'll just not do it and close any bug reports with "See Figure 1". And he'd actually be right for once.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 24, 2016 0:10 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (12 responses)

Yes, you can change behaviour such that users now need to run additional commands before something that used to work works. Doing so would (correctly) be described as breaking userspace. Since it was possible to fix it in the kernel without breaking userspace, we did that instead.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 24, 2016 23:57 UTC (Sun) by linuxrocks123 (subscriber, #34648) [Link] (11 responses)

Dude ... SystemD _IS_ _USERSPACE_. This isn't the kernel system call ABI. This isn't the kernel _ANYTHING_. And _nothing_is_being_broken_! We're talking about a _human_ user, running _rarely_used_ admin tools, having to mount a filesystem before using it, just like is the case with _every_filesystem_!

If anything, SystemD mounting that filesystem without being asked is a bug, even ignoring the "destroy the machine" thing, because /you're not supposed to mount things without being asked to in fstab/!

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 25, 2016 5:17 UTC (Mon) by zlynx (guest, #2285) [Link] (3 responses)

> If anything, SystemD mounting that filesystem without being asked is a bug, even ignoring the "destroy the machine" thing, because /you're not supposed to mount things without being asked to in fstab/!

You might want to tell that to the startup program that runs from inside initrd then. Those often mount /proc, /dev, /sys, etc. also, so that they can assemble the root filesystem. Probably efivars too because you might need to read a boot parameter. And of course the initrd software doesn't read /etc/fstab because the file doesn't exist yet.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 25, 2016 23:08 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link]

Yeah, some initramfs scripts can do some funky things. When I code an initramfs, my philosophy is, if you mounted /proc or /sys because you had to for some reason, you unmount them before switch_root. But not everyone follows that, and it works because everyone kind-of expects /proc and /sys and devtmpfs to sometimes be mounted by random crap -- or, more accurately, no one notices when they are, because they get mounted very quickly anyway. That's sloppy, though, and it's best if we don't add more pseudo-fses to the slop.

Also, btw, initrd has been deprecated for about a decade.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 25, 2016 23:24 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link] (1 responses)

Oh, also: why would you need efivarfs mounted to read a kernel parameter? Wouldn't that be in /proc/cmdline?

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 25, 2016 23:40 UTC (Mon) by zlynx (guest, #2285) [Link]

Initrd, initramfs, potato, potahto.

I was thinking of the case where UEFI is booting an EFI enabled Linux kernel directly without an intermediate bootloader. In that case one way to pass data to the initramfs image is through EFI variables.

You can of course rewrite the boot entry to set the kernel command line but it seems safer to use other variables to reduce the risk of becoming unbootable.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 25, 2016 5:43 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (5 responses)

So if systemd made a change that required people to rewrite their deployment scripts and meant a bunch of documentation was no longer accurate, you'd be fine with that? Because that's kind of a controversial position.

(And just in case there's a question here: I wrote efivarfs. I expected init systems to mount it read/write. That was the entire point)

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 25, 2016 5:53 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I love systemd, but in this case I'm kinda against it.

It's clear that efivars appears to be dangerous, so maybe it's better to try evasive actions like not mounting it until it's absolutely necessary (autofs?).

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 25, 2016 6:06 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

efivarfs has been modified such that this kind of accidental damage is impossible, and the patches for that have gone back to every stable kernel.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 25, 2016 22:45 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link] (2 responses)

Efibootmgr does not appear to me to be the kind of utility likely to be used by a script. Even if it were, my position would still be, better to break scripts than brick computers. You keep mentioning that the kernel fix has been released and backported; that's great, and, if SystemD can verify it's running on a kernel with the fix, then by all means mount efivarfs rw. But first priority always has to be "don't destroy the hardware".

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 25, 2016 22:53 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

efibootmgr is part of my deployment scripts. I'm not alone in this.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 28, 2016 17:05 UTC (Thu) by josh (subscriber, #17465) [Link]

> Efibootmgr does not appear to me to be the kind of utility likely to be used by a script.

The scripts multiple distributions use to make the system bootable (e.g. installing the UEFI version of GRUB) require efibootmgr.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 25, 2016 13:31 UTC (Mon) by SEJeff (guest, #51588) [Link]

Dude, you realize you're speaking with Matthew Garrett, right? Someone who knows these systems inside and out demonstrably better than you do, or likely ever will.