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

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Thorsten Schöning
Hi all,

during installation of Ubuntu 16.04 LTS Server I could choose manual
partitioning and create a /-partition using BTRFS. The installer
automatically mapped that to creating one subvolume called @ for /
itself and and another one called @home for /home.

That doesn't seem to be the case anymore for UB 18.04 LTS Server, I
only managed to get one BTRFS subvolume for / itself if I only create
one partition. It seems I'm able to create multiple different
partitions with different mount points, but I prefer the former
behaviour of one partition containing multiple subvolumes.

Am I'm doing something wrong or do I miss something in the
installer-usage or does have things simply changed for some reason? In
case of the latter, is there any discussion somewhere on why that was
changed? Did the former setup have any downsides that needed to be
addressed with the new release? Are there maybe any plans to restore
the old behaviour if the new installer has matured?

I couldn't find any such discussion myself, only descriptions about
the old behaviour[1] of UB 16.04.

Thanks!

[1]: https://wiki.ubuntuusers.de/Installieren_auf_Btrfs-Dateisystem/

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning       E-Mail: [hidden email]
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

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

Tom H-4
On Sat, Sep 29, 2018 at 12:51 PM Thorsten Schöning
<[hidden email]> wrote:

>
> during installation of Ubuntu 16.04 LTS Server I could choose manual
> partitioning and create a /-partition using BTRFS. The installer
> automatically mapped that to creating one subvolume called @ for /
> itself and and another one called @home for /home.
>
> That doesn't seem to be the case anymore for UB 18.04 LTS Server, I
> only managed to get one BTRFS subvolume for / itself if I only create
> one partition. It seems I'm able to create multiple different
> partitions with different mount points, but I prefer the former
> behaviour of one partition containing multiple subvolumes.
>
> Am I'm doing something wrong or do I miss something in the
> installer-usage or does have things simply changed for some reason? In
> case of the latter, is there any discussion somewhere on why that was
> changed? Did the former setup have any downsides that needed to be
> addressed with the new release? Are there maybe any plans to restore
> the old behaviour if the new installer has matured?

It depends on which installer you use.

If you use the default subiquity installer, you get your current setup.

If you use the no-longer-default d-i installer, you get the previous setup.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

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

Thorsten Schöning
Guten Tag Tom H,
am Samstag, 29. September 2018 um 16:42 schrieben Sie:

> If you use the default subiquity installer, you get your current setup.
> If you use the no-longer-default d-i installer, you get the previous setup.

How do I switch between both? Do you know any reasons why things have
changed?

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning       E-Mail: [hidden email]
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

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

Tom H-4
On Sat, Sep 29, 2018 at 5:29 PM Thorsten Schöning <[hidden email]> wrote:
> am Samstag, 29. September 2018 um 16:42 schrieben Sie:


> Guten Tag Tom H,

Guten Abend!


>> If you use the default subiquity installer, you get your current setup.
>>
>> If you use the no-longer-default d-i installer, you get the previous setup.
>
> How do I switch between both? Do you know any reasons why things have
> changed?

Ubuntu's changed its default installer from Debian's d-i to its own
subiquity. The latter uses a different, new preseeding system, curtin.

If you look at the files with "curtin" in their names under
"/var/log/installer/", you'll see the yaml format of the preseed files
(like the yaml files that netplan's been using for the last few
releases). I have no idea how to use them to preseed a pxe install
with curtin, the way that you can with d-i (and with
kickstart/anaconda in the RH world), or even whether it can be used in
that way, but it's interesting (to me!) to see what the installer's
being fed. Compared to a d-i preseed, the partitioning directives, for
example, aren't obtuse.

The ISOs are available at these URLs:

subiquity
http://releases.ubuntu.com/bionic/

d-i
http://cdimage.ubuntu.com/releases/bionic/release/

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

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

Thorsten Schöning
Guten Tag Tom H,
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 bhehaviour 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 behaviour
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 behaviour 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 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 behaviour 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

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning       E-Mail: [hidden email]
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

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

Rashkae-2
On 2018-09-30 07:51 AM, Thorsten Schöning wrote:

>
> But recently I recognized that UB 18.04 changed its default behaviour
> 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 behaviour once
> again in the near future.
>
>

I know for all intents and purposes, it works out that way,, but Ubuntu
did not change the default file layout. They changed the default
*Installer*.  Previous versions of Ubuntu Server used the Debian
installer,  for 18.04, they switched to the far less capable Ubiquity,
(or whatever they call it), GUI that they have been using for Desktop
install.  If you download the Server image prepared with the Debian
installer, it behaves just the same as before.. (though watch out for
ifupdown no longer installed by default, and if you install a desktop
over your server install, Network Manager is left with Ethernet
explicitly disabled from it's purview.. just a few of the 18.04 wtf's,,
but now I'm ranting off topic, sorry.)



--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

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

Tom H-4
In reply to this post by Thorsten Schöning
On Sun, Sep 30, 2018 at 1:53 PM Thorsten Schöning <[hidden email]> 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.)

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

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

