Hello,
Osamu Aoki <os...@debian.org> writes:
> It is great to have btrfs support with @rootfs. Thanks. I wish if it
> is a bit more verbose on what it does in installer dialogue. This is
> more important if we want to use existing btrfs with something like
> @home-uid1000 in it ;-)
>
You are welcome, and yes, I agree, the current state is definitely
incomplete! By the way, it's cool to hear from someone who is using
user $HOME subvolumes :)
> Anyway, I experienced an unsuccessful install to the existing btrfs
> partition. I had @rootfs-broken-backup in it and I set "btrfs subvolume
> set-default ..." to it. Don't ask me why I did. But this caused d-i
> to stop installation without much error report.
>
Agreed, silent failure is a major problem.
> EXPECTED BEHAVIOR:
>
> 1. Clearly mention the use of subvolume @rootfs in d-i dialogue.
> (This is for both fsck or fsck-less install cases.)
>
The entirety of my reply supposes that you intended 's/fsck/mkfs/'.
Yes, I agree this should be more verbose.
> 2. Check "btrfs subvolume get-default <btrfs-partition>" to be "ID 5
> (FS_TREE)". If not,
> * stop installation with clear message or (reasonable?)
Yes, and this will not break other installed operating systems that use
set-default (eg SUSE, last I checked). Have you investigated whether
Snapper rollbacks necessarily use set-default as well? If so, we will
need to coordinate with Hedeki Yamane.
> * set-default to fix this. (better?)
> (This is for fsck-less install)
>
As you know, I am categorically against this approach.
Within a Debian context, it seems to me that the most typical use-cases
for a shared volume are:
1. Boot environments (like system restore checkpoints). This is a
project that I used to have a lot of energy for, and why I joined
Debian, but I have suffered significant demotivation for a variety of
reasons.
2. A rootfs subvolume for stable, and another rootfs subvolume for
sid, or possibly some other Debian-derivative distribution.
3. Please share what you use them for :)
Why not just:
* Always mount a btrfs volume with subvolid=5 during the subvolume
creation step of a Debian installation to btrfs. The debootstrap
and bootloader steps occur after remounting subvol=@rootfs, so
the bootloader subvol autodetection generates the correct config
for the new installation. If os-prober fails to find other OS on
other bootable subvolumes then that is a bug in os-prober. To
put this option another way: If you want to hide something from
debian-installer, use LUKS, not a default-subvolume...that said,
I seem to remember that the use of default subvolumes, plus
multiple installed OS plays havoc with GRUB.
* To support this policy in an optimal way may also suggest the
creation of a new subvolid=5 view in the default install. By
this I mean the creation of something like /btrfs-admin, which is
subvolid=5 of the device that contains @rootfs, by default, in
all installations.
> 3. Check existance of @rootfs. If exists,
> * stop installation with clear message or (simple)
I believe this is the current best option, and maybe go one step farther
in an advanced installation and emit a message that advanced users will
use to prepare the volume. (ie something like "The Debian Installer
currently requires @rootfs; however, this subvolume already exists.
Please switch to a console and move the existing @rootfs out of the way)
> * make a backup snapshot of @rootfs to some other name and
> remove @rootfs to have clean start. (better)
> (This is for fsck-less install)
>
The Debian Installer cannot guess what the correct action is, and it is
wrong to automatically make an existing working installation unbootable.
Last I checked we didn't even do that to Windows.
Regards,
Nicholas
