LWN: Comments on "Poettering: The Wondrous World of Discoverable GPT Disk Images"

Painting yourself into a corner with GPT UUIDs

Gladrim — Thu, 17 Jun 2021 11:46:12 +0000

Seemed more like the OP admitting his bias than any kind of personal attack.

Painting yourself into a corner with GPT UUIDs

roblucid — Thu, 17 Jun 2021 08:54:49 +0000

As a former sysadmin, these kind of automatic systems seem nice until something goes wrong, then you find yourself with a system that syncs up to the wrong disk. Under pressure you have no idea why and you have to rebuild the system part from scratch. Hopefully you maintained a clear seperation of user data and can get the service back fast on a duplicate server.

The auto part doesn't help the admin much, but it means replacing OS disks requires an understanding of these developer's specs.
Lennart unfortunately in the past stubbornly insisted that /usr had to be in the same partition as / and said no one bothered with disk partitions on modern systems. OpenSUSE actually solved it simply by mounting & remounting /usr as part of the ram disk startup, which showed it was perfectly feasible to be more flexible.
I still don't see any focus on solving other people's problems in the blog, it's about defining HIS configuration data as a standard and making systemd implementation easier.

The big mistake was SysV's move away from /etc config files for scripts and hidden state.
Instead of human readable config tables used by a daemon, slow inefficient scripts had to be run to change my and update state. It stymied GUI admin programs because there wasn't a single source for the data they needed to manipulate.

Painting yourself into a corner with GPT UUIDs

roblucid — Thu, 17 Jun 2021 08:14:45 +0000

But, when migrating systems I would often boot an OS on a different disk from the boot manager.
Switching onto a newly prepared disk, might mean booting the old OS partition in the case of an oversight.
The irony is that fstab(5) was designed as the mount(8) configuration file, it is by definition machine readable but convenient for a competent sysadmin.
When SysV and Solaris "improved" BSD style config files the result was a mess, it actually worsened configuration visibility by hiding state in data files. To understand a running system remotely, I'd have to run a utility to display the disk partitions.
To me Lennart is trying to optimise for an installer that is run once, or maybe never (I used to clone machines with dd(1)).
The installer creates an fstab(5), it could create the GRUB file too, Linux mount was able to use labels or uids.

Poettering: The Wondrous World of Discoverable GPT Disk Images

lsl — Wed, 16 Jun 2021 14:53:39 +0000

> and could normally be disabled on bare-metal unless you really *were* in a dynamic networking environment;.

Not at all. Without something like biosdevname or the PredictableInterfaceNames thing, your interface names may be shuffled around at every other reboot on many, if not most, servers (basically everything with >1 NIC).

It's unnecessary for VMs with a single network interface, but just don't use it there? Eth0 is what you get by default when using the Fedora and EL cloud images, so nothing to do there.

Poettering: The Wondrous World of Discoverable GPT Disk Images

intgr — Wed, 16 Jun 2021 12:05:49 +0000

> There have been a lot of silly notions coming from the author of systemd over the years that we now have to deal with on the ground.

OK you had one example. But what are the other ones?

When it comes to interface names, I sort of emphatise with both sides: it seemed like a problem worth solving, and I think they did a decent job given the constraints, but I also see how it needlessly complicates configuration in places that don't need it.

I've read most articles on Lennart's blog and from my point of view nearly all of the changes he describes are improvements. Not saying perfect, but they're finally working on areas of Linux that were previously neglected for decades.

Painting yourself into a corner with GPT UUIDs

nix — Tue, 15 Jun 2021 18:19:22 +0000

> The GPT autodiscovery logic described in the article will only automount partitions from the same physical disk whose bootloader was booted from. Am I missing something?

No, I was. It should even be safe if you accidentally boot from the wrong disk: a consistent set of fses will be picked regardless. (Well, as long as neither system uses /etc/fstab but only systemd mountpoint generators, which describes precisely zero systems I have ever seen, and will probably only be able to handle simple cases in any case -- but of course, that describes most systems, and almost all non-server systems. My laptop has one big fs, even if the server has dozens.)

