Use of boot0cfg to set boot slice broke between r209459 and
danny at cs.huji.ac.il
Sat Jun 26 09:11:00 UTC 2010
> 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.
> > 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
> * 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 set -a active -i n aacd0
n will probably be 5.
bottom line, the MBR is NOT being updated by boot0cfg
More information about the freebsd-current