DragonFly bugs List (threaded) for 2007-03
Re: Installer: no option to set geometry/corrupts partition table
Matthew Dillon wrote:
:I installed the 1.8.0 release from the liveCD and it screwed up my
:partition table. How can I set the drive geometry so that the
installer :will use my c/h/s values instead of the (possibly
incorrect) values said :to be obtained from BIOS?
:I noticed this problem in FreeBSD but it seems to have been mitigated
by :the installer offering a "G" option to set drive geometry around
6.1/6.2 :release, not sure exactly when.
:I posted a question on the users list on Feb. 26 but hearing nothing
:(and wanting to install Dfly 1.8.0 release) I am posting here on
bugs. :Someone with a multiboot setup who doesn't track changes to his
:partition table can suffer loss of data because of this error. It
could :be a relatively serious problem, especially for newbies to
multibooting :as symptoms probably won't appear immediately, it will
be difficult to :diagnose.
Hmm. usually that sort of problem is due to the disk mode in the
BIOS setup not being set to Large or logical block mode. Nobody
has used CHS in a long time, and BIOSes still get confused by faked
There needs to be an option such as FreeBSD (and NetBSD and iirc
OpenBSD) are providing, to set c/h/s for use by the DFly installer. I
don't understand the comment that nobody is using it- all the *BSD show
their view of it and if it doesn't match the partition table (which is
laid out to this day in terms of c/h/s whether it's actual or virtual)
it causes problems...
I'm curious how old your machine is, and how your partition table was
created in the first place.
I have two machines booting about 12 OS between the two of them. This
one is a pIII server box on a Dell motherboard. So far I run OpenBSD,
NetBSD, FreeBSD, and four Slackwares on this box and I'm hoping to add
DFly and Solaris, I haven't been able to install DFly on my newer
(2.2GHz P4) because it (and 1.6.0) fails in init and we weren't able to
get the issue straightened out.
I created the partition table using Linux fdisk, then I preallocate all
the partitions according to which OS I plan to install. I leave three
primaries for *BSD and Solaris flavours and then I allocate extended
partitions as necessary for my Linux systems.
This is a good explanation of why modern machines 'don't use' CHS:
I don't doubt that your partition table got screwed up, but based on
many years of installing/multibooting OS's of many flavors, I'm a
bit skeptical about the CHS thing being responsible for it. Perhaps
there is a different problem which needs attention.
It's tangential that modern machines 'don't use' c/h/s; the issue is
that the partition table is designed around c/h/s values and that's how
space gets allocated. When you use fdisk you can certainly allocate
things in terms of tracks or cyls or megs or what have you, but the
partition table contains c/h/s values and the map is built around this
geometry. There's no other common point of control for multiple OS
coexistence; how else can partition boundaries be respected?
All the other BSDs installers make provisions for preventing this...that
being the case, I don't understand the skepticism or the surprise! It
hardly seems reasonable that all these other variants make a provision
to deal with an issue that is obsolete or irrelevant. Rather, it seems
extremely critical. If I understand correctly that the DFly installer
was taken from the FreeBSD installer, then I am hoping it will be a very
simple matter to add the G option to DFly's installer.
How did you recover from this problem, BTW? Did you edit the bad
partition table by hand, or restore a backup copy, or.....?
I keep records of the partition table, because I multiboot a lot of
systems. Before every installation I check the partition table against
my expectations, and I do the same thing afterwards as a sanity check. I
saw that the DFly installer noted that he was using different values
than I set for c/h/s. I would have stopped him but the opportunity I was
expecting to change the geometry never arrived. Another message was
issued that said that he adjusted the allocation to end on an integral
cylinder boundary- and that's the source of the problem.
After DFly built the filesystems I halted the system, booted my trusty
Slackware system and did an fdisk -l to see what had happened.
The numbers of cylinders, heads, and sectors per track had been changed
(and therefore the sizes of cylinders, which is the crucial part) and
the slice I had preallocated for DFly had changed in size. Luckily, the
next DOS partition was my Linux swap file, which provided enough buffer
that the intrusion by the DFly filesystems wasn't able to reach my other
filesystems on the same drive.
To fix it, I reset the cyl/head/sectors values to what they should be (I
understand these are arbitrary, but all the OS on the drive have to
agree to the same view) and changed the limits on the DFly slice back to
my original even cylinder allocation, and all was well.
It is possible than in many cases the partition table gets built with
geometry that corresponds to the BIOS geometry so if you multiboot on a
system like that you never observe this problem. It could be that Linux
fdisk wants to use 255 heads with 63 sectors/track. (I say this because
I noted in many newsgroup postings the c/h/s on Linux distros had this
geometry.) I don't know how that got decided. Maybe if you fdisk with
one of the BSD variants it's different. The bottom line is that
everybody has to sing the same tune and it doesn't matter what the c/h/s
values are as long as all the OS agree to use those values.
It seems to me that for DFly to be able to peaceably exist with other OS
on the same drive in all circumstances, there needs to be a provision in
the installer, such as is part of the OpenBSD, NetBSD, and FreeBSD
installers, to be able to change DFly's view of the disk geometry to
match the existing partition table.