Poettering: The Wondrous World of Discoverable GPT Disk Images

tzafrir — Tue, 15 Jun 2021 11:13:16 +0000

Elsewhere in the "VM" space, Xenserver tried to tackle the same issue. They added a mechanism to keep persistent interface names for eth* network interfaces. It worked.

... by renaming them to temporary names when they appear and then renaming them back "when they all appeared" (on an explicit run of a specific program).

And this is only one of many kludges attempting to maintain persistent names for eth* interfaces.

Poettering: The Wondrous World of Discoverable GPT Disk Images

bluca — Tue, 15 Jun 2021 09:43:44 +0000

New architectures are added as needed. Nobody requested the ones you mentioned so far. If they support GPT and you need support for them, please send a PR.

Poettering: The Wondrous World of Discoverable GPT Disk Images

geert — Tue, 15 Jun 2021 09:39:26 +0000

CONFIG_EFI_PARTITION defaults to yes since commit 5f6f38dbb0fc8518 ("partitions: enable EFI/GPT support by default") in v3.8, under the premise that GPT is now (2013) commonly used.
Looking at the defconfigs, only some old m68k and MIPS machines, microblaze, and riscv nommu disable it explicitly.

Poettering: The Wondrous World of Discoverable GPT Disk Images

farnz — Tue, 15 Jun 2021 09:28:54 +0000

It's the architectures that can use UEFI to boot - GPT is the UEFI partition format.

PowerPC and S/390 don't boot via UEFI, hence omitted.

Poettering: The Wondrous World of Discoverable GPT Disk Images

geert — Tue, 15 Jun 2021 08:45:45 +0000

For now, this seems to have support for only a subset of architectures capable of running Linux: x86, x86-64, arm32, arm64, ia64, rv32, rv64.
No idea why ia64 made the list, while e.g. powerpc and s390 are missing.

Poettering: The Wondrous World of Discoverable GPT Disk Images

jamesh — Tue, 15 Jun 2021 03:13:00 +0000

This kind of reminds me of the mount scheme of some pre-Fedora versions of Red Hat Linux, where volume labels would be set to preferred mount points, and the /etc/fstab file identified file systems with e.g. "LABEL=/home". While it fixed the problem of file systems changing device name when moving disks from one controller to another, it really didn't work well if you had two installs connected to the same computer, and was replaced by the UUID system most distros use today.

This spec seems to cover the common failure modes of that old scheme, so could be quite useful. Outside of containers/VMs, the behaviour of picking the newest root file system if multiple ones are found on the disk should be quite useful for transactionally updated embedded systems. All that's really needed is something to automatically revert to the old image if booting the new one fails.

Poettering: The Wondrous World of Discoverable GPT Disk Images

rahulsundaram — Tue, 15 Jun 2021 02:25:24 +0000

> My original point stands

I don't think it does. Going back to what you originally said:

> Remember when we dropped eth0 being your ethernet interface on simple VMs because Lennart was concerned about laptop wifi?

1) Laptop wifi was certainly not used as rationale for the udev change and you have conceded as much already.
2) It wasn't driven by Lennart and you have now admitted to that as well. When you use specific names, it has to be meaningful. Otherwise, making it personal isn't justifiable.

You might not like the change personally and it is neither here nor there but you have to be accurate about your characterization.

Poettering: The Wondrous World of Discoverable GPT Disk Images

jccleaver — Tue, 15 Jun 2021 02:17:05 +0000

> Laptops were not used a justification anywhere that I am aware of.

Laptops were the use-case cited for a number of low level infrastructure changes around this time intended to make networking better in dynamic environments. That's all fine and dandy, but server admins don't need or want this. So-called "predictable interfaces" were anything but, especially in an era when kickstart servers were the most likely provisioning method in use in the RH ecosystem.

