Failure reading sector 0x9a2e8 from `hd0'

Support
12

that is non-destructive…

  1. one -c means readonly test
  2. two -cc means non-destructive read-write test 
       -c     This  option  causes e2fsck to use badblocks(8) program to do a read-only scan of the device in order
              to find any bad blocks.  If any bad blocks are found, they are added to the bad block inode  to  pre‐
              vent  them  from being allocated to a file or directory.  If this option is specified twice, then the
              bad block scan will be done using a non-destructive read-write test.

fsck.ext4 has no destructive mode. Only when running mkfs.ext4 -cc or badblocks -w

13

Yes, I read that but was still second guessing.

Great! So that first delete wouldn’t have gone ahead (because I was using fsck.ext4).

A lot of stuff was output by the fsck. Is there anything that I should relay or use? I’m a bit tired now so will, check tomorow and read everything again with fresh brain :slight_smile:

14

Results of:
sudo fsck.ext4 -vcck /dev/mapper/name_I_gave

It’s typed by hand so please don’t be surprised by minor errors.

Pass 1: Checking inodes, blocks, and sizes
Bad block list says the bad block list inode is bad. Clear indoe<y> yes
Error reading block <NUMBER> (Input/output error) while getting next inode from scan. Ignore error? yes
Force rewrite? yes
Root inode is not a directory. Clear? yes

Pass 2: Checking directory structure
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED_1> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes
Entry'..' in <2>/<NUMBER IN THE MILLIONS OMITTED_13> (SAME_NUMBER) has deleted/unused inode 2. Clear? yes

Pass 3: Checking directory connectivity
Root inode not allocated. Allocate? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED_1 (...)
Connect to /lost+found? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED (...)
Connect to /lost+found? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED (...)
Connect to /lost+found? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED (...)
Connect to /lost+found? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED (...)
Connect to /lost+found? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED (...)
Connect to /lost+found? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED (...)
Connect to /lost+found? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED (...)
Connect to /lost+found? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED (...)
Connect to /lost+found? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED (...)
Connect to /lost+found? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED (...)
Connect to /lost+found? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED (...)
Connect to /lost+found? yes
Unconnected directory inode NUMBER IN THE MILLIONS OMITTED_13 (...)
Connect to /lost+found? yes

Pass 4: Checking reference counts
Inode NUMBER IN THE MILLIONS OMITTED_1 ref count is n(OMITTED), should be n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Unattached inode NEW_BIG_NUMBER_A
Connect to /lost+found? yes
Inode NEW_BIG_NUMBER_A ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Unattached inode NEW_BIG_NUMBER_B
Connect to /lost+found? yes
Inode NEW_BIG_NUMBER_B ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Unattached inode ANOTHER_NEW_BIG_NUMBER
Connect to /lost+found? yes
Inode ANOTHER_NEW_BIG_NUMBER ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Unattached inode ANOTHER_NEW_BIG_NUMBER
Connect to /lost+found? yes
Inode ANOTHER_NEW_BIG_NUMBER ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Unattached inode ANOTHER_NEW_BIG_NUMBER
Connect to /lost+found? yes
Inode ANOTHER_NEW_BIG_NUMBER ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Unattached inode ANOTHER_NEW_BIG_NUMBER
Connect to /lost+found? yes
Inode ANOTHER_NEW_BIG_NUMBER ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Unattached inode ANOTHER_NEW_BIG_NUMBER
Connect to /lost+found? yes
Inode ANOTHER_NEW_BIG_NUMBER ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Unattached inode ANOTHER_NEW_BIG_NUMBER
Connect to /lost+found? yes
Inode ANOTHER_NEW_BIG_NUMBER ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes
Inode NUMBER IN THE MILLIONS OMITTED ref count is another_n(OMITTED), should be another_n-1. Fix? yes

Pass 5: Checking group summary information
Block bitmap differences:  -(NNNN--NNNN) -(NNNNN--NNNNN) -NNNNN -(NNNNN--NNNNN) -NNNNNNNN -(NNNNNNNN--NNNNNNNN) -NNNNNNNN -NNNNNNNN -(NNNNNNNN--NNNNNNNN)
Fix? yes
Free blocks count for group #0 (NNNN, counted=<SLIGHTLY_LARGER_NUMBER>)
Fix? yes
Free blocks count for group #1 (NNNNN, counted=<SLIGHTLY_LARGER_NUMBER>)
Fix? yes
Free blocks count for group #2 (NNNN, counted=SLIGHTLY_LARGER_NUMBER)
Fix? yes
Free blocks count for group #NN (NNNNNNNNNN, counted=0)
Fix? yes
Free blocks count for group #NN (NNNN, counted=SLIGHTLY_LARGER_NUMBER)
Fix? yes
(...)
(... THERES ENOUGH OF THIS WITH MINOR VARIATION...)
(...)
/dev/mapper/name-chosen: ***** FILE SYSTEM WAS CHANGED *****

      NNNNNN inodes used (1.N%, out of NNNNNNNN)
        NNNN non-contiguous files (0.N%)
         NNN non-contiguous directories (0.N%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: NNNNNN/NNN
    NNNNNNNN blocks used (40.NN%, out of NNNNNNNNN)
           0 bad blocks
           N large files

      NNNNNN regular files
       NNNNN directories
           0 character device files
           0 block device files
           1 fifo
        NNNN links
       NNNNN symbolic links (fast symbolic links)
           N sockets
------------
      NNNNNN files

What say the gods of fs restoration? :slight_smile:

EDIT: BTW the Dolphin File Manager won’t show the files/folders still. All it shows is a lost+found folder.

EDIT EDIT: Its locked and has a directory ‘#NN’ with folders and files that match the inodes mentioned above. What to do with them though? Hmm.

15

Well at least it seems that fsck could recover some files and folders and put it into lost+found folder. I hope it is not your root partition, otherwise you have to backup the files and reinstall everything, if no backup is available. lost+found has root permissions. To see the files, you need to be root.

16

Happy weekend to you.

Yes, sorry for the wrong terminology. I did use root permissions to investigate.

I didn’t do this on the root partition, no, just on the mapped encrypted drive. Will this now mean that my system should boot? Or is the lost+found folder only temporary while I am logged into the LiveDisk partition, and the moment that I reset, the data retrieved by fsck.ext4 will be lost. This part is unclear because I was under the impression that fsck.ext4 is not destructive, Ie. it will not write to the disk but I;m starting to think I’m wrong, on that given “read-write test” above.

The files (eg. see. ‘#NEW_BIG_NUMBER_A’ above) appear to be VERY interesting. And may tell the story as to why things went pair-shaped. I’ve had a chance to look at half of them and all that I’ve looked at have a bunch of binary, but ALSO what LOOKS LIKE i2p router settings.

One example:
SSU]caps=B;host=<DARTA_THINKS_IT_MIGHT_BE_A_LINE_FEED_CHARACTER>78.45.87.145;key=,<DARTA_WON’T_WRITE_KEYS_HERE>;port=32NNN;NTCP2uhost=<LINE_FEED_CHAR>78.45.87.145;i=< OMITTED>;port=32NNN<>;s=< OMITTED>;v=2;acaps=XXX;netId=2;netdb.kt<BINARY_TO_THE_END>

Another eg:
(…DARTA SAYS BINARY, THEN WHAT LOOKS LIKE LOTS OF I2P INFO FOR HOST 160.119.189.248 FOLLOWED BY) netdb.knownLeaseSets=86;netdb.knownRouters=4NNN;router.version=0.9.51;<BINARY_TO_THE_END>

Its all looking like the corrupted inodes have < BINARY>< I2P router info>< BINARY>

It could be possible that I reset the computer in the middle of i2p doing a write operation to eight different areas CLOSE TOGETHER (I should add) on the disk? Or something when wrong during writes. Hmm.

Anyway, as important as that might be, I’m most interested now in knowing whether I can reboot and the o/s might load now and I’ll see some new files in the lost+found folder when I do?

This is all a bit fascinating to me tbh.

17

Same to you :wink:

Well if it wasn’t the encrypted root drive, which you need to boot and is not the encrypted home partition, then you are good to go, but since the error comes from grub, I assumed that the root partition failed. The rescued files in lost+found will stay, but since I am not in front of you computer I cannot say anything about it.

18

Sorry I meant it wasn’t the “boot partition”. Not sure what is meant by root partition, sorry. Its the partition the o/s is encrypted on (sda3) and what I ‘mapped out’ to ran fsck.ext4 on.

19

Okay.

The /home folder is on this mapped, encrypted drive as well as the o/s btw, but I think I understand that lost+found is a thing that o/s can handle.

Going to try, wish me luck.

20

Failure reading sector 0x98012 from `hd0’

I’m moving up in the disk, at least, right? ::sweating::

21

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.

22

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

23

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.

D’oh.

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:

24

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?)”

26

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.

27

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.

28

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.

29

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

30

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.
https://wiki.archlinux.org/title/File_recovery

31

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