TestDisk: Flash Drive="CHS and LBA don't match" [SOLVED]

Using applications, configuring, problems
Message
Author
User avatar
Semme
Posts: 8399
Joined: Sun 07 Aug 2011, 20:07
Location: World_Hub

#61 Post by Semme »

Are you saying it wasn't pulled between the write and the fdisk remount? My thoughts are still here.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#62 Post by npierce »

Sylvander wrote:I read that as a FAILURE to delete. :(
Am I correct?
You are correct. The partition table isn't getting written.

And it looks like the formatting isn't getting written. Neither of the sectors examined with the dd command have the correct data for a boot sector. And although I've not tried reformatting my own flash drive, I would expect the LED to blink when doing so.

It seems like this drive doesn't want to be written to anymore.

Let's see what information is found when the flash drive is inserted. Pull out drive, then plug it in again and try this command:

Code: Select all

dmesg | tail -30 | grep -A 30 usb

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#63 Post by Sylvander »

Semme:
1. "Are you saying it wasn't pulled between the write and the fdisk remount?"
Correct/yes.
I thought I was being told it wasn't necessary to do this.
I'll be doing it for the following.

npierce:
2. "Pull out drive, then plug it in again and try this command:"
Did so, and then...
The command gave this result:

Code: Select all

# dmesg | tail -30 | grep -A 30 usb
[ 1179.925574] usb 1-1.1: USB disconnect, device number 3
[ 1185.481062] usb 1-1.1: new high-speed USB device number 4 using ehci_hcd
[ 1185.567446] usb 1-1.1: New USB device found, idVendor=0a16, idProduct=2004
[ 1185.567450] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1185.567453] usb 1-1.1: Product: Store 'n' Go
[ 1185.567455] usb 1-1.1: Manufacturer: Verbatim
[ 1185.567457] usb 1-1.1: SerialNumber: de656f60c080aa
[ 1185.567752] scsi5 : usb-storage 1-1.1:1.0
[ 1186.570999] scsi 5:0:0:0: Direct-Access     Verbatim Store 'n' Go     1.00 PQ: 0 ANSI: 2
[ 1186.572241] sd 5:0:0:0: [sdb] 1974271 512-byte logical blocks: (1.01 GB/963 MiB)
[ 1186.573220] sd 5:0:0:0: [sdb] Write Protect is off
[ 1186.573225] sd 5:0:0:0: [sdb] Mode Sense: 00 00 00 00
[ 1186.574202] sd 5:0:0:0: [sdb] Asking for cache data failed
[ 1186.574205] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[ 1186.579315] sd 5:0:0:0: [sdb] Asking for cache data failed
[ 1186.579319] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[ 1186.689749]  sdb: sdb1
[ 1186.693315] sd 5:0:0:0: [sdb] Asking for cache data failed
[ 1186.693318] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[ 1186.693321] sd 5:0:0:0: [sdb] Attached SCSI removable disk
# 

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#64 Post by npierce »

My apologies!

I gave you the wrong dd commands for reading the boot sector of the partition.

I said to use /dev/sdb1 because we want to read the partition. But I gave you the offset from the start of the drive, not the partition. Normally we would use /dev/sdb1 with skip=0 (or no skip parameter) but since your partition table has problems, I wasn't sure if /dev/sdb1 would point to the proper sector, so I gave the offset from the start of the drive. So I should have told you to use "if=/dev/sdb".

Sorry about that.

So the correct commands are:

Code: Select all

dd if=/dev/sdb bs=256 skip=4096 count=1 2>/dev/null | hexdump -C
dd if=/dev/sdb bs=256 skip=640 count=1 2>/dev/null | hexdump -C
The first command should return the same as:

Code: Select all

dd if=/dev/sdb1 bs=256 skip=0 count=1 2>/dev/null | hexdump -C
If either sector was formatted as the boot sector by mkdosfs, you should see "mkdosfs" in the first line of output.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#65 Post by npierce »

If using the corrected commands in my previous post show no evidence of any formatting, it is likely that the drive is no longer writable.

You could try one final test to see if you can write to the partition with dd.

Since you will write to /dev/sdb1, you again want to be very sure that /dev/sdb1 is still your flash drive.

Code: Select all

fdisk -l /dev/sdb
If you still get the familiar "Disk /dev/sdb: 1010 MB, 1010826752 bytes . . .", enter this command line:

Code: Select all

dd if=/dev/sdb1 bs=1 skip=3 count=4  2>/dev/null | hexdump -C
That reads four bytes from the boot sector of the partition, beginning with the fourth byte of the sector.