> It came from Dell called Biosdevname and was driven entirely by server concerns and it landed in Fedora 15

I'm aware of this. Was running a Dell shop both before and after this was introduced (although mostly in EL land, not running Fedora Server for the most part). biosdevname was useful only in very specific situations, and could normally be disabled on bare-metal unless you really *were* in a dynamic networking environment. This was the exception, not the rule. Regardless, it was inapplicable to VMs.

> Also it was driven by Kay Sievers as the udev maintainer and not Lennart.
The "systemd cabal" is one and the same here for all intents and purposes.

My original point stands: A variety of "silly notions" ended up affecting everyone because they wanted to make weird special use cases easier. In the networking example, replacing the mostly-predictable "eth0" with a unique string on any given box, e.g. "enp5s0", and justifying the increased complexity on being able to swap out a blown NIC (?!) was not a win. I brought it up my first comment because replacing existing partition mechanisms (which mostly work), or even human-readable LVM labels, with UUIDs I have to look up strikes me as a similarly unjustified normalized obfuscation. And there's a history of "optional" things getting steadily less optional.

Poettering: The Wondrous World of Discoverable GPT Disk Images

jccleaver — Tue, 15 Jun 2021 02:03:40 +0000

> These people have obviously never installed a second Ethernet card in a computer and noticed that their eth0 is now suddenly eth1 and all their routing tables and firewall rules no longer work right

I have installed many a NIC in a physical machine, and much more rarely had to add in virtual network hardware. If I'm re-arranging hardware like that, I'm *expecting* there to be the possibility of side-effects, but most of that was avoided by using MACs properly. And on the VM side, you'd either remove hardware address affinity, or make sure you're moving the MAC around during a VMotion. It's not complicated, and the few annoyances out there were handled easily enough. For every one server with 6 NICs we had hundreds of VMs where it didn't mean anything.

> and just as obviously haven't read the “predictable interface names” document to the end where it explains three different straightforward methods for making sure the scheme is not used.

I certainly have; the justifications given are laughably rare, and the workarounds are either:
a) remove the entirety of a config (the systemd way: accept all of our nudges or go off the reservation),
b) roll all of your own names manually (if I'm doing super complex routing I'm already doing this; a single-interface VM doesn't need it), or
c) add to your kernel command line for the rest of your life (including initial installs at first)

This implementation was a needless cluster F of a system that worked fine for 99.9+% of cases, and the added complexity directly led to BZ#1391944.

Poettering: The Wondrous World of Discoverable GPT Disk Images

rahulsundaram — Tue, 15 Jun 2021 02:02:38 +0000

> The "laptop" callout was a bit of hyperbole, but laptops for developers at Starbucks were used as a justification for a variety of Fedora changes that trickled down into EL rebuilds after this time running on servers

You admit now that the laptop claim was hyperbolic but what you stated here still appears to be quite misleading. Laptops were not used a justification anywhere that I am aware of. It is not mentioned in the article you linked to nor in the feature proposals within Fedora. In fact the first naming effort had nothing to do with systemd at all. It came from Dell called Biosdevname and was driven entirely by server concerns and it landed in Fedora 15

https://fedoraproject.org/wiki/Features/ConsistentNetwork...

The udev naming scheme came much later in Fedora 19 and only really took priority in Fedora 21

https://fedoraproject.org/wiki/Features/SystemdPredictabl...

Also it was driven by Kay Sievers as the udev maintainer and not Lennart.

Poettering: The Wondrous World of Discoverable GPT Disk Images

jccleaver — Tue, 15 Jun 2021 01:44:14 +0000

> Don't remember that. Do you have a source for this claim?

https://www.freedesktop.org/wiki/Software/systemd/Predict...

The "laptop" callout was a bit of hyperbole, but laptops for developers at Starbucks were used as a justification for a variety of Fedora changes that trickled down into EL rebuilds after this time running on servers. You'll have to forgive me for thinking that the zillions of Linux VMs out there with the simplest possible ethernet interface setup should be the default use case. All of the justifications listed there are pretty laughable when you consider the collateral effect.

