DragonFly bugs List (threaded) for 2007-03
DragonFly BSD
DragonFly bugs List (threaded) for 2007-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Installer: no option to set geometry/corrupts partition table

From: randux@xxxxxxxxxxx
Date: Mon, 05 Mar 2007 05:04:08 +0200

walt wrote:
randux@noreply.org wrote:
Matthew Dillon wrote:
:Hi guys,
: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
    CHS numbers.

Matthew Dillon <dillon@backplane.com>
Hi Matt,

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: http://www.dewassoc.com/kbase/hard_drives/lba.htm

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.

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]