Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Jan 2011 11:27:00 +0200
From:      Daniel Braniss <danny@cs.huji.ac.il>
To:        Tom Judge <tom@tomjudge.com>
Cc:        freebsd-hackers@freebsd.org, luigi@freebsd.org
Subject:   Re: sys/boot/boot0/boot0.S - r186598 
Message-ID:  <E1PcE1k-00020L-DJ@kabab.cs.huji.ac.il>
In-Reply-To: <4D29ED16.7030401@tomjudge.com> 
References:  <4D295820.20807@tomjudge.com> <E1PbsfL-0009ky-QP@kabab.cs.huji.ac.il> <4D29ED16.7030401@tomjudge.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --------------enig0AE178BF2380C8CAA3249E0C
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> On 09/01/2011 04:38, Daniel Braniss wrote:
> >> There was a post on the embedded list that suggested this work around:=
> 
> >>     echo 'a 2' | fdisk -f /dev/stdin ad0
> >>     boot0cfg -s 2 ad0
> >>
> >> There are 2 issues with this:
> >> 1) It can't be done without setting kern.geom.debugflags to 0x10.
> >> 2) It resulted in most/all commands resulting in the error message
> >> "Device not configured" including the second command and 'shutdown -r =
> now=3D
> >> '.
> >>
> >> Both of which leave this really work around fairly broken.
> > the problem is that boot0cfg -s does NOT update the boot block, it fail=
> s!
> > the work around is:
> > 	boot0cfg -s -t n dev
> > then
> > 	gpart set -a active -i n dev
> >
> > danny
> >
> Hi Danny,
> 
> The bug does not seem to be in boot0cfg as:
> 
> 1) It succeeds to write the new configuration to the boot block every
> time i have tried.
> 2) It does not touch the partition table at all only the mbr, so it was
> never designed to change the active partition.

arguable, since it used to work.

> 
> If this is not a bug in boot0 then its a bug in the man pages for
> boot0cfg as it does make reference to having to change the active slice
> to make this work.

the problem is not as simple as it looks, and I don't have all the answers, but after spendig much time on this, it seems that not all BIOSes behave
in a 'standard way' :-)

	danny





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1PcE1k-00020L-DJ>