PDA

View Full Version : What is wrong with my partition table?



yonatan
02-04-2005, 12:28 PM
Suddenly knoppix is hanging on boot while creating fstab. It used to work fine, but I recently messed with my partitions. What is wrong with my partiion table? I know that the problem is with hda, because I even disabled hdb in the BIOS. Booting from hdb, fdisk and parted show the following about hda:

fdisk:

The number of cylinders for this disk is set to 3649.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/hda: 30.0 GB, 30020272128 bytes
255 heads, 63 sectors/track, 3649 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 727 5839596 b W95 FAT32
/dev/hda2 728 3648 23462932+ f W95 Ext'd (LBA)
/dev/hda5 728 1454 5839596 b W95 FAT32
/dev/hda6 1455 2181 5839596 b W95 FAT32
/dev/hda7 2182 2908 5839596 b W95 FAT32
/dev/hda8 2909 3648 5944018+ b W95 FAT32

parted:
sing /dev/hda
(parted) p
Disk geometry for /dev/hda: 0.000-28629.562 megabytes
Disk label type: msdos
Minor Start End Type Filesystem Flags
1 0.031 5702.761 primary fat32 boot
2 5702.761 28615.781 extended lba
5 5702.792 11405.522 logical fat32
6 11405.553 17108.283 logical fat32
7 17108.314 22811.044 logical fat32
8 22811.076 28615.781 logical fat32


Additional note: Previously, I had deleted /dev/hda8 (which was a FAT partition) and created a Reiser partition. (I also made it bootable, but Windows didn't like that, so I removed the boot flag, and it wasn't necessary anyway for LILO). After encounerting the problem with knoppix creating fstab, I deleted /dev/hda8 again and reverted it to a FAT partition. But there still must be a problem with the partitions.

Thanks,
Yonatan

yonatan
02-06-2005, 09:59 PM
It seems like /dev/hda and /dev/hdb each has its own problems. Any ideas what to do about them?

Here it what sfdisk has to say about /dev/hda:

[root@localhost ~]# sfdisk -V /dev/hda
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Warning: partition 1 does not end at a cylinder boundary
[root@localhost ~]# sfdisk -l /dev/hda

Disk /dev/hda: 58168 cylinders, 16 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Warning: The partition table looks like it was made
for C/H/S=*/255/63 (instead of 58168/16/63).
For this listing I'll assume that geometry.
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/hda1 * 0+ 726 727- 5839596 b W95 FAT32
/dev/hda2 727 3647 2921 23462932+ f W95 Ext'd (LBA)
/dev/hda3 0 - 0 0 0 Empty
/dev/hda4 0 - 0 0 0 Empty
/dev/hda5 727+ 1453 727- 5839596 b W95 FAT32
/dev/hda6 1454+ 2180 727- 5839596 b W95 FAT32
/dev/hda7 2181+ 2907 727- 5839596 b W95 FAT32
/dev/hda8 2908+ 3647 740- 5944018+ b W95 FAT32
start: (c,h,s) expected (1023,254,63) found (1023,1,1)
[root@localhost ~]# sfdisk -l -uS /dev/hda

Disk /dev/hda: 58168 cylinders, 16 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Warning: The partition table looks like it was made
for C/H/S=*/255/63 (instead of 58168/16/63).
For this listing I'll assume that geometry.
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/hda1 * 63 11679254 11679192 b W95 FAT32
/dev/hda2 11679255 58605119 46925865 f W95 Ext'd (LBA)
/dev/hda3 0 - 0 0 Empty
/dev/hda4 0 - 0 0 Empty
/dev/hda5 11679318 23358509 11679192 b W95 FAT32
/dev/hda6 23358573 35037764 11679192 b W95 FAT32
/dev/hda7 35037828 46717019 11679192 b W95 FAT32
/dev/hda8 46717083 58605119 11888037 b W95 FAT32
start: (c,h,s) expected (1023,254,63) found (1023,1,1)


Here it what sfdisk has to say about /dev/hdb:

[root@localhost ~]# sfdisk -V /dev/hdb
end of partition 1 has impossible value for head: 254 (should be in 0-14)
[root@localhost ~]# sfdisk -l /dev/hdb

