[solved]Howto recover rw-locked pendrive's data?

Getting your soundcard to work, using Debian on non-i386 hardware, etc

Re: Howto repair a particular pendrive to again read its dat

Postby bkpsusmitaa » 2017-10-14 09:43

To p.H.,
I have read about Ext4 but that is only academic knowledge. If I could look at one Logical Block what I am I likely to encounter? Not the academic symbolism or theoretical/pictorial concept-building drawing, but hard-core values, in digits! And for two contiguous LBs?

I looked at the outputs from the two applications, (1) gparted, (2) dmesg and (3) e2fsck. I quote them below. One says that the block is ext4 while the other, ext2.
Code: Select all
Libparted 2.3
Check and repair file system (ext4) on /dev/sdc2  00:00:00    ( ERROR )


Code: Select all
[ 2650.406111] EXT4-fs (sdc2): INFO: recovery required on readonly filesystem


Code: Select all
e2fsck: Bad magic number in super-block while trying to open /dev/sdc

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
Last edited by bkpsusmitaa on 2017-10-14 10:02, edited 1 time in total.
Freedom is impossible to conceive.
bkpsusmitaa
 
Posts: 333
Joined: 2009-07-04 06:32
Location: Home: Barrackpore and Mysore

Re: Howto repair a particular pendrive to again read its dat

Postby p.H » 2017-10-14 09:55

bkpsusmitaa wrote:e2fsck: Bad magic number in super-block while trying to open /dev/sdc

You did not run fsck on the right device. The filesystem is in the partition /dev/sdc1, not the whole drive /dev/sdc.
p.H
 
Posts: 161
Joined: 2017-09-17 07:12

Re: Howto repair a particular pendrive to again read its dat

Postby bkpsusmitaa » 2017-10-14 10:04

I had, but forgot to post.
Code: Select all
sudo e2fsck -f -n -v /dev/sdc1

Code: Select all
e2fsck 1.42.5 (29-Jul-2012)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdc1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
Freedom is impossible to conceive.
bkpsusmitaa
 
Posts: 333
Joined: 2009-07-04 06:32
Location: Home: Barrackpore and Mysore

Re: Howto repair a particular pendrive to again read its dat

Postby p.H » 2017-10-14 10:19

My mistake, the ext4 filesystem is in the second partition /dev/sdc2.
According to your previous messages, the first partition contains a FAT filesystem.
p.H
 
Posts: 161
Joined: 2017-09-17 07:12

Re: Howto repair a particular pendrive to again read its dat

Postby pylkko » 2017-10-14 10:36

bkpsusmitaa wrote:Pyikko, please don't enter into an academic argument in my thread.

If you desire for an academic argument, you are free to create your own thread and free to invite p.H. to your thread.

This is my thread, and I have decided that I am going to ask p.H. my questions stepwise, because he is near my wavelength.

Piykko, you have said:
Code: Select all
... ... But several posts ago you were told that the kernel log is indicating the the disk is read only and that therefore this is very likely not a mounting problem... but a hardware/firmware problem.  ... ...

But you only said so. We are science-believing rationalists. We like to be pointed to the evidence.

Mr. p.H. pointed to the exact code. He is the teacher for me, he is a teacher, believes in and practices transparency, prima facie. You are apparently not! You didn't practice transparency in your interactions. Why, I don't know, and don't need to know! It is your perspective and your angle, and I respect them. You are welcome to follow your value system.

I thank you, RUSSEL and Debiman for interacting this long with me and compelling me to multiply raise and waive the red-herrings to attract the right kind of people,


I don't know what you mean by academic discussion and that you have p.h as your teacher. But I do understand that you do not want me to write more in this thread. But when you blame me for not being 'transparent', I would like to say that in my opinion that is just factually and morally wrong. You have an attitude problem. The fact that you refer to there is deductible from many other factors in addition to the one line of output and if you suggest that I deliberately obfuscated where exactly it is stated is just mean especially taking into consideration that I was trying to, well, help you for nothing in return. You need to grow up.
User avatar
pylkko
 
Posts: 1180
Joined: 2014-11-06 19:02

Re: Howto repair a particular pendrive to again read its dat

Postby bkpsusmitaa » 2017-10-14 11:45

Pyikko,
But when you blame me for not being 'transparent'
I did not blame you, I simply said, with evidence, that you were not transparent.

You have an attitude problem.
I won't deny when you say that, when I caused you hurt. I feel the same. But some things need to be said as clearly as possible.

You need to grow up.
We keep growing our entire lives! So I can't grow up! :-)

Thank you for understanding! Hope that on hindsight, i.e., when you look back, this interaction gives you ample windows of opportunities to mend your ways. Now I need to stop engaging with you and be with Mr. p.H. and learn from him.
Freedom is impossible to conceive.
bkpsusmitaa
 
Posts: 333
Joined: 2009-07-04 06:32
Location: Home: Barrackpore and Mysore

Re: Howto repair a particular pendrive to again read its dat

Postby bkpsusmitaa » 2017-10-14 11:55

p.H., if you look at this post, you would see that I had posted the outputs for
Code: Select all
e2fsck -f -n -v /dev/sdc2
.
The output included these comments:
Code: Select all
e2fsck 1.42.5 (29-Jul-2012)
Warning: skipping journal recovery because doing a read-only filesystem check.


While:
Code: Select all
sudo e2fsck -f -n -v /dev/sdc1

outputs:
Code: Select all
e2fsck 1.42.5 (29-Jul-2012)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdc1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

I apologise for an erroneous comment earlier. The filesystem sdc1 is read-only, not read-write. I had erroneously stated that I could read-write.

I can very well understand that it is easy to lose perspective, amidst all these cacophony going around us. Would you like me to coalesce all the posts and repost in one, so that both you and I are clear as to which next step do we need to take next?

Code: Select all
sudo e2fsck -f -n -v /dev/sdc2

Code: Select all
e2fsck 1.42.5 (29-Jul-2012)
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

       29666 inodes used (9.22%, out of 321920)
          88 non-contiguous files (0.3%)
          12 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 29601/51
      731236 blocks used (56.83%, out of 1286656)
           0 bad blocks
           1 large file

       27577 regular files
        2074 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           6 symbolic links (6 fast symbolic links)
           0 sockets
------------
       29657 files


I finally remember: I had also kept a snapshot for uploading but Debian Forum has picture quota exceeded. So I could not upload, and then forgot altogether to post a link of, the snapshot to my Google Drive. I have now! Apologise again!
Last edited by bkpsusmitaa on 2017-10-14 12:34, edited 3 times in total.
Freedom is impossible to conceive.
bkpsusmitaa
 
Posts: 333
Joined: 2009-07-04 06:32
Location: Home: Barrackpore and Mysore

Re: Howto repair a particular pendrive to again read its dat

Postby debiman » 2017-10-14 12:19

did you look at this person's blog?
clearly they're on a mission, one that involves A LOT of preaching.
i don't think we can stop them (to get them to listen).
well, maybe someone can stop them from posting...
User avatar
debiman
 
Posts: 1545
Joined: 2013-03-12 07:18

Re: Howto repair a particular pendrive to again read its dat

Postby bkpsusmitaa » 2017-10-14 12:49

p.H.I am not aware of any command line version similar to gparted. If there is please let me know, if you are comfortable with the command line outputs. Posted the e2fsck for either of the partitions, and the gparted link image in the earlier post.
Last edited by bkpsusmitaa on 2017-10-15 00:11, edited 1 time in total.
Freedom is impossible to conceive.
bkpsusmitaa
 
Posts: 333
Joined: 2009-07-04 06:32
Location: Home: Barrackpore and Mysore

Re: Howto repair a particular pendrive to again read its dat

Postby Head_on_a_Stick » 2017-10-14 13:34

bkpsusmitaa wrote:I am not aware of any command line version similar to gparted. If there is please let me know

https://packages.debian.org/stretch/parted

@OP, your posts are too prolix.
"Only the mediocre are always at their best." — Jean Giraudoux
User avatar
Head_on_a_Stick
 
Posts: 6680
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: Howto repair a particular pendrive to again read its dat

Postby p.H » 2017-10-15 06:41

bkpsusmitaa wrote:p.H.I am not aware of any command line version similar to gparted.

Why do you need it ?
AFAIK there is nothing wrong with the partition table on the USB stick.

bkpsusmitaa wrote:Would you like me to coalesce all the posts and repost in one, so that both you and I are clear as to which next step do we need to take next?

No. I already know everything I need to know and posted the next steps a long time ago.

Create a copy of partition 2 :

Code: Select all
dd if=/dev/sdc2 of=partition2.img bs=4k


ddrescue is not needed if the pendrive can be read without error.

/dev/sdc2 contains an ext4 filesystem, so the image file contains an ext4 filesystem too. It can be mounted like a regular partition with the mount command (the "-o loop" option is not required any more) or checked with e2fsck.

Code: Select all
mount partition2.img /mnt

If you prefer, or if mount fails, run e2fsck first.
Code: Select all
e2fsck partition2.img
p.H
 
Posts: 161
Joined: 2017-09-17 07:12

Re: Howto repair a particular pendrive to again read its dat

Postby bkpsusmitaa » 2017-10-15 07:59

p.H., I do remember and acknowledge that you had posted the first solution earlier. Thank you for the complete code-lines for the recovery process.
Code: Select all
dd if=/dev/sdc2 of=partition2.img bs=4k
Outputs:
Code: Select all
1286656+0 records in
1286656+0 records out
5270142976 bytes (5.3 GB) copied, 255.102 s, 20.7 MB/s


Code: Select all
e2fsck partition2.img
Outputs:
Code: Select all
e2fsck 1.42.5 (29-Jul-2012)
partition2.img: clean, 29666/321920 files, 731236/1286656 blocks


Code: Select all
mount partition2.img /mnt
mounts normally in the /mnt directory. I've checked the files. They can be read.

Code: Select all
dd if=/dev/sdc1 of=partition1.img bs=4k
Outputs:
Code: Select all
2621692+0 records in
2621692+0 records out
10738450432 bytes (11 GB) copied, 538.849 s, 19.9 MB/s


