Bug 59053
Summary: | cannot see one of two windows partitions created with fdisk | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | ralph hinton <ralph.hinton> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED NOTABUG | QA Contact: | Aaron Brown <abrown> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | CC: | sct |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-06-08 00:55:56 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
ralph hinton
2002-01-30 00:35:57 UTC
Can you mount the partition at all? Is there a filesystem on it? What's the output of /proc/partitions? 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 Let me rephrase: what's the *contents* of /proc/partitions? /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. The filesystem would be handled by the kernel, so assigning there. What do you get if you do 'mount -t vfat /dev/hdb4 /misc'? The interesting bit is if the kernel gives any messages when it fails (eg type "dmesg" and check the last few lines) 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. Are you getting anywhere with analysing the data?. 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 # 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): 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. 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 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. 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. 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? 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?. |