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

Using applications, configuring, problems
Message
Author
npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#46 Post by npierce »

Sylvander wrote:Hey, I notice I reported in the title, that it was TestDisk that gave that report. :D
Oh, ya. Sorry about that -- time I got some new glasses! :)
Sylvander wrote:I'd need to attempt to retrace my steps and see if I encounter that message again.
Is that really necessary?
No. At least it is not a priority right now. We have something bigger to chase.
Sylvander wrote:Then entered w to write, and the console closed.
Should it do that?
Oh dear, no. It should print some messages and exit back to the command prompt, like it did for you on Tuesday.
Sylvander wrote:

Code: Select all

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
# 
But it shouldn't close the terminal window.

(Note: if you run fdisk from the menu, it will close the window. To see the messages it prints before it exits, it needs to be run from a terminal window (e.g., urxvt).)

It seems to me I remember that w would sometimes not exit gracefully. Since it worked for you on Tuesday, perhaps its failure today was a fluke. Probably not, but it might be worth trying to change the type one more time. I know this is probably getting a bit tedious, but if you can get it to work, it might be easier than trying other things.

I'm going to dig up a flash drive and see if I have similar problems trying to change its partition table.
Sylvander wrote:Would that write only take effect after a reboot WITH SAVE of the session changes?
I notice that when I re-run "System->Pdisk->fdisk" on sdb1, and enter the command p, the Id=b and System=w95 FAT32!
The write, if it had worked, would write to the flash drive. So it should be readable immediately -- no save to the save file is necessary.
Sylvander wrote:4. "The CHS values on your partition table do not agree with the LBA values.
Might we attempt to change so as to correct the CHS values?
Can you give me instructions to follow?
That is a possibility, although it is a little more complicated. For instance, there should be a backup partition table somewhere which also would need to be changed, so I'll have to go see where that lives.

I'll dig up a flash drive and do some experiments. In the meantime, you might try using fdisk once more to change the partition type, if you've not yet run out of patience with fdisk. :) If it works it could save us some time.

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

#47 Post by Semme »

NPierce- my 1g SanDisk Cruzer. Using fdisk alone, 5.2.8 has no problem with the mismatch.

Code: Select all

Disk /dev/sdb: 1027 MB, 1027416576 bytes
32 heads, 62 sectors/track, 1011 cylinders
Units = cylinders of 1984 * 512 = 1015808 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

Device     Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           2         530      524288   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sdb2             530        1012      478024+  83  Linux
Partition 2 does not end on cylinder boundary.

Code: Select all

00000000  80 01 03 01 83 11 a2 11  00 08 00 00 00 00 10 00  |................|
00000010  00 11 a3 11 83 0d eb f3  00 08 10 00 91 96 0e 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000040
These from my 2g Cruzer >> Id=c..

Code: Select all

Disk /dev/sdb: 2055 MB, 2055021056 bytes
255 heads, 63 sectors/track, 249 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

Device  Boot     Start    End     Blocks      Id  System
/dev/sdb1        1        250     2006825     c   W95 FAT32 (LBA)
Partition 1 has different physical/logical endings:
     phys=(248, 254, 63) logical=(249, 214, 46)

Code: Select all

00000000  00 01 01 00 0c fe 3f f8  3f 00 00 00 52 3e 3d 00  |......?.?...R>=.|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000040
Last edited by Semme on Fri 01 Mar 2013, 20:21, edited 2 times in total.

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

#48 Post by Sylvander »

npierce:
1. "it needs to be run from a terminal window"
Did that, and used the write command [w], and the console window didn't close.
Instead, it gave the following [also see the end of the results of the p command prior to it]:

Code: Select all

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048     1972223      985088    c  W95 FAT32 (LBA)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.
# 
Will now close the console window [NOT using q command prior to close], re-open it, enter the p command.
Oh dear, here's what I see:

Code: Select all

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048     1972223      985088    b  W95 FAT32
2. "it might be worth trying to change the type one more time. I know this is probably getting a bit tedious, but if you can get it to work, it might be easier than trying other things"
I find this interesting, not tedious at all [not yet anyway].
This is certainly good practise in using commands in a terminal.

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

#49 Post by npierce »

Semme,

Thanks for the report. That's good to know. Yes, since your partitions are Linux partitions, and since Linux always uses LBA, I would expect that the CHS fields are ignored.

In fact, I suspect that mount may also ignore the CHS fields even though it is mounting a type b (not-LBA) FAT partition. It is likely that the TestDisk program is simply more critical, and reported that inconsistency, since it might make the drive unusable on an old MS-DOS system.

If so, and if mount really doesn't care about the CHS fields, then the problem is elsewhere. But with few other clues, it was worth investigating the TestDisk error message. And it would be nice if simply (or not so simply, as this case seems to be) changing to type c made mount happy.

