root partition full

[Schwarzer Kater]

[…]
Regarding this:

sudo snap remove firefox if you don't insist on using the Snap and install Firefox to the other partition in /home/$USER/Applications (or another place in /home/$USER if you prefer) instead, following Debian' s installation suggestion (https://wiki.debian.org/Firefox#From_Mozilla_binaries).

Will it uninstall firefox? […]

Yes, it will uninstall the Firefox Snap and afterwards you will have to install Firefox from Mozilla.org to your /home partition instead (so be careful to not install it to /opt, which is on your full / partition!).
If you don't need anything from the Firefox Snap (or if you use e.g. a Firefox account to save / sync your bookmarks etc.) you could even sudo snap remove --purge firefox .

If you don't want to use Debian's step-by-step instructions, I could also change my installation script according to your needs - just tell me where in your /home you would like to install Firefox from Mozilla.org: Script to install traditional Firefox.

[GreyGeek]

Oh ok.
But you can do that with any filesystem format, of course.
...

I believe you missed the point.

When formatting an HD for use using EXT4 you have to determine in advance how many partitions you'll need AND how much space each partition will use.
IF, for example you create partitions for home, root, var, opt and give them each 1/4th of the HD space, you've fixed how many files each can store. If you install a bunch of software in home and receive a msg that home has only 50mb of space left you have a problem that is going to require that you remove some of the software in home OR make backup your data and repartition your HD to give home more space.

During installation of BTRFS on an HD, /dev/sda, a root file system is established, rootfs, which is the top volume. Inside of it is a subvolume called @, which is mounted by fstab as /. IF @home is also created during the install then it is mounted to /home in fstab. Here is the point: rootfs is a reservoir of HD space that both @ and @home can call upon if either begins to run short on space.

Here is where things get sweet. Say you want to create a place to store special data to make archiving, backing up and restoring easier.
You open a konsole and sudo to root. There you mount /dev/sda to /mnt, while your system is running! Listing /mnt shows
/mnt/@
/mnt/@home
Now,
btrfs subvolume create /mnt/@data
Then,
mkdir /data
as a location to mount @data to.
In fstab you add a line that mounts @data to /data during bootup.
Now you store what data you want to save in /data.
Need to back it up? Mount /dev/sda to /mnt and it exposes @data.
btrfs subvol snapshot -r /mnt/@data /mnt/snapshots/@datayyyymmdd

The HD runs out of space ONLY if rootfs runs out of space. When that happens there are methods to move the rootfs to the new system and resize it to fill the new SSD.

And all I've done is scratch the paint to show a slight inkling of what is underneath and makes life easy for BTRFS users.

[oshunluvr]

[USER="34079"]
oshunluvr Once I'll have properly backed up my data, could you tell me what I should do to move the contents of /var to the /backup partition and mount /backup as /var instead? Is it something trivial?

The way I've done this is to:

1. Boot to a Live USB (or another install if you have one)
2. Mount the root and /backup partitions
3. Move ALL the contents of /var on the root partition to the /backup partition.
4. Edit /etc/fstab on the root partition and change the mount point of /backup to /var
5. Reboot

Note you move the contents of /var not the /var folder itself. Leave /var in place as an empty folder because t it will become the mount point.

On reboot, you should notice no difference except more free space on the root partition and when you list mounts you'll see /var as a mount.

If you're a super cautious person;

• Instead of moving the files, COPY them into the /backup partition
• Edit fstab and reboot

This will not immediately result in space savings but gives you a chance to test your work.

If the system boots and works fine, then reboot into the Live USB and delete the content of /var on the root partition - again, leave the empty folder behind.
If the system does NOT boot, edit /etc/fstab again on the root partition, reboot, and try to figure out what you did wrong.

[Robert24]

Sorry for the delay of my answer. I came back home very late both Monday and Tuesday.


oshunluvr Thanks a lot for your detailed answer. I will try to do this as a last resort. For now I will try to re-install firefox as @Schwarzer\ Kater suggested.
Schwarzer Kater Thank your for your detailed answer. I will try the Debian's step by step instructions to start with.

[jglen490]

GreyGeek Yes, when using EXT4 with manual partitioning it is necessary to pre-determine how much space to reserve for each partition. It's actually a minor issue - with experience! I do mine every two years coincident with doing a clean install of the latest LTS, and actually for the past few times I've kept my existing scheme, and sizes, and only formatted the / partition. It just works

And as you may know I'm just not a fan of BTRFS on simple, single user systems.

[Schwarzer Kater]

Slightly OT:

[…]
And as you may know I'm just not a fan of BTRFS on simple, single user systems.

For LTS releases I don't see the need (yet?) either.
But for something like openSUSE Tumbleweed or Arch having / on btrfs can be a life saver and is very convenient.

[oshunluvr]

I'll never understand feeling like there's no need for native file system supported snapshot and backup capability on any kind of system, or the idea that a file system based on a 31+ year old design and relying on a collection of external tools is somehow better.

Not that it will convince anyone, I had two update issues in the last month that took literally 5 seconds and a reboot to resolve because that's all it takes to roll back. Even if EXT4 could do that, it would still be totally basic. Like using a hand-crank drill instead of a power tool.

LOL

[jglen490]

I understand your position oshuluvr. It's true that snapshot will run on any native Linux filesystem, and can be useful for recoverability. But no backup tool that retains data on the same device as the source can contribute to reliability.

I kind of like handcrank drills

[Qqmike]

jglen:

I kind of like handcrank drills

Over the (many) years here, there's been very few -- if any -- things that you & I have disagreed on! Including file systems and hand crank drills. 👍

[jglen490]

Many thanks

Over the many years that I've used Kubuntu and been a member here, it's just like family. Sometimes there seems to be a need to punch a brother in the nose, but it's better to just let it be, 'cause it's all good and all the brothers and sisters are great

[oshunluvr]

jglen490, you and I have sparred over this issue enough I was pretty confident you could take the jab in the nature it was intended...


...until we cross swords again! Huzzah! LOL

[claydoh]

Naw, BTRFS definitely isn't a backup tool per se, it is more a recovery tool, as part of one's backup and recovery strategy. I see them as part of the same banana.

Restoring after a fubar saves time in reinstalling and recovering etc.

I can easily browse my snapshots in Dolphin (via Timeshift, I am lazy) to find specific files quite quickly. So in a sense these are some of my 'local' backups.

I still have a few somewhat overlapping backup plans sent to my NAS, and/or USB drives. My 'on-site' backups. I can access these a little less quickly, either from Dolphin accessing my synced stuff directly on the NAS, or via Kup Backup's file browser for the incremental ones on the same server. Before the NAS, these were stored on an external USB drive.

Then I do some online storage for some things, from those external backups.

[jglen490]

jglen490, you and I have sparred over this issue enough I was pretty confident you could take the jab in the nature it was intended...


...until we cross swords again! Huzzah! LOL

Sword-rattling is good

[jglen490]

Naw, BTRFS definitely isn't a backup tool per se, it is more a recovery tool, as part of one's backup and recovery strategy. I see them as part of the same banana.

....

Yep, the "-ilities" do matter!

[oshunluvr]

IMO BTRFS send|receive IS a backup tool. I send weekly backups of @ and @home from my desktop to my server via RSH. And you can send a subvolume to a file for more mobility if desired.

BTRFS alone isn't a backup management tool, I'll give you that. But seemless, on-line, single command, browseable, backups are a joy. I'm sure one of the various BTRFS tools does backup management, I just don't need it.