Failure reading sector 0x9a2e8 from `hd0'

Hello, I’m having a similar problem (to /t/error-failure-reading-sector-0xc800-from-hd1/85832/3) now.

  1. First year of PC usage, although the PC is not strictly new, it just was under-utilized,
  2. Have two LUKS partitions, one large (and only 40% used) and one as the swap space that is 2x the RAM as is generally recommended for dual boot, though its not a dual boot machine.
  3. PC failed to wake from sleep, standby etc so I held down the power button for 5 seconds to reset,
  4. After successful decryption (ie. “Slot 0 opened” (?)) a new terminal screen I’d not seen before explained that a superblock could not be read!
  5. I did a bunch of research and on these forums iirc someone explained that they had success by loading a Live Disk, then running KDE Partition Manager and running a ‘Check’ / Repair for errors. I did that (using ‘manjaro’ as the admin password to access the Partition info).
  6. I was then able to see the contents of the drive, from the Partition Manager or File Manager (Dolphin).
  7. Tried rebooting, but after successful decryption (?) (or at least ‘Slot 0 opened’) the following appears about 9 seconds later on the next lines:
error: failure reading sector 0x9a2e8 from `hd0'.
Entering rescue mode...
grub rescue>

Is there a way to repair and read a sector so I can boot the OS again? It’s supposedly decrypted(? or being decrypted) when the error occurs. Is there a checksum type process, is there a way the I can fix this via the “grub rescue>” prompt or should I load the Live OS and try something (what megavolt suggests above) with that?

Advice would be greatly appreciated (EDIT and I’m really a perennial beginner that needs a bit of context of what things are, because by the time I come back to this topic I’ve forgotten everything I learned a year before.)

Hello @darta and welcome :wink:

Please don’t hijack a topic even if it is unsolved. Better would l be adding a link or a remark, so one knows that it is related to it. Thank you. I moved your post and created a new topic.

Forum_Rules#Thread_Hijacking

1 Like

@darta At least you can see the content of the file system, but the badblocks does not disappear magically. Badblocks are physically damaged blocks/sectors which needs to be marked as bad for the file system.

Have a look at this article: badblocks - ArchWiki

If it is a ext4 filesystem, then just run:

sudo fsck -vcck /dev/decrypted-luks-device-mapper

Of course not mounted.

It is very slow, but is will check every block, correct it and mark badblocks for skipping them.

Thanks @megavolt,

