I have a 1.5TB internal disk on my server. I partitioned this with fdisk, and CentOS-5.6 runs perfectly on it. But fdisk gives a very strange report.
Here is the perfectly normal response to mount: ----------------------------- /dev/sdb10 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sdb2 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw) /dev/sdb5 on /home type ext3 (rw) /dev/sdb6 on /common type ext3 (rw) /dev/sdb7 on /BackupPC type ext3 (rw) /dev/sdb8 on /Photos type ext3 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) ----------------------------- and here is the response to "sudo fdisk /dev/sdb" ----------------------------- Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
This doesn't look like a partition table Probably you selected the wrong device.
Device Boot Start End Blocks Id System /dev/sdb1 ? 188019 188051 253319 e4 SpeedStor Partition 1 does not end on cylinder boundary. /dev/sdb2 ? 62656 186401 993984023 98 Unknown Partition 2 does not end on cylinder boundary. /dev/sdb3 ? 105611 225119 959953209 7d Unknown Partition 3 does not end on cylinder boundary. /dev/sdb4 ? 347 865 4161536 0 Empty Partition 4 does not end on cylinder boundary.
Partition table entries are not in disk order -----------------------------
Does fdisk not like large disks?
Hi Timothy,
Does fdisk not like large disks?
fdisk cannot handle drives >2TB (you can use parted to work around this, using gpt label rather than msdos). However, this should not affect you, as your drive is well within fdisk's limits. Do you have any idea why the system type is Speedstor instead of 'Linux' ? That would slightly concern me, though you could always change it in fdisk - make a full backup first, of course.
Timothy Murphy wrote:
I have a 1.5TB internal disk on my server. I partitioned this with fdisk, and CentOS-5.6 runs perfectly on it. But fdisk gives a very strange report.
Here is the perfectly normal response to mount:
/dev/sdb10 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sdb2 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw) /dev/sdb5 on /home type ext3 (rw) /dev/sdb6 on /common type ext3 (rw) /dev/sdb7 on /BackupPC type ext3 (rw) /dev/sdb8 on /Photos type ext3 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw)
and here is the response to "sudo fdisk /dev/sdb"
Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
This doesn't look like a partition table Probably you selected the wrong device.
Device Boot Start End Blocks Id System /dev/sdb1 ? 188019 188051 253319 e4 SpeedStor Partition 1 does not end on cylinder boundary. /dev/sdb2 ? 62656 186401 993984023 98 Unknown Partition 2 does not end on cylinder boundary. /dev/sdb3 ? 105611 225119 959953209 7d Unknown Partition 3 does not end on cylinder boundary. /dev/sdb4 ? 347 865 4161536 0 Empty Partition 4 does not end on cylinder boundary.
Partition table entries are not in disk order
Could it be that the partition table has become corrupt (e.g. overwritten)?
If this has been the case, then you need to find a tool that can attempt to recover the partition table - see http://tldp.org/HOWTO/Partition/recovering.html
James Pearson
James Pearson wrote:
here is the response to "sudo fdisk /dev/sdb"
Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
This doesn't look like a partition table Probably you selected the wrong device.
Device Boot Start End Blocks Id System /dev/sdb1 ? 188019 188051 253319 e4 SpeedStor Partition 1 does not end on cylinder boundary. /dev/sdb2 ? 62656 186401 993984023 98 Unknown Partition 2 does not end on cylinder boundary. /dev/sdb3 ? 105611 225119 959953209 7d Unknown Partition 3 does not end on cylinder boundary. /dev/sdb4 ? 347 865 4161536 0 Empty Partition 4 does not end on cylinder boundary.
Partition table entries are not in disk order
Could it be that the partition table has become corrupt (e.g. overwritten)?
But everything seems to be working perfectly; is that possible if the partition table is corrupt?
If this has been the case, then you need to find a tool that can attempt to recover the partition table - see http://tldp.org/HOWTO/Partition/recovering.html
Thanks, I'll study that.
Timothy Murphy wrote:
Could it be that the partition table has become corrupt (e.g. overwritten)?
But everything seems to be working perfectly; is that possible if the partition table is corrupt?
Yes - the partition table may have been fine when the various file systems were mounted - which could be why all looks OK now. However, if you were to reboot, you may have problems ...
Make sure you have backups before doing any changes to the partition table.
James Pearson
James Pearson wrote:
Could it be that the partition table has become corrupt (e.g. overwritten)?
But everything seems to be working perfectly; is that possible if the partition table is corrupt?
Yes - the partition table may have been fine when the various file systems were mounted - which could be why all looks OK now. However, if you were to reboot, you may have problems ...
Make sure you have backups before doing any changes to the partition table.
Yes, I think I backup everything important every night, with BackupPC.
What is strange is that I don't recall any episode that might have corrupted the partition table. I run smartd on this machine; and according to "sudo smartctl -a /dev/sdb" everything seems fine with this drive, no errors reported. (I'm a bit wary of running "smartctl -t" as I'm not in the same country as the machine at the moment.)
On 04/26/2011 06:56 PM, Timothy Murphy wrote:
James Pearson wrote:
Could it be that the partition table has become corrupt (e.g. overwritten)?
But everything seems to be working perfectly; is that possible if the partition table is corrupt?
Yes - the partition table may have been fine when the various file systems were mounted - which could be why all looks OK now. However, if you were to reboot, you may have problems ...
Make sure you have backups before doing any changes to the partition table.
Yes, I think I backup everything important every night, with BackupPC.
What is strange is that I don't recall any episode that might have corrupted the partition table. I run smartd on this machine; and according to "sudo smartctl -a /dev/sdb" everything seems fine with this drive, no errors reported. (I'm a bit wary of running "smartctl -t" as I'm not in the same country as the machine at the moment.)
It might be instructive to see what is actually in that sector. Try:
dd if=/dev/sdb count=1 | od -tx1z
Robert Nichols wrote:
Could it be that the partition table has become corrupt (e.g. overwritten)?
What is strange is that I don't recall any episode that might have corrupted the partition table. I run smartd on this machine; and according to "sudo smartctl -a /dev/sdb" everything seems fine with this drive, no errors reported. (I'm a bit wary of running "smartctl -t" as I'm not in the same country as the machine at the moment.)
It might be instructive to see what is actually in that sector. Try:
dd if=/dev/sdb count=1 | od -tx1z
Thanks, I give the output below.
I guess I must have run "mkdosfs /dev/sdb" at some point rather than "mkdosfs /dev/sdb1", as I usually try to install Windows on the first partition.
This would have been about a year ago; It's surprising it's been running fine ever since. I hope there isn't a power outage in the next week, before I get home ...
Is there a safe way of recovering the partition table? I have a vague idea that copies are kept at various places on the disk?
------------------------------------ 0000000 eb 58 90 6d 6b 64 6f 73 66 73 00 00 02 04 01 00 >.X.mkdosfs......< 0000020 02 00 02 00 60 f8 18 00 20 00 40 00 00 00 00 00 >....`... .@.....< 0000040 00 00 00 00 00 00 29 9d 29 d6 4b 20 20 20 20 20 >......).).K < 0000060 20 20 20 20 20 20 46 41 54 31 36 20 20 20 0e 1f > FAT16 ..< 0000100 be 5b 7c ac 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 >.[|.".t.V.......< 0000120 5e eb f0 32 e4 cd 16 cd 19 eb fa fc 31 c0 8e d0 >^..2........1...< 0000140 bc b4 7b 8e c0 b9 08 00 89 e7 f3 a5 8e d8 bb 78 >..{............x< 0000160 00 0f b4 37 0f a0 56 88 16 a5 4b 20 d2 78 15 b1 >...7..V...K .x..< 0000200 06 89 3f 89 47 02 64 f3 a5 8a 0e 18 7c 88 4d f8 >..?.G.d.....|.M.< 0000220 cd 13 eb 27 f6 45 f0 7f 75 08 66 8b 45 f8 66 a3 >...'.E..u.f.E.f.< 0000240 1c 7c b4 08 cd 13 72 13 20 e4 75 0f c1 ea 08 42 >.|....r. .u....B< 0000260 89 16 1a 7c 83 e1 3f 89 0e 18 7c fb bb aa 55 b4 >...|..?...|...U.< 0000300 41 8a 16 a5 4b cd 13 72 10 81 fb 55 aa 75 0a f6 >A...K..r...U.u..< 0000320 c1 01 74 05 c6 06 ff 7c 00 66 a1 f8 7d bb 00 7e >..t....|.f..}..~< 0000340 e8 10 00 66 81 3e 24 7e e8 51 a3 7d 0f 85 c3 00 >...f.>$~.Q.}....< 0000360 e9 3d 02 bd 01 00 66 03 06 1c 7c 66 31 d2 eb 4f >.=....f...|f1..O< 0000400 55 e8 d5 00 66 0f b7 fd b9 10 00 66 52 66 50 06 >U...f......fRfP.< 0000420 53 57 6a 10 89 e6 66 60 8a 16 a5 4b 1e 16 1f b4 >SWj...f`...K....< 0000440 42 cd 13 1f 66 61 8d 64 10 72 10 5d 66 01 f8 29 >B...fa.d.r.]f..)< 0000460 fd c1 e7 09 01 fb 21 ed 75 c6 c3 66 60 31 c0 8a >......!.u..f`1..< 0000500 16 a5 4b cd 13 66 61 e2 c2 c6 06 ff 7c 4f 5d 66 >..K..fa.....|O]f< 0000520 52 66 50 55 53 66 0f b7 36 18 7c 66 0f b7 3e 1a >RfPUSf..6.|f..>.< 0000540 7c 66 f7 f6 31 c9 87 ca 66 f7 f7 e8 6b 00 29 ce >|f..1...f...k.).< 0000560 39 f5 76 02 89 f5 c0 e4 06 41 08 e1 88 c5 88 d6 >9.v......A......< 0000600 8a 16 a5 4b 95 b4 02 bd 10 00 66 60 cd 13 66 61 >...K......f`..fa< 0000620 72 17 66 0f b6 c8 c1 e0 09 5b 01 c3 5d 66 58 66 >r.f......[..]fXf< 0000640 5a 66 01 c8 29 cd 75 a7 c3 4d 75 de 95 d1 2e fc >Zf..).u..Mu.....< 0000660 7d 75 df 31 f6 8e d6 bc b0 7b 8e de 66 8f 06 78 >}u.1.....{..f..x< 0000700 00 be e4 7d ac 20 c0 74 09 b4 0e bb 07 00 cd 10 >...}. .t........< 0000720 eb f2 98 cd 16 cd 19 eb fe 3b 2e fc 7d 76 04 8b >.........;..}v..< 0000740 2e fc 7d c3 42 6f 6f 74 20 65 72 72 6f 72 0d 0a >..}.Boot error..< 0000760 00 00 00 00 00 00 00 00 55 00 00 00 7f 00 55 aa >........U.....U.< 0001000 ------------------------------------
Timothy Murphy wrote:
I guess I must have run "mkdosfs /dev/sdb" at some point rather than "mkdosfs /dev/sdb1", as I usually try to install Windows on the first partition.
This would have been about a year ago; It's surprising it's been running fine ever since. I hope there isn't a power outage in the next week, before I get home ...
Is there a safe way of recovering the partition table? I have a vague idea that copies are kept at various places on the disk?
AFAIK, there is only one copy at the start of the disk - however what does /proc/partitions contain?
This may well have the details of the partitions and sizes when the machine was booted - it this is the case, take a copy of this info - which you can then use to manually re-create the partition table using fdisk
James Pearson
James Pearson wrote:
Is there a safe way of recovering the partition table? I have a vague idea that copies are kept at various places on the disk?
AFAIK, there is only one copy at the start of the disk - however what does /proc/partitions contain?
This may well have the details of the partitions and sizes when the machine was booted - it this is the case, take a copy of this info - which you can then use to manually re-create the partition table using fdisk
Thanks very much for that; /proc/partitions does indeed seem to contain correct information, so all will not be lost if there is a power outage tomorrow: ------------------------------------ [tim@helen ~]$ cat /proc/partitions major minor #blocks name
8 0 78125000 sda 8 1 30716248 sda1 8 2 104422 sda2 8 3 3911827 sda3 8 4 1 sda4 8 5 29302528 sda5 8 6 14088973 sda6 8 16 1465138584 sdb 8 17 61440561 sdb1 8 18 9775552 sdb2 8 19 9775552 sdb3 8 20 1 sdb4 8 21 97667136 sdb5 8 22 97667136 sdb6 8 23 244147806 sdb7 8 24 146488671 sdb8 8 25 97667136 sdb9 8 26 97667136 sdb10 8 27 97667136 sdb11 ------------------------------------
On 04/27/2011 07:26 AM, Timothy Murphy wrote:
James Pearson wrote:
Is there a safe way of recovering the partition table? I have a vague idea that copies are kept at various places on the disk?
AFAIK, there is only one copy at the start of the disk - however what does /proc/partitions contain?
This may well have the details of the partitions and sizes when the machine was booted - it this is the case, take a copy of this info - which you can then use to manually re-create the partition table using fdisk
Thanks very much for that; /proc/partitions does indeed seem to contain correct information, so all will not be lost if there is a power outage tomorrow:
It most certainly _will_ be lost. The "files" you see in /proc are just windows into various kernel data structures. The /proc file system does not exist anywhere on disk.
Make a paper copy of those numbers, and don't lose it. You will need to be very careful to re-create the partitions exactly as they were or risk losing data. Each logical partition within the extended partition begins with a secondary partition table, and if those get written in the wrong places they could overwrite something important. When you create the partitions with fdisk, you will have to play around with numbers until you get a listing with block counts that exactly match those numbers (except for the size of sdb4, the extended partition, which the kernel always reports as "1"). Only then can you safely write out the new table.
It would make life so much easier if fdisk would simply accept those same numbers as Kilobytes, but alas it keeps trying to round up to the next "cylinder" boundary, so you have to fiddle a bit to get it right. Yes, fdisk is a very old, crufty, and slightly buggy program. Newer programs are either much too "user-friendly" (e.g., cfdisk "enter partition size in decimal magabytes"), or way too dangerous (e.g., parted, which writes each change out to disk immediately without giving you a chance to verify what it just did).
Robert Nichols wrote:
On 04/27/2011 07:26 AM, Timothy Murphy wrote:
Thanks very much for that; /proc/partitions does indeed seem to contain correct information, so all will not be lost if there is a power outage tomorrow:
It most certainly _will_ be lost. The "files" you see in /proc are just windows into various kernel data structures. The /proc file system does not exist anywhere on disk.
Make a paper copy of those numbers, and don't lose it. You will need to
by posting the numbers to this list, the OP has effectively made the safest possible backup ;-)
Nicolas Thierry-Mieg wrote:
Robert Nichols wrote:
On 04/27/2011 07:26 AM, Timothy Murphy wrote:
Thanks very much for that; /proc/partitions does indeed seem to contain correct information, so all will not be lost if there is a power outage tomorrow:
It most certainly _will_ be lost. The "files" you see in /proc are just windows into various kernel data structures. The /proc file system does not exist anywhere on disk.
Make a paper copy of those numbers, and don't lose it. You will need to
by posting the numbers to this list, the OP has effectively made the safest possible backup ;-)
He's, ummm, cloud sourced it? <g>
mark
On Wed, Apr 27, 2011 at 10:18:28AM -0500, Robert Nichols wrote:
On 04/27/2011 07:26 AM, Timothy Murphy wrote:
James Pearson wrote:
Is there a safe way of recovering the partition table? I have a vague idea that copies are kept at various places on the disk?
AFAIK, there is only one copy at the start of the disk - however what does /proc/partitions contain?
This may well have the details of the partitions and sizes when the machine was booted - it this is the case, take a copy of this info - which you can then use to manually re-create the partition table using fdisk
Thanks very much for that; /proc/partitions does indeed seem to contain correct information, so all will not be lost if there is a power outage tomorrow:
It most certainly _will_ be lost. The "files" you see in /proc are just windows into various kernel data structures. The /proc file system does not exist anywhere on disk.
Make a paper copy of those numbers, and don't lose it. You will need to be very careful to re-create the partitions exactly as they were or risk losing data. Each logical partition within the extended partition begins with a secondary partition table, and if those get written in the wrong places they could overwrite something important. When you create the partitions with fdisk, you will have to play around with numbers until you get a listing with block counts that exactly match those numbers (except for the size of sdb4, the extended partition, which the kernel always reports as "1"). Only then can you safely write out the new table.
It would make life so much easier if fdisk would simply accept those same numbers as Kilobytes, but alas it keeps trying to round up to the next "cylinder" boundary, so you have to fiddle a bit to get it right. Yes, fdisk is a very old, crufty, and slightly buggy program. Newer programs are either much too "user-friendly" (e.g., cfdisk "enter partition size in decimal magabytes"), or way too dangerous (e.g., parted, which writes each change out to disk immediately without giving you a chance to verify what it just did).
sfdisk has "dump" mode, and it can also import old dump to new disk.
-- Pasi
On 04/27/2011 01:15 PM, Pasi Kärkkäinen wrote:
On Wed, Apr 27, 2011 at 10:18:28AM -0500, Robert Nichols wrote:
It would make life so much easier if fdisk would simply accept those same numbers as Kilobytes, but alas it keeps trying to round up to the next "cylinder" boundary, so you have to fiddle a bit to get it right. Yes, fdisk is a very old, crufty, and slightly buggy program. Newer programs are either much too "user-friendly" (e.g., cfdisk "enter partition size in decimal magabytes"), or way too dangerous (e.g., parted, which writes each change out to disk immediately without giving you a chance to verify what it just did).
sfdisk has "dump" mode, and it can also import old dump to new disk.
That dump mode doesn't help if the partition table is currently munged, and sfdisk is extraordinarily unforgiving of the tiniest mistake in human-generated input.
Robert Nichols wrote:
sfdisk has "dump" mode, and it can also import old dump to new disk.
That dump mode doesn't help if the partition table is currently munged, and sfdisk is extraordinarily unforgiving of the tiniest mistake in human-generated input.
But it seems I could generate correct input for sfdisk from the entries in /proc/partitions ?
But I notice "man sfdisk" has a warning against use with large partitions, which it defines as > 8GB. Hopefully this no longer applies?
On 04/27/2011 07:08 PM, Timothy Murphy wrote:
Robert Nichols wrote:
sfdisk has "dump" mode, and it can also import old dump to new disk.
That dump mode doesn't help if the partition table is currently munged, and sfdisk is extraordinarily unforgiving of the tiniest mistake in human-generated input.
But it seems I could generate correct input for sfdisk from the entries in /proc/partitions ?
But I notice "man sfdisk" has a warning against use with large partitions, which it defines as> 8GB. Hopefully this no longer applies?
That warning was inserted in July, 2005, and there hasn't been much change to sfdisk since. On a 64-bit system, at least, it seems to work OK on a 1 Terabyte disk where I just successfully copied the partitioning from another disk of that same size.
Figuring out the exact numbers to put into that hand-made dump file is not quite as simple as it seems, and sfdisk isn't known for doing much in the way of validating what you feed it. I would advise trying your hand at re-creating the partitioning for some spare disk first.
Actually, if it were my drive I would just re-create the 4 primary partitions using whatever tool was handy, but giving that extended partition a "normal" type instead. Once I had the primary partitions looking right, then I'd go in with a hex editor and change the type code to "5" for that partition. Listing the partition table again with fdisk should now show that everything is back. (It's very unlikely that any of those secondary partition tables got overwritten when you essentially turned the whole disk into one giant DOS file system.)
Robert Nichols wrote:
Actually, if it were my drive I would just re-create the 4 primary partitions using whatever tool was handy, but giving that extended partition a "normal" type instead. Once I had the primary partitions looking right, then I'd go in with a hex editor and change the type code to "5" for that partition. Listing the partition table again with fdisk should now show that everything is back. (It's very unlikely that any of those secondary partition tables got overwritten when you essentially turned the whole disk into one giant DOS file system.)
Thanks. I think I'd better wait until I have acquired a large external drive, and backed up everything!
But re your method, couldn't I just use fdisk to change the type of sdb4?
On 04/28/2011 04:06 AM, Timothy Murphy wrote:
Robert Nichols wrote:
Actually, if it were my drive I would just re-create the 4 primary partitions using whatever tool was handy, but giving that extended partition a "normal" type instead. Once I had the primary partitions looking right, then I'd go in with a hex editor and change the type code to "5" for that partition. Listing the partition table again with fdisk should now show that everything is back. (It's very unlikely that any of those secondary partition tables got overwritten when you essentially turned the whole disk into one giant DOS file system.)
Thanks. I think I'd better wait until I have acquired a large external drive, and backed up everything!
But re your method, couldn't I just use fdisk to change the type of sdb4?
No, you can't change a normal partition to one of the "extended" types or change an extended partition to a normal one. Making either of those changes radically alters the way that portion of the disk is viewed, and I don't know of any partitioning tool that is written to handle that. In particular, creating an extended partition implies initializing the secondary partition table at the start of that new partition, and that might or might not be what you intended if you changed a normal type to an extended one.
-
Christopher J. Buckley -
James Pearson -
m.roth＠5-cent.us -
Nicolas Thierry-Mieg -
Pasi Kärkkäinen -
Robert Nichols -
Timothy Murphy