Date: Fri, 27 Oct 2000 14:45:10 -0600 (MDT) From: Fred Clift <fclift@verio.net> To: Robert Nordier <rnordier@nordier.com> Cc: Matt Dillon <dillon@earth.backplane.com>, Terry Lambert <tlambert@primenet.com>, "freebsd-stable@FreeBSD.ORG" <freebsd-stable@FreeBSD.ORG>, hackers@FreeBSD.ORG Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware Message-ID: <Pine.BSF.4.21.0010271443130.20866-100000@vespa.orem.iserver.com> In-Reply-To: <200010271110.NAA26088@siri.nordier.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 27 Oct 2000, Robert Nordier wrote:
>
> Just doing the disklabel -w -r followed by the disklabel -B is creating
> a dangerously dedicated disk, which your BIOS apparently doesn't like.
> (See the first hex dump you did, where boot1 has ended up in the MBR.)
>
> That's why installing boot blocks is messing with the partition table,
> to answer the question you asked elsewhere.
>
> You need to dd and fdisk before the disklabel commands, which will give
> you a standard partition table (at the cost of 63 sectors of disk
> space).
>
So why not just put a valid partition table inside the boot1 that gets put
on sector zero? When boot1 gets dropped onto sector zero, it does hose
the partition table, but there is no reason why a valid one couln't be put
there insead of this broken one:
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 0, size 50000 (24 Meg), flag 80 (active)
beg: cyl 0/ sector 1/ head 0;
end: cyl 1023/ sector 63/ head 255
Why not edit the partition table after boot1 gets installed?
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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0010271443130.20866-100000>