Rashkae-2
On 2018-10-02 09:46 AM, Tom H wrote:

> - 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);
>

Actually, yes, @home is mounted after root, it's not a subvolume of /
both / and /home are subvolumes that exist on the same device... (you
can think of it as a traditional 2 partition scheme.  Mechanically, for
fstab, it works the same way.  The only difference is the use of
subvol=@ and subvol=@home options instead of device partition numbers.

That being said, I would think fixing the dependencies of systemd units
so that whatever it is waits until file systems are mounted would be a
better approach.



--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

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

Tom H-4
On Tue, Oct 2, 2018 at 4:24 PM Rashkae <[hidden email]> wrote:

> On 2018-10-02 09:46 AM, Tom H wrote:
>>
>> - 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);
>
> Actually, yes, @home is mounted after root, it's not a subvolume of /
> both / and /home are subvolumes that exist on the same device... (you
> can think of it as a traditional 2 partition scheme. Mechanically, for
> fstab, it works the same way. The only difference is the use of
> subvol=@ and subvol=@home options instead of device partition numbers.
>
> That being said, I would think fixing the dependencies of systemd
> units so that whatever it is waits until file systems are mounted
> would be a better approach.

I set up an 18.10 VM using the d-i installer.

I hadn't thought of the fact that @home is fsck'd. Strangely so, given
that fsck.btrfs is a no-op.

So "home.mount" depends on being fsck'd before being mounted.

But it has "Before=local-fs.target" so it should be mounted before any
user units are run.


root@localhost:~# cat /run/systemd/generator/-.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target

[Mount]
Where=/
What=/dev/disk/by-uuid/14dfb82d-ecd9-4803-9035-ac7c47fbfac0
Type=btrfs
Options=defaults,subvol=@


root@localhost:~# cat /run/systemd/generator/home.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target
Requires=systemd-fsck@dev-disk-by\x2duuid-14dfb82d\x2decd9\x2d4803\x2d9035\x2dac7c47fbfac0.service
After=systemd-fsck@dev-disk-by\x2duuid-14dfb82d\x2decd9\x2d4803\x2d9035\x2dac7c47fbfac0.service

[Mount]
Where=/home
What=/dev/disk/by-uuid/14dfb82d-ecd9-4803-9035-ac7c47fbfac0
Type=btrfs
Options=defaults,subvol=@home


root@localhost:~# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @5.985s
└─multi-user.target @5.975s
  └─snapd.seeded.service @3.398s +2.575s
    └─snapd.service @2.947s +447ms
      └─basic.target @2.943s
        └─sockets.target @2.939s
          └─snapd.socket @2.908s +26ms
            └─sysinit.target @2.888s
              └─apparmor.service @1.814s +1.073s
                └─local-fs.target @1.807s
                  └─home.mount @1.796s +10ms

└─systemd-fsck@dev-disk-by\x2duuid-14dfb82d\x2decd9\x2d4803\x2d9035\x2dac7c47fbfac0.service
@1.759s +35ms

└─dev-disk-by\x2duuid-14dfb82d\x2decd9\x2d4803\x2d9035\x2dac7c47fbfac0.device
@1.753s


Changing @home's passno in "/etc/fstab" to "0" should remove the fsck
dependency.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Install via tarball? (Was: Why does Ubuntu 18.04 doesn't create multiple BTRFS subvolumes anymore during installation by default?)

Ken D'Ambrosio
In reply to this post by Tom H-4
On 2018-10-02 09:46, Tom H wrote:

> 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.

I'll bite: how do you do an install via tarball?  I mean, are you just
taking a running system, tarring it up, swiping the MBR/partition table,
and reversing the process afterward?  Or something a bit different?

Just curious,

-Ken

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Install via tarball? (Was: Why does Ubuntu 18.04 doesn't create multiple BTRFS subvolumes anymore during installation by default?)

Tom H-4
On Tue, Oct 2, 2018 at 10:22 PM Ken D'Ambrosio <[hidden email]> wrote:

> On 2018-10-02 09:46, Tom H wrote:
>>
>> 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.
>
> I'll bite: how do you do an install via tarball? I mean, are you just
> taking a running system, tarring it up, swiping the MBR/partition
> table, and reversing the process afterward? Or something a bit
> different?
>
> Just curious,

Basically, yes.

When Ubuntu publishes an lts release (or Debian a stable release), I
use deboostrap to set up a chroot, install/uninstall packages,
customize it as a base for any Ubuntu installation that I'm likely to
make, and tar it up. I then untar it, bring it up in lxc, update it,
and retar it on a regular basis in order to keep it up to date.

For installation, as you describe, I lay down a filesystem, unpack the
tarball, chroot to it, and install a bootloader, etc...

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users