Bug 59053 - cannot see one of two windows partitions created with fdisk
cannot see one of two windows partitions created with fdisk
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-29 19:35 EST by ralph hinton
Modified: 2007-04-18 12:39 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-07 20:55:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description ralph hinton 2002-01-29 19:35:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)

Description of problem:
Support have asked me to refer service request 197053 to you.  It concerns a 
FAT32 partition
 (hdb4) that I cannot read with LINUX or WINDOWS although I can read hda1.  It 
is either
 a bug or a corrupt partition and we don't know which.  Please let me know what 
you
 require in addition or whether you cannot access the service request.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.look with shell commands
2.look with konqueror
3.
	

Additional info:
Comment 1 Bill Nottingham 2002-01-30 10:00:32 EST
Can you mount the partition at all?

Is there a filesystem on it?

What's the output of /proc/partitions?
Comment 2 ralph hinton 2002-01-30 19:50:45 EST
Answers :
Can you mount the partition at all?
  - Not now even from windows, I could before the upgrade.
Is there a filesystem on it?.
  - Yes there are files on it which i was using for many months
What's the output of /proc/partitions?
  - cannot use the command, because its' length is 0.
    Here is part of /etc/fstab :
/dev/cdrom              /mnt/cdrom              iso9660 noauto,owner,kudzu,ro 0 
0
/dev/fd0                /mnt/floppy             auto    noauto,owner,kudzu 0 0
/dev/hda1               /mnt/winhda1            vfat    defaults        0 0
/dev/hdb4               /mnt/winhd4             vfat    defaults        0 0
Comment 3 Bill Nottingham 2002-01-30 19:54:31 EST
Let me rephrase: what's the *contents* of /proc/partitions?
Comment 4 ralph hinton 2002-01-31 21:35:52 EST
/proc/partitions gives (I don't know how)
major minor  #blocks  name     rio rmerge rsect ruse wio wmerge wsect wuse 
running use aveq

   3     0    3092544 hda 22 0 32 70 0 0 0 0 0 70 70
   3     1    3088480 hda1 22 0 32 70 0 0 0 0 0 70 70
   3    64    8257032 hdb 4099 10891 117094 41280 1230 206 11590 32360 0 36660 
73710
   3    65     184716 hdb1 24 427 902 410 2 1 6 0 0 410 410
   3    66     136552 hdb2 3 0 18 40 0 0 0 0 0 40 40
   3    67    2963992 hdb3 4055 10464 116146 39840 1228 205 11584 32360 0 35420 
72270
   3    68    4964085 hdb4 16 0 26 980 0 0 0 0 0 980 980

hdb4 is the problem partition.
        Thanks for your help, Ralph.
Comment 5 Bill Nottingham 2002-01-31 22:16:35 EST
The filesystem would be handled by the kernel, so assigning there. What do you
get  if you do 'mount -t vfat /dev/hdb4 /misc'?
Comment 6 Arjan van de Ven 2002-02-01 04:12:01 EST
The interesting bit is if the kernel gives any messages when it fails (eg type
"dmesg" and check the last few lines)
Comment 7 ralph hinton 2002-02-03 18:57:58 EST
the mount command produces :
mount: wrong fs type, bad option, bad superblock on /dev/hdb4,
       or too many mounted file systems
the dmesg command produces :
FAT: Did not find valid FSINFO signature.
Found signature1 0x100001 signature2 0x10007a sector=8224.
[MS-DOS FS Rel. 12,FAT 32,check=n,conv=b,uid=0,gid=0,umask=022,bmap]
[me=0xf8,cs=8,#f=2,fs=32,fl=-1054277503,ds=-2108554974,de=0,data=-
2108554974,se=0,ts=9928170,ls=512,rc=538976288,fc=0]
hard sector size = 512
VFS: Can't find a valid FAT filesystem on dev 03:44.
Comment 8 ralph hinton 2002-02-07 21:00:09 EST
Are you getting anywhere with analysing the data?.
Comment 9 Stephen Tweedie 2002-02-20 12:36:29 EST
I'd also like to see "fdisk" output for the /dev/hdb disk, both normal and
expert.  Run:

# fdisk /dev/hdb
Command (m for help): p
... capture this output ...
Command (m for help): x
Expert command (m for help): p
... capture this output ...
Expert command (m for help): q
#
Comment 10 ralph hinton 2002-02-20 22:09:34 EST
Here is the output :
Command (m for help): 
Disk /dev/hdb: 255 heads, 63 sectors, 1027 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hdb1   *         1        23    184716   83  Linux
/dev/hdb2            24        40    136552+  82  Linux swap
/dev/hdb3            41       409   2963992+  83  Linux
/dev/hdb4           410      1027   4964085    b  Win95 FAT32

Command (m for help): 
Expert command (m for help): 
Disk /dev/hdb: 255 heads, 63 sectors, 1027 cylinders

Nr AF  Hd Sec  Cyl  Hd Sec  Cyl    Start     Size ID
 1 80   1   1    0 254  63   22       63   369432 83
 2 00   0   1   23 254  63   39   369495   273105 82
 3 00   0   1   40 254  63  408   642600  5927985 83
 4 00   0   1  409 254  63 1023  6570585  9928170 0b

Expert command (m for help): 



Comment 11 Stephen Tweedie 2002-02-21 08:59:10 EST
Hmm, nothing wrong with that --- I was wondering if there was any chance of
there being overlapping partitions: if that gets set up by mistake, then you
could easily get the results described.

Would it be possible to see the contents of the first chunk of hdb4?  That might
give some clue as to what is going on here.

    dd if=/dev/hdb4 bs=4k count=1 | hexdump > /tmp/dump.txt

will do it.
Comment 12 ralph hinton 2002-02-21 22:17:00 EST
Here is the data:0000000 58eb 4d90 5753 4e49 2e34 0031 0802 0020
0000010 0002 0000 f800 0000 003f 00ff 4259 0064
0000020 7dea 0097 0081 c129 5d69 202b 2020 2020
0000030 2020 2020 2020 4146 3154 2036 2020 0000
0000040 0080 6b29 d033 4918 4d42 3030 3030 2031
0000050 2020 4146 3354 2032 2020 33fa 8ec9 bcd1
0000060 7bf8 c18e 78bd c500 0076 561e 5516 22bf
0000070 8905 007e 4e89 b102 fc0b a4f3 d98e 00bd
0000080 c67c fe45 8b0f 1846 4588 38f9 404e 257d
0000090 c18b bb99 0700 97e8 7200 831a 3aeb a166
00000a0 7c1c 3b66 8a07 fc57 0675 ca80 8802 0256
00000b0 c380 7310 bfed 0002 7e83 0016 4575 468b
00000c0 8b1c 1e56 03b9 4900 7540 4201 00bb e87e
00000d0 005f 2673 f8b0 744f 8b1d 3246 d233 03b9
00000e0 3b00 77c8 8b1e 0e76 ce3b 1773 f12b 4603
00000f0 131c 1e56 d1eb 0b73 27eb 7e83 002a 0377
0000100 fde9 be02 7d7e 98ac f003 84ac 74c0 3c17
0000110 74ff b409 bb0e 0007 10cd eeeb 81be eb7d
0000120 bee5 7d7f e0eb cd98 5e16 661f 048f 19cd
0000130 5641 6a66 5200 0650 6a53 6a01 8b10 60f4
0000140 7e80 0e02 0475 42b4 1deb 9291 d233 76f7
0000150 9118 76f7 4218 ca87 76f7 8a1a 8af2 c0e8
0000160 02cc cc0a 01b8 8a02 4056 13cd 8d61 1064
0000170 725e 400a 0175 0342 0b5e 7549 c3b4 1803
0000180 2701 0a0d 6e49 6176 696c 2064 7973 7473
0000190 6d65 6420 7369 ff6b 0a0d 6944 6b73 4920
00001a0 4f2f 6520 7272 726f 0dff 520a 7065 616c
00001b0 6563 7420 6568 6420 7369 2c6b 6120 646e
00001c0 7420 6568 206e 7270 7365 2073 6e61 2079
00001d0 656b 0d79 000a 0000 4f49 2020 2020 2020
00001e0 5953 4d53 4453 534f 2020 5320 5359 017e
00001f0 5700 4e49 4f42 544f 5320 5359 0000 aa55
0000200 5252 4161 0000 0000 0000 0000 0000 0000
0000210 0000 0000 0000 0000 0000 0000 0000 0000
*
00003e0 0000 0000 7272 6141 3e61 0009 f3f9 0001
00003f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000400 66fa b60f 1046 8b66 244e f766 66e1 4603
0000410 661c b70f 0e56 0366 33c2 66c9 4689 66fc
0000420 46c7 fff8 ffff faff 8b66 2c46 8366 02f8
0000430 820f fccf 3d66 fff8 0fff 830f fcc5 0f66
0000440 c2a4 fb10 5052 66fa e0c1 6610 ac0f 10d0
0000450 8366 02e8 0f66 5eb6 8b0d 66f3 e3f7 0366
0000460 fc46 0f66 c2a4 fb10 00bb 8b07 b9fb 0001
0000470 bee8 0ffc aa82 38fc 742d b11e 560b d8be
0000480 f37d 5ea6 1974 f903 c783 3b15 72fb 4ee8
0000490 d675 5a58 66e8 7200 83ab 04c4 64e9 83fc
00004a0 04c4 758b 8b09 0f7d c68b 66fa e0c1 8b10
00004b0 66c7 f883 7202 663b f83d ffff 730f 6633
00004c0 6648 6648 b60f 0d4e f766 66e1 4603 66fc
00004d0 a40f 10c2 bbfb 0700 b953 0004 52e8 5bfc
00004e0 820f fc3d 3f81 5a4d 0875 bf81 0200 4a42
00004f0 0674 80be e97d fc0e 00ea 7002 0300 13c0
0000500 03d2 13c0 e8d2 0018 26fa 8b66 6601 ff25
0000510 ffff 660f a40f 10c2 3d66 fff8 0fff c3fb
0000520 00bf fa7e c166 10e0 0f66 d0ac 6610 b70f
0000530 0b4e 3366 66d2 f1f7 3b66 f846 4474 8966
0000540 f846 0366 1c46 0f66 4eb7 660e c103 0f66
0000550 5eb7 8328 0fe3 1674 5e3a 0f10 a483 52fb
0000560 8b66 66c8 468b 6624 e3f7 0366 5ac1 6652
0000570 a40f 10c2 8bfb b9df 0001 b4e8 5afb 820f
0000580 fb9f 8bfb c3da 0000 0000 0000 0000 0000
0000590 0000 0000 0000 0000 0000 0000 0000 0000
*
00005f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000600 0000 0000 0000 0000 0000 0000 0000 0000
*
0000c00 58eb 4d90 5753 4e49 2e34 0031 0802 0020
0000c10 0002 0000 f800 0000 003f 00ff 4259 0064
0000c20 7dea 0097 25d6 0000 0000 0000 0002 0000
0000c30 0001 0006 0000 0000 0000 0000 0000 0000
0000c40 0080 6b29 d033 4918 4d42 3030 3030 2031
0000c50 2020 4146 3354 2032 2020 33fa 8ec9 bcd1
0000c60 7bf8 c18e 78bd c500 0076 561e 5516 22bf
0000c70 8905 007e 4e89 b102 fc0b a4f3 d98e 00bd
0000c80 c67c fe45 8b0f 1846 4588 38f9 404e 257d
0000c90 c18b bb99 0700 97e8 7200 831a 3aeb a166
0000ca0 7c1c 3b66 8a07 fc57 0675 ca80 8802 0256
0000cb0 c380 7310 bfed 0002 7e83 0016 4575 468b
0000cc0 8b1c 1e56 03b9 4900 7540 4201 00bb e87e
0000cd0 005f 2673 f8b0 744f 8b1d 3246 d233 03b9
0000ce0 3b00 77c8 8b1e 0e76 ce3b 1773 f12b 4603
0000cf0 131c 1e56 d1eb 0b73 27eb 7e83 002a 0377
0000d00 fde9 be02 7d7e 98ac f003 84ac 74c0 3c17
0000d10 74ff b409 bb0e 0007 10cd eeeb 81be eb7d
0000d20 bee5 7d7f e0eb cd98 5e16 661f 048f 19cd
0000d30 5641 6a66 5200 0650 6a53 6a01 8b10 60f4
0000d40 7e80 0e02 0475 42b4 1deb 9291 d233 76f7
0000d50 9118 76f7 4218 ca87 76f7 8a1a 8af2 c0e8
0000d60 02cc cc0a 01b8 8a02 4056 13cd 8d61 1064
0000d70 725e 400a 0175 0342 0b5e 7549 c3b4 1803
0000d80 2701 0a0d 6e49 6176 696c 2064 7973 7473
0000d90 6d65 6420 7369 ff6b 0a0d 6944 6b73 4920
0000da0 4f2f 6520 7272 726f 0dff 520a 7065 616c
0000db0 6563 7420 6568 6420 7369 2c6b 6120 646e
0000dc0 7420 6568 206e 7270 7365 2073 6e61 2079
0000dd0 656b 0d79 000a 0000 4f49 2020 2020 2020
0000de0 5953 4d53 4453 534f 2020 5320 5359 017e
0000df0 5700 4e49 4f42 544f 5320 5359 0000 aa55
0000e00 5252 4161 0000 0000 0000 0000 0000 0000
0000e10 0000 0000 0000 0000 0000 0000 0000 0000
*
0000fe0 0000 0000 7272 6141 ffff ffff 0002 0000
0000ff0 0000 0000 0000 0000 0000 0000 0000 aa55
0001000

Comment 13 Stephen Tweedie 2002-02-22 12:14:22 EST
I have no idea _how_ this got corrupt, but the info block for the FAT filesystem
is weird.

The FAT info is perfectly intact.  It is followed by the FAT32 info (because
it's a FAT32 filesystem), and *that* is toast.  Some bits of it are recognisable
as ascii spaces, other parts are unrecognisable junk.

However, the backup FAT info is perfectly intact.  The FAT descriptor is the
same in both the primary and the backup, but the difference is that in the
backup, the FAT32 stuff also looks perfectly sane.

Note, *ONLY* the FAT32 bytes are corrupt in the FAT header.  The rest is
completely intact.

Please save a backup copy of your entire FAT header first, to be safe, with

  dd if=/dev/hdb4 bs=4k count=1 of=/root/hdb4.header.BACKUP

then, I *think* you will be able to rescue the partition with

  dd if=/dev/hdb4 bs=512 count=1 of=/dev/hdb4 skip=6 conv=notrunc

which will copy one 512-byte block from /dev/hdb4 to /dev/hdb4, starting reading
at block 6 and writing at block 0.  Running that on a local copy of your
partition header has the desired effect.

Good luck.
Comment 14 ralph hinton 2002-02-27 21:59:32 EST
EXCELLENT that worked on the actual disk, so you can close this off
 (unless you want to try to find out what went wrong).
  Thanks for your help - really appreciated it. I didn't know what to do.
               Cheers,  Ralph.
Comment 15 Stephen Tweedie 2002-02-28 06:37:54 EST
Just before we close this for good, do you have any clues as to why this might
have happened in the first place?  What were you doing on the system before you
first noticed the problem?
Comment 16 ralph hinton 2002-03-04 20:36:00 EST
The possibilities for what went wrong are either the Linux upgrade to 
version 5.1 or the oracle data-base on that partition, which is not woorking.
A problem with writing backups, or a general Windows problem, on that disk seem 
unlikely.
That is all I used that partition for, does that help shed light?.

Note You need to log in before you can comment on or make changes to this bug.