Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 22, 2016 15:45 UTC (Fri) 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

> could've been when users updated SystemD, which they probably do more often

Why? Stable kernel point releases come out much more frequently than systemd releases, and the kernel fix was backported to all of them. If systemd had changed its behaviour, code that relied on being able to write to efivarfs would have stopped working. The correct choice was made.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 22, 2016 16:28 UTC (Fri) by linuxrocks123 (subscriber, #34648) [Link] (23 responses)

It's myopic to look purely at how often upstream releases things. Distros can and do package and release software that is not yet released upstream, and distros can and do ignore updates from upstream and not release new versions for long periods of time.

There are many systems, I know for a fact VPSes but probably also many others, running kernel 2.6.32, but with modern userspaces. There are also individuals, me included, who have systems that depend on out-of-tree or proprietary drivers and so don't update kernels nearly as often as they update userspace.

The right thing to do was fix it in the kernel, fix it in SystemD, and maybe also fix it in mount.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 22, 2016 16:37 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (22 responses)

Which distros provide updated systemd packages but don't provide updated kernel packages?

> The right thing to do was fix it in the kernel, fix it in SystemD, and maybe also fix it in mount.

If systemd had changed its behaviour, existing userland applications would have been broken. What was your proposal for fixing them?

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 22, 2016 16:55 UTC (Fri) by raven667 (subscriber, #5198) [Link] (5 responses)

I'm not sure any of this matters, the OPs concern is not primarily technical, so a technical argument isn't going to change any minds.

> Btw, I'm really not interested in debating the merits of SystemD. If you like it, use it; have fun; I don't care. But I personally will not allow software made by people this immature/irresponsible to do anything important on systems I maintain

You certainly aren't going to get an "aw shucks, you were right and I was wrong, sorry" out of this. Even the bystanders, who are normally the real target for these kinds of responses, have all the information and have probably made up their minds by now.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 22, 2016 19:54 UTC (Fri) by tao (subscriber, #17563) [Link] (4 responses)

Of course not. The OP's "concern" was to find something that allows for a diatribe against systemd.
If the response to this issue would've been to patch this and thus break userland you can bet that
OP would've used that for a diatribe against systemd instead.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 22, 2016 22:21 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

Dunno if it's this particular bug, but I seem to remember a bug of this magnitude bricking systems that WEREN'T running systemd.

Don't see how you can blame systemd when systems running SysVinit or OpenRC were getting bricked too.

Cheers,
Wol

Ubuntu 16.04 LTS (Xenial Xerus) released

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

That was a different issue - https://mjg59.dreamwidth.org/25091.html

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 22, 2016 23:00 UTC (Fri) by johannbg (guest, #65743) [Link] (1 responses)

Yup and if windows users ran
mountvol p: /S
rm p:\* -recurse
he probably blame systemd for the outcome of that as well . . .

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 23, 2016 19:36 UTC (Sat) by hitmark (guest, #34609) [Link]

But do Windows do so by default? Because one of its internal function needs to have access to one variable in there?

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 23, 2016 14:46 UTC (Sat) by linuxrocks123 (subscriber, #34648) [Link] (15 responses)

What userland applications? Do you mean scripts that use SystemD to set wakeup times on EFI systems being shutdown, or is there something I'm unaware of?

To preserve wakeup time functionality, SystemD could have remounted the FS r/w only when actually performing the write, then immediately remounted it r/o.

Ubuntu 16.04 LTS (Xenial Xerus) released

Posted Apr 23, 2016 18:42 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (14 responses)

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.