BTRFS volume is erased by mkfs.btrfs even if it "Format" is unchecked and the volume is initialized.

[Poikilos]

Version: Linux Mint 22 (Wilma)

Steps taken

• I was in a situation where I tried to reinstall over a non-working Linux Mint caused by an upgrade failure (21.3 to 22): Upgrade from mint 21.3 to 22 with some Sury (and winehq and kxstudio) packages installed makes systemd and apt non-functional mintupgrade-legacy#58.
• I read that Ubuntu normally uses @ and @home subvolumes, so I assumed Mint would re-use them
  (https://askubuntu.com/a/1277695/766334).
  • Yeah, I understand assumptions like this are not good, and I'll try not to make them. I was in a rush to get things working, and made some mistakes. Consider though, that the installer should probably not let you make these mistakes (But yeah, I'll take the blame for the root causes of the issue above if it was using both Sury & WineHQ repos).
• I read an article that recommend renaming /usr/sbin/mkfs.btrfs and replacing it with a symlink to /usr/bin/true, but I thought, "There is no way that is necessary. I'll just uncheck format."
• In ubiquity options, I set / to the btrfs volume
• I unchecked "Format" for the btrfs volume.
• result: the installer ran mkfs.btrfs which deleted @ (old /) and @home (old /home).
• I restored my backup but due to Upgrade from mint 21.3 to 22 with some Sury (and winehq and kxstudio) packages installed makes systemd and apt non-functional mintupgrade-legacy#58 it turned out to be incomplete. I didn't know it was incomplete since rsync didn't complete nor show an error due to said issue. Due to the backup being restored (previous /home's files that were occupying unused space being overwritten by the incomplete restore), data recovery attempts failed. I tried btrfscue and UFS Explorer. In UFS Explorer I added the standard MIDI header to the pattern matching settings. The recovery tools found some recoverable files, but not any of the files I actually didn't have. I had to use an older backup for many files, though thankfully I didn't lose significant work (I recovered mostly usable MIDI from FLAC in a few cases and remembered the BPM so that helped, and most of my other stuff is on Nextcloud or git or hadn't changed recently).

Later on, I remembered the last time I did this, I did use the older set of instructions I mentioned above and replaced /usr/sbin/mkfs.btrfs with a symlink to /usr/bin/true, and that worked back then.

• I am not sure I can find the post, but I may have gleaned it from this thread where two people highly recommend doing that: https://bbs.archlinux.org/viewtopic.php?pid=1370237#p1370237

Expected behavior

Do not run mkfs.btrfs on an existing volume when "Format" is not checked. A stopgap solution barring the features below would be to simply not run it, and keep everything else the same. Then at least the user could later manually fix their fstab to mount /home to @home if they wanted in that case, and get their files from @ such as files they want in their old /etc or other folders. Not wiping / is convenient for those of us who can manage it safely (rename /etc, /opt, and /var/www and delete most or all others), and that should be allowed. Having a backup is a separate issue from the convenience of not having to restore it if unchecking "Format" is respected. I know format and mkfs are technically different things, but not erasing it is clearly what is expected--It is misleading and potentially destructive to have a "Format" checkbox that is able to be unchecked if mkfs.btrfs is run no matter what.

A complete btrfs install feature set would include letting the user set mountpoints on subvolumes (Treat them similarly to partitions in the UI).

• By default, set mountpoints on @ and @home btrfs subvolumes to / and /home respectively whether or not each exists, like Ubuntu does.
  • There are no apparent drawbacks since they share the same space by default.
• A solution providing more clarity to the user when the volume doesn't exist or @ and/or @home does not exist (as opposed to creating subvolumes silently) would be to speculatively list @ and @home under the btrfs subvolume in the mount selection screen and allow choosing mountpoints for them (and existing ones, and the volume) whether or not each exists.
• Selectively let the user check each subvolume to format or not.

Then during install:

• Use mkfs.btrfs only if there is no btrfs filesystem yet on each partition marked as btrfs in the custom partition layout UI.
• mkdir /mnt/$UUID (or wherever is ideal)
• mount UUID=$UUID /mnt/$UUID
• For each SUBVOL marked with a mountpoint:
  • If format is checked for it individually, btrfs subvol delete /mnt/$UUID/$SUBVOL, otherwise leave the subvolume intact.
  • If subvolume does not exist at this point, btrfs subvol create /target-brfs/$SUBVOL.
  • Else leave the subvolume intact.

Related issues:

• swapfile is not set correctly with a BTRFS filesystem #78