From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 16:41:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38CA31065680 for ; Tue, 11 Aug 2009 16:41:22 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id B3AFB8FC4D for ; Tue, 11 Aug 2009 16:41:21 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 5BD0D19963E; Tue, 11 Aug 2009 18:41:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 4EC011995C0; Tue, 11 Aug 2009 18:41:20 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 3A7BA1994DC; Tue, 11 Aug 2009 18:41:20 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2FP1HF244) with ESMTP id 2009081118411928-3450 ; Tue, 11 Aug 2009 18:41:19 +0200 Received: by wep4035 (sSMTP sendmail emulation); Tue, 11 Aug 2009 18:41:19 +0200 Date: Tue, 11 Aug 2009 18:41:19 +0200 From: Alexey Shuvaev To: freebsd-embedded@freebsd.org, freebsd-current@freebsd.org Message-ID: <20090811164119.GA79544@wep4035.physik.uni-wuerzburg.de> Mail-Followup-To: freebsd-embedded@freebsd.org, freebsd-current@freebsd.org References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <20090807.104414.221852486.imp@bsdimp.com> <20090807205817.GA82868@psconsult.nl> <200908111449.51779.nick@van-laarhoven.org> <20090811155851.GA50096@psconsult.nl> Mime-Version: 1.0 In-Reply-To: <20090811155851.GA50096@psconsult.nl> User-Agent: Mutt/1.4.2.3i Organization: Universitaet Wuerzburg X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 08/11/2009 06:41:19 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 08/11/2009 06:41:19 PM, Serialize complete at 08/11/2009 06:41:19 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: Subject: Re: [NanoBSD] Can't use boot0cfg for changing the booting slice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 16:41:22 -0000 On Tue, Aug 11, 2009 at 05:58:51PM +0200, Paul Schenkeveld wrote: > 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? > A lot of new functionality was brought in. I would suggest going through the history at http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/boot0/boot0.S?view=log and examine which compile-time options are now there. Also you can also try contacting luigi who has touched boot0.S My 0.02$, Alexey.