TestDisk: Flash Drive="CHS and LBA don't match" [SOLVED]
amigo:
1. Followed your instructions [correctly I hope], and got the following:
Any useful info there?
Before entering the above command I checked, and /mnt/sdb1 did in fact exist.
I had chosen to make partition type c=W95 FAT32 (LBA).
Hope this was the correct choice.
proebler:
Will now reboot into Mint, and look for Disk Utility.
Done: No Disk Utility in Accessories!
Will make new Mint=Debian-xfce bootable DVD-RW, and try in there.
Got a link for the Debian-xfce iso file?
1. Followed your instructions [correctly I hope], and got the following:
Any useful info there?
Code: Select all
# 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
#
I had chosen to make partition type c=W95 FAT32 (LBA).
Hope this was the correct choice.
proebler:
Will now reboot into Mint, and look for Disk Utility.
Done: No Disk Utility in Accessories!
Will make new Mint=Debian-xfce bootable DVD-RW, and try in there.
Got a link for the Debian-xfce iso file?
Sylvander- go ahead and fdisk your device again- we won't write to it.
Once up, type *p* to dump the partition table. What's the *Id* read?
To quit without write >> *q*
PS- You don't need Mint to zero your drive.
Once up, type *p* to dump the partition table. What's the *Id* read?
To quit without write >> *q*
PS- You don't need Mint to zero your drive.
Semme:
1.
Here's the result:
2.
Hmmm, how do I create the junk.bin file on sdb1 if I cannot mount sdb1?
proebler:
3.
I'm certainly getting around.
1.
Done.Semme wrote:Once up, type *p* to dump the partition table. What's the *Id* read?
Here's the result:
Code: Select all
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
Thanks, I'll try using these instructions to zero the drive.Semme wrote:You don't need Mint to zero your drive.
Hmmm, how do I create the junk.bin file on sdb1 if I cannot mount sdb1?
proebler:
3.
In "linuxmint-xfce-201104-dvd-64bit", I found it in "System", but it failed to complete all the operations I tried [format drive, format partition, delete partition].proebler wrote:Disk Utility is in Accessories...
I'm certainly getting around.
Hold up on that zero link. I recall there being a typo..
Not sure why, but your sector size looks odd. Hmm..
Ah, yes- it's the format me thinks..
Haven't seen FAT in a while.
==
fdisk can alter cylinders, heads and sectors?
:idea: <rubs hands together> Hmm..
==
Ya know- how about an fsck?
Format switch ext2/3..
e2fsck *
Then back >> FAT32.
Just think'n..
==
Aha! You've got an old boot sector on this drive!
mount -t vfat >> bad superblock? I think NOT!
Not sure why, but your sector size looks odd. Hmm..
Ah, yes- it's the format me thinks..
Haven't seen FAT in a while.
==
fdisk can alter cylinders, heads and sectors?
:idea: <rubs hands together> Hmm..
==
Ya know- how about an fsck?
Format switch ext2/3..
e2fsck *
Then back >> FAT32.
Just think'n..
==
Aha! You've got an old boot sector on this drive!
mount -t vfat >> bad superblock? I think NOT!
sorry, but what is the problem?
I'm confused.
Does the device still not work?
The output from fdisk looks reasonable.
This is an USB flash drive, not a HD.
Heads, sectors/track cylinders, are meaningless.
This is from one of my own USB's, it works, mounts and shows perfectly.
It is bootable, as indicated by the *, but that is no necessity.
..or this, from a single partition 8 GB USB.
It too works and mounts correctly but Gparted cannot make sense of it. It is not bootable.
I'm confused.
Does the device still not work?
The output from fdisk looks reasonable.
Code: Select all
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
Heads, sectors/track cylinders, are meaningless.
This is from one of my own USB's, it works, mounts and shows perfectly.
It is bootable, as indicated by the *, but that is no necessity.
Code: Select all
Command (m for help): p
Disk /dev/sdb: 4083 MB, 4083351552 bytes
126 heads, 62 sectors/track, 1020 cylinders, total 7975296 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: 0x000139ca
Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 3729407 1863680 83 Linux
/dev/sdb2 3729408 7450623 1860608 83 Linux
/dev/sdb3 7450624 7974911 262144 b W95 FAT32
..or this, from a single partition 8 GB USB.
It too works and mounts correctly but Gparted cannot make sense of it. It is not bootable.
Code: Select all
Command (m for help): p
Disk /dev/sdc: 8086 MB, 8086618112 bytes
249 heads, 62 sectors/track, 1023 cylinders, total 15794176 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: 0x2c6b7369
This doesn't look like a partition table
Probably you selected the wrong device.
Device Boot Start End Blocks Id System
/dev/sdc1 ? 1936028272 3787887330 925929529+ 68 Unknown
/dev/sdc2 ? 1330184192 1869160479 269488144 79 Unknown
/dev/sdc3 ? 538989391 1937352302 699181456 53 OnTrack DM6 Aux3
/dev/sdc4 ? 1394627663 1394648999 10668+ 49 Unknown
Partition table entries are not in disk order
Since you got had the "CHS and LBA don't match" error message, it could be helpful to see the raw partition table. This can be done as follows:
First, just to be sure that your Puppy can still find your flash drive as /dev/sdb, and to be sure nothing has changed, enter this command:
If you still get "Disk /dev/sdb: 1010 MB, 1010826752 bytes . . .", enter this command line:
As you are probably aware, it is always good to know what you are doing with the dd command, since a typo can be a dangerous thing. So I'll explain what that line does.
The partition table is 64 bytes in length and lives 446 bytes from the beginning of your drive.
if=/dev/sdb means dd will take its input from /dev/sdb, currently your flash drive.
bs=1 means dd will work in units of one-byte blocks.
skip=446 means dd will skip the first 446 units of input.
count=64 means dd will copy the next 64 units.
2>/dev/null suppresses the status message from dd.
| hexdump -C pipes the output from dd to hexdump, which displays the byte values.
(This command doesn't write to your flash drive, it only reads from it.)
This should display four lines of sixteen bytes each. These are the four entries in the partition table. Please post that output as well as the output from the above "fdisk -l /dev/sdb" command.
First, just to be sure that your Puppy can still find your flash drive as /dev/sdb, and to be sure nothing has changed, enter this command:
Code: Select all
fdisk -l /dev/sdb
Code: Select all
dd if=/dev/sdb bs=1 skip=446 count=64 2>/dev/null | hexdump -C
The partition table is 64 bytes in length and lives 446 bytes from the beginning of your drive.
if=/dev/sdb means dd will take its input from /dev/sdb, currently your flash drive.
bs=1 means dd will work in units of one-byte blocks.
skip=446 means dd will skip the first 446 units of input.
count=64 means dd will copy the next 64 units.
2>/dev/null suppresses the status message from dd.
| hexdump -C pipes the output from dd to hexdump, which displays the byte values.
(This command doesn't write to your flash drive, it only reads from it.)
This should display four lines of sixteen bytes each. These are the four entries in the partition table. Please post that output as well as the output from the above "fdisk -l /dev/sdb" command.
Sylvander, it's a PILEUP! Cuz, weez'ALL *really* wantcha ta have photos on dat dare flash drive'a yers..
- Attachments
-
- sylvander_datchoo-down-dare.jpg
- (115.47 KiB) Downloaded 773 times
proebler:
1. "Does the device still not work?"
Correct.
2. "what is the problem?"
It won't do anything I'd expect a Flash Drive to do.
e.g. Won't mount; can't do anything with it in most programs like GParted.
npierce:
3. "If you still get "Disk /dev/sdb: 1010 MB, 1010826752 bytes . . .""
Yes got that.
Here's the output:
4. Next tried:
And got:
amigo:
5.
6.
Semme:
7. Ready to check for corruption.
1. "Does the device still not work?"
Correct.
2. "what is the problem?"
It won't do anything I'd expect a Flash Drive to do.
e.g. Won't mount; can't do anything with it in most programs like GParted.
npierce:
3. "If you still get "Disk /dev/sdb: 1010 MB, 1010826752 bytes . . .""
Yes got that.
Here's the output:
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
#
Code: Select all
dd if=/dev/sdb bs=1 skip=446 count=64 2>/dev/null | hexdump -C
Code: Select all
# dd if=/dev/sdb bs=1 skip=446 count=64 2>/dev/null | hexdump -C
00000000 00 20 21 00 0b c3 09 7a 00 08 00 00 00 10 1e 00 |. !....z........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000040
#
5.
Code: Select all
# cat /proc/filesystems
nodev sysfs
nodev rootfs
nodev bdev
nodev proc
nodev tmpfs
nodev binfmt_misc
nodev debugfs
nodev sockfs
nodev usbfs
nodev pipefs
nodev anon_inodefs
nodev devpts
reiserfs
ext3
ext2
ext4
nodev ramfs
vfat
msdos
iso9660
ntfs
udf
squashfs
nodev aufs
fuseblk
nodev fuse
nodev fusectl
#
Code: Select all
# lsmod
Module Size Used by
cpufreq_ondemand 4361 2
acpi_cpufreq 4301 1
mperf 859 1 acpi_cpufreq
i915 284201 2
drm_kms_helper 17719 1 i915
drm 121515 3 i915,drm_kms_helper
video 9383 1 i915
i2c_algo_bit 3672 1 i915
iptable_mangle 904 0
iptable_nat 2575 0
nf_nat 9805 1 iptable_nat
ipt_REJECT 1517 1
nf_conntrack_ftp 4065 0
nf_conntrack_irc 2379 0
iptable_filter 804 1
xt_state 791 4
nf_conntrack_ipv4 7266 7 iptable_nat,nf_nat
nf_conntrack 38062 6 iptable_nat,nf_nat,nf_conntrack_ftp,nf_conntrack_irc,xt_state,nf_conntrack_ipv4
nf_defrag_ipv4 787 1 nf_conntrack_ipv4
ip_tables 7021 3 iptable_mangle,iptable_nat,iptable_filter
snd_hda_codec_hdmi 18363 1
snd_hda_codec_realtek 135150 1
usblp 7516 0
pcspkr 1195 0
atl1c 22782 0
snd_hda_intel 17167 0
snd_hda_codec 54456 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 3708 1 snd_hda_codec
snd_pcm_oss 27363 0
snd_mixer_oss 9850 1 snd_pcm_oss
snd_pcm 47145 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_seq_dummy 907 0
i2c_i801 6166 0
i2c_core 12587 5 i915,drm_kms_helper,drm,i2c_algo_bit,i2c_i801
snd_seq_oss 19155 0
snd_seq_midi 3248 0
snd_seq_midi_event 3636 2 snd_seq_oss,snd_seq_midi
snd_rawmidi 11838 1 snd_seq_midi
snd_seq 32204 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
snd_seq_device 3541 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
snd_timer 11743 2 snd_pcm,snd_seq
shpchp 17907 0
snd 33354 13 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_seq_device,snd_timer
soundcore 3321 1 snd
snd_page_alloc 4697 2 snd_hda_intel,snd_pcm
intel_agp 7984 1 i915
intel_gtt 9153 3 i915,intel_agp
agpgart 17858 3 drm,intel_agp,intel_gtt
parport_pc 18328 0
parport 20351 1 parport_pc
evdev 5812 0
processor 21886 1 acpi_cpufreq
thermal_sys 9730 2 video,processor
hwmon 877 1 thermal_sys
button 3275 1 i915
fuse 47727 0
aufs 120424 72
squashfs 18852 1
#
7. Ready to check for corruption.
Sylvander, thanks for the information.
If you are unfamiliar with the terms "CHS" and "LBA", you can read the next three paragraphs for a brief explanation. But you don't really need to know what they mean, so may skip ahead if you like.
----------------------------------------------------------------
Partition tables contain the information needed to find the starting sector and the ending sector of each partition. There are two ways of doing this.
The older way was to specify the cylinder, head, and sector (CHS). So a sector was identified by where it physically lived on the disk. That way requires knowing how many sectors were on each track of the cylinder and how many heads there were. As drives got bigger it became impossible to fit the actual cylinder number into the ten-bit field allowed for it, so a bit of poetic license was used to allow bigger drives, like specifying head numbers greater than the actual number of heads. Nowadays these numbers rarely refer to actual cylinders and heads. This is clearly the case for your flash drive, which has no physical cylinders or heads.
The newer way of doing things is to just identify each sector with a number, instead of by where it lives on the drive. This is known as "Logical Block Addressing" (LBA).
----------------------------------------------------------------
Normally, Linux only uses the LBA values, so I am a little surprised by the "CHS and LBA don't match" error message. Perhaps instead of simply ignoring the CHS values, something has noticed that they don't match and assumes that the partition is not really a type b FAT partition.
Two questions:
1. When did you see that error message? (Clicking on the icon? Using pmount? Using the mount command? Using some other utility and/or another non-Puppy operating system? Using gparted? Using fdisk? Something else?)
2. Do you still get that error message, and does it still say "Incorrect number of heads/cylinder 255 (FAT) !=32 (HD)", or have those values changed?
Anyway, some utility seems to have put bad values in the CHS fields. That utility assumed that the drive had 255 heads and 63 sectors per track (not actual physical heads and tracks, of course) -- those numbers are commonly used for large drives, since they are the maximum allowed for CHS, but your drive is not so large, and fdsik indicates that it has 196 heads and 9 sectors per track. So the utility got the values wrong.
Probably the easiest way to fix this is to change your drive type from type b (W95 FAT32) to type c (W95 FAT32 (LBA)), which uses Logical Block Addressing, and so the CHS values should be ignored.
I know that you intended to set the type to c earlier, but both "fdisk -l" and the raw partition table show that it is still b.
1. Run fdisk /dev/sdb
2. Press p then Enter to and look to make sure it is working on your flash drive ("Disk /dev/sdb: 1010 MB, 1010826752 bytes . . ."). (If not, press q then Enter to quit, and tell us what it said.)
3. Press t then Enter to prepare to change the type.
4. Press 1 then Enter to choose partition 1.
5. Press c then Enter to set type c.
6. Press p then Enter and look to ensure that the Id column says c and the System column says "W95 FAT32 (LBA)" (If not, press q then Enter to quit, and tell us what it said.)
7. Press w then Enter to write to the partition table.
The partition table has fields for both CHS and LBA values. If CHS values are used, they should agree with the LBA values. The CHS values on your partition table do not agree with the LBA values.Sylvander wrote:. . .Code: Select all
196 heads, 9 sectors/track, 1119 cylinders, total 1974271 sectors
Code: Select all
00000000 00 20 21 00 0b c3 09 7a 00 08 00 00 00 10 1e 00 |. !....z........|
If you are unfamiliar with the terms "CHS" and "LBA", you can read the next three paragraphs for a brief explanation. But you don't really need to know what they mean, so may skip ahead if you like.
----------------------------------------------------------------
Partition tables contain the information needed to find the starting sector and the ending sector of each partition. There are two ways of doing this.
The older way was to specify the cylinder, head, and sector (CHS). So a sector was identified by where it physically lived on the disk. That way requires knowing how many sectors were on each track of the cylinder and how many heads there were. As drives got bigger it became impossible to fit the actual cylinder number into the ten-bit field allowed for it, so a bit of poetic license was used to allow bigger drives, like specifying head numbers greater than the actual number of heads. Nowadays these numbers rarely refer to actual cylinders and heads. This is clearly the case for your flash drive, which has no physical cylinders or heads.
The newer way of doing things is to just identify each sector with a number, instead of by where it lives on the drive. This is known as "Logical Block Addressing" (LBA).
----------------------------------------------------------------
Normally, Linux only uses the LBA values, so I am a little surprised by the "CHS and LBA don't match" error message. Perhaps instead of simply ignoring the CHS values, something has noticed that they don't match and assumes that the partition is not really a type b FAT partition.
Two questions:
1. When did you see that error message? (Clicking on the icon? Using pmount? Using the mount command? Using some other utility and/or another non-Puppy operating system? Using gparted? Using fdisk? Something else?)
2. Do you still get that error message, and does it still say "Incorrect number of heads/cylinder 255 (FAT) !=32 (HD)", or have those values changed?
Anyway, some utility seems to have put bad values in the CHS fields. That utility assumed that the drive had 255 heads and 63 sectors per track (not actual physical heads and tracks, of course) -- those numbers are commonly used for large drives, since they are the maximum allowed for CHS, but your drive is not so large, and fdsik indicates that it has 196 heads and 9 sectors per track. So the utility got the values wrong.
Probably the easiest way to fix this is to change your drive type from type b (W95 FAT32) to type c (W95 FAT32 (LBA)), which uses Logical Block Addressing, and so the CHS values should be ignored.
I know that you intended to set the type to c earlier, but both "fdisk -l" and the raw partition table show that it is still b.
1. Run fdisk /dev/sdb
2. Press p then Enter to and look to make sure it is working on your flash drive ("Disk /dev/sdb: 1010 MB, 1010826752 bytes . . ."). (If not, press q then Enter to quit, and tell us what it said.)
3. Press t then Enter to prepare to change the type.
4. Press 1 then Enter to choose partition 1.
5. Press c then Enter to set type c.
6. Press p then Enter and look to ensure that the Id column says c and the System column says "W95 FAT32 (LBA)" (If not, press q then Enter to quit, and tell us what it said.)
7. Press w then Enter to write to the partition table.
npierce:
1. "When did you see that error message?"
Oh dear, I can only try to remember and guess.
Might have been in Testdisk, or Gparted, or Pmount->fdisk, or Falconfour's UBCD->XP->CheckDisk.
Hey, I notice I reported in the title, that it was TestDisk that gave that report.
2. "Do you still get that error message?"
I'd need to attempt to retrace my steps and see if I encounter that message again.
Is that really necessary?
3. Followed your steps [with tiny deviations to truly put your intent into effect], as follows:
Then entered w to write, and the console closed.
Should it do that?
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!
In full:
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?
amigo:
5. "What exact command did you use to format the drive? (mkdosfs...)"
Originally, I used Gparted to reformat [the existing partition] from EXT3 to FAT32.
Then, through the course of this thread I've followed various instructions...
[And reported back on those]
Rather parrot fashion...
Since most are beyond my understanding.
Did any of those include yet another reformat?
GParted always reports a failure to reformat.
Also reports failure to delete the partition.
1. "When did you see that error message?"
Oh dear, I can only try to remember and guess.
Might have been in Testdisk, or Gparted, or Pmount->fdisk, or Falconfour's UBCD->XP->CheckDisk.
Hey, I notice I reported in the title, that it was TestDisk that gave that report.
2. "Do you still get that error message?"
I'd need to attempt to retrace my steps and see if I encounter that message again.
Is that really necessary?
3. Followed your steps [with tiny deviations to truly put your intent into effect], as follows:
Code: Select all
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): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))
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 c W95 FAT32 (LBA)
Command (m for help):
Should it do that?
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!
In full:
Code: Select all
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
Might we attempt to change so as to correct the CHS values?
Can you give me instructions to follow?
amigo:
5. "What exact command did you use to format the drive? (mkdosfs...)"
Originally, I used Gparted to reformat [the existing partition] from EXT3 to FAT32.
Then, through the course of this thread I've followed various instructions...
[And reported back on those]
Rather parrot fashion...
Since most are beyond my understanding.
Did any of those include yet another reformat?
GParted always reports a failure to reformat.
Also reports failure to delete the partition.
Oh, ya. Sorry about that -- time I got some new glasses!Sylvander wrote:Hey, I notice I reported in the title, that it was TestDisk that gave that report.
No. At least it is not a priority right now. We have something bigger to chase.Sylvander wrote:I'd need to attempt to retrace my steps and see if I encounter that message again.
Is that really necessary?
Oh dear, no. It should print some messages and exit back to the command prompt, like it did for you on Tuesday.Sylvander wrote:Then entered w to write, and the console closed.
Should it do that?
But it shouldn't close the terminal window.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. #
(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.
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: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!
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.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?
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.
NPierce- my 1g SanDisk Cruzer. Using fdisk alone, 5.2.8 has no problem with the mismatch.
These from my 2g Cruzer >> Id=c..
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
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.
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]:
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:
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.
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.
#
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
I find this interesting, not tedious at all [not yet anyway].
This is certainly good practise in using commands in a terminal.
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,
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:
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.):
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.
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,
Oh dear.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
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'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
Oh good.Sylvander wrote:I find this interesting, not tedious at all [not yet anyway].