'fdisk' is quite broken for BSD disklables. On a disk with a geometry, as printed by 's' request from fdisk: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 119150 asking for 500M partition (+500M) ends up with a partition with '64' in a column 'size'. This is seen by DiskDruid as 31 MBytes (roughly right). Other similar requests end up with equally funny numbers. The same breakage shows both in an installed fdisk and in fdisk used by anaconda. An 'fdisk' version which I mailed recently to Jeff does not have this problem and +500M means there what it is expected. Michal michal
verified in test lab (seems to be controller specific ...) ... thanks for your report!
Maybe controller specific but I have some doubts. The version of 'fdisk' which I mailed to jbj, and which I am using in a "real life", does not sport this bug no matter which controller - as far as I can tell. I will not quarrel as I did NOT pinpoint the real cause. :-)
Could you please attach the patch to this bug?
I do not know what is the bug in your current sources, in particularly in what is used by anaconda, but on 9 Oct 2000 Jeff Johnson <jbj> got from me source rpms for 'fdisk' which I am currently using (and also for 'bdsfdisk' which is a scriptable variant, like sfdisk but for BSD type labels) which does not sport this bug. These tools are for a while in quite heavy everyday use on various Alpha platforms by Hard Data so I have a pretty high level of confidence that they behave mostly sane.
I *think* this is all resolved now,.. (almost a year later but still...)