Systemd Adds Feature To Fallback Automatically To Older Kernels On Failure

[Weasel]

If it's writing to disk in recovery mode, then it's broken.

Heck, even outside of recovery mode, that sort of thing is what UEFI's support for storing small amounts of non-volatile OS-set metadata was intended for. (IIRC, Microsoft envisioned it being used for things like "Don't delay the boot with a prompt... just have a "reboot into BIOS menu" option in the OS.)

I'm not sure I follow. systemd-boot supposedly writes a counter (where if not on disk?), so it knows which kernel to load. I don't want it to touch my disk, except for loading the kernel.

[jacob]

Unix principles have nothing to do with UNIX, they are general guidelines for sane software development. The people postulating them happened to be working on Unix systems back then.

Unix principles have nothing to do with reality, they are general guidelines for INSANE software development. The people postulating them happened to be working on Unix systems back then which is why Unix never managed to offer a productive and user-friendly desktop platform.

There, that's probably a lot more accurate.

[ssokolow]

systemd-boot supposedly writes a counter (where if not on disk?)

It can be stored in the motherboard's flash memory. Here's an entry from the "Features" section of Wikipedia's Unified Extensible Firmware Interface (UEFI) page:

Variable services
UEFI variables provide a way to store data, in particular non-volatile data, that is shared between platform firmware and operating systems or UEFI applications. Variable namespaces are identified by GUIDs, and variables are key/value pairs. For example, variables can be used to keep crash messages in NVRAM after a crash for the operating system to retrieve after a reboot.^[37]

As in the example of crash messages, the whole point is to store simple information when it's not safe or not possible to manipulate the hard drives.

...and it's not as if storing a byte-sized counter is going to tax it. As I remember, to qualify for Windows Logo certification, a motherboard must have at least 120K of space for UEFI variables.

[ssokolow]

Unix principles have nothing to do with reality, they are general guidelines for INSANE software development. The people postulating them happened to be working on Unix systems back then which is why Unix never managed to offer a productive and user-friendly desktop platform.

There, that's probably a lot more accurate.

Have you read what they actually are? They're pretty well agreed upon by the software engineering world... it's just that they don't say much about how an OS written by and for programmers in the pre-GUI era must also be friendly to non-programmers in the GUI era. That's outside their scope.

This is how said principles were described in 1978. What specific complaints do you have against them?

1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

In modern terms, you could think of them like this:

