You are not logged in.
Pages: 1
Hi all,
I've just make a big mistake and I risk to lose all my data.
I have my data on a separate partition: /dev/sda10
launching gparted I have noticed that there was a 2 free Gb area just before /dev/sda10. My idea: let's take it and put in /dev/sda10.
I've asked gparted to resize my data partition but something went wrong and now I can't mount it anymore.
try to mount it:
[medeo@luienuovo ~]$ sudo mount /dev/sda10 /fedoraHome/
[sudo] password di medeo:
mount: wrong fs type, bad option, bad superblock on /dev/sda10,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.trying to fix it:
[medeo@luienuovo ~]$ sudo fsck.ext4 -v /dev/sda10
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Valore magic non corretto nel super-blocco
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Valore magic non corretto nel super-blocco nell'aprire /dev/sda10
The super-blocco could not be read or does not describe a valid ext2/ext3/ext4
file system. If the device is valid and it really contains an ext2/ext3/ext4
file system (and not swap or ufs or something else), then the super-blocco
is corrupt, and you might try running e2fsck with an alternate super-blocco:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>I've tryied to restore with every superblock backup: nothing
searching on the web I've found that maybe
mkfs.ext4 -S /dev/sda10 would work but since my error was to not backup any files before risk the resize (gpartend have alerted me) now I would like to wait to receive some helps before proceed.
mkfs.ext4 manual say:
-S Write superblock and group descriptors only. This is useful if all of the superblock and backup superblocks are corrupted, and a last-ditch recov‐
ery method is desired. It causes mke2fs to reinitialize the superblock and group descriptors, while not touching the inode table and the block and
inode bitmaps. The e2fsck program should be run immediately after this option is used, and there is no guarantee that any data will be salvageable.
It is critical to specify the correct filesystem blocksize when using this option, or there is no chance of recovery.so how I can know the correct filesystem blocksize?
tyia
Last edited by tracuboTL (2015-11-30 14:47:08)
Offline
i would suggest to create a dd-image of the partition and operate on that or even better a copy of it, whatever you do to (hopefully) prevent (further or non revertable) data loss.
Last edited by c0mm0ner (2015-11-22 20:07:49)
Offline
Offline
Did it fail quickly or after some long time?
And yes, check if testdisk can find your ext4 filesystem in the old place - maybe it hasn't been overwritten yet. (See here how to look for lost partitions). Testdisk will offer to recreate the old partition, but doing so will overwrite some 512 bytes so it may be good idea to play with it on some dd backup, if you have enough disk space to make one.
Also, testing things on a dd backup is a doubly good idea if this is your boot disk.
Last edited by mich41 (2015-11-22 20:27:18)
Offline
The big question is, what did gparted do and where exactly did it fail?
If you're looking at a partition whose data was moved half-way, you will not recover it with traditional methods (backup superblocks, testdisk, etc.).
dd image is good, but if the partition boundaries are in question, you'll have to include the region it was moving from/to as well.
For experiments you can use Overlay like described here https://raid.wiki.kernel.org/index.php/ … erlay_file This lets you write things w/o actually writing so you can undo failed experiments without having to do the copy over and over and over again ...
You can use device mapper (linear target) to produce a block device that appears "moved", and whole even if it was only moved halfway (so the linear mapping will have two segments, the already-moved segment and not-yet-moved segment, cutoff point to be determined by you).
I don't know gparted well enough, maybe it keeps metadata / progress indication of what it was doing somewhere?
Last edited by frostschutz (2015-11-22 20:28:51)
Offline
Gparted failed very soon, the 2 gb free are no more presents in my hd (so they result now as part of /dev/sda10). Partition is recognized by gparted.
here's the screenshots of gparted
Offline
I performed similar resize with gparted and it seems that it uses e2image instead of raw copying. I'm not sure what to think about that.
Anyway, it certainly won't hurt to run:
chmod 400 /dev/sda10 # just to ensure that nothing can be overwritten
testdisk /dev/sda10Once in testdisk, confirm that you want to scan sda10, choose "none - non partitioned media", choose "analyze" and see if the quick or deep search can find the original filesystem at 2GB after the start of partition. If the filesystem is found, it's possible to quickly check its contents by hitting "p".
Offline
yeah! it seem that is all there (hope still working), but how can I restore it?
Offline
Yuck, CHS. If I got my math right ((261*255 + 248)*63 + 52-1), there are 4208640 sectors on sda10 before the original ext4 starts, which is exactly 2055MB. The ext4 itself is 250142720 sectors (122140MB) long. This seems to make sense so far.
If the filestystem hasn't been corrupted, you only need to move the beginning of sda10 2055 megs to the right. But in case it is corrupted, it would be nice not to overwrite anything yet.
You can either play tricks with device mapper as frostschutz suggested, or go the lazy way and backup the whole sda10 to some external disk. Another, extremely lazy option is to backup only the first 2100MB (dd bs=1M count=2100 </dev/sda10 >some-file). At least 512 bytes within the first 2055MB certainly will be overwritten just by moving the partition, but with some care, the rest can be inspected without modifications.
Once you are sure that you aren't overwriting anything that isn't backed up, start gparted and reduce partition size to 122140MB. This should leave either 2055MB or 2054MB of empty space before the partition - I'm not sure how gparted counts 1MB of space eaten by metadata. If anything doesn't add up, don't go further and check all the math until everything matches.
Finally, cross fingers and check the filesystem with fsck:
chmod 400 /dev/sda10 # no, I don't trust fsck -n :)
fsck -n /dev/sda10Offline
I've tryied to restore files directly from testdisk. Thank you all for your helps, you all was amazing.
After I have restored the files, if you like and want to make suggestion, I can try to fix it (without risk to lose nothing). Or I'll just format it ![]()
Thanks again
Offline
Pages: 1