On Sat, 08.03.14 08:16, Andrey Borzenkov (arvidj...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