I’ve yet to use `fsck’ as you’ve described, I decided to backup some of the contents first. but it seems that something is, or has been, destructive.

I booted a LiveDisk of Manjaro XFCE that I had from 2020, and ran GParted, it had some interesting things to say about the LUKS partition after I unencrypted it. Yes, it is an ext4. One of the stats suggested only 250GB approx was written to the disk since it was starting to be used, a year or so ago. The partition is about 450GB.

  • In the file manager (Thundar) the disk had a little yellow caution triangle over it.
  • I tried to mount/open the disk but error.
  • Decided to use KDE LiveDisk instead (because that worked above),
  • I tried Dolphin, an error appeared that was a few lines long and talked about not received something back in “cleartext”.
  • I closed that error box.
  • This time KDE Partition Manager was unable to ‘Unlock’ the partition, it instantly pops up a dialog box with the title, “Could Not Unlock Encrypted File System” and body text “The encrypted file system on partition /dev/sda3 could not be unlocked.”
  • The “Check” option (that worked before) is also grayed and unable to be used.
  • I tried Dolphin again error says (newlines added by me for readability):
An error occured while accessing 'Home', the system responded: The
requested operation has failed: Error mounting /dev/dm-0 at
/run/media/manjaro/[0-9a-f]8-[0-9a-f]4-[0-9a-f]4-[0-9a-f]4-[0-9a-f]12: wrong fs type, bad
option, bad superblock on /dev/mapper/
luks[0-9a-f]8-[0-9a-f]4-[0-9a-f]4-[0-9a-f]4-[0-9a-f]12, missing
codepage or helper program, or other error

(There is no logical reason to me for the fairly new disk to start failing. As far as I can tell, its either a bug somewhere or a bug + malfeasance, IMHO.)

WIll be doing what you suggested above soon, megavolt.

If that is true, then try this method:

Of course you need to adjust it to your needs, but in general you need to test the superblocks until you reach a good one. This one will repair all other superblocks.

Sometimes there is no logical reason. It could be just a “Monday model”, or how would someone say in English: a “Lemon”. A product which was produced on Mondays or Friday afternoons, when workers are not in their routine or just thinking of weekend.

However… there are 2 reasons for your problem: The HDD or the Filesystem… If it is just the filesystem, it should be easily fixable, if the HDD has failures than it could be difficult.

Oh, this…

>>>>>>> sudo dumpe2fs /dev/sda3 | grep -i superblock
dumpe2fs: Bad magic number in superblock while
trying to open /dev/sda3

Are there any ways to deal with the bad magin number? Assuming not. :frowning:

Great phrase, “Monday Model”, what language? The effect is not very enjoyable, if this is the case.

Maybe it’s malfeasance and what my client deserves for choosing a technician who speaks up against atrocities and injustices as we see them.

SOrt of bothersome but just more time wastage and more problems to export.

Your disk is encrypted. You need to use the decrypted device, something like /dev/mapper/some-name, instead of the encrypted one :upside_down_face:

German… origin is the automobile industry. (Original: Montagsstück or Montagsgerät or Montagsmodell)

Why encryption is a bad for your healthiness.

1 Like

Sorry for the long times between replies. Juggling stuff.

From the 2020 XFCE LiveDisk

dumpe2fs 1.XX.X (XX-XXX-2020)
dumpe2fs: Input/output error while reading journal inode

Incidentally GParted did say that:

<i>dumpe2fs <AS_I_DARTA_WROTE_ABOVE>
dumpe2fs: Input/output error while reading journal inode</i>

<i>Unable to read the contents of this file system!
Because of this some operations may be unavailable.
The cause might be missing software package.
The following list of software packages is required for ext4 file
 system support: e2fsprogs vX.XXX.</i>

Not looking good.

EDIT: In GParted, in the information about /dev/sda3 there are some data points that might be helpful?

Journal backup:        inode blocks
FS Error count:        16
   (...)
First error function:  __ext4_get_inode_loc
   (... First error and last error are identical save for the error
         time which is 8h42m apart ...)
Checksum type:         crc32c

I’m going to try the 2020 KDE LiveDisk instead now.

Sad cartoon. Encryption is a nice thing and can be exciting and satisfying to do (mostly) so I recommend it.

Backup superblocks do exist:

dear @darta

  • /dev/sda3 is encrypted
  • /dev/mapper/some-name is decrypted.

No matter what you do. If you try to open an encrypted device, it will always fail.

You need to open it:

cryptsetup open /dev/sda3 some-name --key-file /etc/mykeyfile

and now you can access it at: /dev/mapper/some-name ← this must be used for the fsck and not /dev/sda3.

Thanks for putting this into sense, megavolt.

@Keruskerfuerst Ideally I would only use packages that are on the LiveDIsk, but if I might try it later, thanks.

Right so, I’ve been having fsck running for some time now.

I made a mistake and ran the command as specified on an above link, ie. with only -v and not -vcck . So unfortunately I may have done some damage because I didn’t “Ignore error” and then when it asked simply “Clear”? I said yes thinking that “Clear” was a confirmation message. Then I got:

*** journal has been deleted ***

Error reading block <NUMBER> (Input/output error). Ignore error<y>? no
Error reading block <NUMBER> (Input/output error). Ignore error<y>? no
fsck.ext4: Input/output error while reading bad blocks inode
This doesn't bode well, but we'll try to go on...
Pass 1: Checking inodes, blocks, and sizes 
Error reading block <NUMBER> (Input/output error) while opening inode scan. Ignore error<y>? yes
Force rewrite<y>? no
Error reading block <NUMBER+1> (Input/output error) while getting next inode from scan. Ignore error<y>
Recreate journal<y>? cancelled ## I pressed Ctrl+C
/dev/mapper/name_I_chose: e2fsck canceled. ## (sic?)

/dev/mapper/name_I_chose: ***** FILE SYSTEM WAS MODIFIED *****

/dev/mapper/name_I_chose: ********** WARNING: Filesystem still has errors **********

Having looked at the first reply you wrote, @megavolt, I’m now running…:

sudo fsck.ext4 -vcck /dev/mapper/name_I_chose
(...)
Error reading block <NUMBER> (Input/output error). Ignore error<y>? yes
Force rewrite<y>? no. ## Darta assumes this is destructive
Resize inode not valid. Recreate<y>? no
Checking for bad blocks (non-destructive read-write test)
  ## (... Current progress ...)
Testing with random pattern: 80.00% done, (much time) elapsed. (997/0/0 errors)

Just based on my crude occasional check-ins, it seems that most errors, if not all, were are the very start of the test (every 3 seconds I was getting an error initially, now none. Maybe helpful info??)…

More later, when ‘fsck’ is complete.

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

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:

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.

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.

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.

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.

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.

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.

Failure reading sector 0x98012 from `hd0’

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