On 26/03/17 17:24, tu...@posteo.de wrote:
On 03/26 04:50, Bill Kenworthy wrote:
On 26/03/17 15:26, tu...@posteo.de wrote:
On 03/26 03:04, Bill Kenworthy wrote:
On 26/03/17 14:25, tu...@posteo.de wrote:
On 03/26 05:50, tu...@posteo.de wrote:
On 03/26 11:21, Adam Carter wrote:
Step 1: dd the contents into an image
ddrescue is probably a better option than plain dd.
step 2: put the sdcard to one side.
step 3: loopback mount a copy of the image (not the original)
step 4: try recovering the filesystem on the loopback, if it fails ... try
something else on another image copy
Yep, once you've got the image mounted loopback, you can run
testdisk/photorec depending on how bad it is.
Hi all,
thanks a lot for all help! :)
Currently I am ddresucueing the flashcard to the harddisc.
Next I will try to mount the sdcard.
What reliable sdcard-reader can one recommend ?
(...sorry if this sentence sounds harsh...I it by no means meant
that way...I am no native speaker... :)
Cheers
Meino
Hi,
Is the assumption correct, that -- if ddrescue could read each
partitions of the sdcard without stuttering, retries and errors --
the sdcard itsself is ok and "only" the logical structure
(fs, superblock etc) got damaged?
Or do I overlook something?
(Background: I dont want to put a sdcard into the bin, if
fdisking & reformatting that beast would gives me back an ok
media...)
Cheers
Meino
The dd gets you the best chance to work on the data before it completely
fails. In my experience the sdcard will only get worse ending with total
failure - if it hasn't already.
If the dd dump comes up rubbish and cant be recovered, the actual sdcard
will be worse. You can run "strings" against the image to see if there is
any text in there (or even cat the /dev/sdcard node through strings) to see
if the bits are still there.
I dont know of a cdparanoia type recovery utility for sdcards but I suspect
sdcard design means that approach wont work.
BillK
Hi Bill,
I got mixed results: There are three partitions on the sdcard from
which I could fully recover (even mount it directly via loop device)
the first and the third one.
The second one is screwed up.
Running fsch.ext4 against the image it starts with "bad superblock"
and suggests two alternatives.
I started fsch.ext4 again while using -b to define the alternate
superblock and it starts to ask me *zillions of question, which
I all answered with 'yes' in a first attempt (I have a backup of the
image...).
The result was an image, which I could mount again.
But beside 'lost+found' with some small rests of something which
may be files in a previous life nothing was there....
Currently it looks to me, that something has totally messed up the fs
there.
What do you think?
Cheers
Meino
Sounds like its toast :(
I have never had a lot of luck with any of the ext file systems - you have
to baby them and they corrupt very easily compared to others. I try and
avoid them ...
BillK
Hi Bill,
...the SDcard is for my Android tablet, which runs kernel 3.6.x.something
(Lollipop)
if I remember correctly. With the App Linux Deploy I installed Linux
on another partition of the sdcard and used to chroot into it.
With what filesystem did you made good experiences of, Bill? My GENTOO PC
(with which I am currently writing this email) also uses ext4...and
your last mail makes me nervous...very nervous...
For my tablet I have to use an filesystem, which is supported by and
compiled into the kernel. Unfortunately, there is no alternative
Android build for this tablet...
In this case it is ext4 and vfat...and of that both I think ext4 is
better...
Cheers
Meino
I used to prefer reiserfs ... more robust in some ways, less in others
... BUT I almost always was able to rescue files or whole filesystems
with reiserfs, not so with ext*. These days I prefer btrfs ... again
not perfect but with OS disks are single and the rest are bcache/ssd
fronted btrfs raid10's my main issue is running out of space.
Problems with the ext series were inability to deal with dirvish backup
(corrupted), running out of inodes, terminal corruption when running out
of space, silent corruption with hibernation, data loss/corruption on
abrupt power loss, and it goes on ...
Current sdcards are either vfat for win compatibility (no choice) or
btrfs (raspberry pi). Just turned off my older rpi model 1B which is
ext 4 earlier this morning - been corrupted and reimaged a few times!
File systems seem to be very much YMMV - each use, load and environment
present a different set of requirements and problems.
BillK
