Hi,
I'm trying to use ext4magic on a Debian 8.2 system where I accidentally deleted some files due to an rsync misconfiguration. The ext4 filesystem is normally mounted on /data and is on md array /dev/md3. I unmounted /data shortly after I realized my mistake but almost all ext4magic operations give me the same error "NR 22", for example:
# ext4magic /dev/md3 -l Filesystem in use: /dev/md3 Using internal Journal at Inode 8 Inode 2 is allocated Warning: error-NR 22 can not found file: / ext4magic : EXIT_SUCCESS
I can use ext4magic to print the superblock, journal, etc. but cannot list or recover any files. I was able to recover some of the files with extundelete but I need to get at least listing of the directories and possibly the files I deleted.
The version of ext4magic in Debian stable is 0.3.2-2.
I can provide any additional information needed to troubleshoot this error. I looked in the source code for this error message but it was impossible for me to follow.
Thanks & Regards,
Simos
Hi,
The error states ext4magic can not find the root directory. The error number indicates error when reading or interpret a block. It is unclear whether it is the inode block, or the block in which are store the directory data. Also unclear is whether this block comes from the Jornal or not. Thus, the error does not clearly identify only from this error number.
You can try: The output of all inode number 2 from the Journal.
ext4magic -T -x -I2 /dev/md3
This will display the inode data of the root directory may exist in the journal, and the corresponding directory data that are in the current directory data block. If the current directory data block defective or can not interpreted from ext4magic, then you get there no output directory. In this case, it may perhaps be helpful to locate also a copy of that block in the journal.
You need the blocknummer, output example
Dump Inode 2 from journal transaction 738482
Inode: 2 Type: directory Mode: 0755 Flags: 0x80000
Generation: 0 Version: 0x00000000:00000867
User: 0 Group: 0 Size: 4096
File ACL: 0 Directory ACL: 0
Links: 31 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 1443309086:3841393952 -- Sun Sep 27 01:11:26 2015
atime: 1443308983:3121476516 -- Sun Sep 27 01:09:43 2015
mtime: 1443309086:3841393952 -- Sun Sep 27 01:11:26 2015
crtime: 1356652343:0000000000 -- Fri Dec 28 00:52:23 2012
Size of extra inode fields: 28
Level Entries Logical Physical Length Flags
0/ 0 1/ 1 0 - 0 9265 - 9265 1
2 d 755 (2) 0 0 4096 10-Sep-2015 21:07 .
2 d 755 (2) 0 0 4096 10-Sep-2015 21:07 ..
11 d 700 (2) 0 0 16384 28-Dec-2012 00:52 lost+found
787969 d 755 (2) 0 0 12288 27-Sep-2015 01:10 etc
919297 d 755 (2) 0 0 4096 28-Dec-2012 00:52 home
......
The line
0/ 0 1/ 1 0 - 0 9265 - 9265 1
indicates the data blocks (the directory data) for this inode. In this case, only a single block Nr. 9265
You can also try to find copies of that block in the journal
ext4magic -T -B 9265 /dev/md3
If you found some old inode data for the root directory, then look to the timestamps and the transaction number.
Then you can try to list or recover with the corresponding time period ( -a ... -b ...) or with the correct Transaction Number ( -t ...) See also the man page.
Example :
ext4magic -l -I2 -t 738..... /dev/md3
Good luck
regards Robi
Hello Robi,
Thank you very much for your detailed reply. Over the last couple of weeks I've tried your suggestions in different ways but with no luck. You can see the output of the commands below (I still get "error-NR 22" when I try to list by transaction).
I would appreciate your comments if you can see anything obvious about what I'm doing wrong or I should be doing differently, otherwise I'll just give up and remount the filesystem and get on with my life! :-)
Thanks again & regards,
Simos
Last edit: Simos 2015-10-14
Hi again,
I played around with ext4magic some more last night and was able to simply use the -I flag to print the contents of the root inode (ext4magic -I 2 /dev/md3), followed the inode numbers down to the directory that I destroyed, and was able to get a list of the "top-level" sub-directories and files I deleted, which helps a lot in trying to reconstruct what was there. Thanks again for putting this tool together!
Regards,
Simos
Hi Simos,
I hope you can now recover the lost files.
But in your output of inode data I have seen something that looks like a bug.
"Level Entries Logical Physical Length Flags
0/ 0 1/ 1 0 - 15615 59466431787265 - 59466431802880 15616"
is absolute nonsense and impossible. This is a 48-bit display of a 32-bit variable.
You can help me to try to reproduce and analyze this.
I need your kernel version and your architecture. (uname -a) and the exact name of your glibc package.
(example : libc6_2.19-18+deb8u1_amd64.deb)
May also be helpful, the raw output of this inode.
ext4magic -B 1057 /dev/md3 | sed -n '/0100:/,/0200:/p'
and the file system header
ext4magic -S /dev/md3
Regards,
Robi
Hi Robi,
Here you go, hope it helps. Let me know if you need more, I haven't remounted the filesystem yet.
Regards,
Simos
Hi Simos,
the error is 100% reproducible. Also your error message. ext4magic is therefore completely useless in Debian 8.2 (amd64). Which other versions, architecture and distributions are also affected is unknown.
currently I can not find anywhere an open bug report for this topic. Unbelievable that no one has this yet noticed.
Thank you once for error report. I will analyze that and hope as soon as possible to find a solution.
robi
There are first results. The broken function is local_ext2fs_extent_open()
http://ext4magic.sourceforge.net/doxygen/html/block_8c.html#aee0120482de94976df097aa02f7686c4
More detailed investigations and a final solution will take a longer time to complete.
The exact causes, the affected distributions and versions are unknown.
In the meantime, it's downloadable a workaround.patch which replaced the broken function by the corresponding function of new libext2fs versions.
http://sourceforge.net/projects/ext4magic/files/Patches/workaround.patch/download
Robi