Login only through tty after using Testdisk

Hello Dear Fellows,
I am a beginner user learning always from reading tons of tutorials and advices on the Forum so I thank you all.

I deleted by mistake a folder with bunch of pdfs and papers. Then I tried Testdisk on the terminal to recuperate the files. Well, I couldn’t. I don’t know what I did, I guess the backup image downloaded was too big and the system crashed.

After rebooting I have now no access thru graphical login, only thru tty and I get to the terminal where I have no clue what to do next.

I would appreciate any help!

(Dear moderators, I’m not sure if I’m posting this on the right topic :confused: )

The bare minimum should be the output on inxi -zv8 (Enclosed in 3 back quotes, or the preformatted text button.)

At least we would be able to tell what file system you’re using, what desktop environment (DE), plus so much more.

If you are using tools that reverse engineer data blocks, like Testdisk; just by using your system, is lessening your chances to recover your files. Even then, it can be a long shot, or impossible.

How did you delete them? With your DE’s file manager? They are not sitting in Trash, right? You most likely deleted needed files in ~/.local or ~/.config.

Assuming the data is gone, and you’ve deleted files your DE needs. The easiest way, would be to create another user account. (The username can be changed after, but you’ll need a different UID.) Remember to copy the groups over, as users in the wheel group can only sudo, audio for playing sound, etc.

1 Like

ok, I will start from here.
Thanks for the reply.

Not ok, I thought the output would be shorter.

I

Where should I do that? (I am so lost)

How about the output from df -Th in order to verify the state of your partitions?

1 Like

Thanks!
I can copy some lines, sorry for sending a picture.

/dev/nvme0n1p4 ext4 where home is, available at 0% and its use at 100%, is that ok?

No, not ok. Might be one of the reasons your system is not fully loading.
You should check the filesystem for errors and try to delete something from that home. You can do that from a live usb session.
If you don’t have important files or have backup it might be easier for you to reformat the whole disk and reinstall.

1 Like

Thanks.
I am trying to delete some folders, I dont know if it would work.
From a live usb, with manjaro chroot?
Would be different from tty terminal?

You cannot fsck a mounted filesystem.

1 Like

I can’t boot from my live usb, sth’s changed. i cannot access to Bios now…

Do not use made up abbreviations, as if this was social media or a chat app; use correct spelling and punctuation to encourage serious responses.

Please understand I’m not trying to be petty, but even this reader – who can read through it most times – had to stop for several moments to decipher exactly what you had written.

I thought it might have been some vague reference to Star Wars.


Your /home partition is completely full. Whether it was already full before your current predicament, or whether temporary files created by TestDisk added to that, I can’t say.

Filesystem      Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p4  ext4  358G  358H     0 100% /home

Certainly an over utilised /home partition will have contributed to your inability to login via the gui as expected. You would need to clear some of that space; delete larger movie or ISO files, for example, or move them to external (USB) storage.

You also appear to have no swap partition configured (are you using a swap file?).

A bootable Manjaro DVD/ISO/USB will be needed no matter what, to attempt any repairs or workarounds. It’s highly likely that the files you originally tried to recover are beyond that now. I’m tending to agree with the comment from @Teo

1 Like

You can reclaim/gain ~12 GB with one simple command:
sudo tune2fs -m 1 /dev/nvme0n1p4

You don’t even need to boot from USB or care about whether the partition is mounted or not.

But then, after that it is critically important that you make some room by moving or deleting files from your /home .

Explanation:
the ext4 file system is created with 5% of the space reserved for the root user, not accessible to anyone else, namely you as the normal user, using your /home partition.
It’s a waste of space in the case of large partitions.
The command sets that reserved amount to just 1% - so you gain access to 4% more … just like that.
Helpful in cases of “disk full”.

5 Likes

Isn’t that percentage of space reserved on the / (root) partition?

The OP’s / utilisation is within an acceptible range already – though, maybe not so ideal if they happen to be using a swap file. :eyes:

No swap partition is indicated on the posted screenshot, but it’s possible a swap file exists on /. So far, the OP hasn’t responded to the question previously asked, that would conffirm or deny it.

Filesystem      Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  ext4   58G   39G   17G  71% /

As /home is on a separate partition, creating a new user will still require space on that partition, and that space is simply not available. The OP must clear some space - move or delete files from /home.

That said, the OP has hinted at other difficulties which might mean other as yet undisclosed issues are at play. Adding the OP’s obvious (and self-confessed) cluelessness into the mix, I keep returning to @Teo’s resolve.

No.
Upon file system creation, a certain percentage is reserved for the root user exclusively.
By default this is 5% (much too large a reserve with the disk sizes nowadays).
It’s the file system itself, not where it is mounted to.

Ext4 - ArchWiki

This makes it possible, in this case, to “magically” gain some free space for the user, so the login will likely work again.
… this only applies to ext2/3/4 file systems

From what I know about BTRFS (which is next to zero), he would be in much more trouble in this situation.

2 Likes

Interesting;
and after skimming through it, it even seems familiar.

Yet another thing I’ve known, and forgotten;
no doubt the cycle will continue. :smile_cat:

2 Likes

You still didn’t post your system info (inxi). So no idea what DE you’re running. The command line route has been the same as Linux itself. useradd command to add, and usermod to change properties.

I’ll use user for your existing user, that won’t load your DE. And I’ll use the username: olduser, but this can be anything you want your current account renamed to (which will just sit there, broken as is, until you delete it).

# Rename user
sudo usermod -l olduser user

# Move your previous home folder out of the way
sudo mv /home/user /home/olduser

# May as well set the home directory, even though this account is borked
sudo usermod -d /home/olduser olduser

# Get your old groups 
groups olduser

# Add new user. Note: Use the groups from the previous command
sudo useradd -G wheel,audio,users,etc -s /bin/bash -m user

# Change username to previous
sudo usermod -l user olduser

# Set password and go
sudo passwd user

This will have a brand new user with your old username, but different UID, home, etc. The old user and folders still exist. And your old account is called olduser, or whatever you filled into the above commands.

Btrfs requires more free space to work it’s magic. But this is wrong. Btrfs may need that free space to do things, but when it can’t find a chunk for data, it throws a ENOSPC error, and just doesn’t give any more. So same result as ext among others.

With btrfs you could add a flash stick to your pool, on a live filesystem, and start using all the free space instantly. Not that you would do this normally, but you could! There are more options for sure though, for making it bigger, live resizing/transforming, moving all or some things around, etc. So you have more options, once you do fill up.

But isn’t all this moot? I thought all the space was taken up from Testdisk temp files?

1 Like

Yes, likely.
But he won’t find them to delete them when he can’t use the graphical tools, when he can’t have his usual desktop session.

… is my guess

no need to elaborate on BTRFS here - it’s not what is at play.

I already regret having mentioned it in the post to @soundofthunder :sunglasses:

unneeded detail that is just confusing for the OP

1 Like

You said it’s worse when filling up! I could not live with myself if I didn’t have that statement rebutted.

If this person is not remaking his filesystem (reinstalling), then finding these files is a priority.

Start at the top and work down.

sudo du -s /* | sort -nr

This will take some time. But those are the totals in bytes, for the all the data each file and folder in your top level root directory.

If you see that /usr, for example, using a lot of data, check that directory the same way.

sudo du -s /usr/* | sort -nr
5235948 /usr/lib
4900780 /usr/share
973852  /usr/bin
516324  /usr/lib32
479144  /usr/include
632     /usr/src
4       /usr/sbin
4       /usr/local
... 

Then sudo du -s /usr/lib/* | sort -nr, and so on. If they are taking hundreds of gigs, they should be really easy to find.

P.S. We normally use du with -h to read it easier, but you can’t sort them with sort easily.

2 Likes

I would think sorting in ascending order be easier, especially on a tty:

du -sh /home/$USER | sort -h

You can with sort -h

They both do the same thing.