Disk /dev/hdb: 13228 cylinders, 15 heads, 63 sectors/track
Warning: The partition table looks like it was made
for C/H/S=*/255/63 (instead of 13228/15/63).
For this listing I'll assume that geometry.
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/hdb1 * 0+ 12 13- 104391 83 Linux
/dev/hdb2 95 777 683 5486197+ 83 Linux
/dev/hdb3 13 94 82 658665 82 Linux swap
/dev/hdb4 0 - 0 0 0 Empty

[root@localhost ~]# sfdisk -l -uS /dev/hdb

Disk /dev/hdb: 13228 cylinders, 15 heads, 63 sectors/track
Warning: The partition table looks like it was made
for C/H/S=*/255/63 (instead of 13228/15/63).
For this listing I'll assume that geometry.
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/hdb1 * 63 208844 208782 83 Linux
/dev/hdb2 1526175 12498569 10972395 83 Linux
/dev/hdb3 208845 1526174 1317330 82 Linux swap
/dev/hdb4 0 - 0 0 Empty
[root@localhost ~]#

yonatan
02-08-2005, 07:13 AM
Well I thought I'd share the solution here with everyone. After booting up knoppix with 'nofstab' (in order to get past the hang), I attempted to access hda with sfdisk from a konsole. Guess what? It hung. At this point I realized that the hang had nothing to do with my partition table (though messed up it may be), and that my original assumption was wrong. Then, I remembered having read somewhere that the 'nodma' option helped a user get past the fstab hang. Well -- it worked. Booting up knoppix with the parameters "knoppix nodma" boots me straight into KDE now and mounts all of my partitions.

As to why knoppix used to work with my system without specifying the "nodma" option -- I'm guessing that the default was recently changed between versions. (Currently, I have 3.6 handy. I remember working with 3.3 without any trouble.)

jjmac
02-10-2005, 08:13 PM
Howdy yonatan,

More of an apparent solution than an actual one, i would think. It's not fixed, it's just booting thats all. No dma wont help your performance.

Something strange is going on here though. There is an inconsistency in your table layout.

You can ignore the,

"Warning" about the extended partition not starting on a cylinder boundary message.

Thats just a smurfy which shouldn't be there. At least it should be allowed to be suppressed, via a cli switch. It just generates un-needed concern really.

It stems from the fact that 16 will not divide into 255 evenly. But, as geometrys don't have any particular reality anyway. That is, they are completely imaginary, it dosen't actually matter. Just that different tools will see a different scenario.

16 heads is the "ide-ata" specification, so a specification compliant tool will look for that geometry first, and it will be described in such terms on the disks controller as well.

But a dos partition table will be written in a 255 head base, as dos tools will expect it. And bioses designed to work with dos will be coded to accept a 255 head based geometry.

If your using the 2.6.x kernel series, it's an idea to update all your s/w that deals with the main table, as 2.6.x is now fully "ide-ata" compliant. And some of the older tools will expect the 2.4.x kernels behavour which was to read the table directly, rather than the disks controller, thus returning a 255 head based geometry. I think it wouldn't hurt for the 2.6.x kernel to return the actual table geometry as well. But, it seems to now leave that all up to user space now. Hope they change that thinking in the future, as dos isn't going away very fast :)


What is interesting is the difference between /dev/hda and /dev/hdb


sfdisk is showing the expected output for hda. Describing its' logical sector count in a compliant 16 head base formate. But also reading the actual records for comparision. Seeing the dos 255 head based geometry, and going along with that. With the first partition set as "active"

hdb seems strange though !!!

>>
[root@localhost ~]# sfdisk -V /dev/hdb
end of partition 1 has impossible value for head: 254 (should be in 0-14)
>>

I agree with sfdisk, heads count from zero. It should be showing a 16 head base there, (0 - 15).

But it's showing a "15" head base !!!

I think the "nodma" thing is only working as a side-effect. If left like that, it may cause some further problems down the track. Not to mention having to have dma turned off.

Something is wrong there.

cfdisk has a very neat, readable output, that will show exactly how the table records are coded. In a human readable form. As they are in the table bytes themselves. Both geometry fields and logical sector number fields.

]# cfdisk -P t /dev/hdb

Your first primary should start on head "0" and end on head "254". The others should start on head "1".

