Hello. I went to a 4-week coding boot camp using C, Bash, Shell, and Ubuntu. When I heard that ZorinOS was based on Ubuntu, I decided to give it a try and have loved the OS ever since. However, when I tried to update from both the update software and the terminal, I kept seeing "You don't have enough space" notification and "restart your pc to apply updates". I restarted and now my laptop keeps frozen at a black screen each time I try to boot and start up my laptop. I remember that I faced the same issue one time during my boot camp, and I was able to use shell to clear up the space to give enough space for the OS to boot up. I asked ChatGPT for solutions to no avail and now I am stuck. My laptop: Lenovo ThinkPad Yoga X370 (old laptop)
Your nvme drive is most definitely full.
From the Zorim Grub Menu, you can access the option for booting Zorin on -kernel- (Recovery)
Choose that (Recovery) option.
From this, you will see a menu that lists options. The bottom option to drop to root prompt is the one you want.
In the prompt, tap the enter key to get started. Then run
apt clean && apt autoremove
The rm rf command is dangerous if used without specifying a path. Each of these contains the proper path so check and double check that what you enter matches the below before running:
rm -rf /var/log/*.log
rm -rf /var/log/journal/*
rm -rf /var/log/syslog*
rm -rf /tmp/*
If you use snap packages, clear space with:
du -sh /var/lib/snapd/snaps
rm -rf /var/lib/snapd/snaps/*.snap
You may have old kernels clogging the pipes. You can check with
dpkg --list 'linux-image*' | awk '{ print $2 }'
Fun to type that out, I know... if you see more than two, you can remove all except two using (replace the 'version-you-want-to-remove' with the linux-image version number and do not include the [] brackets):
apt purge linux-image-[version-you-want-to-remove]
This should be enough to get space cleared out.
Ensure all packages are good before attempting to boot
apt --fix-broken install
dpkg --configure -a
Then test booting. If booted to the Desktop, you can then use any means you want to search for and clean excessively large files or anything taking up too much space that can go away.
2 Likes
This isn't the first time I've seen you provide variations on this advice. Why are logs not automatically pruned? There's the obvious "the system doesn't know how long you need to keep logs," but anyone who needs gigs of logs likely also knows how to reconfigure to retain so many, so a smaller limit seems sane.
I sometimes (for work) run Windows with only 50 MB free on its only drive, install something, and fail for lack of space, but it's never broken the system. I'm not trying to say Windows is better, but something strikes me as very off for logs to routinely cause Linux systems to become unbootable. o_O
It is preferable for the user to set up a journctl vacuum, for, as you point out - the obvious reasons. But there are a couple of functions including logrotate and of journald that do trim and prune logs.
That being said, the most common reason we see logs fill up to massive sizes is when they fill more quickly than logs rotate out - due to some fault that is sending data to logs at a large rate.
Which........... Is why I do not use Gnome D.E.
And...
This is one of those reasons that systemd continues to come under scrutiny and will come under scrutiny. A lot of people might think that the SystemD debate is something outside of their experience and does not affect them. Here, we see first hand, one of the many times that it affects regular users commonly and how Integration instead of modularity affects the user.
This is why many of us speak up - though most often, we get waved off or ignored.
Ugh. Yes, this is a clear, non-academic problem. I'll have to dig through the tutorials forum and see if setting up journctl to prevent this is covered, and if not, write something once I know enough. This seems like a clear case of prevention being preferable to repair.
...minute learning has occurred, and now I have a headache.
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
H...how are these defaults anything but an invitation to overfill the disk, even if uncommented? Surely I'm missing something...
Edit: Yes, I was. The logs are supposed to cap at ~20% of your filesystem (10% each for system and runtime, which are archived and active logs respectively), and leave a minimum of 15% free. If the file system dips under 15% though, from what I understand in the manpages, in low space scenarios it may exceed that, and it only deletes archived logs, so if a new log is created that fills the filesystem...
If I understand correctly, editing /etc/systemd/journald.conf so SystemMaxFileSize and RealtimeMaxFileSize are fairly small (and removing the # so the line isn't commented out), logs should never get over 1 GB for both active and archived. Alternatively, MaxRetentionSec can be set to an amount of time to have logs deleted once they're older than that, though they'd have to rotate out before that can happen. Alternatively, a sufficiently large SystemKeepFree and RuntimeKeepFreeought to stop the logs from growing if you have less free space than you set.
If my babbling is accurate, I'll write up a proper how to sometime this week.
As @Aravisian says, this would be a symptom of something else going on. Pruning these logs automatically based on size alone could be counter productive, as you want to read them to find out some clues as to what's going on.
Assuming that this issue was due to log files exploding in size (we don't even know that for sure yet), whatever is causing this much logging activity will likely continue to do so until it's fixed. Deleting the log files alone is not a guaranteed solution.
How is systemd related to this issue? 
This was the issue that I was having and a folder with my files that had multiple pdfs and some videos. I removed the linux-image-6.8.0-40-generic until 50, and kept the newest one. For the unsigned files, they were removed automatically as well. The OS still didn't boot properly. After restarting with the power button, holding shift, selecting the advanced option to boot (not the recovery option), holding down alt+control+f2 or f1 (a cs buddy of mine told me about this), I was able to launch the OS as a safe graphics mode I assume where I was able to access only the terminal and remove the folder with the most memory on it. Hope that my reply helps people with the same issue and thank you for your help Aravisian. Fun fact: My laptop decided to give up on me one hour before I had an exam 
, but now that I was able to fix it I feel more relieved 
I just tiedied up the quote formatting in your last past above to look nice 
SystemD is an integrated Daemon system - which includes JournalD.
Due to SystemD being far-reaching and overly-complex, errors can occur and accrue at a swifter rate than logs would be cleared... and JournalD is a bit like policing yourself, where it is part of the same process that is accruing the errors in the first place.
You asked, so I am providing a brief answer. I do not want to go too far into it as a SystemD debate over init systems in a solved thread (my fault) but would be plenty happy to discuss it at length in a thread of its own.
Just checked my own /var/log directory out of curiosity. These are the largest files and directories (ascending order):
636K /var/log/syslog.1
844K /var/log/syslog.4.gz
952K /var/log/libvirt
974M /var/log/journal
Quite the difference in size...
One day I'd also like to be able to talk about it more intelligently. For now, I just don't know enough since I can get by without worrying about it. Maybe once I run into serious issues with it (maybe I already did, without knowing so) I'll spend more time to learn what's going on.