From owner-freebsd-questions Tue Mar 21 7: 6:45 2000 Delivered-To: freebsd-questions@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id 0020537B955 for ; Tue, 21 Mar 2000 07:06:38 -0800 (PST) (envelope-from fred@veriohosting.com) Received: by gatekeeper.veriohosting.com; Tue, 21 Mar 2000 08:06:37 -0700 (MST) Received: from unknown(192.168.1.7) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma008156; Tue, 21 Mar 00 08:06:32 -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 IAA44713 for ; Tue, 21 Mar 2000 08:06:32 -0700 (MST) Date: Tue, 21 Mar 2000 09:10:53 -0700 (MST) From: Fred Clift X-Sender: fred@vespa.orem.iserver.com To: freebsd-questions@freebsd.org Subject: 'truly' or 'dangerously' dedicated enhancement request? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yeah -- some bioses choke over 'dangerously dedicated' disks. The one I just looked at (and another that I've heard about) seem to just want to verify that the partition table and size of the active partition are valid. I'm using a MB with a phoenix bios that hangs at boot time when boot1 is in the mbr. Note that this is when boot1 is in sector zero of _any_ disk in the system, not just in the boot disk. It doesn't even get to where it is loaded before the machine hangs. (Yes, a bios that wont boot the primary boot device because of a messed up partition table in a non-boot device should be considered broken, but I digress). So I've found that if I fdisk the 'broken' disks (ie changing the partition table found in boot1 in sector 0 in a dedicated installation) to have values that are more correct, then the bios doesn't choke and the disks boot fine. All I ended up having to do was to check my disklabel, note the number of sectors and put that in in place of the 'size' paramater (by default, 50000), and let fdisk recompute the CHS numbers automagically. I can't guess what problems other bioses have with dedicated installations, but at least for this one, just fixing the partition table with 'sane' numbers was sufficient to make the machine work. To be honest, I dont know exactly what magic the bios thinks it is trying to do but when I put the number of sectors in as reported by disklabel as the number of sectors in partition 4 (the fake one stored in boot1 in sector 0) things suddenly started working. So, how about an option to disklabel, or perhaps something like fdisk -e that actually puts valid data in the boot1 partition table for 'dedicated' installs? I certainly wouldn't hurt to make boot1 partition table contain valid data, and it might make 'truly' or 'dangerously' dedicated installs work better for a wider variety of people. -- Fred Clift - fred@veriohosting.com -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message