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 SchenkeveldReceived 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