Poettering: The Wondrous World of Discoverable GPT Disk Images

anselm — Mon, 14 Jun 2021 22:23:35 +0000

Remember that for some people, Lennart Poettering is personally responsible for everything they don't like about Linux.

It's true that the “predictable interface names” approach comes from the systemd (or, really, udev) crowd. IMHO predictable network interface names are a good idea in principle, but there are those who appear to take exception to the fact that what used to be eth0 now tends to be called enp2s0 or something. These people have obviously never installed a second Ethernet card in a computer and noticed that their eth0 is now suddenly eth1 and all their routing tables and firewall rules no longer work right, and just as obviously haven't read the “predictable interface names” document to the end where it explains three different straightforward methods for making sure the scheme is not used.

Poettering: The Wondrous World of Discoverable GPT Disk Images

rahulsundaram — Mon, 14 Jun 2021 21:48:12 +0000

> Remember when we dropped eth0 being your ethernet interface on simple VMs because Lennart was concerned about laptop wifi?

Don't remember that. Do you have a source for this claim?

Poettering: The Wondrous World of Discoverable GPT Disk Images

jccleaver — Mon, 14 Jun 2021 21:28:04 +0000

> Nobody (least of all Lennart Poettering) said that this was supposed to replace /etc/fstab in its full generality, which would be a silly notion.

There have been a lot of silly notions coming from the author of systemd over the years that we now have to deal with on the ground. Remember when we dropped eth0 being your ethernet interface on simple VMs because Lennart was concerned about laptop wifi?

The Slippery Slope Argument is not a logical fallacy if there's plenty of slope to induce from. Hesitation is warranted here IMHO.

Painting yourself into a corner with GPT UUIDs

intgr — Mon, 14 Jun 2021 20:07:59 +0000

> It looks like exactly the same advantages, and problems, as automounting RAID arrays
> it can happen unexpectedly when you attach it to an existing machine which already has an fs of the specified type

The GPT autodiscovery logic described in the article will only automount partitions from the same physical disk whose bootloader was booted from. Am I missing something?

As long as the attached disk is a separate disk, there's no risk of unexpected mounts. RAID does not have this advantage, because it spans multiple physical disks.

Poettering: The Wondrous World of Discoverable GPT Disk Images

Pc5Y9sbv — Mon, 14 Jun 2021 19:14:26 +0000

I wonder, would the spec benefit from using a tree of normative namespace UUIDs and hash-based UUID generation, like you can produce using the Python uuid.uuid5(namespace, name) routine? I realized you'd still need a list of recognized UUIDs to be known by a particular instance of the bootloader, since the hashes aren't really reversible. But, this could be easier to manage if it were a simple list of human-readable strings or namespace IDs which can be converted into the UUIDs that will get encoded in the partition tables and bootloaders.

With hashing, you would get deterministic UUIDs for specific mount point scenarios, so you can predict and coordinate usage of UUIDs across drafts or custom builds of the tooling. Depending on how deep you want this to go, you could standardize a namespace hierarchy and hashing scheme to encode binary platform, mountpoint paths, and even mount option strings. The spec, codebase, or build-time tooling could share a human readable table of mountpoints which could be trivially extended by the community, converging on the same UUIDs for the same purposes no matter who first tries to coin a new mountpoint variation.

Question: Does this make UUIDs non-unique?

ausserirdischesindgesund — Mon, 14 Jun 2021 15:49:13 +0000

Makes sense, thanks!

Poettering: The Wondrous World of Discoverable GPT Disk Images

mezcalero — Mon, 14 Jun 2021 15:32:53 +0000

You can have images this way that are truly universal, i.e. work on x86-64 and aarch64 the same way for example. i.e. let's say you prep an nspawn container and want it to be deployable on both your x86-64 and your aarch64 servers. Using this you can easily do so.