I'm hoping that mount or the kernel may provide a more specific error message in the dmesg log. Read on . . .

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

Sylvander,
Sylvander wrote:Oh dear, here's what I see:

Code: Select all

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048     1972223      985088    b  W95 FAT32
Oh dear.

Do you know if this is one of those flash drives that have some kind of software or hardware (switch) write protection? If so, perhaps that has been confused somehow.

I'm hoping mount or the kernel may tell us more.

Running these commands, in this order, might provide enlightening output:

Code: Select all

guess_fstype /dev/sdb1
mkdir -p /mnt/sdb1
mount -t vfat /dev/sdb1 /mnt/sdb1
dmesg | tail -9
I know you already provided the output of mount. But I'm asking you to run it again because I would like to see if it writes anything to the dmesg log.

I've been playing with an old 8 GB Toshiba TransMemory flash drive. Currently, it has a type c partition at /dev/sdb1 and a type 83 (Linux) partition at /dev/sdb2. I have repeatedly been able to change partition 1 from type c to type b, remove the drive, plug it in again, verify that the type really changed with "fdisk -l /dev/sdb", and change it back again. So it can be done -- at least with my flash drive, and using the version of fdisk from util-linux-ng 2.18, which came with Racy 5.2.2.

By the way, if you still have that copy of testdisk.log that you mentioned in your first post, I'd be glad to take a look at it if you gzip it and add it as an attachment -- I'm assuming it may be too long to just insert as text. You probably know how to gzip a file, but if not, this should do it. (This assumes that it is in your /root/ directory, if not adjust accordingly.):

Code: Select all

gzip /root/testdisk.log
That's not a big priority, and it might not have anything useful in it, but if you have the time to attach it, it just might provide a clue.
Sylvander wrote:I find this interesting, not tedious at all [not yet anyway].
Oh good.

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

#50 Post by npierce »

Sylvander,

I forgot to ask: Assuming that there is an LED on your flash drive, does it blink just after you use the write command in fdisk? Mine does.

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

#51 Post by Semme »

While we're in Q & A.. This drive come with Store 'n' Go or V-Safe software (sitting inside the opening 2048 sectors)?
Last edited by Semme on Sun 03 Mar 2013, 13:18, edited 1 time in total.

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

#52 Post by amigo »

So, try again to manually format the drive. Make sure it is unmounted and from the terminal run:
mkdosfs -F 32 /dev/sdb1

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

#53 Post by Sylvander »

npierce:
1. "Do you know if this is one of those flash drives that have some kind of software or hardware (switch) write protection?"
I'm certain theres none.
Neither software on the drive, nor any hardware switch/protection; just a plain drive.

2. "Running these commands, in this order, might provide enlightening output:"
I'll try those now and report back.
This is what is given:

Code: Select all

# guess_fstype /dev/sdb1 
unknown
# mkdir -p /mnt/sdb1 
# mount -t vfat /dev/sdb1 /mnt/sdb1 
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

# dmesg | tail -9
[ 5420.484714] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 5420.489795] sd 4:0:0:0: [sdb] Asking for cache data failed
[ 5420.489799] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 5420.600103]  sdb: sdb1
[ 5420.603798] sd 4:0:0:0: [sdb] Asking for cache data failed
[ 5420.603801] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 5420.603804] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[ 5516.321762] FAT-fs (sdb1): bogus number of reserved sectors
[ 5516.321766] FAT-fs (sdb1): Can't find a valid FAT filesystem
# 

3. "I have repeatedly been able to change partition 1 from type c to type b, remove the drive, plug it in again, verify that the type really changed with "fdisk -l /dev/sdb", and change it back again."
I haven't been unplugging and re-plugging the Flash Drive.
Might this be why all my efforts come to naught?

4. "if you still have that copy of testdisk.log that you mentioned in your first post, I'd be glad to take a look at it if you gzip it and add it as an attachment"
I have a copy of the file saved to a different folder on the 24th Feb...
Then I appended additional info on the 27th.
I've gzip'd the later version OK.
Not sure if a .gz file will attach, but will try it.
Do I need to change the extension to txt to attach?
Apparently not. :D
It attached OK.
I was then able to download, unzip, and read OK.

5. "Assuming that there is an LED on your flash drive, does it blink just after you use the write command in fdisk?"
No, it doesn't.
Not a good sign, eh?
It blinks when I 1st plug it in, as the Puppy detects it [and then the Puppy displays its icon on the desktop].

6. "This drive come with Store 'n' Go or V-Safe software (sitting inside the opening 2048 bytes)?"
I believe it does NOT.
Will keep on the lookout for that.
I usually do keep a watch for stuff like that, and haven't seen any sign of it.

