Failure reading sector 0x9a2e8 from `hd0'

It seems as though the partition became more damaged after the fsck, unfortunately.

The lost+found didn’t seem to persist.

The GParted will not even display stats on the drive anymore like “Journal backup” and “FS Error Count” and Used vs Free Space etc. Its a bit concerning for me.

To Dear @Keruskerfuerst ,

I tried [that page you mentioned above](https: //linuxexpresso. wordpress. com/2010/03/31/repair-a-broken-ext4-superblock-in-ubuntu/) namely the command to output the relevant superblocks and then the last one to attempt to restore the filesystem from another superblock (backup), but now at boot I get an error immediately after ‘Slot 0 opened’:

error: file `/boot/grub/x86_64-efi/normal.mod' not found.
Entering rescue mode...
grub rescue>

Maybe its too much, again I’m about to pass out, so will look at this with fresh brain later.

Best remedy might be prevention. ie. never hold down a power button on Arch/Manjaro Linux (?) while running i2p? I was always able to on a different gnu linux but admit that that other o/s had some bothersome aspects too.

Maybe the hardddisc is faulty. Then you can do nothing more.

It doesn’t appear to be the HDD because at two moments above I did have access to files. fsck.ext4 restored them into a lost+folder, but again they’ve seemingly vanished after I rebooted.


Whenever I try a different superblock (from that page you mentioned, @keruskerfuerst ) ie.

sudo e2fsck -b block_number /dev/mapper/xxx 

…the output on the screen iterates through SO MANY blocks that the screen looks like white noise for ten minutes. That might be a CLUE as to what I’m doing wrong. I can’t imagine that the developers of the software intended for that sort of output.

I could be wrong.

One person in 2013 commented to use the readonly flag -c . So I’m going to try that.

Wish me luck again. If any ideas, please tell. :slight_smile:

Have been trying a bunch of stuff to try and get that ‘lost+found’ folder back.

Have tried a couple different blocks and -vcckb < SUPER_BLOCK_NUM> (so yes after trying -c for the read-only test a couple times I came to the conclusion that its the same as fsck.ext4 so I reverted back to that to do -cc and -k and -b )

Each of these takes about half a day to run.

Going to keep running it with different settings until I get this person’s stuff back. Yep, yule fool time.

