[SOLVED] Automatic Subvolume Mounting

[oldgeek]

I have recently re-installed Kubuntu 18.04 on btrfs (sda1). Trying to follow Oshunluvr's instructions to mount subvolumes at startup I did the following:
--mounted sda1 to /mnt (sudo mount /dev/sda1 /mnt)
--took snapshots of both @ and @home
--edited the /etc/stab file and got this:

<file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda1 during installation
UUID=7f608567-065d-432f-adc6-988d8de941a2 / btrfs defaults,subvol=@ 0 1
# /home was on /dev/sda1 during installation
UUID=7f608567-065d-432f-adc6-988d8de941a2 /home btrfs defaults,subvol=@home 0 2
UUID=7f608567-065d-432f-adc6-988d8de941a2 / btrfs defaults 0 0
/swapfile none swap sw 0 0

Then I saved the file and checked the results using ls: all four subvolumes appeared under /mnt.
Finally, I rebooted, expecting to find the subvolumes mounted under /mnt. They weren't.

What did I do wrong?

[GreyGeek]

Attempting to add or change the mounting subvolumes, names and/or mounting points without knowing what you are doing. The kind of action that destroys systems.

I think you are continuing to misunderstand the purpose of mounting the device your system is on to the /mnt mount point. It is to allow you to work on your system live while you take snapshots and do maintenance.

Once you mounted /dev/sda1 to /mnt that mounting process made /mnt the <ROOT_FS> for your system. IOW, /mnt = <ROOT_FS> while it is mounted. After you umount /mnt then /mnt is just another empty subdirectory under /.

When you took snapshots I assume you didn't create a subdirectory to store them in, i.e., mkdir /mnt/snapshots, so they were stored at /mnt along with @ and @home and the two snapshots you made. To do that your btrfs snapshot command must have looked like this:

btrfs su snapshot -r /mnt/@ /mnt/@20180814 (assuming you used -r)
btrfs su snapshot -r /mnt/@home /mnt/@home20180814


Doing
vdir /mnt
should show
@
@home
@20180814 (or what ever you named it)
@home20180814 (or what ever you named it)

When you rebooted the system merely followed the commands in fstab and loaded @ and @home because taking a snapshot does not change them:
UUID=7f608567-065d-432f-adc6-988d8de941a2 / btrfs defaults,subvol=@ 0 1
It looked into the given UUID (as the <ROOT_FS>) for @ because of "subvol=@" and assigned @ to /

UUID=7f608567-065d-432f-adc6-988d8de941a2 /home btrfs defaults,subvol=@home 0 2
Then it looked in the same UUID for subvol=@home and assigned @home to /home.

Do yourself a favor and DO NOT change the "subvol=" part of fstab, or the order of the lines.

The line you added:
UUID=7f608567-065d-432f-adc6-988d8de941a2 / btrfs defaults 0 0
does not follow the syntax for lines in fstab. Remove it. It is not needed.

Also, Btrfs does not use a swap partition or swap file. A swapfile is especially bad because it can create holes in the btrfs filesystem if a dynamic db attempts to use it.
Turn off the swapfile: sudo swapoff -a
Edit fstab and put a # in front of that line or delete the line.

[oldgeek]

OK, I did what you said. You're right, I'm still working my way around this mounting business. I changed the /etc/fstab as well. Now one small question: I accidentally sent a snapshot as a directory to root. How do I get rid of it?

[GreyGeek]

OK, I did what you said. You're right, I'm still working my way around this mounting business. I changed the /etc/fstab as well. Now one small question: I accidentally sent a snapshot as a directory to root. How do I get rid of it?

You don't have to worry about mounting your system to use it. Fstab takes care of that if you don't mess it up.
What you are trying to wrap your mind around is mounting the device your system is on to a mount point (I use /mnt but it is not sacred) so you can maintain it.

Show me the command you used to "sent a snapshot as a directory to root"?

[oldgeek]

The snapshot error was a typing mistake: //@home20180814 instead of one slash. It made a new directory with that name in root. I had to redo the snapshot to get it right. What I keep forgetting to do is to put the -r trigger after snapshot so that I can send it to a backup HD later. Part of the learning curve I guess.

[GreyGeek]

The snapshot error was a typing mistake: //@home20180814 instead of one slash. It made a new directory with that name in root. I had to redo the snapshot to get it right. What I keep forgetting to do is to put the -r trigger after snapshot so that I can send it to a backup HD later. Part of the learning curve I guess.

What was the ENTIRE command you used to create that snapshot?

[oshunluvr]

I have recently re-installed Kubuntu 18.04 on btrfs (sda1). Trying to follow Oshunluvr's instructions to mount subvolumes at startup I did the following:
--mounted sda1 to /mnt (sudo mount /dev/sda1 /mnt)
--took snapshots of both @ and @home
--edited the /etc/stab file and got this:

<file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda1 during installation
UUID=7f608567-065d-432f-adc6-988d8de941a2 / btrfs defaults,subvol=@ 0 1
# /home was on /dev/sda1 during installation
UUID=7f608567-065d-432f-adc6-988d8de941a2 /home btrfs defaults,subvol=@home 0 2
UUID=7f608567-065d-432f-adc6-988d8de941a2 / btrfs defaults 0 0
/swapfile none swap sw 0 0

Then I saved the file and checked the results using ls: all four subvolumes appeared under /mnt.
Finally, I rebooted, expecting to find the subvolumes mounted under /mnt. They weren't.

What did I do wrong?

To answer your question, this line:

UUID=7f608567-065d-432f-adc6-988d8de941a2 / btrfs defaults 0 0

mounts the root filesystem on top of your OS. My instructions were to mount it in it's own mount point, not over the top of some other mount. Assuming you wanted it mounted at /mnt (not a good idea either because it will overlay other mounts in there) the line should look like;

UUID=7f608567-065d-432f-adc6-988d8de941a2 /mnt btrfs defaults 0 0

Again - don't do that either. The /mnt folder is used to hold other mount points. Make a specific, new mount point for your root file system and mount it there.

For example, a good choice might be /mnt/subvols .

sudo mkdir /mnt/subvols

Then edit fstab and make the bad line look like;

UUID=7f608567-065d-432f-adc6-988d8de941a2 /mnt/subvols btrfs defaults 0 0

You still can use /mnt if you want, but it's unconventional. I don't recommend it because other things you may attempt in the future will direct you to mount something in /mnt/<some folder> and you'll be overlaying mounts again.

The best practice is to use unique mount points that are not conventionally used by other processes. Personally, I use just /subvols for all my root file systems and have /subvols/snapshots in it to keep snapshots separate from subvolumes in use.

[oshunluvr]

Also this:

/swapfile none swap sw 0 0

