Tiny Core Linux
Off-Topic => Off-Topic - Tiny Tux's Corner => Topic started by: Misalf on September 03, 2013, 02:31:59 PM
-
I'm upset because I fear to loose all my settings, scripts, modifications I did to TinyCore and GRUB2.
I always boot TC from my USB flash drive (much quicker than my HDD) and didn't have made backups to an alternate storage device (bummer).
Yesterday USB boot failed 2 or 3 times - but was working again without a glitch after powering off my PC. It boots natively from USB via BIOS.
Now, the OSes I have installed on HDD do not recognize any filesystem on it.
GParted shows the hole drive as 'unallocated' space - and is unable to repair the partition table (Attempt Data Rescue...).
fdisk also can't see a valid partition table and shows only 'unallocated' space (option v).
Please, does anyone have an idea hot to recover the data? I really do not want to format.
I am (was) using an USB flash drive (Kingston DataTraveler G3 - 4GB) to boot several Linuxes via GRUB2 (v2.00).
Partitions:
3BG FAT32
(data + .ISOs)
~700MB EXT2
(BOOT + GRUB2 + TinyCore)
I recently added making use of the env_var feature to grub.cfg (for booting lastly selected OS).
At the very last succsessful boot, I saw a message after loading TinyCore's initrd (my grub.cfg echo'es that) about an bad env_var entry or something similar (I also played with unicode characters in menu titles).
Though, everything booted and worked fine - until reboot (without saving the session).
Thanks in advance.
-
You can try re-creating the fdisk partitions to be exactly like they were before.
Then try accessing the filesytsems.
The problem with flash drives is that when they die, they are generally completely unrecoverable.
-
So I have to know/guess the correct partitioning.. Is there any tool that can lead me a hand there?
The problem is I moved and merged partitions when I ran out of space.
The result was that xfe in TinyCore always showed me this:
/mnt/sdb (not mountable/usable)
/mnt/sdb1 (ext2)
/mnt/sdb3 (fat32)
So I have no idea where the first partition (the important one for me) would start.
-
You might try the testdisk app.
-
Try to dd the whole drive to a file on a regular hard drive, then attach it to a loop device. Then try data recovery from there. But then a boot drive shouldn't have much data in the first place. That's why you're keeping the drives separate, right?
-
Thanks gerald_clark
I have installed testdisk and it is indeed able to at least find something. So I know now that my USB drive is not entirely fried. I think only the partitioning got messed up for some reason. Maybe I shouln't let grub write to my drives in the future (or I should use a propper partitioning for that matter)?
Thanks andyj for your suggestion
Unfortunately I do not have enough space left on my HDD to dd my USB drive there.
I have initially partitioned it that way to be able to still use it under windows (which didn't work btw since windows only wants to read the first partition..)
So, now the situation is as follows (not copy/pasted):
TestDisk -> Analyse
Disk /dev/sdb - 4003 MB / 3817 MiB - CHS 1017 124 62
Current partition structure:
~~ nothing listed ~~
Partition sector doesn't have the endmark 0xAA55
>[Quick Search]
Warning: the current number of heads per cylinder is 124
but the correct value may be 255.
[Continue]
~~ "FAT16" (sdb; not sdb3) ~~
~~ "Linux" (sdb1) ~~
>[Deeper Search]
~~ "FAT16" (sdb; 343 MB oh so big? - seems to contain only unreadable garbage but thats not new) ~~
~~ "Linux" (sdb1; 781MB hmm might be correct - a little bit gabage - nothing else) ~~
~~ "Linux" (sdb1; 781MB - no file found) ~~
~~ "FAT32" (sdb3; 3220MB - I can browse files) ~~
The ext2 partition (sdb1) is not accessible. testdisk sees it as two paritions which are overlapping each other. I tryed changing heads from 124 to 255 via options but same result.
-
Does anyone know some magic CHS values I could try to use or what values might possibly be the correct ones?
-
Hi Misalf
I don't think you should be changing the CHS values.
Warning: the current number of heads per cylinder is 124
but the correct value may be 255.
255 may be a common setting for the number of heads but it's not a requirement. If you change it to 255 you are telling
it your drive is a little over 8Gbytes in size.
-
Oh, thanks for that info.
Is my data lost if TestDisk can't recreate the partition or at least copy files?
-
Hi Misalf
Is my data lost if TestDisk can't recreate the partition or at least copy files?
I don't know. What does the command:
fdisk -lreport for the drive? Use your left mouse button to highlight the results in the terminal. This copies the text into the paste
buffer. Then use the center mouse button to paste into the browser.
-
fdisk and gparted were not able to see anything on that drive (unallocated space).
I was able to recreate my FAT32 (second) partition using TestDisk so this one is now listed in fdisk as sdb1 (originally sdb3).
My linux machine is another PC where I do not have configured a dialup network so I can't copy/paste right now but I could do so later. Any useful info I could post from fdisk output apart from partitioning layout?
-
Hi Misalf
fdisk and gparted were not able to see anything on that drive (unallocated space).
Then it sounds like the partition table is messed up. You might want to ask Google for information on how to attempt
to fix it, though I don't think it will be easy.
-
Test disk is the only of tool I know which can rewrite the partition structure whilst leaving the contents intact.
It has saved my bacon many a time.
Sent from my iPad using Tapatalk HD
-
Hi Misalf
This tutorial may be of some help:
http://www.dedoimedo.com/computers/linux-data-recovery.html
-
Rich, that's a good tutorial and honest too. I mean, test disk is a great tool but it is only magic when given something it can handle. Sometimes we are doomed before we attempt any recovery.
They have good info at the developers web site also.
definitely agree not wise to be changing geometry values.
Sent from my iPad using Tapatalk HD
-
not that I am an expert but me thinks one might clone the usb stick onto another usb stick
and then attempt recovery from usb number 2
2) There are number of threads on usb sticks and whether or not to format it as journalised or NOT journalised
my personal view is to journalise as I accept usb sticks are cheap to buy.
----when they reach their write limit number....ditch it but
3) for my internal drive, which is journalised as ext4.....I use fsarchiver to "IMAGE" the partition
partimage can not handle (currently) ext4 but can handle ext3
but
fsarchiver is super fast....much faster than partimage....in both writing and restoring images.
so to the OP, if recovery fails I suggest you record the tool you use to format and partition (eg gparted)
the actual number you input.....whether they change to cylinder boundaries or not
------so you can always reproduce your table
b) make a backup of your MBR assuming you are don't have to use GPT
I will always use PRIMARY and never use LVM or extended partitions so
sudo dd if=/dev/sdx of=/pathway/mbr-backup bs=512 count=1
will be a backup, if you have more than one drive or usb stick to backup, rename mbr-backup to something more specific
change sdx to sda or sdb etc
c) once you have some data on your usb stick
use a second usb stick or internal drive to "image" the partition and then burn that image to a dvdrw
or send to cloud storage such as dropbox with its MBR
good luck
Of course specific files can be sent to cloud storage if not sensitive
NSA may have broken encryption so don't worry about it
http://www.itnews.com.au/News/355942,nsa-can-break-some-encryption-new-snowden-leak.aspx
-
Thanks for the link to the tutorial.
I'm afraid I won't be able to recreate the partition table..
My situation seems to resemble the "sad example".
Though, I learned about PhotoRec (actually was included in the TestDisk package I have installed) which is able to recover any files (including deleted ones) without the drive need to have a valid partition.
Most of my files seem to be corrupted but PhotoRec was not yet able to copy everything because my HDD ran out of space. I will try to copy to a network shared drive where I have more free space.
Since TestDisk found my bad TinyCore partition as two overlapping partitions, could it be a bad idea to manually create a partition using TestDisk based on the start/end values it shows me?
Meaning, start sector from first overlapping partition and end sector from second overlapping partition.
thanks gordonselfish
I will backup my files in some way next time.
-
Test disk is the only of tool I know which can rewrite the partition structure whilst leaving the contents intact.
fdisk. that said, I've only used testdisk to find info to type into fdisk. Also used Ranish Partition Manager (before finding testdisk) as it can test some parameters.
Anyways, my hard rule of data recovery (unless it's trivial) is treat the "damaged" media as read-only (which implies never using Windows) and try to read it only once. My first action is always ddrescue (GNU ddrescue, that is) to a raw file (typically as `ddrescue -nc 2048 /dev/sda1 sda1.i sda1.log` with a second run as `ddrescue -c 2048 /dev/sda1 sda1.i sda1.log` if any blocks need to be split down to smaller failures). In your situation, I'd want 2-3 times the capacity of the source drive to recover since I'd keep the first raw copy, then make another copy of the raw that'd be manipulated to attempt recovery.
-
At this point in the event, I'd say that recovery is very unlikely due to overwriting of any previous good backup structure
Having said that all may not be lost, at least not until you've tried the following
Best to use a spare drive to practice the recovery techniques with. Deliberately corrupt partition tables, boot records, make partitions unreadable attempting to simulate the current conditions of your drive, then practice their recovery. when comfortable attempt these techniques on the real drive
Use this guide http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step
Looking at the notes above id say there was never any overlapping structures, only found partition structures and backups of same partition structures.
the reported geometry error is only because the software was not able to determine between what is expected and geometry being reported.
For geometry changes use this as a guide
http://www.cgsecurity.org/wiki/Data_Recovery_Examples
If ext2 is your file system then try recovery of the superblock
http://www.cgsecurity.org/wiki/Advanced_Find_ext2_ext3_Backup_SuperBlock
Best to backup what data you can, then
Be sure to see all your expected partitions before committing the new structure
-
Thanks everyone who tryed to help.
Thanks a lot for those links, coreplayer2.
But I think I'm doomed.
I dd'ed my flash drive as a file on a network connected drive, made another copy and tryed to mess with this for hours (replaced the copy after fail attempts). No luck.
So I let PhotoRec try to copy all the files it could find. This time with enough space on the target.
Most files it has recognized as archives are corrupted but lots of .png and .txt files where found which are actually the files I was after (exept for mydata.gz). Well, some config files and scripts have an .java extension so I might have to check every file in a text editor (even corrupted .pngs etc.) which will be an enormous task.
I'll keep my flash drive's dd copy on that hard drive just in case I want to try to improve my recovery skills some time later. (:
-
When the USB died and files got lost, please stop saving more files on it.
Then you can try to use Recuva or PhotoRec for recovering your lost files. The 2 are freeware that has windows version.
You can also try to recover deleted files on windows (http://www.kvisoft.com/data-recovery/) with the tool I shared. I'm using it.