Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 24, 2016 23:57 UTC (Sun) by linuxrocks123 (subscriber, #34648)
In reply to: Ubuntu 16.04 LTS (Xenial Xerus) released by mjg59
Parent article: Ubuntu 16.04 LTS (Xenial Xerus) released

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.