"run fsck manually" but runs indefinitely

millus · 2021-12-23 11:20:45

I unplugged a TV USB stick and as so often the pc froze up from that cause it causes some kernel error.
So I pressed off switch for long enough for forced power off and rebooted.
Usually fsck will then do a few things to restore the file system and it's fine.

But now I goot:
/dev/mapper/volume-archlinux: Block bitmap for group 4416 is not in group.
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
ERROR: Bailing out.
FILESYSTEM CHECK FAILED.
Please run fsck manually.

So I do run

[rootfs ]# fsck /dev/mapper/volume-archlinux
fsck from util-linux 2.37.2
e2fsck 1.46.4 (18-Aug-2021)
ext2fs_ckec_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad.. trying backup blocks...
/dev/mapper/volume-archlinux was not cleanly unmounted, check forced.
Pass 1: Checking inodes, block,s and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differances:   ............ 15 lines of weird numbers spam
Fix<y>?

And if I say "y" now I get prompted a few times more, and then it asks if I just want to fix "a"ll, and I said yes and after some more lines a mad number spam started that makes the whole screen unreadable and never seems to end so I had to hard shutdown the system.
Uh, what do I do now? Thanks!

Last edited by millus (2021-12-23 12:50:49)

seth · 2021-12-23 13:49:10

Stop performing hard shutdowns - your filesystem is already fucked up and cutting into fsck's rewrite process is just going to make things worse.
"weird numbers" and "mad number spam" isn't really informative but I assume fsck is simply printing the blocks and inodes it repairs.

You can run "fsck.ext4 -p -y /dev/mapper/volume-archlinux" for a non-interactive scan & repair.
Your best chance is to just let fsck finish its thing - this can take a while depending on the size of the FS. But since the FS descriptor is corrupt, you also better have backups…

millus · 2021-12-24 01:38:28

Thanks for the reply.
Well the number spam is just as informative as my description thereof: The screen just gets spammed at unreadable speed by numbers, there is no further information output either.

I made a new backup just in case and let your command run, btw -p and -y don't go together, and -p isn't considered "manual" run so it would refuse, but just "-y" actually worked.
After it finished, I was able to boot into the system normally.
I just wonder if there is now some minor file corruption that cannot be spotted except by chance (eg if it's a text file, I happen to open it and see it contains some garbage at some point?). So far I didn't notice anything unusual though.

According to SMART tests the SSD was phyisically totally fine though, so it was just Linux (kernel) which hard-freezes everytime I unplug the TV USB.
But really, isn't there a way to make the system more robust somehow against silly thing like USB-unplugging??? Does it really need to completely blank + freeze just from something like that? Seems really weaksauce, no? "This USB stick can now no longer be used on archlinux machines because the kernel might kill my filesystem when I remove it".. lol.

Last edited by millus (2021-12-24 01:40:20)

seth · 2021-12-24 08:51:01

A filesystem corruption doesn't require bad sectors.
There's not way to check the integrity of files except for comparing them to some validated base (ie. md5sums against your backup) - I guess fsck would have printed the files it touched but that got lost in the flurry of output (you could have redirected that into a log…)

About the usb key: if the kernel module goes wild and compromises the kernelspace, you're fucked (that's the main argument for a microkernel architecture) - there's a chance that only the usb stack got fucked up and you could access the system over ssh (or a PS/2 keyboard…)
I'd tell you to unload the kernel module before withdrawing the dongle, but guess we've been there in your other thread.
Did you file a bug against the kernel module for the dvb dongle?

Arch Linux

#1 2021-12-23 11:20:45

"run fsck manually" but runs indefinitely

#2 2021-12-23 13:49:10

Re: "run fsck manually" but runs indefinitely

#3 2021-12-24 01:38:28

Re: "run fsck manually" but runs indefinitely

#4 2021-12-24 08:51:01

Re: "run fsck manually" but runs indefinitely

Board footer