1. Build many small, task-specific libraries, rather than one kitchen-sink library. (Unless you're using C++, where the lack of package management is irksome enough to merit all-in-one things like Boost and Qt.
2. Expose an API that allows others to incorporate your work into their own projects.
3. Release early, release often. Start dogfooding your creation as soon as possible and don't be afraid to throw out code that hasn't lived up to its goals.
4. Automate your drudgework, even if it takes a little longer and you don't yet foresee how you might find such scripts useful again later.

Everything beyond that is specific people's interpretations of what those mean, written in the 1990s and beyond.

Heck, the criticism mentioned on the Wikipedia page from 1981 is exactly what I said: That the UNIX Philosophy considers user interface design to be an out-of-scope problem.

(And I don't see that as a problem. I certainly wouldn't expect a set of Human Interface Guidelines to chime in on how to architect an OS kernel. If anything, keeping the UNIX Philosophy narrowly focused on a specific area of interest is perfectly in line with its attitude toward keeping programs narrowly focused.)

[F.Ultra]

This is a sh*t feature. I am running kernel version 4.4 and at some point systemd decides that 4.3 is better for me, and I am left wondering why some driver or software has stopped working, because I don't know about the automatic kernel downgrade.

Exactly how unstable is the kernel expected to be, to come up with such mechanisms?

There is already an option to run an older kernel version at boot. It works well.

That is not how it works. If you are happily running kernel 4.4 then that version is blessed. The boot-counting and reverting to the blessed version only happens when you install a new kernel (at which point only the new kernel is marked for boot counting).

Also this is optional.

[F.Ultra]

Or maybe I don't want systemd to touch or write that stupid counter to my fucking disk. When I go to recovery mode (which happens after the bootloader), there's a reason I want literally ZERO writes to my disk. This will make such thing impossible.

Pathetic feature.

It's the boot loader that performs the write of the counter and not systemd so once you enter recovery mode there will be no writes to your disk.

This is the work flow:

1. The user runs echo 3 > /etc/kernel/tries to enable boot counting.
2. A new kernel is installed. kernel-install is used to generate a new boot loader entry file for it. Let's say the version string for the new kernel is 4.14.11-300.fc27.x86_64, a new boot loader entry /boot/loader/entries/4.14.11-300.fc27.x86_64+3.conf is hence created.
3. The system is booted for the first time after the new kernel is installed. The boot loader now sees the +3 counter in the entry file name. It hence renames the file to 4.14.11-300.fc27.x86_64+2-1.conf indicating that at this point one attempt has started and thus only one less is left. After the rename completed the entry is booted as usual.
4. Let's say this attempt to boot fails. On the following boot the boot loader will hence see the +2-1 tag in the name, and hence rename the entry file to 4.14.11-300.fc27.x86_64+1-2.conf, and boot it.
5. Let's say the boot fails again. On the subsequent boot the loader hence will see the +1-2 tag, and rename the file to 4.14.11-300.fc27.x86_64+0-3.conf and boot it.
6. If this boot also fails, on the next boot the boot loader will see the the tag +0-3, i.e. the counter reached zero. At this point the entry will be considered "bad", and ordered to the end of the list of entries. The next newest boot entry is now tried, i.e. the system automatically reverted back to an earlier version.

[F.Ultra]

It can be stored in the motherboard's flash memory. Here's an entry from the "Features" section of Wikipedia's Unified Extensible Firmware Interface (UEFI) page:



As in the example of crash messages, the whole point is to store simple information when it's not safe or not possible to manipulate the hard drives.

...and it's not as if storing a byte-sized counter is going to tax it. As I remember, to qualify for Windows Logo certification, a motherboard must have at least 120K of space for UEFI variables.

It can but it's not. systemd-boot uses filerenames as a way to keep the counter and does not store a counter as such, from the FAQ:

• Why do you use file renames to store the counter? Why not a regular file? — Mainly two reasons: it's relatively likely that renames can be implemented atomically even in simpler file systems, while writing to file contents has a much bigger chance to be result in incomplete or corrupt data, as renaming generally avoids allocating or releasing data blocks. Moreover it has the benefit that the boot count metadata is directly attached to the boot loader entry file, and thus the lifecycle of the metadata and the entry itself are bound together. This means no additional clean-up needs to take place to drop the boot loader counting information for an entry when it is removed.
• Why not use EFI variables for storing the boot counter? — The memory chips used to back the persistent EFI variables are generally not of the highest quality, hence shouldn't be written to more than necessary. This means we can't really use it for changes made regularly during boot, but can use it only for seldom made configuration changes.

[discordian]

I'm not sure I follow. systemd-boot supposedly writes a counter (where if not on disk?), so it knows which kernel to load. I don't want it to touch my disk, except for loading the kernel.

There is often an amount of nonvolatile registers in basic hardware components, I implemented such a scheme on the Realtime-clock of some SOCs. Also, if there is a spec for bootloaders you probably could implement some few KB of memory that survives a reset.
I dont think systemd will go at such a scheme as it obviously cant keep track across a shutdown, but the real meaty part would be the part thats added in the bootloader spec so atleast the standard bootloaders can deal with fallback-schemes.

[starshipeleven]

I'm not sure I follow. systemd-boot supposedly writes a counter (where if not on disk?), so it knows which kernel to load. I don't want it to touch my disk, except for loading the kernel.

systemd-boot does not have any kind of access to the OS partition as it can only read FAT32 using UEFI's default drivers.

[oiaohm]

I'm not sure I follow. systemd-boot supposedly writes a counter (where if not on disk?), so it knows which kernel to load. I don't want it to touch my disk, except for loading the kernel.

https://github.com/systemd/systemd/b..._ASSESSMENT.md
Its covered here. It writing the counter into the EFI partition by file renames. Personally I would prefer that it started with
filename+3-0 as starting. So the rename by bootloader does not have to change the file name. Even more if the counter was a counter file not the boot information file.

The implementation has allowed for other boot-loaders providing their own versions of boot failure counting.