Re: Use of boot0cfg to set boot slice broke between r209459 and r209502

> 
> --jr/gb2Ce1GM9KKZD
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Fri, Jun 25, 2010 at 08:37:36AM -0400, John Baldwin wrote:
> > On Friday 25 June 2010 7:40:11 am David Wolfskill wrote:
> > > Well, one one of my machines -- I realize that there are some
> > > machines for which it's been problematic for a while.  And all of
> > > the machines I'm using run FreeBSD/i386.
> >=20
> > 209469 perhaps?
> 
> Apparently so.
> 
> Here's what I did to test the above assertion:
> 
> * Booted the build machine from slice 4 (usual "head" slice); cloned
>   that slice to slice 1; booted from slice 1.
> 
> * In a "head" src working directory, I issued
> 
> 	svn diff -c209469
> 
>   and saw that r209469 merely added 2 lines to usr.sbin/boot0cfg/boot0cfg.c.
> 
> * On the build machine's src working directory, I edited
>   usr.sbin/boot0cfg/boot0cfg.c to remove the lines in question.
> 
> * Then (as root), I made /usr/src/usr.sbin/boot0cfg/ my current working
>   directory and issued:
> 
> 	make && make install
> 
> * I then issued
> 
> 	boot0cfg -s 4 aacd0 && shutdown -r now
> 
>   then watched the serial console.
> 
> * I noticed that the default boot slice -- which had been 1 -- was now
>   4.
> 
> * For grins, I then booted slice 4 (head) in single-user mode, mounted
>   the file systems, then invoked the boot0cfg executable from slice 1 to
>   switch the default to slice 2, then issued "halt -p".  I waited a bit,
>   then powered the machine back up (WoL can be handy!) noted it was
>   booting from slice 2, brought it up in single-user mode, then issued
>   "halt -p" to reduce its power consumption and heat & nouse generation.
> 
> All that said, it looks as if r209469 merely noticed an existing error
> condition and tried to do something arguably sensible with it, rather
> than merely ignore it.  So it would seem that there's a more fundamental
> issue at stake, here....

what do you see when you type boot0cfg -v ...?
gpart show?
then try 
	gpart set -a active -i n aacd0
n will probably be 5.

bottom line, the MBR is NOT being updated by boot0cfg

danny