In case anyone on these forums an I2P enthusiast (or knows someone who is please, report this to them. I’ll update the title with “(FATAL I2P BUG?)”

Initially I thought that I would rename that thread to add “Fatal I2P vulnerability/bug?” but I thought about it and decided it may warrant its own thread completely because I think its serious.

Are there any I2Pers here that are willing (and importantly, able) to pass this to the dev team at this time?

The precise version of I2P that I was running was the one just prior to the new version that was sent out to folks over i2psnark about one week eariler. I had yet to restart and thus update.

Other info: A torrent may have finished downloading while the PC was in standby nothing huge.

Lifetime writes on the partition was only 250GB and that’s from a year of usage. Then problem is in software and not in hardware in my honest opinion. I have good reason to believe that I2P is not playing nicely with Manjaro and or ArchLinux.

I should also mention that I did say something the day prior pseudo-anonymously about a grave injustice by western governments.

Silently starting to question whether computers are designed for actual humans.

I don’t use I2P, but i don’t see why a network layer software would access a file system directly, instead of relying on the operating system it is installed on. Even from a bug in it.

Vulnerabilities are flaws in a (software or hardware) system that allow to run arbitrary code. So strictly speaking, a vulnerability doesn’t break a file system, the malware code may. Though unless you run I2P with superuser privileges, that should hardly happen.

But the most likely source of your original issue is simply a failing drive.

Hello again, dear Manjaro people!!

@maycne.sonahoz Yes. Maybe it is not I2P to blame but the way I reset the system by holding down the power button to off-and-on. That could’ve damaged the filesystem, yes?

**A person I saw recently said I should have used the technique of holding Alt + Print Screen while pressing REISUB (or BUSIER backwards) and this is much safer. **

Anyway I decided to test (mind the pun) testdisk and it worked! I hoped to use software only available on the live disk but beggers can’t be choosers. :slight_smile: The lost+found folder appeared to me again, and had a number of folders in it and together they are many GB and possibly the entire operating system?? The extent of what has been restored is here.

One folder (maybe /boot ??) contains:

 drwx------     0     0      4096 ..
 drwxr-xr-x     0     0      4096 efi
 drwxr-xr-x     0     0      4096 grub
 drwxr-xr-x     0     0      4096 memtest86+
 -rw-r--r--     0     0       XXX linux54-x86_64.kver
 -rw-r--r--     0     0       XXX linux510-x86_64.kver
 -rw-r--r--     0     0       XXX vmlinuz-5.8-x86_64
 -rw-r--r--     0     0       XXX initramfs-5.8-x86_64.img
 -rw-r--r--     0     0       XXX initramfs-5.8-x86_64-fallbac
 -rw-r--r--     0     0       XXX linux59-x86_64.kver
 -rw-r--r--     0     0       XXX vmlinuz-5.9-x86_64
 -rw-r--r--     0     0       XXX initramfs-5.9-x86_64.img

Another folder ()

 lrwxrwxrwx     0     0         3 lib64
 lrwxrwxrwx     0     0         3 sbin
 drwxr-xr-x     0     0       XXX bin
 drwxr-xr-x     0     0       XXX include
 drwxr-xr-x     0     0       XXX lib
 drwxr-xr-x     0     0       XXX local
 drwxr-xr-x     0     0       XXX share
 drwxr-xr-x     0     0       XXX src
 drwxr-xr-x     0     0       XXX lib32
 drwxr-xr-x     0     0      4096 libexec

Another folder

 drwx------ .gnupg
 drwx------ .cache
 -rw-r--r-- .bash_logout
 -rw-r--r-- .bash_profile
 -rw-r--r-- .bashrc
 drwxr-xr-x .config
 -rw-r--r-- .screenrc
 -rwxr-xr-x .Xclients
 -rw-r--r-- .dir_colors
 -rw-r--r-- .profile
 -rw-r--r-- .xinitrc
 drwx------ .dbus

Another folder

(the contents of /home/ !! )

Another folder (/var?)

 lrwxrwxrwx     0     0       XXX lock
 lrwxrwxrwx     0     0       XXX mail
 lrwxrwxrwx     0     0       XXX run
 drwxr-xr-x     0     0      4096 cache
 drwxr-xr-x     0     0      4096 db
 drwxr-xr-x     0     0      4096 empty
 drwxrwxr-x     0    50      4096 games
 drwxr-xr-x     0     0      4096 lib
 drwxr-xr-x     0     0      4096 local
 drwxr-xr-x     0     0      4096 log
 drwxr-xr-x     0     0      4096 opt
 drwxr-xr-x     0     0      4096 spool
 drwxrwxrwt     0     0      4096 tmp
 -rw-r--r--     0     0       XXX .updated

Another folder

 dr-xr-xr-x     0    11      4096 ftp
 drwxr-xr-x     0     0      4096 http

Another folder

 lrwxrwxrwx     0     0       XXX arch-release
 lrwxrwxrwx     0     0       XXX os-release
 drwxr-xr-x     0     0      4096 binfmt.d
 drwxr-xr-x     0     0      4096 cron.daily
 drwxr-xr-x     0     0      4096 cron.monthly
 drwxr-xr-x     0     0      4096 exports.d
 drwxr-xr-x     0     0      4096 gssproxy
 drwxr-xr-x     0     0      4096 iptables
 drwxr-xr-x     0     0      4096 kernel
 drwxr-xr-x     0     0      4096 lvm
 drwxr-xr-x     0     0      4096 mkinitcpio.d
 drwxr-xr-x     0     0      4096 modprobe.d
        (... skipped files ...)
 drwxr-xr-x     0     0      4096 sensors.d
 -rw-r--r--     0     0       XXX ts.conf
 drwxr-xr-x     0     0      4096 grub.d
 -rw-r--r--     0     0       XXX tlp.conf
 drwxr-xr-x     0     0      4096 openldap
 -rw-r--r--     0     0       XXX resolvconf.conf
 -rw-r--r--     0     0       XXX ostree-mkinitcpio.conf
 -rw-r--r--     0     0       XXX anacrontab
 drwxr-xr-x     0     0      4096 libnl
 -rw-r--r--     0     0       XXX mhwd-x86_64.conf
 drwxr-xr-x     0     0      4096 timeshift

I’ve done a bunch of searches online about whether an O/S can be restored from files collected in Lost+found but nothing seems to talk in those terms. Possibly because its difficult to guarantee that a bunch of restored files will function as a whole system. Not even the website of System Rescue seemed to talk about it.

Maybe I should cut my losses and just go through the process of reinstalling the O/S?

I would like to try to repair the O/S and/or partition and/or GRUB though, as an exercise in seeing whether I really have a bad HDD or its just a software glitch.

When I boot I get:

error: file `/boot/grub/x86_64-efi/normal.mod' not found.
Entering rescue mode...
grub rescue>

Whenever I run fsck though, irrespective of which superblock I try (with fsck -b [SUPERBLOCK]) I’m always getting the same

If you do it regularly, more like the drive itself. Obviously, if you cut the power while the drive is working, you likely leave it in an unstable stable.
But it could also simply be the drive wearing itself; that’s not uncommon.

I’m not knowledgeable enough to help you on file recovery.

Gentle shut down a suddenly hanged PC to minimize a chance of getting a broken filesystem and data loss: