Running out of disk space. Something in the Kub. is accummulating log files that take up all the partition (50 Gb).

[claydoh]

Easy enough to find out how

[Qqmike]

I'm not going to use that, but this is the kind of straightforward instructions we need around here. Right: Easy enough!

[RLynwood]

Thanks. I've bookmarked it, must lean how to replace Kub's snaps and have Kub maintain it.

[Schwarzer Kater]

[…] I don't know how to put Flatpaks into my system, do you?

I added this for Kubuntu 22.04 LTS:
How to enable Flatpak in Kubuntu 22.04 LTS

[RLynwood]

Fantastic. I won't be able to do this this weekend, but it defintiely just got on my to-do list for asap. And I still will want some of my apps, esp. Fx and Brave, outside of a container.

[Schwarzer Kater]

[…] And I still will want some of my apps, esp. Fx and Brave, outside of a container.

For Firefox see https://gitlab.com/scripts94/kubuntu...tional-firefox or https://www.kubuntuforums.net/forum/...tional-firefox.
In this script (and generally) I recommend to install Firefox from Mozilla.org in *Ubuntu due to its versatility regarding Snap and release-upgrades. For example you can use the Firefox version from Mozilla.org and leave the Snap version installed.


For Brave use their PPA (and not the Snap - they recommend not to use the Snap as "it is not yet working as well as our official packages.").
Here is a copy of their official installation instructions for *Ubuntu (https://brave.com/linux/):

sudo apt install curl (if it is not already installed), then

sudo curl -fsSLo /usr/share/keyrings/brave-browser-archive-keyring.gpg https://brave-browser-apt-release.s3.brave.com/brave-browser-archive-keyring.gpg ;

echo "deb [signed-by=/usr/share/keyrings/brave-browser-archive-keyring.gpg] https://brave-browser-apt-release.s3.brave.com/ stable main"|sudo tee /etc/apt/sources.list.d/brave-browser-release.list ;

sudo apt update && sudo apt install brave-browser

[RLynwood]

Thank you, Schwarzer Kater. I'll note this and do it when I'm able.

[RLynwood]

I have to revisit this original post. I've run out of room in my main Kub., 22.04, in the first of two 50-Gb partitions again. Now it's so bad that I can't even log in; it doesn't even boot. And this time it gave me virtually no warning. Now, in order to fix sda3, where my working OS is, I'm trying to install the same OS, Kub. 22.04, into a second partition, also 50 Gb. But I'm stuck: When I specified sda4 (the 2nd 50 Gb partition) for the installation, it asked where to put "Device for bootloader installation" > [drop-down menu > /dev/sda]). Not wanting to confuse those established mini-partitions, sda1 & sda2, I said to put it into /dev/sda4. But the installation crashed. I want to know if it'll be ok to specify /dev/sda for the device for bootloader installation, assuming it will put its boot info into the original mini boot partitions, sda1 bios/grub & sda2 efi without affecting the first 22.04, sda3. Sda4 is already formatted btrfs, so I specified no formatting.

I want to access sda3 with Filelight in sda4 in order to delete the excess files. I've installed very little, so I think it's Kub's propensity to continually create new log files that accumulate, but maybe it's something else.

[oshunluvr]

Logs are rotated by default - meaning they get cleaned up automatically as the age. I have never once been able to get a Kubuntu install to grow over 30GB even with a ton of extra software installed.The only thing I've seen that grew to the point of choking a small partition was /tmp and I keep tmpfs in RAM now so I haven't seem that in years. I've comfortably kept a Kubuntu install in a 20GB partition. The point is Kubuntu itself including the logs isn't the problem.

As far as the bootloader, you can launch Ubiquity from the command line (when booting to the ISO) with the no bootloader switch: -b

I'm not sure how a second installation will solve your problem.

I suggest you boot to a live session and rather than installing yet again, mount the full file system somewhere, then run du as sudo with the option -chs. Like this:

sudo mount /dev/sda3 /mnt
sudo du -chs /mnt/*

This should print out a list of the first level directories on sda3 and the total amount of space each of them has consumed. You will likely get some "cannot access" messages on some folders. You can ignore those. or you can do it this way:

for f in bin boot etc home lib opt root sbin srv sys tmp usr var; do sudo du -csh /$f ; done

This will skip unreadable parts. Either way, once you see where the largest amount of space is used, drill down until you find the culprit. For example, I ran the above on my KDENeon install and saw this in the list:

37G /var

What? That's a lot of used space!. So then I did:

sudo du -chs /var/*

Then I saw this:

30G /var/lib

So next:

sudo du -chs /var/lib/*

and got these meaningful results:

1.7G /var/lib/flatpak
28G /var/lib/libvirt

So there's my space hogs.

Flatpak and Snaps take up a ton of space, which is the primary argument against them if you are running with a small partition. My system is de-snapped so you don't see snaps here.

Libvirt uses the /var/lib folder as it's repository for virtual drives by default. Normally I set it to a separate drive but last year I upgraded my system and my install file system is a full 1T so I stopped caring where I install things.

Worth noting that here /var/log showed 4.1G on my system and nearly ALL that space was taken up by /var/log/journal not by other log files. If this is your problem, you can set the journal space to something more suitable by editing /etc/systemd/journald.conf and setting SystemMaxUse= to something like 100M. You can also clear out the journal manually with:

sudo journalctl --vacuum-size=100M

will keep only the most recent 100M of data.

sudo journalctl --vacuum-time=10d

will keep only the last 10 days of data.

Note I haven't tested any of these commands because drive space isn't a concern here.

[RLynwood]

Thank you. That's an incredibly complete answer. I got up extremely late today and just now am getting started. I have go out and will begin following your instructions as soon as I return. I get the most incredibly wonderful help here. It's just fabulous.

[RLynwood]

Following your initial instructions told me that /mnt/@ took 23G, and /mnt/@home took 24G, 47 total. Then, running your long string yielded no great hog in any of those directories. /usr took 4.7G. But it ended with these statements: "du: cannot read directory '/var/crash' : Input/output error" and "du: cannot read directory '/var/log' : Input/output error". I don't know what to do with this; what's next?

[oshunluvr]

I don't have /var/crash folder but that folder has kernel dumps in it caused by kernel crashes. I'm surprised that it's not automatically cleared out. It's probably safe to delete it but I'd verify that elsewhere before doing that. I'm unsure as to why you wouldn't be able to read your /var/log folder. That's not normal.

23G for your install isn't excessive. You simply have too much in your home subvolume to use a 50G file system. First thing I would do is run a "balance" operation on your BTRFS file system. You may be getting a "no space available" result because the metadata space needs cleaning up. Read about it here: https://wiki.archlinux.org/title/Btrfs

The good news is with BTRFS you can easily add a second partition to your file system or move @home to another one. This requires some more drive space obviously.

[RLynwood]

First reaction: I don't understand some of your second paragraph (I understand the English). I'll read your linked Btrfs info. and respond further then. Thanks again for this fantastic help.

[RLynwood]

Haven't begun reading your btrfs info yet, but I just looked at the gui version of the crash folders. The size of _usr_bin_zim.1000.crash is 0 B, and that of _usr_share_kubuntu-notification-helper_whoopsie-upload-all.1000.crash is 445 B, and both are locked. So, those files themselves are insignificant. /@/var is 11.2 GiB.
/@, which appears to contain the entire OS, takes 20.6 GiB. /@home, which contains two folders and is the other folder in OS1, is 20.6 GiB. One of its folders, Data, is empty, and the other, Lynn, my OS home, won't calculate or let me in. This appears to be in line. All for now.

[RLynwood]

That btrfs site is too complicated for me now, and I didn't see a balance operation. Could you tell me how to do that?

[RLynwood]

I'm still interested in and need help with this problem; I still can't use my computer.