Failed to start light display manager - running low on space

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.

Best Regards
Jean

1 Like

Yes that’s not enough space.

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.

What percentage is 3.8GB of the root partition?

4 Likes

How big is your / (root) partition?

lsblk -f
will tell you

or

df -h

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.

3 Likes

Welcome back! :wave:

Please help us help you by:

  • Editing your topic title to be clear and concise about the issue you’re having
  • Editing your first post to provide more information

Please see:

2 Likes

diskspace
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.

thanks.

rm: can not ‘sudo rm /var/cache/pacman/pkg/*’ remove: file or folder does not exist.

no candidate packages found for pruning.

My native language is Dutch so i am trying to write correctly in english but forgive me if it is not always correct.

Thanks
Jean

3.6Gb 92%

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.

Search results for 'btrfs order:latest' - Manjaro Linux Forum

Btrfs Maintenance - Manjaro

Btrfs - Manjaro

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.

1 Like

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

:footprints:

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

 Device unallocated:		523.94GiB
...
Unallocated:
   /dev/sda2	261.97GiB
   /dev/nvme0n1p3	261.97GiB

is what you need to look for.


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 :wink:
:footprints:

2 Likes

I don’t know - isn’t this a little less information than that command gave you? :wink:

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 … :grimacing:
I wrote under the assumption that your file system was ext4 - which it is not, as it turns out.

3 Likes

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.

Thanks
Jean

1 Like

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:

#Start it:
sudo btrfs balance start -musage=90 -dusage=90 --bg /
# Watch the progress:
sudo watch -n1 'btrfs balance status /'

Anyhow @andreas85 explained it also:

:notebook: A final word: If you are using BTRFS and snapshots, keep an eye on the filesystem to make sure it is about 20% free.

3 Likes

I know - it is a choice I made - I considered the pros and cons - and the cons weighed too much.

1 Like

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.
:+1:

2 Likes

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. :wink:

Ok Thanks.

How do i install that btrfsmaintenance package?

Deleting all the timeshift snapshots was maybe part of the solution?
I don’t know.

Either way i am happy that i can continue using my Manjaro setup again.

Best Regards
Jean

The same way you would install any other package:

sudo pacman -Syu btrfsmaintenance
2 Likes

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. :wink:

2 Likes

That’s not quite how it works :wink:

A snapshot uses almost no storage space!

  • 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 :footprints:

1 Like

That’s what I was trying to say. :wink:

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.

2 Likes