Re: [NanoBSD] Can't use boot0cfg for changing the booting slice

From: Paul Schenkeveld <fb-embedded_at_psconsult.nl>
Date: Tue, 11 Aug 2009 17:58:51 +0200
On Tue, Aug 11, 2009 at 02:49:51PM +0200, Nick Hibma wrote:
> > > :  > But, after the reboot my system still reboot from the slice 1 (but
> > > :  > the boot loader show correctly that the default choice is now the
> > > :  > 2)! Where is my problem ?
> > > :
> > > : Are you sure you're booting from slice 1?
> > > : Is fstab on slice 2 pointing to slice 1?
> > >
> > > Also, boot0cfg won't mark the slice as ACTIVE, just remember that was
> > > the last slice you booted from...  To mark it active, you must use
> > > fdisk.  If by 'active' you mean 'what mount reports root as' then I
> > > think John's suggestion is right on the money...
> 
> Perhaps you could change the line in the update script from
> 
> 	boot0cfg -s $oslice $NANO_DRIVE
> 
> to
> 
> 	boot0cfg -s $oslice $NANO_DRIVE
> 	echo "a $oslice" | fdisk -f /dev/stdin $NANO_DRIVE

boot0cfg -s $oslice $NANO_DRIVE
fdisk -f - << !
a $NANO_DRIVE
!

is even cheaper 8->

> That's taken from our own version of the update script, but should fit in 
> the NanoBSD update script.

I know how to solve the problem on NanoBSD machines I administer, the
bigger picture is that the bootloader (boot0) changed from looking at
its own default answer as tuned by boot0cfg -s to looking at the
active flags in the MBR record.  IMHO this is a regression and a POLA
violation.  The default action can no longer be "F5 boot from next drive"
which is valid and useful on multi-drive servers/desktops.

So far nobody has come up with a good reason why this was changed and
the change cripples the functionality of boot0cfg, makes NanoBSD no
longer work as advertised and will scare off new users (of NanoBSD) to
some kind of embedded whatever OS besides FreeBSD.

So who wins?

> Nick

Kind regards,

Paul Schenkeveld
Received on Tue Aug 11 2009 - 13:58:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:53 UTC