set-default - caution

[jlittle]

I came across btrfs subvolume set-default a couple of weeks ago, after seeing a reference to snapper using it to restore to a snapshot.

Beware, there are pitfalls here. I blundered into a couple, both causing a failure to boot.

The "default subvolume" is normally set to the btrfs root, subvolume id 5. I mucked about with this to see what it would do, and it's tricky in that setting it has no effect until the next time the btrfs is mounted. So, I could screw things up, and found out about it a week later when Kubuntu failed to boot.

The "subvol=" and subvolid=" mount options override the default subvolume, and that can lead to inconsistencies. grub presently generates "rootflags=subvol=" on the linux command line, which become the mount options the kernel uses. I don't know how snapper-rollback gets around that. I've seen posts where the poster removes that phrase in grub.cfg to enable boot from the default subvolume.

So, I (misguidedly) set the default subvolume to be the root of the install I want to boot by default... That was fine till I tried to do a fresh install of kinetic to try it out, same as I have every release for years, expecting it to install into @ and @home as usual. The installer put @ and @home into the default subvolume, which should have been ok, but then went a level up, (leaving @ empty) then deleted most of /usr, /var, /snap and /etc, and crashed. Ok, the installer crashed, it's pre-release, whatever. But the next day, Kubuntu didn't like it at all that most of it had been deleted. I could quickly restore from a snapshot (though I wasted time trying to copy files over).

Setting the default subvolume should be a cool way to control where the install goes, but I'm not sure the installer will cope.

[GreyGeek]

Near the bottom of the first post in the BTRFS subforum is a warning against using "set-default".
It is a shorthand version of the warning here:

The btrfs-tools command ''set-default'' will break Ubuntu's layout

Since Ubuntu is set up to always keep the top of the btrfs tree as the default mounting subvolume it will break when using the btrfs-tools command set-default, since this command is specifically designed to change the default mounting subvolume.

The mount options for / and /home described above relies on the fact that the corresponding subvolumes @ and @home can be located below the default mounting subvolume, and if set-default is used, this is no longer the case.

If you have accidentally used set-default and want to revert, you can do the following
sudo mount /dev/sdX# /mnt
sudo btrfs subvolume set-default 5 /mnt

since the id 5 is a permanent alias for the top of the btrfs tree.

[jlittle]

Thank you; I probably read that years ago but likely didn't remember it because I didn't understand it at the time. I should re-read that post.

...relies on the fact that the corresponding subvolumes @ and @home can be located below the default mounting subvolume, and if set-default is used, this is no longer the case.

I don't understand that last assertion; why can't @ and @home be just that, located below the default mounting subvolume, wherever it is? Maybe it's that the kernel command line "root=" phrase (typically on the "linux" command in a grub entry) and the /etc/fstab entry for /home would be complicated.

My researches to fix this have led me to adopt the Arch recommended set up of snapper. Snapper puts its snapshots in /.snapshots, which breaks snapper if one reverts to a snapshot (whether a snapper snapshot or not), because the snapshots remain in the subvolume where they were created. In the Arch set up, one uses a separate subvolume @snapshots which is mounted on /.snapshots for snapper to work with.

On other distros snapper continues to develop and do more, and I expect it will become part of systemd; but I prefer to only use the automatic snapshotting and automatic clean up. If I'm doing drastic things like rolling back to a previous state, potentially trashing a lot of work, I think it's better to do it manually.

[GreyGeek]

I make all of my snapshots and rollbacks using either my bash script or manually. I alway plug in my external SSD and run the script to create a snapshot under /mnt/snapshots and I send a copy of it to /backup, my external SSD, which I unplug when it is done. Then I run another script to mount /mnt again and this time the internal 1TB SSD. I use "btrfs send -p ..." manually to make a copy to the internal SSD archive. My external SSD is 500GB and keeps about 7 days of snapshots. The internal SSD holds about 12 or so snapshots. Both use less than half of the space available.