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