Just got a warning Root has '0' bytes left --- [ gonna Fresh Install it, and be done ]

[linux-rox]

There's no reason to think this is a Timeshift problem. If it were, the rogue snapshot(s) would show up in one of the file system reports the OP has run. Besides, as mentioned above, in this case snapshots are on a different partition.

[rene]

There's a timeshift directory not only in that Backup partition but also in /. I.e., and as said, I expect the current Timeshift configuration to be to save in /timeshift but it trying to include that/those backup location and failing each time due to running out of space (and deleting that failed snapshot again immediately -- admittedly I don't in fact know if it does that upon failure).

Anycase please just wait for OP to look at his current Timeshift configuration and confirm/deny.

[AZgl1800]

I expect this is again Timeshift trying to back up some permanently mounted and not excluded large data-type filesystem, and upon running out of space halfway through deleting the "failed" snapshot again before you even notice that it was doing such.

Only other possibility seems to be something writing humongous temporary files to /tmp until it fails similarly -- but at 60G that seems pushing it, so I'd go check Timeshift configuration and/or correlate with indeed such a data-type filesystem being mounted somewhere that Timeshift feels needs backing up.

If it's again Timeshift as per above contemplate disabling the stupid thing outright -- but at least exclude what needs excluding.

to test this theory,
I have just now Deactivated Timeshift.
I have enough backups that is not a concern at all today, or this week.

Definitely will report back on how well this works to resolve the situation.

[AZgl1800]

There's a timeshift directory not only in that Backup partition but also in /. I.e., and as said, I expect the current Timeshift configuration to be to save in /timeshift but it trying to include that/those backup location and failing each time due to running out of space (and deleting that failed snapshot again immediately -- admittedly I don't in fact know if it does that upon failure).

Anycase please just wait for OP to look at his current Timeshift configuration and confirm/deny.

when I look inside the /timeshift folder, it is Empty, nada, zilch

the Settings in Timeshift are to only store the snapshots on /Backup/Timeshift

[rene]

You should be able to check immediately by going into Timeshift -> Settings -> Location. If it's currently set to your root partition sda2 instead of that backup partition sda3 that'd be the issue. Yes, the empty /timeshift would as said be explained by a failed snapshot being deleted immediately -- and we need that kind of explanation to explain the popup followed by an immediate display of 60G free space.

[AZgl1800]

Just now did a Forced Reboot, that is to say, PRESS POWER KEY until BIOS shut down the laptop.

this thread is the only thing FF had open.

I was inspecting /backup to see what I had in various folders, and then the mouse and keyboard quit responding.

of course, that means that using the control-alt-prtScn command won't work.

this is just plain getting weird, I can't find anything wrong, but things are NOT working well for me

[jackkileen]

I got a warning a few weeks ago that Root was almost filled up and I deleted some things don't remember what exactly but the warning went away. Now I just checked after reading this thread and my 100 GB root partition is almost filled up again.
Maybe I should start a new thread?

[AZgl1800]

I got a warning a few weeks ago that Root was almost filled up and I deleted some things don't remember what exactly but the warning went away. Now I just checked after reading this thread and my 100 GB root partition is almost filled up again.
Maybe I should start a new thread?

yes, you should for Personal Attention to your own issue.

[senjoz]

Have you checked journalctl logs after the notification was displayed?

If you run terminal command journalctl -b 0 | grep -i filesystem or journalctl -b 0 | grep -i "filesystem root" after displayed notification, do you get any relevant information? Try also with grep options -B 5 -A 5. This will display 5 lines before and after a line with pattern match.

[AZgl1800]

Have you checked journalctl logs after the notification was displayed?

If you run terminal command journalctl -b 0 | grep -i filesystem or journalctl -b 0 | grep -i "filesystem root" after displayed notification, do you get any relevant information? Try also with grep options -B 5 -A 5. This will display 5 lines before and after a line with pattern match.

Code: Select all

john@FX705GM:~$ journalctl -b 0 | grep -i filesystem or journalctl -b 0 | grep -i "filesystem root"
grep: or: No such file or directory
grep: journalctl: No such file or directory
grep: 0: No such file or directory

john@FX705GM:~$ journalctl -b 0 | grep -i filesystem or journalctl -b 5 | grep -i "filesystem root"
grep: or: No such file or directory
grep: journalctl: No such file or directory
grep: 5: No such file or directory

john@FX705GM:~$ sudo journalctl -b 0 | grep -i filesystem or journalctl -b 0 | grep -i "filesystem root"
grep: or: No such file or directory
grep: journalctl: No such file or directory
grep: 0: No such file or directory
[sudo] password for john: 

[SMG]

If you run terminal command journalctl -b 0 | grep -i filesystem or journalctl -b 0 | grep -i "filesystem root" after displayed notification, do you get any relevant information? Try also with grep options -B 5 -A 5. This will display 5 lines before and after a line with pattern match.

That was meant to be two different commands you could run.

Code: Select all

journalctl -b 0 | grep -i filesystem

or

Code: Select all

journalctl -b 0 | grep -i "filesystem root"

You ran both of them with an "or" in the middle all as one command. That is why your first line gave an error about "or".

[AZgl1800]

If you run terminal command journalctl -b 0 | grep -i filesystem or journalctl -b 0 | grep -i "filesystem root" after displayed notification, do you get any relevant information? Try also with grep options -B 5 -A 5. This will display 5 lines before and after a line with pattern match.

That was meant to be two different commands you could run.

Code: Select all

journalctl -b 0 | grep -i filesystem

or

Code: Select all

journalctl -b 0 | grep -i "filesystem root"

You ran both of them with an "or" in the middle all as one command. That is why your first line gave an error about "or".

I ran each command independently,
then I highlighted the results.

Once I pasted inside the Brackets, I added a space between the Results to clarify what happened.

guess it would have been more clear, to enter each result as a Separate entity.

will do it again:

Code: Select all

john@FX705GM:~$ journalctl -b 0 | grep -i "filesystem root"
john@FX705GM:~$ journalctl -b 5 | grep -i "filesystem root"
john@FX705GM:~$ sudo journalctl -b 0 | grep -i "filesystem root"
john@FX705GM:~$ 

it is not returning any results, thought it needed 'sudo' but that didn't change anything.

[Moem]

Mod note:
One post removed, let's be better than that.

[AZgl1800]

Woke up this morning to yet another of those Alerts,
at this point I am just clicking Ignore and going on.

I have rebooted several times, and nothing has gone wrong at all.
Just the normal process of getting back to a working OS.

I have been on Vacation now since April 8th wandering around the country, so trying to figure out issues with Linux is a bit awkward....

I can't devote the diligence to it that I should.

I think when I get back home in Okieland in 15 days,
that I will just do a Fresh Install and start over.

all of my data is in /home, and Aptik will do a reinstall of all of my apps.

[linux-rox]

Another shot in the dark. I wonder whether this is a trim problem, an accumulation of three years of deletes not being cleared. Shouldn't be. Mint runs trim once a week as a matter of routine system maintenance. OTOH, easy to trim manually and can't hurt anything. The command is sudo fstrim -av. Unlike fsck, trim only works on mounted partitions, so you want to run the command during a regular session with all three Mint partitions mounted.

FWIW, what brought this to mind is that I had an issue a few months ago (not worth trying to summarize here) where I shouldn't have had a trim problem, but tried manual trim on a lark and it turned out to be the solution. As I said, easy to do and can't hurt.

Note: AFAIK, there's no way to confirm whether trim did anything. What you will get in response is a report of the amount of free space in each partition, which we already know. You get the same response if running trim twice in quick succession, where plainly the second run didn't do anything.

[AZgl1800]

Another shot in the dark. I wonder whether this is a trim problem, an accumulation of three years of deletes not being cleared. Shouldn't be. Mint runs trim once a week as a matter of routine system maintenance. OTOH, easy to trim manually and can't hurt anything. The command is sudo fstrim -av. Unlike fsck, trim only works on mounted partitions, so you want to run the command during a regular session with all three Mint partitions mounted.

FWIW, what brought this to mind is that I had an issue a few months ago (not worth trying to summarize here) where I shouldn't have had a trim problem, but tried manual trim on a lark and it turned out to be the solution. As I said, easy to do and can't hurt.

Note: AFAIK, there's no way to confirm whether trim did anything. What you will get in response is a report of the amount of free space in each partition, which we already know. You get the same response if running trim twice in quick succession, where plainly the second run didn't do anything.

that took longer than I thought it would

Code: Select all

john@FX705GM:~$ sudo fstrim -av
[sudo] password for john:  
/home: 68.3 GiB (73387364352 bytes) trimmed on /dev/sda4
/boot/efi: 224.9 MiB (235810816 bytes) trimmed on /dev/nvme0n1p1
/mnt/83601e83-13ac-4887-b8d6-7928f1be3245: 0 B (0 bytes) trimmed on /dev/sda3
/: 64 GiB (68711464960 bytes) trimmed on /dev/sda2
john@FX705GM:~$ 

I don't quite understand why the large numbers on sda4 and the NVME which is Windows, not Linux, but does hold Grub for bootup menu Mint/Win10

[linux-rox]

I'm much more puzzled by: /mnt/83601e83-13ac-4887-b8d6-7928f1be3245: 0 B (0 bytes) trimmed on /dev/sda3. I wonder whether we have accidentally hit on the nub of the problem. Per your earlier screeenshots, sda3 (the backup partition) should have 374 GB free, and therefore trimmed. For that matter, 68 GB for sda4 seems low to me. On the bright side, the system partition (sda2) is exactly as I would expect and that's the one you're getting error messages about. The reason you're seeing nvme0n1p1, by the way, it that the EFI partition is automatically mounted at boot.

Let's get a third opinion on the space available in sda3. What does lsblk -f say?

[AZgl1800]

I'm much more puzzled by: /mnt/83601e83-13ac-4887-b8d6-7928f1be3245: 0 B (0 bytes) trimmed on /dev/sda3. I wonder whether we have accidentally hit on the nub of the problem. Per your earlier screeenshots, sda3 (the backup partition) should have 374 GB free, and therefore trimmed. For that matter, 68 GB for sda4 seems low to me. On the bright side, the system partition (sda2) is exactly as I would expect and that's the one you're getting error messages about. The reason you're seeing nvme0n1p1, by the way, it that the EFI partition is automatically mounted at boot.

Let's get a third opinion on the space available in sda3. What does lsblk -f say?

Code: Select all

john@FX705GM:~$ lsblk -f
NAME        FSTYPE FSVER LABEL    UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                   
├─sda1      vfat   FAT32 EFI      A9A2-D1F0                                           
├─sda2      ext4   1.0   /LM21    a68a4a63-99de-4474-8ed8-75f23142d59f   59.6G    24% /
├─sda3      ext4   1.0   /Backup  83601e83-13ac-4887-b8d6-7928f1be3245  349.2G    17% /mnt/83601e83-13ac-4887-b8d6-7928f1be3245
└─sda4      ext4   1.0   /home    32f44c92-4ac5-4580-8b6b-cb4f2016a022  163.7G    51% /home
nvme0n1                                                                               
├─nvme0n1p1 vfat   FAT32 SYSTEM   88FF-235F                             224.9M    12% /boot/efi
├─nvme0n1p2                                                                           
├─nvme0n1p3 ntfs         Win10    64C600F8C600CBEC                                    
└─nvme0n1p4 ntfs         RECOVERY 64106268106240E2                                    
john@FX705GM:~$ 

[linux-rox]

So, basically agrees with Disks, especially when we bear in mind they weren't run on the same day. Maybe there's a good explanation for that trim result on sda3, but sure looks wrong to me. Anyway, let us know if/when you get the next '0' bytes warning.

[AZgl1800]

So, basically agrees with Disks, especially when we bear in mind they weren't run on the same day. Maybe there's a good explanation for that trim result on sda3, but sure looks wrong to me. Anyway, let us know if/when you get the next '0' bytes warning.

been out of the house, just returned at 11 AM a few minutes ago,
when I moved the mouse and woke the screen up, this was showing again.