amigo:
7. "try again to manually format the drive. Make sure it is unmounted and from the terminal run:
mkdosfs -F 32 /dev/sdb1
"
Done.
Here's what I get:

Code: Select all

# mkdosfs -F 32 /dev/sdb1
mkdosfs 3.0.11 (24 Dec 2010)
# 
Attachments
testdisk.log.gz
(1.58 KiB) Downloaded 262 times

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

#54 Post by Semme »

Ya think? Dwnlds here! Is your FalconFour system enough?

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

#55 Post by Sylvander »

Not sure what you mean Semme. :?

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.

I'm likely to have written zeros to the partition, then re-partitioned and re-formatted.
Was probably used as a bootable Puppy drive...
And then for file storage.
Eventually I either deleted all of the partition contents or wrote zeros or random patterns to the partition.
It always worked well.

Never was any sign of anything on the drive.
If there had been, I'd have eliminated it.
I don't like such stuff.

Semme:
You suggested in a PM [why don't you do such stuff here?], that I have another [and more careful] attempt at a fix using TestDisk, and that seems like a good idea to me.
Anyone think it's not a good idea, or other things should be tried first?

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

#56 Post by Semme »

*For the sake of get'n you on your way, I'm gonna overlook the privacy breach.

==

fdisk the drive again. Delete the sole partition, then write the op. Remove, wait a few seconds, reinsert.

Pup probably won't see it now, but it's there along with your other partitions.

Code: Select all

fdisk -l
This should be empty:

Code: Select all

Device Boot      Start         End      Blocks   Id  System
And the total readout after disk /dev/sdb:?

Whether empty or not, run this:

Code: Select all

fsck /dev/sdb
The response?

==

No quoted reply- simple answers.

We can all follow..
Last edited by Semme on Sat 02 Mar 2013, 21:56, edited 1 time in total.

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

#57 Post by Sylvander »

Semme:
1. "fdisk the drive again. Delete the sole partition, then write the op."
Treat me like a beginner.
I need explicit instructions/commands on how to do this, otherwise I'm likely to get it wrong.
What's an op?

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

#58 Post by Semme »

Unless switches are included, this type of opening never changes.

Code: Select all

fdisk /dev/sdb
For giggles, hit: m

Code: Select all

Command action
   a   toggle a bootable flag
   b   edit bsd disklabel
   c   toggle the dos compatibility flag
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)
ALWAYS hit "m" to start- so you're aware of your options.

After each (op)eration, hit: p

This allows you to view the layout and track your work.

Now we wanna (d)elete a partition, right? Right.

Since there seems to be only one partition, it'll probably submit a: 1

Go ahead: d

Whadda we wanna see? That's right- the (p)artition table again.

It's: p

If anything remains, again hit: d

Once clear, (w)rite the (op)erations to disk: w

Easy when you've spent some time with it.

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

#59 Post by npierce »

Sylvander wrote:

Code: Select all

# dmesg | tail -9
. . .
[ 5516.321762] FAT-fs (sdb1): bogus number of reserved sectors
[ 5516.321766] FAT-fs (sdb1): Can't find a valid FAT filesystem 
OK, so this is what mount is choking on: "bogus number of reserved sectors". If it is looking at the correct sector (by using the LBA fields, not the CHS fields) then this would indicate a formatting error, since the number of reserved sectors would be written to the first sector (the "boot sector") of the partition by the utility that created the FAT filesystem (mkdosfs).

I see that, last Sunday, TestDisk reported the number of reserved sectors (and all of the other values it found in the boot sector) as zero, which is certainly wrong. This was after you used gparted to re-format the partition and it failed, so its not too surprising that the boot sector was incorrect.

Based on reports from Monsie who "had problems with gparted in the past when it came to formatting a disk with Windows file systems," and from proebler's experience "where gparted could no longer be used to reformat a flash drive," this could certainly be attributed to a failing of gparted. Or, of course, it could be attributed to a failing of the flash drive itself.

I noticed that when you first tried to format it with gparted, you had success, and after you started having problems, gparted then failed to format successfully, as it had done previously. That sounds ominous.

But you formatted it again on Tuesday, using mkfs.vfat (which I think is usually a symlink to mkdosfs), and then again on Thursday, using mkdosfs, so good values should have been written to it. Unfortunately, the error message that was logged when you tried to mount the partition doesn't tell us the actual value that it considered bogus.

And my guess is that there are probably other bogus numbers, the "reserved sectors" value was just the first one encountered, so the mount operation quit when it saw that.

If you haven't yet tired of trying new things, you could try this command so we can see what's currently in the first half of your boot sector:

Code: Select all

dd if=/dev/sdb1 bs=256 skip=4096 count=1 2>/dev/null | hexdump -C
[CORRECTION, Mar-04: Sorry, the above command is wrong. The correct command is:

Code: Select all

dd if=/dev/sdb bs=256 skip=4096 count=1 2>/dev/null | hexdump -C
The skip offset I gave was from the start of the drive, not the partition, so I should have said "if=/dev/sda".]

Then to see what is in the first half of the sector that the CHS start field points to, in case mkdosfs believed the CHS numbers and put the boot sector there:

Code: Select all

dd if=/dev/sdb1 bs=256 skip=640 count=1 2>/dev/null | hexdump -C
[CORRECTION, Mar-04: Sorry, the above command is also wrong. The correct command is:

Code: Select all

dd if=/dev/sdb bs=256 skip=640 count=1 2>/dev/null | hexdump -C
The skip offset I gave was from the start of the drive, not the partition, so I should have said "if=/dev/sdb".]

Note that this time if=/dev/sdb1 since we are looking at the partition, unlike the other day when we were looking at the drive so it was if=/dev/sdb.

[CORRECTION, Mar-04: So the above paragraph is also wrong. Normally we would use /dev/sdb1 to read from the partition. But since your partition table has problems I wanted the command to ignore it, and use the desired offsets from the start of the drive, so I should have said "if=/dev/sdb". I thought I'd tested the command, but somehow I managed to confuse things. Sorry about that. (See my latest post: http://www.murga-linux.com/puppy/viewto ... 480#689480).]

The bs=256 lets us deal in half-sectors, and the LBA start field indicates that the first sector of the partition is at sector 2048 on the drive, so skip=4096 (half-sectors).

Likewise, the incorrect CHS start field indicates that the first sector of the partition is at sector 320, so skip=640 (half-sectors).
Sylvander wrote:I haven't been unplugging and re-plugging the Flash Drive.
Might this be why all my efforts come to naught?
.
No. Running "fdisk -l /dev/sdb" immediately after writing the partition table to the drive would show any changes you made if the write had worked. I only removed and reinserted my drive to be sure that the changes I saw were really getting written to the drive, and not just sitting in a buffer in RAM somewhere.


Thanks for attaching the TestDisk.log file. As well as the "CHS and LBA don't match" problem (for both "heads/cylinder" and "sect/track"), it showed (as mentioned above) that the boot sector of the partition wasn't created correctly.
Sylvander wrote:5. "Assuming that there is an LED on your flash drive, does it blink just after you use the write command in fdisk?"
No, it doesn't.
Not a good sign, eh?
No, it's not.

The fact that it has not been possible to write to the partition table is certainly troublesome. I am curious to see if you have any better luck with writing to it when you try deleting the partition from the table.

Do you remember if the LED blinked when running mkdosfs?

It will be interesting to see what is in the partition's boot sector, to see if there is any sign of it being formatted properly. If not, perhaps it is no longer possible to write to the partition either.

[Edited 2013-Mar-04 to add above corrections in red.]
Last edited by npierce on Mon 04 Mar 2013, 16:00, edited 1 time in total.

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

#60 Post by Sylvander »

npierce:
1.

Code: Select all

dd if=/dev/sdb1 bs=256 skip=4096 count=1 2>/dev/null | hexdump -C
Gave:

Code: Select all

# dd if=/dev/sdb1 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
# 
And....
2.

Code: Select all

dd if=/dev/sdb1 bs=256 skip=640 count=1 2>/dev/null | hexdump -C
Gave:

Code: Select all

# dd if=/dev/sdb1 bs=256 skip=640 count=1 2>/dev/null | hexdump -C
00000000  28 80 00 00 28 80 01 00  28 80 02 00 28 80 03 00  |(...(...(...(...|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100
# 
3. "Do you remember if the LED blinked when running mkdosfs?"
No, didn't look, but will look for an opportunity to do so ASAP.
Just tried it, and...
I thought I saw the faintest blink, but may have imagined it.
There was certainly no obvious blinking.

Semme:
4. "fdisk the drive again"
Here's what I get:

Code: Select all

# fdisk /dev/sdb

Command (m for help): m
Command action
   a   toggle a bootable flag
   b   edit bsd disklabel
   c   toggle the dos compatibility flag
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)

Command (m for help): p

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

Command (m for help): d
Selected partition 1

Command (m for help): p

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

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
# fdisk /dev/sdb

Command (m for help): p

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

Command (m for help): 
I read that as a FAILURE to delete. :(
Am I correct?
p.s. The Flash Drive was plugged in, its icon [sdb1] was displayed on the desktop, and no attempt had been made to mount the partition.

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.

Post Reply