From bugmaster at FreeBSD.org Mon Aug 3 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 3 11:08:04 2009 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200908031106.n73B6re6088547@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o misc/136889 embedded [nanobsd] [path] nanobsd error reporting and other ref o misc/135588 embedded [nanobsd] simple patch for adding amd64 support o misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 4 problems total. From olivier at cochard.me Fri Aug 7 15:10:10 2009 From: olivier at cochard.me (=?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?=) Date: Fri Aug 7 15:10:17 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice Message-ID: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> Hi, I meet a problem under FreeBSD 7.2 and 8.0-current (nanoBSD) using boot0cfg: I can't use boot0cfg for changing the booting slice. Here is my problem: I'm using the FreeBSD Boot manager on a system with MBR partitions. The active slice is the partition 1, but I want to boot from the slice 2. Then I use boot0cfg like that: sysctl kern.geom.debugflags=16 boot0cfg -s 2 -v /dev/ad0 sysctl kern.geom.debugflags=0 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 ? The "active" flag of the slice is not modified after using boot0cfg, is normal ? Here is the full log: [root@router]~#fdisk /dev/ad0 ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=968 heads=16 sectors/track=63 (1008 blks/cyl) parameters to be used for BIOS calculations are: cylinders=968 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 465822 (227 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 28/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 465948, size 465822 (227 Meg), flag 0 beg: cyl 29/ head 1/ sector 1; end: cyl 57/ head 254/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 931770, size 16065 (7 Meg), flag 0 beg: cyl 58/ head 0/ sector 1; end: cyl 58/ head 254/ sector 63 The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 947835, size 16065 (7 Meg), flag 0 beg: cyl 59/ head 0/ sector 1; end: cyl 59/ head 254/ sector 63 [root@router]~#sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 -> 16 [root@router]~#boot0cfg -s 2 -v /dev/ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5 28:254:63 63 465822 2 0x00 29: 1: 1 0xa5 57:254:63 465948 465822 3 0x00 58: 0: 1 0xa5 58:254:63 931770 16065 4 0x00 59: 0: 1 0xa5 59:254:63 947835 16065 version=1.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv default_selection=F2 (Slice 2) [root@router]~#sysctl kern.geom.debugflags=0 kern.geom.debugflags: 16 -> 0 [root@router]~#fdisk /dev/ad0 ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=968 heads=16 sectors/track=63 (1008 blks/cyl) parameters to be used for BIOS calculations are: cylinders=968 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 465822 (227 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 28/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 465948, size 465822 (227 Meg), flag 0 beg: cyl 29/ head 1/ sector 1; end: cyl 57/ head 254/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 931770, size 16065 (7 Meg), flag 0 beg: cyl 58/ head 0/ sector 1; end: cyl 58/ head 254/ sector 63 The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 947835, size 16065 (7 Meg), flag 0 beg: cyl 59/ head 0/ sector 1; end: cyl 59/ head 254/ sector 63 Thanks, Olivier From jhein at timing.com Fri Aug 7 16:32:12 2009 From: jhein at timing.com (John Hein) Date: Fri Aug 7 16:32:41 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice In-Reply-To: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> Message-ID: <19068.18919.843159.936827@gromit.timing.com> Olivier Cochard-Labb? wrote at 17:09 +0200 on Aug 7, 2009: > I meet a problem under FreeBSD 7.2 and 8.0-current (nanoBSD) using > boot0cfg: I can't use boot0cfg for changing the booting slice. > Here is my problem: > I'm using the FreeBSD Boot manager on a system with MBR partitions. > The active slice is the partition 1, but I want to boot from the slice 2. > > Then I use boot0cfg like that: > > sysctl kern.geom.debugflags=16 > boot0cfg -s 2 -v /dev/ad0 > sysctl kern.geom.debugflags=0 > > 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? From imp at bsdimp.com Fri Aug 7 16:47:49 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Aug 7 16:47:55 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice In-Reply-To: <19068.18919.843159.936827@gromit.timing.com> References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <19068.18919.843159.936827@gromit.timing.com> Message-ID: <20090807.104414.221852486.imp@bsdimp.com> In message: <19068.18919.843159.936827@gromit.timing.com> John Hein writes: : Olivier Cochard-Labb? wrote at 17:09 +0200 on Aug 7, 2009: : > I meet a problem under FreeBSD 7.2 and 8.0-current (nanoBSD) using : > boot0cfg: I can't use boot0cfg for changing the booting slice. : > Here is my problem: : > I'm using the FreeBSD Boot manager on a system with MBR partitions. : > The active slice is the partition 1, but I want to boot from the slice 2. : > : > Then I use boot0cfg like that: : > : > sysctl kern.geom.debugflags=16 : > boot0cfg -s 2 -v /dev/ad0 : > sysctl kern.geom.debugflags=0 : > : > 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... Warner From fb-embedded at psconsult.nl Fri Aug 7 20:58:26 2009 From: fb-embedded at psconsult.nl (Paul Schenkeveld) Date: Fri Aug 7 20:58:32 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice In-Reply-To: <20090807.104414.221852486.imp@bsdimp.com> References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <19068.18919.843159.936827@gromit.timing.com> <20090807.104414.221852486.imp@bsdimp.com> Message-ID: <20090807205817.GA82868@psconsult.nl> On Fri, Aug 07, 2009 at 10:44:14AM -0600, M. Warner Losh wrote: > In message: <19068.18919.843159.936827@gromit.timing.com> > John Hein writes: > : Olivier Cochard-Labb? wrote at 17:09 +0200 on Aug 7, 2009: > : > I meet a problem under FreeBSD 7.2 and 8.0-current (nanoBSD) using > : > boot0cfg: I can't use boot0cfg for changing the booting slice. > : > Here is my problem: > : > I'm using the FreeBSD Boot manager on a system with MBR partitions. > : > The active slice is the partition 1, but I want to boot from the slice 2. > : > > : > Then I use boot0cfg like that: > : > > : > sysctl kern.geom.debugflags=16 > : > boot0cfg -s 2 -v /dev/ad0 > : > sysctl kern.geom.debugflags=0 > : > > : > 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... [I cc'ed freebsd-current as I feel this is a regression that really needs fixing before 8.0 comes out] Pre-7.2 world: boot0cfg changes the default slice to boot from by altering block0 byte at offset 0x1b9. Allowed values are 0-3 to boot from slice 1 thru 4 or 4 to boot from the next drive. Boot0 ignores the active flag in the MBR and only looks at the byte described above. 7.2-and-up world: boot0cfg still changes the same byte at 0x1b9 in block0 but boot0 seems to completely ignore this byte and boots from the slice marked active in the MBR. NanoBSD relies on the working of boot0cfg when upgrading, since 7.2 this just does not work any more. It seems that the original implementation of boot0 introduced the new way of storing the default slice to boot from to allow for other defaults than just slice 1 thru 4 which the active flag(s) in MBR allow. My personal opinion is that boot0 should either look at the byte at 0x1b9 or at the active flags. Since the active flags can only specify a default of 1 thru 4 and the design of MBR and the active flags is broken by design [1] I'd *really* like to see boot0 revert to the pre-7.2 behaviour. Hope this gets fixed before 8.0 comes out, leaving it the way it is renders boot0cfg and NanoBSD (which relies on boot0cfg) crippled and too difficult to use for all users not intimately acquainted with the way boot0cfg, the MBR record and boot0 interact. Unfortunately I'm not enough x86 assembly literate to understand the diffs between boot0.s in 7.1 and 7.2 to be able to produce a useful patch. [1] I have had installs of 8.0 snapshots that left MBR with more than one MBR slice marked active, BIOS subsequently completely rejected the disk and the only remedy was to manually fdisk -a from fixit mode using a live CD/DVD. This has happened with several recent Intel desktop boards like DG965RY and DP35DP. > Warner Regards, Paul Schenkeveld From bugmaster at FreeBSD.org Mon Aug 10 11:06:53 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 10 11:07:43 2009 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200908101106.n7AB6qhp025094@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o misc/136889 embedded [nanobsd] [path] nanobsd error reporting and other ref o misc/135588 embedded [nanobsd] simple patch for adding amd64 support o misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 4 problems total. From nick at van-laarhoven.org Tue Aug 11 13:05:36 2009 From: nick at van-laarhoven.org (Nick Hibma) Date: Tue Aug 11 13:05:43 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice In-Reply-To: <20090807205817.GA82868@psconsult.nl> References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <20090807.104414.221852486.imp@bsdimp.com> <20090807205817.GA82868@psconsult.nl> Message-ID: <200908111449.51779.nick@van-laarhoven.org> > > : > 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 That's taken from our own version of the update script, but should fit in the NanoBSD update script. Nick From fb-embedded at psconsult.nl Tue Aug 11 15:58:59 2009 From: fb-embedded at psconsult.nl (Paul Schenkeveld) Date: Tue Aug 11 15:59:06 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice In-Reply-To: <200908111449.51779.nick@van-laarhoven.org> References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <20090807.104414.221852486.imp@bsdimp.com> <20090807205817.GA82868@psconsult.nl> <200908111449.51779.nick@van-laarhoven.org> Message-ID: <20090811155851.GA50096@psconsult.nl> 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 From shuvaev at physik.uni-wuerzburg.de Tue Aug 11 17:14:38 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Tue Aug 11 17:14:44 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice In-Reply-To: <20090811155851.GA50096@psconsult.nl> 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> Message-ID: <20090811164119.GA79544@wep4035.physik.uni-wuerzburg.de> 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. From mike at reifenberger.com Tue Aug 11 21:50:59 2009 From: mike at reifenberger.com (Michael Reifenberger) Date: Tue Aug 11 21:51:05 2009 Subject: [NanoBSD] Can't use boot0cfg for changing the booting slice In-Reply-To: <200908111449.51779.nick@van-laarhoven.org> References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <20090807.104414.221852486.imp@bsdimp.com> <20090807205817.GA82868@psconsult.nl> <200908111449.51779.nick@van-laarhoven.org> Message-ID: On Tue, 11 Aug 2009, Nick Hibma wrote: ... > to > > boot0cfg -s $oslice $NANO_DRIVE > echo "a $oslice" | fdisk -f /dev/stdin $NANO_DRIVE > Why not: gpart set -a active -i 1 ${NANO_DRIVE} Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From bugmaster at FreeBSD.org Mon Aug 17 11:06:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 17 11:07:41 2009 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200908171106.n7HB6pmq075737@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o misc/136889 embedded [nanobsd] [path] nanobsd error reporting and other ref o misc/135588 embedded [nanobsd] simple patch for adding amd64 support o misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 4 problems total. From bugmaster at FreeBSD.org Mon Aug 24 11:06:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 24 11:07:47 2009 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200908241106.n7OB6q1B048506@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o misc/136889 embedded [nanobsd] [path] nanobsd error reporting and other ref o misc/135588 embedded [nanobsd] simple patch for adding amd64 support o misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 4 problems total. From bugmaster at FreeBSD.org Mon Aug 31 11:07:03 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 31 11:07:46 2009 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200908311107.n7VB72Rc070504@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o misc/136889 embedded [nanobsd] [path] nanobsd error reporting and other ref o misc/135588 embedded [nanobsd] simple patch for adding amd64 support o misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 4 problems total.