You might have some files hard-linked across directories, or worse (but less likely), there's a directory hard-link (not supposed to happen) somewhere.
For the uninitiated, a hard-link is when more than one filename points at the same file data on the disk. This is not the same as a symbolic link. Symbolic links are special files that contain a file or directory name and the OS knows to follow them to that destination. (And they can be used to link to directories safely.)
Some programs are not hard-link aware and will count a hard-linked file as many times as it sees it through its different names. Likewise they will count the entire contents of a hard-linked directory through each name.
Programs tend not to be fooled by symlinks because it's more obvious what's going on.
Try running a duplicate file finder. Don't use it to delete anything, but it might help you determine which directories the files are in and maybe why it's like that.
Also back up everything important and arrange for a fsck on next boot. If it's a hard-linked directory fsck might be able to fix it safely, but it might choose the wrong name to be the main one and remove the other, breaking something. Or remove both. Or it's something else entirely, which by "fixing" will stabilise the system but might cause some other form data loss.
That's all unlikely, but it's nice to have that backup just in case.
OK, one possibility I can think of. At some point, files may have been created where there is currently a mount point which is hiding folders that are still there, on the root partition.
You can remount just the root partition elsewhere by doing something like
mkdir /mnt/rootonly
mount -o bind / /mnt/rootonly
Then use du or similar to see if the numbers more closely resemble the values seen in df. I'm not sure if that graphical tool you used that views the filesystem can see those files hidden this way. So, it's probably worth checking just to rule it out.
Anyway, if you see bigger numbers in /mnt/rootonly, then check the mount points (like /mnt/rootonly/home and /mnt/rootonly/boot/efi). They should be empty, if not those are likely files/folders that are being hidden by the mounts.
When finished you can unmount the bound folder with
This! Thank you, this allowed me to find the culprit! It turns out I had an external disk failure some weeks ago, and a cron rsync job was writing in /mnt/thatdrive. When the externaldrive died rsync created a folder /mnt/thatdrive. Now that I replaced the drive, /mnt was disregarded by the disk analyser, but the folder was still there and indeed hidden by the mount… It is just a coincidence that it was half the size of /
This might help in the future in case you setup a remote mount for backups in the future. Look into using systemd’s automount feature. If the mount suddenly fails then it will instead create an unwritable directory in its place. This prevents your rsync from erroneously writing data to your root partition instead.
You can also do the following to prevent unwanted writes when something is not mounted at /mnt/thatdrive:
<span style="font-style:italic;color:#969896;"># make sure it is not mounted, fails if not mounted which is fine
</span><span style="color:#323232;">umount /mnt/thatdrive
</span><span style="color:#323232;">
</span><span style="font-style:italic;color:#969896;"># make sure the mountpoint exists
</span><span style="color:#323232;">mkdir -p /mnt/thatdrive
</span><span style="color:#323232;">
</span><span style="font-style:italic;color:#969896;"># make the directory immutable, which disallows writing to it (i.e. creating files inside it)
</span><span style="color:#323232;">chattr +i /mnt/thatdrive
</span><span style="color:#323232;">
</span><span style="font-style:italic;color:#969896;"># test write to unmounted dir (should fail)
</span><span style="color:#323232;">touch /mnt/thatdrive/myfile
</span><span style="color:#323232;">
</span><span style="font-style:italic;color:#969896;"># remount the drive (assumes it’s already listed in fstab)
</span><span style="color:#323232;">mount /mnt/thatdrive
</span><span style="color:#323232;">
</span><span style="font-style:italic;color:#969896;"># test write to mounted dir (should succeed)
</span><span style="color:#323232;">touch /mnt/thatdrive/myfile
</span><span style="color:#323232;">
</span><span style="font-style:italic;color:#969896;"># cleanup
</span><span style="color:#323232;">rm /mnt/thatdrive/myfile
</span>
From man 1 chattr:
A file with the ‘i’ attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file’s metadata can not be modified, and the file can not be opened in write mode.
Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.
I do this to prevent exactly the situation you’ve encountered. Hope this helps!
I think I would have expected/preferred mount to complain that you’re trying to mount to a directory that’s not empty. I feel like I’ve run into that error before, is that not a thing?
Ahh, that might be it. I run TrueNAS too. IMO that should be the default behavior, and you should have to explicitly pass a flag if you want mount to silently mask off part of your filesystem. That seems like almost entirely a tool to shoot yourself in the foot.
I’m happy to see it’s finally happening, and I hope they left its implementation flexible.
What I’d really love to see (aside from triple buffer) is a real solution to the system tray situation. AppIndicator is problematic for some apps and under certain X11/Wayland desktops, and even when it works well it is cumbersome to use compared to traditional tray implementations. Hoping we see a new approach soon.
In the meantime, I’ve been enjoying a revisit to KDE Plasma under Kinoite and I have to say I’m really impressed with both DEs!
Sure, it’ll be there for those who want it. As an extension. It isn’t part of the vision the project has so they won’t implement it, they already have the Background Apps section for things like these. Simple as that.
And I don’t even care if they keep it as a “tray”. I’d be content with integration into the dash if they can make it work smoothly. For example, just having the app start minimized as a regular icon (or segregated icon) in the dash…just something at this point.
Gnome have been trying to agree on a standardised, cross-desktop system tray replacement for a long time now. Unfortunately it hasn’t really got anywhere, so it’ll be a while.
Very weird, I can think of some things I might check:
It is possible that you have files on disk that don’t have a filename anymore. This can happen when a file gets deleted while it is still opened by some process. Only the filename is gone then, but the file still exist until that process gets killed. If this were the problem, it would go away if you rebooted, since that kills all processes.
Maybe it is file system corruption. Try running fsck.
Maybe the files are impossible to see for baobab. Like if you had gigs of stuff under (say) /homeon you root fs, then mount another partition as /home over that, those files would be hidden behind the mount point. Try booting into a live usb and checking your disk usage from there, when nothing is mounted except root.
If you have lots and lots of tiny files, that can in theory use up a lot more disk space than the combined size of the files would, because on a lot file systems, small files always use up some minimum amount of space, and each file also has some metadata. This would show up as some discrepancy between du and df output. For me, df --inodes / shows ~300000 used, or about 10% of total. Each file, directory, symlink etc. should require one inode, I think.
I have never heard of baobab, maybe that program is buggy or has some caveats. Does du -shx / give the same results?
It was my first Linux distro after using Microsoft stuff for ages and let me tell you: it was a big mistake. It was absolutely confusing, had to use terminal for so many things with even msdos commands that I forgot that existed, broke it 3 times by just trying to automount the other drivers and a host of other things.
End up switching to Linux mint and the transition went much smoother after that. I’m going back to it eventually though. I actually like it a lot.
I think it’s possible that the filesystem ran out of inodes, so even though there is space on disk, there is no space in the filesystem metadata to store new files.
Now, I don’t know off the top of my head how to check this, but I assume the answer is on the internet somewhere (am on phone and can’t help much more than this, sorry)
how do I install rpm fusion repos on debian? I only found instructions for fedora and rhel rpmfusion.org/Configuration
Stop. You do not want to do this.. While resources published on other sites may be full of information, that information is not always relevant to you. Don’t blindly follow bad advice.
The “rpm” in “rpmfusion” refers to the filetype that Fedora’s built-in package management system, dnf, uses.
You want to use Debian’s builtin package management system, apt, which uses the “deb” filetype.
Do not follow information for other distros unless you know how to extract the bits that are relevant to your distro.
In general, I recommend following the advice from Debian’s wiki or website, then debian’s forums if you can’t find anything there, then debian specific forums elsewhere, then other distro’s wikis, then any other site in a last-ditch effort.
Now that you understand the “why,” here’s the “how”: go back to Debian’s download website and download the appropriate installation image from the bullet point that says
A larger complete installation image:
Reason being: the smaller “netinst” images are made to work generally for most people who can plug their computer into ethernet. It’s made to only use the bare minimum of disk space and get the rest of the files it needs from the internet (the “net” in “netinst”).
You need the installation image that come with the “drivers” (firmware) for your WiFi card already on disk, which should automatically detect your device, find the correct firmware for it, and set up the non-free-firmware repository for you.
If that doesn’t work out for you, you can try manually installing using the guide on Debian’s own wiki, which I found by searching for your wifi card BCM4360
The large /var suggests flatpak, and that plays some hardlinking games.
(If you ever need to free up / space, shifting your flatpak usage to a --user repo will help a lot. No there is no handy command for that, it’s a matter of adding and deleting one package at a time.)
the last time i tried doing something similar was with a plasma 1080i tv (yes that long ago) connected via hdmi to component adapter and i eventually learned that the nvidia driver will overwrite everything in favor of it’s own detection method, thus ignoring the custom edid i provided; perhaps the ati driver your using does something similar?
i would have tried switching to one of the open source drivers but the tv died and it’s replacement had hdmi ports and the problem went away
No before i passed the custom EDID it showed up as “Unknown display” and letter-boxed the entire display, limiting my resolution to 640x480 and 1366x768
Switcheroo is patched on Bazzite. switcherooctl to make sure Flatpaks etc are using the correct dedicated GPU and not trying to use iGPUs.
Tho an update was on the 18th that was supposed to fix some issues people were having.
(Weeks ago steam was trying to use my iGPU again on my AMD system, and that’s when I learned about switcheroo list etc etc. sometimes Flatpak Games like B.A.R. were trying to do the same thing. Bleh!)
You can also force .desktop or shortcuts on KDE Plasma to run using dedicated GPUs by Right Clicking >
Or… Was this an Adaptive Sync issue…in that case try turning that off. sometimes I skim over things when replying.
Anyway, Discourse, Discord and GitHub are all good ways to get in touch/help with the community vs Lemmy/Mastodon. Sometimes I feel like an Ambassador.
I tried both flatpak Steam and the non-flatpak one which comes with Bazzite. I gave it access through flatsel like usual, but when I tried to add the drive from within steam it just sat there doing nothing.
I have not encountered this issue on other distros.
I think it’s based on the xdg-desktop-portal accent color support, but there were specific hooks added to libadwaita to handle that desktop standard, at least that’s my guess based on this.
Definitely glad we have the major desktops all natively supporting accent colors now, it’s been a long time coming.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.