Why does Ubuntu 18.04 doesn't create multiple BTRFS subvolumes anymore during installation by default?

[Tom H]

On Sun, Sep 30, 2018 at 1:53 PM Thorsten Schöning <tschoening at am-soft.de> wrote:
> am Samstag, 29. September 2018 um 19:49 schrieben Sie:


>> Ubuntu's changed its default installer from Debian's d-i to its own
>> subiquity. The latter uses a different, new preseeding system, curtin.
>
> Thanks for your explanation, but that's going a bit in the wrong
> direction. I think my question lacks some background:
>
> In 16.04 the default installer created the subvolumes @ and @home
> within one partition automatically. I'm deplyoing services for
> customers by storing them in /home/some_customer and some of those
> services are managed by systemd to start automatically etc. That
> failed with @home because it was not available during boot for
> systemd[1], so I changed things to how the default behavior of the
> current installer is: One subvolume for / only containing all data.
>
> I'm not using preseeding currently for various reasons and think that
> I prefer the old distinction of @ and @home. That's why I still have
> restoring the old, default setup in my TODOs by changing how I manage
> services of different customers in systemd.
>
> But recently I recognized that UB 18.04 changed its default behavior
> to exactly what I'm using now and I try to follow default
> installations as much as possible. So in theory I don't need to change
> anything anymore, unless UB decides to change their default behavior
> once again in the near future.
>
> And to better being able to decide what to do with my current setup, I
> was searching for the reasons why the default BTRFS-layout has been
> changed and maybe if it's discussed to change it again. SuSE etc. uses
> a lot more subvolumes by default already.

So, if I've understood correctly this time:

- you're not using the 16.04 @/@home default subvolume setup (even
though you'd prefer ti use it) because it's not compatible with your
use of systemd (which is strange because a subvolume of "/" isn't,
AFAIK, a mount that happens later than the "/" mount);

- you're surprised that you no longer have to override the @/@home
scheme with the 18.04 installer because the latter doesn't create
subvolumes.

So all's OK really.


> So while I appreciate your hints about the YAML files and will have a
> look at those, because using preseeding in future is the goal, I would
> first like to be able to understand the decisions leading to the
> current default behavior of UB 18.04. Or just live with what it is
> and I have now if there's simply no particular reason why things have
> changed. :-) I simply didn't find those discussions, bugs or whatever
> myself.
>
> [1]: https://lists.freedesktop.org/archives/systemd-devel/2018-May/040688.html

I have no idea whether a subiquity yaml file can be used the way that
a d-i preseed file can be used. AFAIK, it requires a maas server. I
haven't really looked into it because I started using tarballs to
deploy systems (Debian, Funtoo, Gentoo, Ubuntu), a few years ago.

As for the reason for the switch, I suspect that it's simply that the
default server installer was changed and that it cannot (yet?) handle
btrfs subvolumes. d-i cannot set up subvolumes either, AFAIR; the
Ubuntu d-i team added a script to partman-btrfs to create the @/@home
subvolumes.

The partitioning options available in subiquity are basic. You can use
regular partition and lvm; mdadm isn't available; you cannot
pre-partition a disk and present it to the installer (or switch to a
virtual console, partition it, and switch back to the installer); you
can only use btrfs, ext4, and xfs to format a partition, not zfs. So
there's work to be done. (The networking options are also limited.)