I’ve been having lots of issues ever since I installed Manjaro. I’ve managed to fix majority of the problems on my own, but now I’m stumped.

I got this on my screen

/dev/mapper/luks-3acb28cf-a378-4e96-a336-0df25478de40 contains a file system with errors, check forced.
Error reading block 185598141 (Input/output error) while getting next inode from scan.

/dev/mapper/luks-3acb28cf-a378-4e96-a336-0df25478de40: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)

I typed out:

fsck /dev/mapper/luks-3acb28cf-a378-4e96-a336-0df25478de40

The computer isn’t responding or showing up. I expected a shell or grub rescue or something to show up. Am I doing something wrong?

I’ve corrected the typo of the error message in the title.
Make sure the filesystem to check is not mounted. Best to boot your system from usb and

$ fsck -f /dev/mapper/luks-3acb28cf-a378-4e96-a336-0df25478de40

from there.
You should get prompted for any errors and answer y to let fsck fix them.

I booted from an SD card, and used the open-source driver. After I put in the information above, I received:

fsck from util-linux 2.36.2
e2fsck 1.46.2 (28-Feb-2021)
fsck.ext2: No such file or directory while trying to open /dev/mapper/luks-3acb28cf-a378-4e96-a336-0df25478de40
Possibly non-existent device?

I’ll try to mess around with it, but if you have any idea what to do, let me know.

That (corrupted) filesystem identifier looks like an encrypted one to me.
You need to open the cryptdevice first:

$ cryptsetup luksOpen $partition $cryptdevice

and only then issue

$ fsck -f /dev/mapper/$cryptdevice
1 Like

Alright so I messed around with it, and it looks like I forgot to unencrypt it like you said. I just unencrypted it using my passphrase/password, it seemed to start working again.

Here’s as far as I got:

$ sudo umount /dev/mapper/luks-3acb28cf-a378-4e96-a336-0df25478de40
$ sudo fsck -f /dev/mapper/luks-3acb28cf-a378-4e96-a336-0df25478de40 fsck from util-linux 2.36.2 e2fsck 1.46.2 (28-Feb-2021) Pass 1: Checking inodes, blocks, and sizes Error reading block 185074164 (Input/output error) while getting inode from scan. Ignore error<y>? yes Force rewrite<y>? yes

And now I haven’t gotten a response in an hour.
This is the same wherever there is an Error reading block

If I respond with a:
Ignore error<y> no
I get:
Error while scanning inodes (46275840): Can't read next inode e2fsck: aborted

It keeps giving a list of blocks, and I have to keep skipping them to avoid getting an error. Is there a way to target specific blocks? Or is there a way to fix the huge wait time for it to be rewritten? I’m fine with waiting, but I don’t know if it’s even accomplishing that task or not. The terminal just let’s me type anything without responding (just like what happened when I tried to boot it up).

(This all in Case 1; I’ll update this with what’s happening in Case 2.)

if it is an ext4 (or ext2 or ext3) filesystem
run the filesystem check more specifically
targeted at the filesystem actually present

man e2fsck

the -y option will allow you to run it with a response of “yes” to every question

after all:
you want to repair the filesystem
if you don’t / if you say “no” …
the error will persist
of course
it will not be corrected
that is what you told it to do …

having a backup is good - old wisdom …


I went along with:
Ignore error<y>? yes
Force rewrite<y>? no
Until I got to Case 2

The rest of the process fixed the computer. I pressed y a lot and it looks like it worked. The rest of the process fixes those blocks it seems. I just had to made sure not to force a rewrite.

Thank you so much both of you!

My solution:

$ sudo umount /dev/mapper/luks-3acb28cf-a378-4e96-a336-0df25478de40

$ sudo fsck -f /dev/mapper/luks-3acb28cf-a378-4e96-a336-0df25478de40

fsck from util-linux 2.36.2
e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes Error reading block 185074164 (Input/output error) while getting inode from scan.

I repeated the following until I got to Case/Pass 2:
Ignore error<y>? yes
Force rewrite<y>? no

Make sure not to force rewrite if it pops up.
The rest is pressing y a lot.
It probably works because the rest of the process fixes the issue. (Correct me if I’m wrong)

G’luck to anyone who might be reading this in the future

if you do not fix it - if you say “no”
… it will not get fixed
and it will pop up later, again, as an error
fix it,
yes to all
no way around it
have a backup from before fixing it if you don’t trust e2fsck :wink:

you know the filesystem
it is (very likely) ext4
so you can use
with the “-y” option
instead of
fsck …

Yeah, it looks like you’re right. The problem doesn’t get fixed and it shows up again.
I’ll try that the next time I boot it up.
My problem is that when I chose yes on both, the computer didn’t respond for at least an hour. Do I have to wait it out?

don’t know
probably not
the error will be present next boot, I guess

tune your filesystem
to be checked every x mounts
no matter what - no matter whether there was a failure or not
takes a few seconds
every x boots

man tune2fs
sudo tune2fs -c 10

to have it checked after 10 boots

I can’t make anything of that - no idea what happened there.

These don’t look good. Backup your important data as soon as possible.
Check the device with another cable on another (sata?) port if possible in another machine to be on the safe side.

I took your suggestion with e2fsck -y, but the computer stopped responding after I said yes to Force rewrite. I’ll try it again, but this time with skipping rewrite.

(It’s a bit of exaggeration to say “stopped responding”. It’s more like no text shows up.)

Also, I’ll set that up, but I’ve been repairing this every time I’ve booted this up.

Well, if it’s useful information I have at least 10 of those errors.

I’m confused what you mean. What does that error mean? Sata port?
Also, don’t worry about it, everything is already backed up.

“Input/output error” looks like a hardware problem. There are different hardware parts involved so the suggestion is to check them all:

  • different cable (if a cable is involved)
  • different sata port (if it’s a sata device)
  • different machine (if it’s a problem with the mainboard itself)

If the errors persist after changing all of the above it’s relativly safe to assume the problem lies within the device itself.