Hacker News Reader

Comment by mid-kid | Hacker News Reader

Tbh, the installer was inevitable after systemd integrated a bootloader, crafted a paritioning scheme for autodiscovery, took over user and home directory management, and topped it off with an updater and "system extensions" layering system that some immutable distros are using.

I'm not saying any of this is particularly bad but it's been very clear fot a while that systemd just wants to be an OS. With immutable systems the "distribution" part of it is reduced to a build system, and everything else can be provided by systemd and flatpak.

View on HN

Partition autodiscovery is pretty neat. I did my archlinux install with it using this guide[0]. I have never touched /etc/fstab and I have had zero to worry about corrupting a boot with wrong fstab entries.

[0] https://walian.co.uk/arch-install-with-secure-boot-btrfs-tpm...

Btrfs and zfs don't need an fstab at all, they manage their mountable filesystems internally.

Sure. After you have located root and the boot partition which is what this addresses.

My searches for "systemd partition autodiscovery" lead me to [0]. In the table labeled "Table 1. Partition Type GUIDs", we find this in the Explanation section for 'SD_GPT_HOME'

  The first partition with this type UUID on the same disk as the root partition is mounted to /home/.

...you can't spread your /home and / partitions on separate disks and use this? In fact, it looks like you can't use this autodetection unless all of the partitions of interest (including your /boot/) are on the same disk? Seriously? There's also no indication that this works with LVM... which is -if true- is extremely inconvenient. The document at [1] only mentions LVM in passing, and [2] is Poettering saying "Fuck off, I don't want to support doing this with LVM".

Did I misread a document or fail to find a relevant one? If not, is this really limited to single-disk, "legacy" [3] configurations?

[0] <https://www.freedesktop.org/software/systemd/man/latest/syst...>

[1] <https://uapi-group.org/specifications/specs/discoverable_par...>

[2] <https://github.com/systemd/systemd/issues/1727>

[3] Yes, I'm considering any fixed-partition mechanism, whether MBR or GPT to be "legacy". The flexibility you get from LVM is sooooo nice.

> you can't spread your /home and / partitions on separate disks and use this

No, you'll need to add a line to your fstab manually if you want something autodiscovery cannot do, like multi-disk setups, LVM, and FDE with unsupported configurations. It's great if it works for you and a very minor change if it doesn't.

I don't recall ever installing a system with / and /home on separate partitions, though.

> No, you'll need to add a line to your fstab manually if you want something autodiscovery cannot do...

It's just shocking that autodiscovery is so extremely limited. I'm aware that if you want to do something that autodiscovery can't do, then you cant use autodiscovery for that thing... I'm pretty sure that was covered in a recent Tautology Club meeting.

> I don't recall ever installing a system with / and /home on separate partitions, though.

I'd wager that that's the configuration of vast majority of the consumer systems out there... which makes it even more confusing how anemic partition autodetection is.

Its target user is one who bothers to partition out space for subdirectories, but doesn't use either multiple disks or LVM? That's a very particular sort of user.

> I'd wager that that's the configuration of vast majority of the consumer systems out there...

I'm not so sure. Most people I know, including developers, only have one SSD, maybe a hard drive for photos or whatever that's not mounted inside /home.

The most popular mainstream Linux distributions (Android, ChromeOS, SteamOS) all default to a single disk setup, as do most virtual machines (which must exceed the number of home installs by at least a thousandfold).

For a particular brand of enthusiasts, running multi-disk is definitely more popular (I have 4 in my desktop), but I don't think those are the majority, and even among those splitting partitions across disks rather than just using a /media (or equivalent) to access the larger disk like you would an external drive is quite popular.

Multi-disk detection would be nice, but I can already imagine the absolute mess that would happen if you were to try to boot on a multi-distro PC, or even just a recovery flash drive on an existing Linux image. My recovery boot drive only has a root partition so auto-detecting the drive will work fine, but auto-mounting my home directory to /home would mess up the entire system.

The code would be so full of edge cases and weird guards that it'll inevitably just break without configuration, making the entire thing pretty damn useless.

> I'm not so sure. Most people I know, including developers, only have one SSD...

Right. My intent was to say that a single disk, probably with everything under "/" in a single partition is what the overwhelming majority of personal computers out there are using.

> Multi-disk detection would be nice, but I can already imagine the absolute mess that would happen if you were to try to boot on a multi-distro PC...

This would be trivial if the thing supported LVM. [0] Given that the bootloader needs to use a protocol to tell the automagic fstab creator what is the root device, [1] update that protocol to have the bootloader pass the VG name to search for, and then search for LVs named "$VG_NAME-$MOUNTPOINT" and do the obvious thing. [2] No need to either fuck around with or remember magic GUIDs or worry about what happens when you have multiple partitions with the same magic GUID, and you support all sorts of power-user features for free.