Next you will try to write to those four bytes:

Code: Select all

echo -n test | dd of=/dev/sdb1 bs=1 seek=3 count=4
(In the above, /dev/sdb1 is the output file, so you used of= and seek= instead of if= and skip=.)

Next you read them again:

Code: Select all

dd if=/dev/sdb1 bs=1 skip=3 count=4  2>/dev/null | hexdump -C
If you see "74 65 73 74" and "test" then the write succeeded. If you see the same thing that you saw when you first read it, the write failed.

If the partition is not writable, then I fear that I am out of suggestions.

Most likely your flash drive has simply died.

You could try some of the following, but you probably have already tried most or all of them:

1. Look for damaged contacts in the drive.
2. Look for damaged contacts in the USB port.
3. Try a known-good flash drive in the same USB port. Use a drive that doesn't contain anything that you can't afford to lose, in the unlikely event that the port damages the drive.

(I wouldn't suggest trying the questionable Verbatim drive in another USB port until you have tested the port it was using with a known-good drive to be sure that that port works, and wasn't somehow damaged by the Verbatim drive -- it is unlikely that happened, but anything's possible.)

4. You could try reformatting the drive as ext3 again. That would probably be a waste of time, since if the above test with dd can't write to the partition, it is very unlikely that mkfs.ext3 would be able to. But since you had ext3 working before, this would make it clear that the problem is not specific to mkdosfs.


The information that Semme found about "V-Safe" is interesting. Even if the drive came with no application to use V-Safe, or you removed it without ever running it, the drive still might be designed in a way to support V-Safe. The flash drives that I've seen usually have their first partition at sector 63. The fact that yours starts at sector 2048 indicates that you have a lot of mystery sectors at the start of your drive, which could be there to support V-Safe. But that may not relate to your problem.

The fact that your partition table was not writable, made me think that your drive might have been designed to prevent the partition table being overwritten, in order to support V-Safe. But a search of the Internet indicates that others have been able to repartition their Store 'n' Go drives (although it is possible that they didn't have the exact model you have).

And if the above tests with dd indicate that the partition itself is not writable, that would indicate a different problem, since you previously were able to write to the partition. In that case, I would doubt that your problem is related to V-Safe unless gparted wrote to some place where it should not have, which somehow made the drive unwritable. And if that is the case I wouldn't know how to correct it.

User avatar
Semme
Posts: 8399
Joined: Sun 07 Aug 2011, 20:07
Location: World_Hub

#66 Post by Semme »

<Big round of applause as the crowd rises to their feet> Impressive post(ing) NPierce. I've learned an interesting bit more about disk utilities here than I may have learned elsewhere without such a thread. Thank you for the lesson.

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#67 Post by Sylvander »

npierce:
1. Regarding your post of 11.23 today:

Code: Select all

# dd if=/dev/sdb bs=256 skip=4096 count=1 2>/dev/null | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100
# dd if=/dev/sdb bs=256 skip=640 count=1 2>/dev/null | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100
# 
And...

2. Regarding your post of 15.16 today:

Code: Select all

# fdisk -l /dev/sdb

Disk /dev/sdb: 1010 MB, 1010826752 bytes
196 heads, 9 sectors/track, 1119 cylinders, total 1974271 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009dcf9

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048     1972223      985088    b  W95 FAT32
# dd if=/dev/sdb1 bs=1 skip=3 count=4  2>/dev/null | hexdump -C
*
# echo -n test | dd of=/dev/sdb1 bs=1 seek=3 count=4
4+0 records in
4+0 records out
4 bytes (4 B) copied, 0.00296508 s, 1.3 kB/s
# dd if=/dev/sdb1 bs=1 skip=3 count=4  2>/dev/null | hexdump -C
# 
3. "Try a known-good flash drive in the same USB port. Use a drive that doesn't contain anything that you can't afford to lose, in the unlikely event that the port damages the drive.
I'll try booting my other 1GB Flash Drive [that has a known good Puppy on it] in that USB socket/port.
Then I'll get back and report.
Previously, I've never had any trouble with any USB port or Flash Drive.

4. Unplugged the Verbatim, and...
Plugged in the 1GB "PCLine" bootable 1GB Flash Drive:
It's icon appeared on the desktop, I clicked on it and it mounted...
Ran GParted to look at the partition on the drive, and all looks OK.
Now to reboot the Flash Drive to load it's Puppy.
Oops, wrong drive, the PC reported "Missing OS"; I can see all the folders and files on it, and it has no Puppy on it.

5. It's my "Lexar" 4GB that has the Puppy on it, so I'll now reboot that.
I'm back...
It booted the Slacko-5.3.3.1 just fine; typing from there now. :D
I see no problem with the port or either of these 2 drives.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#68 Post by npierce »

Semme,

You are most welcome. Thanks for saying so.

I too learned quite a bit from this thread. :)

----------------------------------------------------------------

Sylvander,

First, one last question. I've been assuming that, like most Puppy users, you are running as root. Was that a correct assumption?


So it looks like both sectors were full of zeros -- no evidence of a FAT format.
Sylvander wrote:

Code: Select all

# dd if=/dev/sdb1 bs=1 skip=3 count=4  2>/dev/null | hexdump -C
* 
Yes, hexdump sometimes just prints an asterisk if it only see a few zeros. That those four bytes of the boot sector were zero is consistent with the read of the first 256 bytes of the boot sector, reported earlier in your post. And the fact that those bytes didn't change to "74 65 73 74" ("test") shows that they couldn't be written to. (I am a little surprised, though, that the second read didn't produce the single asterisk that the first read did.)

And you've shown that the USB port is working fine.

So the Verbatim drive seems to simply be unwritable.

Not good news.

The fact that you were able to get it to work briefly after using gparted to format it as FAT, and then it started failing for no apparent reason, would seem to indicate that it just decided that it felt that it had put in enough years of service and that the time was right for it to retire. :) It is also remotely possible that gparted formatted it incorrectly and that the first files you wrote to it went to areas within the partition, but later files wrote to areas outside of the partition, causing corruption that made the drive unwritable.

Either way, without being able to write anything to the drive, I cannot see any way to make it writable again. I guess that's what they call a "catch-22". :)

User avatar
ETP
Posts: 1193
Joined: Tue 19 Oct 2010, 19:55
Location: UK

Re: The longest running thread ever about an old 1GB stick.

#69 Post by ETP »

Hi Sylvander,

Before you consign it to the bin, 2 final questions and one very last thing to try.
My wife had this Verbatim Flash Drive on her keychain given her by someone at her workplace, for use in her employment, but she never used it, so gave it to me.
Q1. Did she work anywhere near radiography?

Q2: When the stick is unplugged……does it glow in the dark?

Joking apart, try (Using an XP PC) flashing it with the utility and image mentioned in this post:
http://www.murga-linux.com/puppy/viewto ... 829#687829

Stop after writing the image (step 3) and attempt to boot from it on your own PC.
If it boots to a menu stop the countdown then select “power off
Regards ETP
[url=http://tinyurl.com/pxzq8o9][img]https://s17.postimg.cc/tl19y14y7/You_Tube_signature80px.png[/img][/url]
[url=http://tinyurl.com/kennels2/]Kennels[/url]

proebler
Posts: 178
Joined: Tue 24 Jan 2012, 11:15
Location: TAS

#70 Post by proebler »

I add my applause :!:

Remarkable patience, perseverance and knowledge.

Lucky any forum, to have contributors like npierce and Semme.

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#71 Post by Sylvander »

npierce:
1. "I've been assuming that, like most Puppy users, you are running as root. Was that a correct assumption?"
Correct assumption; I am running as root.

2. "So it looks like both sectors were full of zeros -- no evidence of a FAT format."
So I guess that...
Prior to this problem appearing...
I had zero-filled the drive, then re-partitioned, and formatted as EXT3.
Then re-formatted as FAT32.

3. "the Verbatim drive seems to simply be unwritable"
I think you're correct, and it's time to concede defeat.
I may have a go at ETP's idea...later.

ETP
4. "Q1. Did she work anywhere near radiography?"
NO.

5. "Q2: When the stick is unplugged……does it glow in the dark?"
NO.

6. "try (Using an XP PC) flashing it with the utility and image mentioned in this post"
I'll try to work up the enthusiasm to have a go at this.
Perhaps tomorrow.

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#72 Post by Sylvander »

Tried this:

Code: Select all

# e2fsck -f -p -v /dev/sdb
e2fsck: Bad magic number in super-block while trying to open /dev/sdb
/dev/sdb: 
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>

# 

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#73 Post by Sylvander »

Tried this:
1.

Code: Select all

# fsck -nv /dev/sdb1
fsck from util-linux 2.19
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext2: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Clear? no

fsck.ext2: Illegal inode number while checking ext3 journal for /dev/sdb1
# fsck.ext2 -pv /dev/sdb1
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb1
/dev/sdb1: 
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>

# e2fsck -b 8193 /dev/sdb1
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

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>

# dosfsck -av /dev/sdb1
dosfsck 3.0.11 (24 Dec 2010)
dosfsck 3.0.11, 24 Dec 2010, FAT32, LFN
Logical sector size is zero.
# 

User avatar
Semme
Posts: 8399
Joined: Sun 07 Aug 2011, 20:07
Location: World_Hub

#74 Post by Semme »

Time to thank the man and mark this puppy [SOLVED] >> Corrupt superblock. Writes exhausted.

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#75 Post by Sylvander »

OK :D

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#76 Post by Karl Godt »

is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

# e2fsck -b 8193 /dev/sdb1
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1
-b 8193 is from 1,44MB floppy disk drives times. If mkfs.ext2-4 is called without any inode or block or superblock parameters, the first backup of the superblock is written to -b 32768.

To determine the backup superblocks you can use

Code: Select all

dumpe2fs /dev/sdaX | grep -i backup
I get for example :
bash-3.00# dumpe2fs /dev/sda2 | grep -i backup
dumpe2fs 1.41.11 (14-Mar-2010)
Journal backup: inode blocks
Backup superblock at 32768, Group descriptors at 32769-32771
Backup superblock at 98304, Group descriptors at 98305-98307
Backup superblock at 163840, Group descriptors at 163841-163843
Backup superblock at 229376, Group descriptors at 229377-229379
Backup superblock at 294912, Group descriptors at 294913-294915
Backup superblock at 819200, Group descriptors at 819201-819203
Backup superblock at 884736, Group descriptors at 884737-884739
Backup superblock at 1605632, Group descriptors at 1605633-1605635
Backup superblock at 2654208, Group descriptors at 2654209-2654211
Backup superblock at 4096000, Group descriptors at 4096001-4096003
Backup superblock at 7962624, Group descriptors at 7962625-7962627
Backup superblock at 11239424, Group descriptors at 11239425-11239427

man mke2fs :
-S Write superblock and group descriptors only. This is useful if
all of the superblock and backup superblocks are corrupted, and
a last-ditch recovery 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 salvage-
able. It is critical to specify the correct filesystem block-
size when using this option, or there is no chance of recovery.
«Give me GUI or Death» -- I give you [[Xx]term[inal]] [[Cc]on[s][ole]] .
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal :P

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#77 Post by Sylvander »

I have little to no understanding of all of this stuff.

Could you give explicit instructions as to what I aught to do?
And explanations needed to give me essential understanding needed to get it right?

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#78 Post by amigo »

I'm still wondering if you ever really formatted the drive or only set the partition type?

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#79 Post by Karl Godt »

Sylvander wrote:I have little to no understanding of all of this stuff.

Could you give explicit instructions as to what I aught to do?
And explanations needed to give me essential understanding needed to get it right?
I would like to introduce you to the man command:
man <command>
ie

Code: Select all

man mke2fs
In Puppy while connected to the internet, man should run the pman script to show you a manual page of the desired <command>. I personally had not used the -S option to mke2fs. mkfs.extX is usually a link to the mke2fs binary, like many commands are linked to busybox.
But it might be that you have a devx loaded that contains the real man binary. If you have no manpages installed by copying them from some bigger distros to your Puppy /usr/share/man folder, it would not show much.

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#80 Post by Sylvander »

amigo:
1. "I'm still wondering if you ever really formatted the drive or only set the partition type?"
Originally, the drive was partitioned...
Then that partition formatted as EXT3...
Then the formatting changed to FAT32...
Then it all went bad when I tried to copy some files to the partition.
You'll see [almost all] of the rest of my actions reported in this thread.
My head is in a spin, and I don't really understand all of the things I've been instructed to do, and then done.

Karl Godt:
2. I entered the command:

Code: Select all

man mke2fs
And got the display of information.
I can only hope this will help me better understand its use.

3. Tried entering:

Code: Select all

dumpe2fs /dev/sdb1 | grep -i backup
...and got:

Code: Select all

dumpe2fs /dev/sdb1 | grep -i backup 
dumpe2fs 1.41.14 (22-Dec-2010)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1
# 
...which is nothing like the output you got.
Am I doing something wrong?
I don't know how it would open sdb1, since that [partition] doesn't exist [according to GParted and other programs].

4. "It is critical to specify the correct filesystem block-
size when using this option, or there is no chance of recovery.
"
Sounds DANGEROUS...
Especially when I don't understand the use of the command.
You'd need to lead me by the hand, explaining each step in detail.

Post Reply