Reply To: How to spot (possibly) damaged files in the antiX OS on a device?

[RobinMember]

OK, I’ve proceeded one step. Hopefully somebody can confirm I didn’t something wrong in my calculations:

Plugged in the old stick. Collected some data first:

   $ sudo tune2fs -l /dev/sdc1 | grep Block
   Block count:              15346688
   Block size:               4096
   Blocks per group:         32768

   $ sudo fdisk -l /dev/sdc
   Disk /dev/sdc: 58,59 GiB, 62914560000 bytes, 122880000 sectors
   Disk model: Flash Disk      
   Units: sectors of 1 * 512 = 512 bytes
   Sector size (logical/physical): 512 bytes / 512 bytes
   I/O size (minimum/optimal): 512 bytes / 512 bytes
   Disklabel type: gpt
   Disk identifier: <filter>

   Device         Start       End   Sectors  Size Type
   /dev/sdc1       2048 122775551 122773504 58,5G Linux filesystem
   /dev/sdc2  122775552 122875903    100352   49M EFI System

The significant lines in the above output are:

   Block size:               4096
   Sector size (logical/physical): 512 bytes / 512 bytes

So Sector size is 512 bytes, and Block size is 4096

Now I can calculate the Block number from the Sector number found in dmesg:

Block Number = Sector Number * (Sector Size / Block Size)

For the reported errors it would be:

Block number = 45074464 * (512 / 4096) = 45074464 / 8 = 5634308
Block number = 73407696 / 8 = 9175962
Block number = 73412304 / 8 = 9176538
Block number = 73416912 / 8 = 9177114
Block number = 73419472 / 8 = 9177434
Block number = 73426384 / 8 = 9178298
Block Number = 100949520 * (512 / 4096) = 100949520 / 8 = 12618690

With this now I can feed dbugfs. The trick is, first to enter

testb blocknumber

and if this doesn’t report the block as “not in use”, then enter with the same blocknumber

icheck blocknumber

wich will return an Inode number. That number I have to enter now as argument for the ncheck command to get finally the filename:

ncheck inodenumber

Countinue with the next Block number from the listing, again and again repeating the sequence of testb, icheck and ncheck.

(in the below I have got multiple times the same inode number, so omitted the ncheck for consecutive ocurrences. It points always to the same file)

$ sudo debugfs
debugfs 1.47.0 (5-Feb-2023)
debugfs:  open /dev/sdc1
debugfs:  testb 5634308
Block 5634308 marked in use
debugfs:  icheck 5634308
Block	Inode number
5634308	131076
debugfs:  ncheck 131076
Inode	Pathname
131076	/antiX/initrd.gz
debugfs:  testb 9175962
Block 9175962 marked in use
debugfs:  icheck 9175962
Block	Inode number
9175962	131086
debugfs:  ncheck 131086
Inode	Pathname
131086	/antiX/linuxfs
debugfs:  testb 9176538
Block 9176538 marked in use
debugfs:  icheck 9176538
Block	Inode number
9176538	131086
debugfs:  testb 9177114
Block 9177114 marked in use
debugfs:  icheck 9177114
Block	Inode number
9177114	131086
debugfs:  testb 9177434
Block 9177434 marked in use
debugfs:  icheck 9177434
Block	Inode number
9177434	131086
debugfs:  testb 9178298
Block 9178298 marked in use
debugfs:  icheck 9178298
Block	Inode number
9178298	131086
debugfs:  testb 12618690
Block 12618690 not in use
debugfs:  quit

So this readout tells me, that two files are involved (not really a surprise, this was what was accessed while copying the system) :

/antiX/initrd.gz
/antiX/linuxfs

On a default installed system a result like that would point directly to the damaged files belonging to the OS, so this would be enough already to identify packages, config files or other data involved. It would have been easy to cure in the copy. Not with these two files of the Live system.

First question is: Did I everything right with my calculation and analytics? Any wrong assumptions?
Second question is: Is this result good for anything at all? I mean, these files are file systems themselves again. How to tell, which files are actually damaged inside, if any? Are there self-repair mechanisms (journal?) integrated into ext4 or the compression algorithms, strong enough to restore corrupted data inside these containers? I don’t see how antiX could boot otherwise still perfectly fine from the new stick (and from the old damaged one as well)…

Windows is like a submarine. Open a window and serious problems will start.