Broken file-system after forced shutdown

I just switched from Elementary to Manjaro (the latest KDE min ISO, encrypted disk). In Elementary OS I used to shutdown my machine by running shutdown now from a terminal. Unfortunately, when I tried doing so in my Manjaro installation the file-system got corrupted somehow (?), as I’ll try to explain in the following.

After shutting down the computer with shutdown, the machine wasn’t able to open a tty due to errors in a mapper file (I don’t quite remember what the error message was, but it was something like that) and it asked me to run fsck /dev/mapper/luks-4db6e442-011a-4887-9170-46d9191ebb5b manually. I then run fsck and answered every question it asked with the default answer.

After that, the machine was able to open the tty. However, now the (hard drive) file-system appears to be broken: when I try reading/writing/stating certain files I get the error message “Structure needs cleaning”, which I understand as an indicative of file-system corruption.

Could anyone help me figure out what’s going on/how to fix it? I don’t mind reinstalling Manjaro btw, but I would prefer an alternative solution. If there’s some technical information you need, please ask me (I just don’t know what that information might be).

It’s also worth noting that the file-system corruption issues started in Elementary: I first tried installing Manjaro but it didn’t work out (the ISO wouldn’t boot because I unknowingly had Secure Boot enabled). I then gave up on installing it. However, after the failed installation attempt, the file-system in Elementary got corrupted too! (I was getting the same “Structure needs cleaning” error)

I then tried installing Manjaro again and figured out what was wrong, but the corruption persists somehow.

Mmmh. Try:
Boot-Stick with Manjaro-Gnome.
Start the app Gnome-Disk an let it repair the drives in question…
For the brave: try/use gparted repair options…


Isn’t there a way to do so from KDE? Which driver should I try to repair? Is it the hard drive mapper?

No way to do this from a running system.
KDE-Stick: try gparted… (its there per default)

Ok, I would prefer to reinstall Manjaro then. However, I’d like to prevent this issue from happening again. Should I stop encrypting the disk? Is there a probable cause for this issue?

Iam not the expert for.
But on reinstall you have to fix the filesystem before installing.
GParted is a grapic tool on the installation medium…

I see, thank you very much for your help! I’ll try doing so then.

Also worth noting: I’m using borg for the backups of my personal files. Could borg be the cause of this issue?

Mmh Borg are evil :innocent:
Until borg doesnot run as admin, it can do no harm to the system.
system and userspace are dividet in partes duo / separet issues

I see, thanks! This is a relief, since otherwise I wouldn’t be able to rely on my backups :sweat_smile:

Update: I tried @GaVenga’s solution and it worked flawlessly! Didn’t even need to reinstall anything. There was some data loss (mainly the files that “needed cleaning”), but nothing of significance as far as I can tell. @GaVenga Thanks for your help!

1 Like

I would still worry why your file system would get corrupted on two different distro though.

Yes, I’m concerned about that too. But it is important to remember that the FS only got corrupted in Elementary after I tried (and failed) booting into Manjaro. Could it be the case that the unsuccessful installation attempt messed something up (and the subsequent successful install did not fix it for some reason)?

More information on the unsuccessful attempt: when I selected the USB drive (the one with the ISO burned in) in the BIOS boot device selector I got a black screen for a fraction of a second and then the BIOS boot device selector came up again. I didn’t even got to the installer at first. After this, I started experimenting the corruption issues I described in Elementary.

I later figured out this happened because I had Secure Boot enabled and the Manjaro ISOs are not signed. I imagine trying to boot from the USB drive with Secure Boot enabled caused the issue, thought I don’t have sufficient knowledge to confirm or deny that this is the case. I guess we’ll see whether or not my theory has some merit (I’ll be back here if my system gets unstable again in the near future).

Now you can play with S.M.A.R.T. and look for drive-failures. Do that in Windows, its simpler there…

This might be the reason for your corrupted files - if you ran fsck on the device while it was still encrypted (the encrypted container not yet opened).
You have to open the container/decrypt the device or partition before you can work on the filesystem on it.
… it’s uncertain to me what happened …

Or do that in Manjaro there are lot of tools that will do the same or even better than windows tools. Example: GSmartControl Application - GSmartControl - Discover Applications On Manjaro Linux

Perry Rhodan, Ennerhal:
Es gibt da gewisse Möglichkeiten… :innocent:

O.T.: Ennerhahl – Perrypedia


I managed to do it. Somehow.
I could describe to you how it happened if you are interested.
But that’s how I know.
I lost all my backups. It was a 2 TB USB connected spinning disk which died soon after.

But maybe I was able to run fsck,
which was set to correct errors it found without asking each time,
because the drive was already malfunctioning intermittently.

The one thing I have not yet done is to open the case (it has to be destoyed to do that) and trying to connect the drive by some other way.

But with that many writes - it found and “corrected” a lot of “errors” - I’ts unlikely that I’ll be able to open the encrypted container ever again.