From owner-freebsd-stable Fri Nov 24 8:52:44 2000 Delivered-To: freebsd-stable@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id D6F8637B4CF; Fri, 24 Nov 2000 08:52:37 -0800 (PST) Received: by gatekeeper.veriohosting.com; Fri, 24 Nov 2000 09:52:36 -0700 (MST) Received: from unknown(192.168.1.7) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma022703; Fri, 24 Nov 00 09:52:31 -0700 Received: from vespa.orem.iserver.com (vespa.orem.iserver.com [192.168.1.144]) by orca.orem.veriohosting.com [Verio Web Hosting, Inc. 801.437.0200] (8.8.8) id JAA17013; Fri, 24 Nov 2000 09:52:31 -0700 (MST) Date: Fri, 24 Nov 2000 10:11:20 -0700 (MST) From: Fred Clift X-Sender: fred@vespa.orem.iserver.com To: Terry Lambert Cc: Fred Clift , opentrax@email.com, stable@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: Dedicated disks (was: Dangerously Dedicated) In-Reply-To: <200011240110.SAA05483@usr06.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 24 Nov 2000, Terry Lambert wrote: > > > > o An increasing number of BIOS will divide by 0 when they > > again, 30 seconds in fdisk fixes this > > This can be fixed, but hasn't been. All I do is use disklabel to tell me the number of sectors, take that value and stuff it into the 'length' field while changing the slice table with fdisk -u and then let fdisk automatically round to the nearest cylinder boundary. A couple of snippets from my custom install program (at this point I already know how many sectors/unit there are, from a previous disklable call...) char fdiskcommand[] = "/sbin/fdisk -u da%d < /tmp/fdisk.in"; if ((fo = fopen("/tmp/fdisk.in","w")) == NULL) fprintf(fo, "\n\n\n\ny\n\n\n%d\n\ny\n\ny\n",sectorsperunit); sprintf(buff,fdiskcommand,device); Note that this has been slightly altered from it's original form for brevity and that if there are mistakes in it, it's because I too heavily edited. Essentially, I just run fdisk -u and update the disklabel with the right value. It has nothing to do with 'fixing' fdisk, but rather, with understanding that hey, my hardware does want a valid slice table, so why not give it one... (I'd need to go back and check but I think this updates the geometry info to more valid settings too...) > > > > > > o The FreeBSD fake DOS partition table does not pass a > > > > number BIOS-based self-consistency checks (it needs to ... > > again, 30 seconds in fdisk fixes this > I don't agree with this one. There is a checksum that is not > valid against the FreeBSD created partition tablem regardless > of what you do with FreeBSD fdisk. Are you saying that there are bioses out there that store the checksum of the winX MBR and get grumpy if they dont find it? I guess it's theoretically possible, but I'd not belive it till I saw it... The same machine wouldn't run dr-dos, linux, os/2, beos, etc. I might understand a bios being confused about boot1 only using slice 4, or perhaps being confused that the MBR is _included_ in the only or active partition. It probably wouldn't be that big of a deal to switch to using slice 1, but I dont know if this would break other things. I personally haven't seen bioses that are confused by having a slice that contains the mbr, but that doesn't mean they dont exist. Just not on the hardware I play with... And again, it's usually pretty easy to tell if your hadware dislikes dedicated installs. If it works the first time, the system isn't going to mysteriously stop working because of it later... > > I have yet to see a reasonable justification as to why a DOS > partition table and MBR (or boot manager) causes any problems > that can't be overcome. So, aparently asthetics mean nothing to you? I personally get embarrassed by ugly code and kludges. I have yet to see you 'refute', as you say later in your mail, my arguments in another posting for the asthetic reasons that people might have. Aparently the comleliness of the solution to a problem provides no 'reasonable justification' to you. And really, I guess it's no big deal. I dont have a neatness fetish for my own code, but I know people who do. However, peoples sense of 'doing things the right way' is a valid reason to keep support for this in the code... I have no problem with making this less encouraged for newbies to try, for making it a bit harder to do inintial installs in dedicated mode. What I do have a problem with are people (not necessarily you, I'm to lazy to go back and re-read the whole thread again...) that seem to want to remove the ability to have this work even if you know what you're doing... I have already agreed that 'hey -- if you want to guarantee compatablity, then just do it with a valid slice table'. Howver,I disagree with people who say that that can't be a dedicated install. A dedicated install with a valid slice table is probably about as compatable with any random piece of hardware you pick up as a 'normal' install. Dont take me too seriously though... :) I'm pretty much a nobody in the FreeBSd world - just a very satisfied user who has fiddled with the part of the system a lot. Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message