[0] While it's true that I haven't used a ton of Linux installers, every Linux installer I've used for the past ten, fifteen years that offered to let you partition your disk also had an option to set up LVM. I know that many people think that LVM's an "advanced" feature, but it has been around for ages and is well-supported.

[1] <https://news.ycombinator.com/item?id=48727809>

[2] That is, if the bootloader passes in 'gentoovg', you'd do the obvious things with 'gentoovg-root', 'gentoovg-home', 'gentoovg-opt', etc, etc, etc.

> ...you can't spread your /home and / partitions on separate disks and use this? In fact, it looks like you can't use this autodetection unless all of the partitions of interest (including your /boot/) are on the same disk? Seriously?

How would it choose from 2 home partitions on other disks?

A little better than how you'd handle having multiple '/home' lines in fstab? Either pick one to mount, or have the bootloader give a hint as to which one to mount (as there's apparently a whole protocol the bootloader must use for this to work). [0]

But. Having said that, why would you have two home partitions on other disks? Having a bigass disk for your home partition [2] is way more common than having multiple entirely-independent Linux installs that you all want to use this automagic mount point detection on. Do you disagree?

[0] > Note that automatic discovery of the root only works if the boot loader communicates this information to the OS, by implementing the (Boot Loader Interface)[1].

[1] <https://systemd.io/BOOT_LOADER_INTERFACE/>

[2] ...because where else would you store all your porn?

The various Red Hat affiliated projects have so much more reason to call themselves the "OS" than GNU at this point. A Linux system with systemd for the init, systemd-networkd and NetworkManager for networking, GNOME for the desktop, systemd-boot for the bootloader, RPM/DNF as the package manager, etc. probably contains orders of magnitude more Red Hat code than GNU code even if the system uses glibc and GNU coreutils.

Suppose someone wants to play this game, what's the point? Not to mention the fact that Gnome, even though is not a GNU project, literally means GNU Network Object Model Environment.

Can't these features be toggled?

They're separate programs and system services which all more or less just do their own thing, just developed under the systemd umbrella. So it can't be "toggled", you can just not use the parts of systemd you don't want.

But it's meant to work as a cohesive system when everything in systemd is used together.

FWIW, I think it's great that someone is trying to make a coherent set of system services for Linux. Things tend to interoperate better when they're explicitly written to work together than when every component is meant to be hacked to work with arbitrary other services through shell script soup.

It's great that the same someone has formed a company called Amutable which has the sole purpose of converting Linux to a locked-down immutable OS where the users doesn't have the key.

Also it's interesting that a set of simple interfaces have worked for so long. Maybe they did something wrong that it didn't break?

See: https://www.amutable.com

> converting Linux to a locked-down immutable OS

That approach is part of why Valve has been able to ship Linux to general consumers.

I don't know exactly why you'd go for amutable specifically, but not handing users the key is a huge benefit to any company-owned hardware out there.

Having an immutable OS for some scenarios makes sense. However, I find waving the whole layer into systemd and kernel permanently, instead of having it as a layer which you can install and enable if you need so is a bit sinister.

This enables the danger of locking out every Linux distribution out there, esp. with new IPC protocols, new image based installation methods, encryption and whatnot systemd brings in with all these modules.

One day, Microsoft can disallow disabling of secure-boot for PC certification and stop signing 3rd party bootloaders. The rest will be fun.

> instead of having it as a layer which you can install and enable if you need so is a bit sinister

I don't really get it. If you don't want systemd, you can install your own OpenRC-based immutable OS. I don't know if that currently exists (Android does, I suppose? maybe ChromeOS?) but it's not like systemd is forbidding everyone from doing anything.

The biggest difference between systemd and alternatives is that systemd builds out the architecture that makes things like building immutable distros easy. If you have a thousand different components, all with slightly different roles, the amount of coordination necessary to get everything to play nice together makes it near impossible to achieve the same things a coordinated system can achieve.

I'm sure that if someone would build an alternative to systemd-sysext and prepare a prebuilt set of tooling and configuration that does what systemd does, there will be distros that will use them.

Secure boot can be overridden by just adding your own keys. At worst, Microsoft will refuse to boot Windows because you added a key yourself. The exception is extra expensive, specially labeled Enterprime (TM) hardware built for Windows sysadmins and Microsoft tablets built for consumers, but I don't know why you'd buy either if you don't want to give MS that much control.

Lennart Poettering will not rest until all software is completely unusable.

Right, are any of the things mentioned in the GP really required if you only want this init?

I know they've attached all these projects to the systemd brand because they thought it would beneficial but it's hard not to wonder if we could avoid all those discussions if the umbrella project was called something different...

No, you can just run the systemd init system and not use any other systemd programs.

I would probably run systemd-journald just because it's really nice to have a logging system which knows about the system services, but it's not required.

You probably also want to run udev, and logind comes close. Everything other than these four is absolutely optional.

Reply on news.ycombinator.com