Or consider a disk image you can copy to USB and then boot on any kind of system you have handy as long as it speaks UEFI. i.e. think about Apple desktop systems which switched between ppc, x86-64 and now aarch64 in not so long ago time. You could relatively naturally build a single OS image that you then can booth on either of them.

But you know, I don't want to convince you that this is the ideal way to do that, or if it's even a totally worthy goal, but the logic behind it is trivial (we just use different type uuids for each arch), so there's nothing lost if we prep the ground for usecases like this. And at the very least you get a bit of debuggability out of this, since if you fail to make some image boot on your system you can easily figure out if it's because the arch didn't match.

Not that multi-arch is not a new concept. Debian strives to build the whole OS that way, to some degree, and Fedora's multilib kinda goes in a similar direction (though with much weaker goals).

Lennart

Painting yourself into a corner with GPT UUIDs

mezcalero — Mon, 14 Jun 2021 15:24:26 +0000

Oh, and I forgot to say: the automatic logic only looks for the root partition on the disk the ESP used for booting is on. And it looks for the other partitions only on the disk the root partition is on. Thus, if you plug in random stuff then this logic shouldn't care whatsoever.

Painting yourself into a corner with GPT UUIDs

mezcalero — Mon, 14 Jun 2021 15:22:58 +0000

There are multiple safety checks in place: we don't overmount populated dirs. We don't overmount dirs that already are mount points. And anything listed in /etc/fstab is also excluded from the automatic logic.

Lennart

Poettering: The Wondrous World of Discoverable GPT Disk Images

nix — Mon, 14 Jun 2021 14:06:12 +0000

They are common cases that are frequently needed to boot a system. Seems reasonable. Since they're just UUIDs, distros can generate more for distro-specific partitions they might need: e.g. Nix (no relation) might want /nix to have a partition type ID of its own. Because the UUID space is so sparse, they can just do it: there's no need to coordinate with anyone else until and unless they want other systems to recognize a separately-mounted /nix. (Note: I believe Nix doesn't support a separately-mounted /nix in any case: it was just a random example of an OS with a major fs tree which is not /, /usr or /var.)

There is no pretension here to including *every possible* filesystem path. That would both be pointless and impossible. Nor is there any suggestion that this is replacing /etc/fstab: it's just nailing the partition -> mount point mapping into the partition table. (You could generate pieces of /etc/fstab, or systemd mount units, directly from the partition info: indeed, I believe this is what systemd is doing these days. But that doesn't obsolete the idea of having the partition -> mount point info for other mount points in a readable form somewhere outside the partition table! You don't *have* to use this for everything: you just *can* use it for boot-critical things.)

Poettering: The Wondrous World of Discoverable GPT Disk Images

nix — Mon, 14 Jun 2021 14:01:09 +0000

I think this is mostly useful so you can have one container with many concatenated arch disk images on it, and switch easily between them. I know I've wanted that in the past. Mind you, it's not at all a common case: I'm not sure why it belongs in here (which is mostly about making common cases easier), except that recording the arch of the binaries contained on a root filesystem *is* obviously a piece of useful description if you're trying to decide whether to mount that filesystem, so if you can record it without tradeoffs, why not?

Poettering: The Wondrous World of Discoverable GPT Disk Images

anselm — Mon, 14 Jun 2021 13:59:39 +0000

Nobody (least of all Lennart Poettering) said that this was supposed to replace /etc/fstab in its full generality, which would be a silly notion. If it can streamline the 95% of applications that use only a few well-known partitions then that is already a big win. The remaining 5% can still be treated individually by hand because root= and /etc/fstab will continue to work.

Painting yourself into a corner with GPT UUIDs

mgedmin — Mon, 14 Jun 2021 13:58:02 +0000

What happens if my /etc/fstab doesn't have an entry for /usr (because it's part of /), but I attach a USB drive with a GPT that says "mount this thing as /usr please"?

Does the mere existence of an /etc/fstab prevent mounting of things by magic labels? Or is there a safety check where magic-label-based things are only mounted on empty directories?