I prefer to work from that dump, as it reflects the table records as they actually are, without any rearrangement. If it indeed has a 15 head base on the second disk, it will show in that dump and can be fixed....

By taking the logical counts and manually rewriting the geometries for 255 heads.


You could try first ...

]# sfdisk -d /dev/hdb > table.txt

Edit out ...

Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.

That bit above, then resave the text file. Then do ...

]# sfdisk --no-reread -H255 /dev/hdb < table.txt

Or possibly better ...

]# sfdisk -d /gev/hdb | egrep -v '^(Warning|Dos)' | sfdisk --no-reread -H255 /dev/hdb

The quotes used above are single quotes. Not back ticks.

Please make a copy of your boot-sector to floppy first.

If a tool won't rearrange that geometry on hdb, make sure your bios is set to LBA if available, not auto, and post the,

cfdisk -P -t /dev/hdb

output.

A manual hexedit will fix it, but it would be best to try doing so with a tool first.

The ...

>>
start: (c,h,s) expected (1023,254,63) found (1023,1,1)
>>

message needs looking at as well, i haven't looked at those numbers in any depth as yet. But if you decide to post back the "-P t" output for both disks, it would be easier to see whats actually going on.



jm

yonatan
02-14-2005, 03:51 PM
Hi jm,

Thanks for your interest. Just out of curiosity: If I don't mind wiping out hdb, would it be sufficient to run fdisk, delete all the partitions, and re-partition? Or...should I 1st write a bunch of 0's to the beginning of hdb (or take some other action) in order to force fdisk to realize that there is no valid partition table, and cause it to start from scratch?

Thanks,
Yonatan

jjmac
02-15-2005, 12:24 AM
Howdy yonatan,

I suppose you could wipe it if you really wanted. But if you don't mind doing that, you could also use the oppertunity to experiment with recovering its' geometry state. As it only seems like about 6Mb's or so, i suppose you could tar.gz things up from there and put them on hda temporarily, if needed.

I guess you must be able to get into your Linux on hdb. Which makes sense, as Linuxes loader isn't going to use geometry any way.

Did you try the ...

]# sfdisk -d /dev/hdb | egrep -v '^(Warning|Dos)' | sfdisk --no-re-read -H255 /dev/hdb

command.

That should just take the logical sector fields from the hdb table, and rewrite a 255 head based geometry.

(Just in case ... the verticle bar is just a "pipe" symbol, on the keyboardm top-row, to the right.)

But, if you insist on deleting it...

fdisk will delete the partitions. But cfdisk would probably be clearer in what its doing. Then just re-boot, no more access to hdb. No real need to do much more, except for making sure you can then get into Win.


You mention Lilo in your first post, i guess thats been installed to hda. You probably should run ...

]# lilo -u

before deleting hdb's table. That will restore the original generic loader that existed before Lilo was installed. Then set the main windows partition in hda "active" before the re-boot.

If you installed any loader to hdb, well, you could zero the first sector, but i wouldn't worry about it to much.

Main thing ...

]# lilo -u
]# cfdisk /dev/hda

Set windows partiton active,

]# cfdisk /dev/hdb

Delete all partitions on hdb,

Re-boot.... You won't have hdb any more ... I'd just muck about with hdb first though. Just for the experiment. You may be able to fix the geometry :). When an oportunity comes by ...

You also mentioned "parted", is that what you used to create/delete the reiser partition. There have been issues with that program in the recent past, but only with the 2.6.x kernel series.

The lilo -u cmd should be ok, but, if you look in your /boot directory, you should see a file that looks like "boot.0300". That will be the hda mbr, plus its' table. If you copy that to a floppy you will have a boot disk for hda, as it was before the install.

]# dd if=/boot/boot.0300 of=/dev/fd0 bs=512 count=1

Carefull with "dd", it's a bugger of a command when its' switches get reversed.

Good Luck :)


jm

hakan
02-15-2005, 03:46 PM
Hey there!

I stumbled across this thread as I was trying to solve my own partition table problem, which remind a lot of yonatan's problems. If you don't mind, I'll describe my own situation, and hope both that it may shed some light, and that you can help me solve my problems.