will go horribly wrong on you. Delete this line immediately. The Ubiquity (the installer we're stuck with for the time being) developers basically screwed us when they decided to start using a swapfile instead of a swap partition for new installs. Swapfiles have no place on a btrfs file system. Either create and mount a swap partition or don't use swap at all.

[GreyGeek]

Generally, like /media, /mnt is a general purpose mount point. While one can always mount something to it
mount /dev/sdb1 /mnt
and then do it again with
mount /dev/sdc1 /mnt
the final mount command will determine what is mounted to /mnt.

Leaving something mounted to /mnt or /media permanently is not a good idea, IMO.

I always "sudo -i" to root and then mount, using uuid's, my <ROOT_FS> to /mnt and my external backup HD to /backup. One could "mdkir /subvol" as root to create a mount point for <ROOT_FS> whose use would be obvious. But, none of this stuff is written in stone. People do what they understand the way they understand it.

[oldgeek]

I gather then that unless I plan to work on the file system, such as for snapshots, I don't have to mount them when I start up. If I do mount them, do I have to mount the HD first? (on another mount point, right?) The swapfile might have been what helped mess up my previous install--I didn't know it was there until I looked at /etc/fstab.
As for the bad snapshot command, the whole thing went like this (relying on my 68-year-old memory):

sudo btrfs subvolume snapshot /mnt/@home //@home201814

I should have put -r after snapshot, right? The double slash created a new file in root--at least that's what Dolphin showed me. I would like to get rid of it without messing anything up.
Thanks again for all the help. My ignorance of mounting seems to have caused all the trouble here.

[GreyGeek]

I gather then that unless I plan to work on the file system, such as for snapshots, I don't have to mount them when I start up.

That's correct. The /etc/fstab file does the mounting automatically when you boot up.

If I do mount them, do I have to mount the HD first? (on another mount point, right?) The swapfile might have been what helped mess up my previous install--I didn't know it was there until I looked at /etc/fstab.

When you boot up your system is usually running on the /dev/sda1 partition. To do Btrfs maintenance on your system you can, as root, mount /dev/sda1 to some mount point, like /mnt or /media or any mountpoint you created using "sudo mkdir /somemountpoint". It doesn't matter.

I prefer to do maintenance as root and at the <ROOT_FS> level because it puts the snapshots outside of / or /home, where they can be accessed directly. Snapper works by creating @ snapshots under /.snapshots/1/somesnapshot, etc.... Using "sudo krusador" you can browse them and even do damage to them using ordinary copy & paste commands, etc... Not a good thing. That's why I decided to not use Snapper. TImeShift does something almost the same, but mixes up / and @ and @home and /home. That's why, if you use TimeShift and want to stop using it, YOU MUST delete all snapshots you made using TimeShift BEFORE you uninstall it.

As for the bad snapshot command, the whole thing went like this (relying on my 68-year-old memory):

sudo btrfs subvolume snapshot /mnt/@home //@home201814

I should have put -r after snapshot, right? The double slash created a new file in root--at least that's what Dolphin showed me. I would like to get rid of it without messing anything up.
Thanks again for all the help. My ignorance of mounting seems to have caused all the trouble here.

You cannot delete a Btrfs snapshot command using the 'rm' command.

Is //@home20180814 under <ROOT_FS> (/mnt or /subvol) or is it under / ?

IF it is under /mnt (or what ever) then as root
btrfs subvol delete -C /mnt//@home20180814
If under /
btrfs subvol delete -C //@home20180814

One of them will fail, the other will work.

[oshunluvr]

I don't know why you keep throwing the double-slash in there, we're not dealing with network addresses. It may cause you problems eventually.

There's no reason to mount a snapshot unless you're using it to replace a subvolume. If you mount the root filesystem - like I describe above - to /subvols, you can access all the subvolume and snapshots by simply navigating to /subvols and then into any subvolume/snapshot you want. For example, say you mount your root file system at /subvols. In /subvols, you make a folder named snapshots, and reboot. Then open a terminal and type;

ls /subvols

You will get this output:

@ @home snapshots

Now take a read-only snapshot (to use as backups, so read-only is required) of both subvolumes in /subvols like this:

sudo btrfs su sn -r /subvol/@ /subvol/snapshots/@ro
sudo btrfs su sn -r /subvol/@home /subvol/snapshots/@homero

Now checking the snapshots folder:

ls /subvols/snapshots

and you see

@ro @homero

Notice I added "ro" to each snapshot to indicate "read-only" at a glance. That's not required, just how I do it.

Now lets say you're about to install a new graphics driver. This is often a problem so you'd like to protect yourself by taking a snapshot that you can rollback to.

sudo btrfs su sn /subvols/@ /subvols/@save1

Note here, I did not use read-only and I left it in the root folder. This makes rolling back much easier if you have to do it. So looking again at /subvols;

ls /subvols

@ @home @save1 snapshots

So now go ahead and do your graphics driver update and reboot. If all is well, go back and delete the snapshot.

sudo btrfs su de -c /subvols/@save1

If all hell breaks loose, delete the @ subvolume and boot to the snapshot. To do that, boot to a live USB and mount the root file system, delete @ and rename @save1 to @ and reboot.

sudo mount /dev/sda1 /mnt
sudo btrfs su de -c /mnt/@
sudo mv /mnt/@save1 /mnt/@
reboot

That's it. Of course, my example assumes your btrfs file system is on sda1. Substitute your actual device location.

There are other ways to roll back to a snapshot, but if you're totally unable to boot into your install, the above works well.

I suggest you practice this by taking snapshots, making backups, doing a few roll-backs, until you're comfortable with your ability. Heck, take notes and make a cheater card to CYA in case you forget six months from now or whatever. Once you get this part down pat, you can move into more advanced things like having more than one bootable distro - like a backup - on the same btrfs file system.

I already introduced you to one "advanced" btrfs trick - shortening the commands to two letters or so. You can use su for subvolume, sn for snapshot, and de for delete, among others. Pretty much any btrfs command can be reduced to the shortest amount of letters required to keep it unique.

[oldgeek]

Thanks to both of you. Seems pretty clear now. The only reason I added a double slash was due to heavy fingers, and not checking what I typed! The second delete command got rid of my error, GreyGeek.

[GreyGeek]

Thanks to both of you. Seems pretty clear now. The only reason I added a double slash was due to heavy fingers, and not checking what I typed! The second delete command got rid of my error, GreyGeek.

I've had the fat finger syndrome for a while. Now, it seems that involuntary tremors have added to that plague.

You're learning. Be patient.

If something I've posted led you to believe that you had to mount your file system manually every time you booted up then let me know what post that impression was in so I can edit it.

[oldgeek]

If something I've posted led you to believe that you had to mount your file system manually every time you booted up then let me know what post that impression was in so I can edit it.

No, I just wanted to be sure I understood correctly.