Painting yourself into a corner with GPT UUIDs

nix — Mon, 14 Jun 2021 13:56:19 +0000

It looks like exactly the same advantages, and problems, as automounting RAID arrays: you can mount them automatically and the knowledge of FS identity follows the FS around without your needing to do anything (which is an unambiguously good thing)... except that *because* this is true, it can happen unexpectedly when you attach it to an existing machine which already has an fs of the specified type. The way the md subsystem fixes this is with an attached hostname which can be specified at mount time, but that won't work here: the firmware has no idea of the hostname and the mounting is possibly not being done by a userspace program we control but by the firmware itself. (It will work if systemd, or another component of normal userspace, is doing the mounting, from an initramfs or something on the ESP -- but if you have that, you might just as well bake in the traditional root fs location. Mind you, this *is* strictly nicer than the traditional root fs location, so it's beneficial regardless...)

Painting yourself into a corner with GPT UUIDs

mtu — Mon, 14 Jun 2021 12:31:13 +0000

The blogpost cites eight different possible uses of the Discoverable Partitions Specification.

OP talks about "Use #2: Booting an OS image on bare-metal without /etc/fstab or kernel command line root=" and its potential pitfalls.

You appear to _think_ OP is talking about "Use #1: Running a disk image in a container", but quoting that part of the blogpost doesn't make it so.

If that's how you approach a complex topic, good luck for your career.

Poettering: The Wondrous World of Discoverable GPT Disk Images

mtu — Mon, 14 Jun 2021 12:20:18 +0000

It's ridiculous in any case to cement a select few paths for partition-automounting, but no others. Since /etc/fstab takes arbitrary paths, this is a step backwards.

Poettering: The Wondrous World of Discoverable GPT Disk Images

zdzichu — Mon, 14 Jun 2021 11:26:58 +0000

/var itself should be a read-write mount, even on R/O system images. Otherwise it's not really a /var, right?
But if you insist on getting a dedicated partition for /var/log, just do it – generate some UUID and open a Pull Request against https://github.com/systemd/systemd/blob/main/docs/DISCOVE...
No guarantee it will work, but at least it will be discussed.

Poettering: The Wondrous World of Discoverable GPT Disk Images

bluca — Mon, 14 Jun 2021 10:08:04 +0000

There's a UUID for /var: 4d21b016-b534-45c2-a9fb-5c16e091fd2d

Poettering: The Wondrous World of Discoverable GPT Disk Images

taladar — Mon, 14 Jun 2021 09:02:47 +0000

It is a bit confusing that they have UUIDs for certain common mount points but not for e.g. /var/log which is very common to put on a separate partition both for read-write support in an otherwise read-only system and to avoid the situation where growing log files fill up the entire root partition instead of "just" /var/log.

Poettering: The Wondrous World of Discoverable GPT Disk Images

gspr — Mon, 14 Jun 2021 08:37:24 +0000

The Wiktionary entry for "natural" lists 13 meanings as an English adjective. Maybe number 4 is illuminating?

"Natural: 4. As expected; reasonable. "

Painting yourself into a corner with GPT UUIDs

rahvin — Mon, 14 Jun 2021 06:24:35 +0000

This post doesn't belong here.

Painting yourself into a corner with GPT UUIDs

motk — Mon, 14 Jun 2021 05:46:35 +0000

Yeah, this is pretty obviously bogus mate. Reconsider.

Painting yourself into a corner with GPT UUIDs

linuxrocks123 — Sun, 13 Jun 2021 23:51:24 +0000

> Maybe it's just me not trusting the blogpost's author even with a reimplementation of true(1)

If Poettering ever reimplemented true, the executable would be over 50MB large; it would have hard dependencies to PAM, systemd, PulseAudio, GNOME, Wayland, and the Java runtime; and, when asked why true didn't work correctly, he would respond with a lengthy argument quoting Thomas Aquinas and claiming his implementation's behavior is actually and obviously correct.