I've got an old-ish computer which had been running dual boot WinXP and Gentoo for quite a while. Now, I ran out of disk space (as you do...) and bought and installed a new drive. I decided to reinstall windows, but managed to just migrate all my linux stuff to a partition to the new drive. I kept the old drive, but repartitioned it, one part NTFS and one part FAT32, the latter so that I had a drive which both OS could write to.

To summarize:
New drive, hda, partitioned in Linux, boot drive for both Win XP and a Linux 2.4 kernel.
Old drive, hdb, partitioned in Windows, containing two partitions, one NTFS, one FAT32

As long as I ran my old trusty 2.4 kernel, things were fine and dandy. All partitions popped up nicely under Linux, and I could write to the FAT32 partition. However, one day I had had enough of all the upgrades I couldn't do because of my old kernel, so I decided to find the latest stable 2.6 series kernel and try it out. Turned out to be 2.6.10 if that makes a difference. I made sure to enable VFAT in the kernel, and didn't change anything in fstab.

Off I went and rebooted, but sure enough the FAT32 drive didn't want to mount anymore. Message given:


mount: wrong fs type, bad option, bad superblock on /dev/hdb2,
or too many mounted file systems

Can still reboot using the old kernel (2.4.25) and if I do, it mounts that partition smoothly.

Did some checks: sfdisk and cfdisk etc, and came up with some pretty scary stuff that I had never seen before. Resembles the stuff yonatan has posted above (hence how I found this thread), and because I changed the kernel, jjmac's discussion on the difference between 2.4 and 2.6 could well be the reason.

So should I follow the advice here and try to rewrite the partition table for /dev/hdb in Linux, or are there any other significant upgrades I could try first? Also, if I do decide to wipe out the drive completely, what's the best way to partition (primary etc...) to avoid this pitfall?

Here's output for my two drives from cfdisk and sfdisk. I decided to output both to show possible differences.

Thanks alot!
Hakan, Melbourne, Australia



# cfdisk -P t /dev/hda
Partition Table for /dev/hda

---Starting--- ----Ending---- Start Number of
# Flags Head Sect Cyl ID Head Sect Cyl Sector Sectors
-- ----- ---- ---- ---- ---- ---- ---- ---- ----------- -----------
1 0x00 1 1 0 0x83 254 63 4 63 80262
2 0x00 0 1 5 0x82 254 63 67 80325 1012095
3 0x80 0 1 68 0x07 254 63 1023 1092420 296656290
4 0x00 254 63 1023 0x83 254 63 1023 297748710 14827995

# cfdisk -P t /dev/hdb
Partition Table for /dev/hdb

---Starting--- ----Ending---- Start Number of
# Flags Head Sect Cyl ID Head Sect Cyl Sector Sectors
-- ----- ---- ---- ---- ---- ---- ---- ---- ----------- -----------
1 0x00 1 1 0 0x07 254 63 1023 63 94205097
2 0x00 254 63 1023 0x0C 254 63 1023 94205160 23053275
3 0x00 0 0 0 0x00 0 0 0 0 0
4 0x00 0 0 0 0x00 0 0 0 0 0

# sfdisk -l

Disk /dev/hda: 19457 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/hda1 0+ 4 5- 40131 83 Linux
/dev/hda2 5 67 63 506047+ 82 Linux swap / Solaris
/dev/hda3 * 68 18533 18466 148328145 7 HPFS/NTFS
/dev/hda4 18534 19456 923 7413997+ 83 Linux

Disk /dev/hdb: 116336 cylinders, 16 heads, 63 sectors/track
Warning: The partition table looks like it was made
for C/H/S=*/255/63 (instead of 116336/16/63).
For this listing I'll assume that geometry.
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/hdb1 0+ 5863 5864- 47102548+ 7 HPFS/NTFS
/dev/hdb2 5864 7298 1435 11526637+ c W95 FAT32 (LBA)
start: (c,h,s) expected (1023,254,63) found (1023,0,1)
/dev/hdb3 0 - 0 0 0 Empty
/dev/hdb4 0 - 0 0 0 Empty

jjmac
02-15-2005, 09:50 PM
Howdy hakan,


