[systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Lennart Poettering]

On Sat, 08.03.14 08:16, Andrey Borzenkov (arvidjaar at gmail.com) wrote:

> > Putting this altogether this should work fine for multi-boot cases. That
> > said, the benefit of not requiring an /etc/fstab is primarily one for
> > simpler "appliance" style disk images where only one OS is installed,
> > not for the super generic full distro cases that want to support every
> > possible storage setup. For example, I wouldn't expect anaconda to ever
> > drop the root= param from the kernel cmdline of its installations. I
> > mean, given that anaconda wants to support booting LVM on LUKS on RAID
> > and iscsi on bonded vlans and whatever else, there's no auto-discovery
> > like this possible anyway, and hence they can just keep the root= in
> > there for everybody...
> > 
> 
> So what is the benefit of creating specification and tools that nobody
> will use? If distributions will have to support explicit filesystem
> configuration anyway, what is the benefit for them to add *additional*
> support for automatic configuration? Especially if this automatic
> configuration is incomplete and has to be augmented with explicit
> configuration anyway.

Again, I am not assuming that being able to drop fstab and root= from
the kernel cmdline is that interesting for super generic full distro
cases. This is mostly interesting for appliance cases. 

However, the spec is not just about the ability to drop these things
from fstab and the kernnel cmdline, it is also about tagging the
partitions nicely in the GPT. And that has quite some benefits for the
generic distros too: it allows container managers such as nspawn or
libvirt-lxc to properly understand a disk image, mount its partitions
and boot it up. This enables true portability of disk images between
bare metal and container setups. 

To be more explicit here: I'd like Fedora to adopt the GUIDs, so that I
can take a fedora installation as a block device, and point nspawn to
it, and i get the thing booted up and working -- at least up to the
point where it depends on external hardware...

Or, to see it from a differen perspective: i want that fedora can prep
disk images that i can test in a container, and then either un them on
bare metal, in a VM or in a cotnaier, and they will always do the right
thing.

And this is actually explained pretty early on in the spec in those
bullet points...

Lennart

-- 
Lennart Poettering, Red Hat