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

[randux@xxxxxxxxxxx]

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.
> > > :
> > > :Thanks,
> > > :Rand
> > >
> > >     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.
> > >
> > >                     -Matt
> > >                     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.