>>
As long as I ran my old trusty 2.4 kernel, things were fine and dandy. All partitions popped up nicely under Linux,
.
.
.
Turned out to be 2.6.10 if that makes a difference. I made sure to enable VFAT in the kernel, and didn't change anything in fstab.

Off I went and rebooted, but sure enough the FAT32 drive didn't want to mount anymore. Message given:
[code]
mount: wrong fs type, bad option, bad superblock on /dev/hdb2,
or too many mounted file systems
>>

You probably just didn't configure enough Windows fs support in your 2.6.10 kernel. I can't remember it ever being a default, so it would need to be explicitly provided.


===================================
Your "table" output is fine...
===================================

Bersides, you would have boot problems. otherwise. Not mounting problems :)


Do a search in your .config file in your kernels source directory.

There should be things there like ...

-----------------------------------
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=m
CONFIG_QUOTA=y
CONFIG_QFMT_V1=m
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set


#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=m
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y


#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
CONFIG_NTFS_DEBUG=y
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
.
.
.
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set


#
# Native Language Support
#
CONFIG_NLS=m
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
.
.
.
CONFIG_NLS_ISO8859_1=m
.
.
.
CONFIG_NLS_UTF8=m
-----------------------------------

Native Language support is needed for dos/windows benifit.

Yep ... The 2.4 mounts the partition because it has support for the fs where as, the 2.6 hasn't.

If you configure the new kernel for modular support, don't for get to configure for auto loading as well

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
----------------------------------

NB: The multi references to apparently different Microsoft filesystems is because they are interdependant on each other.


The new kernel will return a 16 base geometry, as per the ide-ata spec, where as earlier kernels would return the geometry as it existed on the table. Usually one based on a 255 head base. It will only effect tools that have been coded/compiled with the older expectation in mind. That was what was behind the Fedoracore2 table scramble fiasco from last year. With an older yersion of "parted" being the offender.

If your going to run 2.6.x it is a good idea to get the very latest packages that contain those tools. Or the latest sources and compile them up manually.

A copy of the whole first sector to floppy, using the above "dd" command can't hurt, as a stand by either :)


yonatan,

Something i forgot to mention before. If you write down your sector and cylinder numbers, from fdisk or cfdisk, then delete all the patitions. Then recreate them using the same numbers, that can also fix a geometry scamble as well.

As long as you don't reformat :)



jm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~

hakan
02-16-2005, 06:10 AM
Brilliant! Won't ask how you figured.

Had a quick look and realised

CONFIG_NLS_CODEPAGE_437

was not set. Would've thought that was default, but perhaps I accidentally unselected it while setting up the new kernel. Anyway, selected that, rebooted and it was all back to business!

Partition table still looks as broken as before, but like stated so many times, geometry doesn't matter anyway.

Still, not sure I would've actually had boot problems if the table was truly broken. It's not on the boot drive, so it probably just wouldn't be available under /dev !(?)

Sorry my topic wasn't related, yonatan. Thanks heaps for the help, jjmac!

Cheers from Downunder,
Hakan

jjmac
02-17-2005, 02:00 AM
Glad to hear it's now ok ...

Iv'e seen discusion on Win mount problems before, that eventually were traced back to a NLS miss-configure. So, just one of many possible reasons ...


>>
Partition table still looks as broken as before, but like stated so many times, geometry doesn't matter anyway.

Still, not sure I would've actually had boot problems if the table was truly broken. It's not on the boot drive, so it probably just wouldn't be available under /dev !(?)
>>

Have a look in ...

/proc/ide/ide0/hda/geometry

and friends.

As said above though, your table isn't broken. The "+" and "-" stuff that gets outputed, especially by sfdisk, can be safely ignored. It just that 16 wont divide evenly into 255 (grin).

Your first primary should always start on "head 1" "sector 1" "cylinder 0" and end on "254 63 whatever".

All others, including a primary typed to hold extended logicals, should start on "head 0". The logicals though, will reflect the first primaries pattern, and start on "head 1".

Once the geometry range runs out you start to get everything starting and ending on the same Head Sector Cylinder columns ...

254 63 1023 ..... 254 63 1023

I agree, it does look messy, but it is normal.


True, the geometry dosn't really matter, at least for a sane OS like Linux. But Windows sure will think it does :roll:

Glad it's fixed :)


jm

One edit at top: