For about 10 years i am using Manjaro linux. Overall i am very pleased with this Operating System and Xfce.
However, i had a few crashes after an update and managed to solve them or installed a new version and reinstalled all the programs i was running.
I even made a list of all the installed programs and how to install them, and saved this file on another partition together with all the data of those programs.
So i thought i was save.
I make a Timeshift copy every time i install a new program so again i thought i was save.
I have a dual boot system with also Linux Mint because that partition is much bigger for the Musescore Sounds, that i cannot install on the Manjaro partition.
This morning i used briefly Musescore on that linux Mint partition, but after i tried to open Manjaro i got this message. [failed] failed to start light display manager.
I then logged in on the terminal via CtrlAlt F2 that worked, and tried all the things i have read online, but nothing worked.
Then i used Linux Mint to reset the TimeShift backup from a few days ago, but nothing happens, still the same error.
When i try to do sudo pacman -Syu i get an unexpected error.
I tried some other commands but he keeps saying no more room on this system, while i checked from Linux Mint 3.8 Gb free space.
Also the command sudo pacman -Sc to make some space gives the same error, no more roomâŚ
I am very disappointed in this and i am seriously thinking to kiss Manjaro goodby and use another distro, unless someone can talk me out of it.
Iâm not going to talk you out of it. No space means no space. ext4 becomes critical at 90% and btrfs already at 80%. If the root directory is full, lightdm will not start because it has to write to the root directory. Write your data to an external data storage or another partition, not the root directory/partition, then there will be no problem.
If there is no space - there is no space.
No need to blame or ditch the OS for it.
ext4 reserves 5% for the root user exclusively by default,
so:
even if you have x amount of unused space - only root may be able to use it
Delete some stuff - or move it off the disk.
sudo rm /var/cache/pacman/pkg/*
could help some
sudo paccache -r -k 0
is another way to do the same
as well as:
sudo tune2fs -m 1 /dev/sdXy
(sdXy being your root partition -
it will reduce the âreserved for rootâ part to 1%, thereby giving you some wiggle room)
That will get you some free space - but you need to act on the issue.
I have made a screenshot from the partition in gparted.
I am doing this from another partition of manjaro recently installed, but never finetuned it because of no reason.
I have two physical SSD drives from 250 Gb both divided in several partitions like data, mint, backup etc.
Thanks for trying to help me out here, but i still cannot see what i did wrong.
As i said i started the day on the Manjaro partition, then via grub switched to linux Mint to do some stuff there with Musecore, and when i rebooted to Manjaro i got this error message. By doing this no space on the Manjaro partition was altered.
I will log back in to the tty2 and try the commands that are stated here below, and then come back here.
Now we see itâs a BTRFS filesystem, this gives a clue:
If both OSes are in subvolumes of the same BTRFS filesystem, note that free space on all âpartitionsâ â which they are not, really â is actually a âpoolâ of free space shared by both. Therefore, if a lot of space is used by Mint, this will also impact the Manjaro installation.
My suggestion is to move stuff out of the Mint subvolume(s).
I feel the need to note that btrfs has only been a thing with Manjaro for a very short time.
The btrfs filesystem is a great file system - but it is a demanding file system when one move a lot of data around and due the dynamic nature and the CoW - when you do so - it will a some point go bonkers on you if you donât do regular maintenance to ensure the internal structure is up-to-date.
When it does - you need to expand your existing file system by adding disk space (temporarily) using an extra disk - which can be a removable device - perhaps we can have @andreas85 chime in as a member with knowledge and expertise on btrfs.
When one moves a lot of data - ext4 or xfs is a better choice and superior to btrfs when writing data and because I do move a lot data around - building ISO - using git repos etc. - I donât use btrfs.
The reason for the problem is simple and has little to do with the above.
Youâve simply used up your available disk space.
This usually has individual reasons that everyone has to investigate for themselves. Some possible reasons are listed in the Manjaro wiki on btrfs. Btrfs in the wiki
But the main problem is that you didnât notice that the disk space was running low. This is fatal for any file system.
There are little helpers for the desktop or taskbar, or Chonky⌠They display the current disk space and also warn you when a self-defined limit is exceeded.
The solution is just as simple.
Make space on your disk. Tips and instructions on what to look out for with btrfs can be found in the wiki:
You find good Information about your problem in Out of space
And please:
Do not use du or df or lsblk to show free space on a btrfs filesystem, but use btrfs fi us / or sudo btrfs fi us /
The line
Itâs always possible to create a separate subvolume (within the file system tree) in which such activities take place.
If you donât create snapshots in this subvolume, you benefit from all the features of btrfs without running the risk of filling up your volume. Any files deleted in this subvolume are immediately deleted from the filesystem and are not retained in snapshots of other subvolumes.
This can be done, for example, with caches, rotating log files, or similar. But also with images of VMs, ISOs, etc.
To avoid having too many subvolumes, I often use symbolic links. This way, I only have one subvolume @nosnap
I donât know - isnât this a little less information than that command gave you?
But BTRFS is quite different in a lot of ways and has got itâs own set of tools.
I have zero experience and nearly zero knowledge when it comes to dealing with this file system.
⌠donât listen to my advice âŚ
I wrote under the assumption that your file system was ext4 - which it is not, as it turns out.
When i used the lsblk -f command this is done in a tty2 terminal, i have no chance to copy that and paste it somewhere else, neither can i use a screenshot in that environment, so i wrote down the importend thing.
Thanks anyway for the help.
Jean
Ok i am going to try that in the tty2, but i can not copy or paste the result of that command, just write down the thing.
That is approx. 87% and with BTRFS 80% is already critical. You are in the critical range where there will be problems and where you need to make adjustments. Just like on ext4 at 90%.
Btrfs offers powerful features like fast snapshots (Timeshift), but these also consume metadata space. If no more metadata can be written - meaning no new metadata chunk of 256 MB can be allocated - then no additional data can be stored, even if free space appears to be available. For example, the system may report 5.49 GB of free space, but this may be reserved exclusively for 1 GB data chunks. At this critical point, a rebalance is required: data must be redistributed across existing data chunks and then free up completely empty chunks afterward, which can then be reused for new metadata chunks.
I hope that makes sense to you. Some sort of defragmentation of data chunks, not the data itself, to get similar meaning.
Check how much space is allocated:
sudo btrfs filesystem usage /
If not enough space is unallocated, you would need to (re)balance:
Dear All,
My problem is solved.
First i have deleted all the timeshift snapshots.
Then i booted into the tty2 terminal.
sudo pacman install -S procps-ng
Then the system said i have the latest procps packages
Then this command continued to make a new timeshift snapshot, upgrated the grub file.
Then i typed reboot end by wonder everything worked as before.
So maybe it is not a bad idea to do that balance command that Megavolt proposedâŚanyway
THANK YOU ALL FOR THE HELP ON GETTING MY SYSTEM BACK UP AND RUNNING.
It is recommended to periodically run a balance operation.
The btrfsmaintenance package has a systemd timer that does exactly that, and itâll completely run in the background too, although I find its default frequency â once a week â a bit too busy. Perhaps once a month would be a better option, but you can either way tweak that in the configuration file.
It can also run a periodic btrfs scrub and a periodic defragmentation, even though the latter should not be used on an SSD.
That all said, please tick the solution mark on the post that helped you on your way the best. That way, the solution will be added to your opening post, and the thread will be properly closed in a few days time, so as to prevent the usual #MeToo necro-bumps.
Yes. They do take up space, and it builds up over time with every new snapshot you create.
The configuration file â /etc/default/btrfsmaintenance â is fully documented and tells you how to start the timers and/or change the configuration.
But from now on, the data in this snapshot is fixed, and you only use the remaining free space on your btrfs volume.
A few days later, you perform an update.
And so on ⌠You change, delete, and rewrite.
This old snapshot prevents btrfs from releasing all the files you âdeletedâ or overwrote during and after the update. This way, you use up more and more free space.
Meanwhile, you create more snapshots that âuse no space.â
Balancing doesnât do you any good!
Deleting some snapshots doesnât seem to do anything!
Deleting some large files doesnât help either!
It seems like you canât break free.
Thatâs because all those files are held by that âevilâ oldest snapshot. Itâs not a problem to take a lot of snapshots. But it is a problem to keep old snapshots for too long. (especially in manjaro)
Delete your oldest snapshot and youâll get the most free space possible!
No joke: Sometimes deleting the 5 oldest snapshots gave me an additional 25% of space on the btrfs volume.
Lesson to be learned:
Donât forget to automatically delete old snapshots
The snapshot uses almost zero space at first, but the subvolume it is a snapshot of will keep on changing, and this data must be stored too, so then ultimately, the snapshot ends up taking up space after all, because it occupies the unmodified disk blocks.