Re: btrfs related option in the debian Installer
Hi Nicholas, thanks for your reply
On 11/26/20 7:23 PM, Nicholas D Steeves wrote:
Hi Pierre-Yves,
Thank you for your interest :-) Reply follows inline:
Cyril, if you have time to skip to the bottom for a problem/question I'd
really appreciate it.
Pierre-Yves David <pierre-yves.david@octobus.net> writes:
Hi Nicolas,
Cyril pointed to you as the person to talk to about btrfs.
Thank you for CCing debian-boot. My username is "sten" and my IRC nick
is "sten0".
I am a btrfs and Debian user and there are a couple of option I would be
happy to have avaible from the installer.
The first one is quite simple, withing the "partition management", there
is a dialog to select mount option. However, the
`user_subvol_rm_allowed` option is not available there. The option is
handy and it would be nice to have a line for it.
I think we should wait a while before doing this one and should not be
encouraging user-initiated snapshots at this time. At a minimum we
should have support for a /home subvolume first. If I understand btrfs
correctly a malicious user can still DOS the I/O from the rootfs
subvolume, similarly to a fork bomb. I'd possibly like to see a
"user_subvol_mk_allowed" mount option, where the default would be "no",
if finer-grained access controls don't materialise soon.
So far, I am not talkiong about anything enabled by default, but having
the option settable in the associated menu during installation.
It is worth noting that right now with default setting, user can create
subvolume, but cannot delete them.
(and I am fine with the "security" implication, having non-privildeged
user volume management is mostly a way to have to rely on `sudo` less in
my context)
The second one is a bit trickier (but not crazy either). I usually
prefer to install my system in a dedicated subvolume (set as the default
subvolume) to allow me to easily do clean snapshot of the system content
with clean snapshot management (ie: outside of the things we
snapshot).
Agreed, and also the current state of no subvolumes is too hard for many
users to migrate from. At some point I should probably write up a doc,
if only for users who installed to btrfs before the future point in time
when we'll install to a rootfs subvolume and have fancy tools to do
next-gen things.
Do you have a step by step guide somewhere ? I usually do this after the
fact by hand, but I suspect some of my se-linux issue could come from that.
I would be nice to have an option to specify a subvolume that should be:
- created
- set as default subvolume for the btrfs volume
This isn't necessary, because "subvol=@rootfs" can be automatically
added to the mount options of the volume chosen for "/". I believe this
approach is better because it's less opaque, and because it appears to
better support future boot environments/bootable snapshots/system restore
points.
This is not strictly necessary, but I found that some tools get confused
by the fact the root of the device and the root of the system are not
the same. So I tend to do both for safety. (unfortunaly I don't remember
which tool). I then explicitly remount the root(of disk) volume
somewhere within my system for management.
- used by the Debian installer to install the system too (should be
trivial once the first 2 are done).
What do you think and how should I proceed if I want to contribute this
kind of changes ?
Well, I'd like to form a btrfs task force team! You're welcome to join
:-)
I have an initial proof of concept MR here:
https://salsa.debian.org/installer-team/partman-btrfs/-/merge_requests/1
It worked in March, but started failing in August or so, and I've had
trouble finding the time to debug the debian-installer. Basically my MR
just creates a non-configurable "@rootfs" subvolume and installs to
that. Everything else can be done post-install.
Ho, having this would be great !
As for the big plan of making btrfs layout and features configurable in
d-i: the three models that come to mind are the d-i code for mdadm, LVM,
and ZFS (if still exists and has been kept up-to-date), with integration
with cryptsetup. Fedora's now defaulting to installing on btrfs, so it
might soon be time to work on this. Previously the problem with making
btrfs volume configuration as visible as mdadm and LVM was that this
would have been an arguably premature implicit endorsement for general
use.
Note that I have been perfectly happy with simply switching etc4 with
btrfs with the current "default" crypt+lvm setup from debian. The main
point of doing so is to have the swap partition in the same crypt block.
Cyril, now the question: Did I miss the memo for a big d-i change that
limited what partman-foo packages could do or make a mistake somewhere?
For btrfs with a rootfs subvolume, the volume needs to be unmounted, and
then remounted. Could this be triggering a d-i error condition?
Thank you,
Nicholas
--
Pierre-Yves David
Reply to: