Use BTRFS to prevent dist-upgrade or new video drivers from trashing your install.

[oshunluvr]

This is not a how-to so functional steps won't be included, this is a discussion about BTRFS and how to use it's features to facilitate a do-release-upgrade (moving to the newest version of Kubuntu from a current one using the "Upgrade" tool) or dist-upgrade/upgrade (upgrading any or all your packages, especially video drivers) in a totally safe way.

I've seen a constant trickle of posts - over many years - about "black screens" and other issues caused by these actions. Let's be clear: Sometimes a new video driver and, unfortunately even more often, do-release-upgrade can break your install. My belief is, if you are actually using your computer and not just playing with it, this is unacceptable. The good news is you can totally prevent this rather than scrambling to repair a mucked installation or having to wipe and start all over.

How? By using the BTRFS file system and it's subvolumes and snapshot capabilities.

Here's how it works and why you should be using btrfs if you're not already:

First, you create your initial install using the Kubuntu installer and choose btrfs for your file system rather than ext4. This will automatically create and use two subvolumes - one for / (root) and one for /home. The default names for these subvolumes is @ for root and @home for home. At this point, when you boot to your install this will be totally transparent to you except when to check your drive space or mount list. Since both subvolumes will reside on the same file system (usually a single partition) both mounts - root and home - you will see separate mounts for home and root but they will have the same UUID and df will show the same amount of used and free space for both.

Now, when it's time to to a do-release-upgrade or install something potentially dangerous like a new video driver, or even just a new piece of software - You make a snapshot of your root subvolume. To do this, you would first mount the parent btrfs file system. This "exposes" the two subvolumes @ and @home to you. A simple snapshot command that takes less than a second to execute creates a copy of @. From here on out, that snapshot remains untouched, just like a photo of you when you were a baby - forever stopped in time.

Moving on, you can now do your dist-upgrade or install whatever.

In the event the action itself causes your system to be unusable or unbootable, you can go into your btrfs file system parent volume and delete your root install subvolume! That's not a typo, just delete it. Then, rename the snapshot to "@" and reboot. It's that simple. In some cases you may have to boot to a liveUSB or another install in order to mount and access the btrfs volume, but that's much easier than trying to wade through your installation upgrade and figure out where or what is broken.

If the action doesn't cause any issues and you're satisfied with the outcome, you may, at your leisure, return to your snapshot location and delete the snapshot to free up any space it's consuming.

This process is so simple and flawless that I do take a snapshot just about every time I install any new software or have 20+ packages to upgrade. The few seconds it costs me are worth the piece of mind. I have created a permanent mount point for my parent btrfs volume and automatically mount it at boot time so I can jump there anytime I need.

BTW, another great use for for this process; Easiest dual-boot setup ever: After you install Kubuntu to btrfs the first time, mount the parent volume and make a snapshot of @. When you make a snapshot, it has to have a different name than the original. Then you enter this snapshot's folders and edit fstab to reflect the new subvolume name (a snapshot is a copy of a subvolume so it is also a subvolume by itself). Now you have a second bootable install. Unfortunately at this point, os-prober (the tool update-grub uses to detect installations) will not find any btrfs installations in subvolumes so you have to address grub.cfg manually. The easiest way to do this is to open up /boot/grub/grub.cfg and copy just your boot stanza to /etc/grub.d/40_custom and edit the subvolume names there to reflect the snapshot subvolume, then run update-grub. Hopefully, this will be fixed sooner rather than later.

