From owner-freebsd-questions Fri Jul 14 14:11:37 2000 Delivered-To: freebsd-questions@freebsd.org Received: from mx.emailqueue.net (mx0.emailqueue.net [209.75.5.2]) by hub.freebsd.org (Postfix) with ESMTP id B700E37C643 for ; Fri, 14 Jul 2000 14:11:31 -0700 (PDT) (envelope-from chris@tierranet.com) Received: from mx0.emailqueue.net (209.75.4.15) by mx.emailqueue.net (8.9.3/8.9.3) with SMTP id OAA61310 for ; Fri, 14 Jul 2000 14:11:28 -0700 (PDT) (envelope-from chris@tierranet.com) Received: from zoom.tierranet.com (zoom.tierranet.com [209.75.7.150]) by mail.tierra.net with ESMTP id nH50JMB2 Fri, 14 Jul 2000 14:11:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20000714140031.05787ef8@mail.tierranet.com> X-Sender: chris@mail.tierranet.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 14:12:05 -0700 To: questions@FreeBSD.ORG From: Chris Samaritoni Subject: Re: Anyone resolved "Missing operating system" issue? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 08:39 AM 7/14/2000 -0700, you wrote: >Intel ISP2150 servers (2U case, with the L440GX motherboard+hotswap >stuff) have an adaptec scsi bios built in to the mother board that kind of >chokes on dangerously dedicated disks. At the first reboot, the box >hangs. In fact, if the 'fake' freebsd fdisk partition talbe that gets put >on dangerously dedicated disks (the one with the 50 meg entry) makes the >machine choke if it is on _ANY_ disk in the system, even if other devices >are supposed to be the boot devices (as chosen by bios setting). The bios >sees what purpots to be a valid partition table on sector 0 (last two >bytes AA 55 or 55 AA) and then finds an entry in the fourth partition slot >marked active with enoguh info to make most motherboards boot the disk >fine, but with enough wrong info that the machine totally chokes. I >assume that it is trying to verify that there is some valid filesystem in >the partition or something. > >I did find a workaround for this particular board -- I do an fdisk -u on >the drive after it has been all installed properly. I go to the partition >entry that has the bogus 50 meg freebsd partition and then interactively >change the value for 'size' to be the same size that disklabel shows and >then let it automatically calculate the beginning/ending addresses and >write the partition back. (note that I tried to use the scripting stuff >built into the fdisk command, but getting the same numbers is virtually >impossible because the scripting stuff thinks it knows better than you do >and is in my opinion broken. I end up sending something like > > "\n\n\n\ny\n\n\n%d\n\ny\n\ny\n" ,driveInfo[disk].size > >to the fdisk -u process which gets the job done but is ugly. One of these >days, I'll fix fdisk instead and submit a patch :) > >Then I have a 'dangerously dedicated' but have a 'real' fdisk entry for >the partition. This fools the so-called 'smart bios' into actually >booting the disks... Of course this could be avoided alltogether by not >doing dangerously dedicated disks, but... We have numerous systems running on ISP2150s and others that use the L440GX+ motherboards, and we've never had any problems with them running the SCSI drives in dangerously dedicated mode. As a matter of fact, we've never had a single system ever have a problem running hard drives in dd mode. Maybe this issue has something to do with brand of SCSI drive, all of our drives are Seagate. Just curious, what brand of SCSI drives do you run? Just a thought. Chris Samaritoni chris@tierranet.com ------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message