The
Code: Select all
e2fsck partition1.img
won't work, as the partition is a fat32 partition, I remembered late :(

Code: Select all
fsck.vfat partition1.img
Outputs:
Code: Select all
dosfsck 3.0.13, 30 Jun 2012, FAT32, LFN
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
  65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
? 3
Reclaimed 39 unused clusters (638976 bytes).
Free cluster summary wrong (133999 vs. really 134038)
1) Correct
2) Don't correct
? 3
Invalid input.
? ^C

I wasn't confident, so I did not damage the filesystem.

Strange, isn't it? The ext4 partition is alright, but unreadable. The fat32 partition has damaged data, but is unreadable!

Since the partition1 has a bad superblock how to recover the maximum possible data from the fat32 partition?

I attempted but changed nothing to the original partition1 in the pendrive:
Code: Select all
fsck.vfat /dev/sdc1

Code: Select all
dosfsck 3.0.13, 30 Jun 2012, FAT32, LFN
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
  65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
? 3
Reclaimed 39 unused clusters (638976 bytes).
Free cluster summary wrong (133999 vs. really 134038)
1) Correct
2) Don't correct
? 2
Leaving file system unchanged.
/dev/sdc1: 1839 files, 521063/655101 clusters

Please advise on the above step. Will this serve any purpose to recover the data that was there in the pendrive?

I read this post: [SOLVED] No Boot, corrupt drive, any help welcome
I found specific clues:
Code: Select all
dumpe2fs /dev/sdb1| grep -i superblock
(I don't know about this, so I left this alone)
and
Code: Select all
blkid


Code: Select all
blkid /dev/sdc1

Code: Select all
/dev/sdc1: LABEL="STRONTIUM" UUID="201B-E085" TYPE="vfat"

Code: Select all
 blkid /dev/sdc2

Code: Select all
/dev/sdc2: UUID="be2a228a-cb20-4e31-8792-316835decbe4" TYPE="ext4"

So there is nothing unknown here!

I searched Google with the string, "e2fsck -b 8193". Finding nothing very informative immediately.

I tried with
Code: Select all
man e2fsck | grep -e "8193"
and found this:

Found this:
-b superblock
Instead of using the normal superblock, use an alternative
superblock specified by superblock. This option is normally
used when the primary superblock has been corrupted. The loca‐
tion of the backup superblock is dependent on the filesystem's
blocksize. For filesystems with 1k blocksizes, a backup
superblock can be found at block 8193; for filesystems with 2k
blocksizes, at block 16384; and for 4k blocksizes, at block
32768.


Guess this code
Code: Select all
e2fsck -b 8193 /dev/sdc1
won't work, as the partition in question is a vFAT partition!

But I am beyond my circle of awareness here. I will have to read the related materials.

Thank you, once again! FOSS still breathes for self-assured and confident people like you!
Last edited by bkpsusmitaa on 2017-10-15 09:22, edited 1 time in total.
Freedom is impossible to conceive.
bkpsusmitaa
 
Posts: 333
Joined: 2009-07-04 06:32
Location: Home: Barrackpore and Mysore

Re: Howto repair a particular pendrive to again read its dat

Postby p.H » 2017-10-15 09:18

Partition 1 (and its image) contains a FAT filesystem. e2fsck and dumpe2fs handle only ext2/3/4 filesystems, not FAT. Each filesystem type has its own set of tools. For FAT you need dosfsck (aka fsck.vfat, fsck.msdos) from package dosfstools.

But if you can mount (even read-only) partition 1 and read its contents without error, why did you create an image and why do you want to fsck it ? As detected by dosfsck, it has only minor inconsistencies which do not prevent reading it.
p.H
 
Posts: 161
Joined: 2017-09-17 07:12

Re: Howto repair a particular pendrive to again read its dat

Postby bkpsusmitaa » 2017-10-15 09:27

p.H wrote:[Each filesystem type has its own set of tools. For FAT you need dosfsck (aka fsck.vfat, fsck.msdos) from package dosfstools.

I apologise! I was editing the post when you posted.
p.H wrote:But if you can mount (even read-only) partition 1 and read its contents without error, why did you create an image and why do you want to fsck it ?

For safety! Please look at the fsck.vfat report posted earlier, especially, this part:
Code: Select all
Reclaimed 39 unused clusters (638976 bytes).
Free cluster summary wrong (133999 vs. really 134038)
1) Correct
2) Don't correct
? 2
Freedom is impossible to conceive.
bkpsusmitaa
 
Posts: 333
Joined: 2009-07-04 06:32
Location: Home: Barrackpore and Mysore

Re: Howto repair a particular pendrive to again read its dat

Postby p.H » 2017-10-15 09:44

As I wrote in my previous post, these are just minor metadata inconsistencies. You can fix them if you like. It should not affect the files. Anyway you can back up the contents before.
p.H
 
Posts: 161
Joined: 2017-09-17 07:12

PreviousNext

Return to Hardware

Who is online

Users browsing this forum: No registered users and 4 guests

fashionable