[#]btrfs[/#]

[GreyGeek]

#btrfs #savingyourbutt #easyrecovery

[vinnywright]

Humm nice write up .

BUT ,,I think you should re-word the first sentence of it .

you I and anyone that has used a *buntu for some time will get it ,,,,,BUT to a newer user the part about

dist-upgrade (moving to the newest version of Kubuntu from a current one using the "Upgrade" tool) or full-upgrade/upgrade (upgrading any or all your packages, especially video drivers) in a totally safe way.

,,,,,could give the impression that "sudo apt-get dist-upgrade" or "sudo apt full-upgrade" would take you to a new Kubuntu release,,,, which of course is not the case ,,,,,,and actually "dist-upgrade IS the recommended way to keep your system current UNLESS you need to keep a package/program at a certain version ...and can not afford for it to move forward.

pining the package and all it's dependencies would be another way ,,,,,but other than the slightly possible confusion over dist-upgrade and the "do-relece-upgrade" tool it's a wonderful writeup ,,,,,,,,,and I still plan on taking my 500GB system drive to BTRFS sooner or later 300GB of it is now + my 1TB storage drive .

VINNY

[oshunluvr]

Humm nice write up .

BUT ,,I think you should re-word the first sentence of it .

you I and anyone that has used a *buntu for some time will get it ,,,,,BUT to a newer user the part about ,,,,,could give the impression that "sudo apt-get dist-upgrade" or "sudo apt full-upgrade" would take you to a new Kubuntu release,,,, which of course is not the case ,,,,,,and actually "dist-upgrade IS the recommended way to keep your system current UNLESS you need to keep a package/program at a certain version ...and can not afford for it to move forward.

pining the package and all it's dependencies would be another way ,,,,,but other than the slightly possible confusion over dist-upgrade and the "do-relece-upgrade" tool it's a wonderful writeup ,,,,,,,,,and I still plan on taking my 500GB system drive to BTRFS sooner or later 300GB of it is now + my 1TB storage drive .

VINNY

Good catch. Fixed.

[vinnywright]

much clearer now ,,,

VINNY

[jlittle]

Thanks again, oshunluvr, for your efforts in educating us about btrfs. I don't think I'd be using btrfs without your and the forum's encouragement, and I've had benefits from its use.

This process is so simple and flawless that I do take a snapshot just about every time I install any new software or have 20+ packages to upgrade. The few seconds it costs me are worth the piece of mind.

I've installed apt-btrfs-snapshot which creates such snapshots automatically. Even simpler. It does them for do-release-upgrade too. These need to be kept on a tight leash, they can pile up quickly.

I'm also persisting with snapper (another tool that needs a tight leash, and to labour the metaphor, a choker on the leash) and since I upgraded to zesty, snapper is doing pre and post apt snapshots too! AFAICT they've got nothing to do with each other, and thanks to copy-on-write magic there's no problem having both, other than the clutter and potential confusion. Snapper offers some interesting snapshot comparison and diff functions, so I can ask it what has changed between snapshots. I'll try uninstalling apt-btrfs-snapshot and see if snapper still does the apt snapshots.

It seems to me that snapper is working towards making btrfs accessible to those who'd rather avoid the command line.

...dual-boot setup ... os-prober will not find any btrfs installations in subvolumes

Thanks for the warning about this gotcha.

[oshunluvr]

These need to be kept on a tight leash, they can pile up quickly.

That is my experience also, and why I don't recommend either of those tools to the uninitiated.

I think btrfs would be much more reachable if we had a GUI for management that covered all the bases. I think, since the tools are still being improved, that the talented folks doing the developing are busy. Maybe I'll retire in a couple years and take up a program language again!

...and thank you for your kind words.

[GreyGeek]

Use BTRFS to prevent dist-upgrade or new video drivers from trashing your install.

A tight leash indeed!
The standard config created so many snapshots that I blew through my HD within three weeks.

The other problem I had with it was that the root snapshots were stored in /.snapshots and home snapshots were stored in /home/.snapshots (IIRC), which were accessible from within the system and subject to accidental erasure or changes. Snapper had some nice features, like comparing two snapshots or rolling back to a previous snapshot, but nothing that Btrfs couldn't do on the CLI and using diff (diff -q snapshot1 snapshot2)

But, all in all, I decided it was too much bother and wrote my own script for snapper:

#!/bin/bash
# created by Jerry L Kreps on July 20, 2015 and released under the GPL 2.0.
# This script merely creates a singleton snapshot in both root and home with the designation of PRE or POST as the type, 
# which indicates that the user created it before an action or afterwards.
# This script is run with PRE as the TYPE before an action which you may want to reverse
# AND this script run again with POST as the TYPE after that action has been completed.  Both snapshots are singletons because
# no timeline is used.  Only the "PRE" or"POST" in the description, along with a timestamp, links the pre to the post snapshot.
# To reverse the action run the following two snapper commands:
#
# snapper -c home udochange n..m   where n or o is the number of the PRE and m or p is the number of the POST snapshot
# sudo snapper -c root undochange o..p
#
# After running those two commands both of the empty snapshots folders can be deleted using
#
# snapper -c home delete n-m
# sudo snapper -c root delete o-p
#
#
#
NOW=$(date +%Y%m%d%H%M)
echo Enter snapshot type PRE or POST:
read TYPE
echo Enter description
read DESC
STR=$TYPE" "$DESC" "$NOW
echo $STR
HCMD='snapper -c home create -d "'${STR}'"'
RCMD='sudo snapper -c root create -d "'${STR}'"'
eval "$HCMD"
eval "$RCMD"

But, it didn't eliminate the fact that the snapshots were still within the accessible system. So, I stopped using that script and went to the CLI. Now, I use something like the following CLI commands to make a backup or to restore from one:

[B]Making a backup snapshot:[/B]

sudo -i
mount /dev/sdb1 /backup/
mount /dev/sda1 /mnt
btrfs su snapshot -r /mnt/@ /mnt/snapshots/@_bkupYYYYMMDD
btrfs su snapshot -r /mnt/@home /mnt/snapshots/@home_bkupYYYYMMDD
btrfs send /mnt/snapshots/@_bkup20170628 | btrfs receive /backup/ (The send commands aren't done every time)
btrfs send /mnt/snapshots/@home_bkup20170628 | btrfs receive /backup/
sync
umount /backup
umount /mnt

[B]Rolling back:[/B]

1) Open a Konsole and issue
"sudo -i"

2) Mount sda1 on /mnt
"mount /dev/sda1 /mnt"

3) Move @ to @_old
"mv /mnt/@ /mnt/@_old", followed by "sync"

4) Move @home to @home_old
"mv /mnt/@home /mnt/@home_old" followed by "sync"

5) Copy /mnt/snapshot/@_bkup20170810 to /mnt/@
"btrfs subvol snapshot /mnt/snapshots/@_bkup20170810 /mnt/@" followed by "sync"

6)Copy /mnt/snapshots/@home_bkup20170810 to /mnt/@home
"btrfs subvol snapshot /mnt/snapshots/@home_bkup20170810 /mnt/@home"

7) Delete @_old and @home_old
"btrfs subvol delete -c /mnt/@_old"
"btrfs subvol delete -c /mnt/@home_old"

8) Exit root and Konsole
"exit"
"exit

9) Reboot

Meanwhile, if I damage a package or file that is in the last snapshot I can copy if from the snapshot to / or /home using Dolphin.