From owner-freebsd-hackers@FreeBSD.ORG Tue May 10 11:35:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58E69106564A for ; Tue, 10 May 2011 11:35:29 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id B46778FC1D for ; Tue, 10 May 2011 11:35:28 +0000 (UTC) Received: from e-new.0x20.net (localhost [217.69.76.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id C24416A6049; Tue, 10 May 2011 13:35:26 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id p4ABZQoB075110; Tue, 10 May 2011 13:35:26 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id p4ABZPTa074412; Tue, 10 May 2011 13:35:25 +0200 (CEST) (envelope-from lars) Date: Tue, 10 May 2011 13:35:25 +0200 From: Lars Engels To: Devin Teske Message-ID: <20110510113525.GA71959@e-new.0x20.net> References: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> <20110509091902.GR47109@e-new.0x20.net> <000601cc0e70$5e960dc0$1bc22940$@vicor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <000601cc0e70$5e960dc0$1bc22940$@vicor.com> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.2-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 10 May 2011 11:42:19 +0000 Cc: 'FreeBSD Hackers' , kmoore@pcbsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 11:35:29 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kris Moore CC'ed On Mon, May 09, 2011 at 10:41:40AM -0700, Devin Teske wrote: > > -----Original Message----- > > From: Lars Engels [mailto:lars.engels@0x20.net] > > Sent: Monday, May 09, 2011 2:19 AM > > To: Devin Teske > > Cc: FreeBSD Hackers > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 > >=20 > > On Thu, May 05, 2011 at 01:20:43AM -0700, Devin Teske wrote: > > > Hello fellow -hackers, > > > > > > I'm so very proud to offer the latest update to my new boot loader > > > menu -- version 1.4 -- addressing ACPI detection, bringing it in-line > > > with HEAD. > > > > > > It took some work and a few days, but I got it! Have a look below for > > > six different displays (three different scenarios -- i386 w/ ACPI, > > > i386 w/o ACPI, and non-i386 -- each in both B&W and Color). > > > > >=20 > > Hi Devin, > >=20 > > PC-BSD also has a slightly patched loader menu compared to the stock Fr= eeBSD > > version. >=20 > Does PC-BSD have CVSweb that I can browse? Link? http://trac.pcbsd.org/browser/pcbsd/current/system-overlay/boot >=20 > > I.E. you can also set unset verbose mode and ACPI with it. > > Some days ago there was a proposal on a PC-BSD list to add an option to= boot a > > different kernel if one is found in /boot. > > Would it be possible to addi this function to your boot menu? >=20 > No need. The basic constructs are there already, we just need to expand o= n them. >=20 > Here's how I've implemented a hard-coded list of kernels to choose from f= or our systems (to be implemented in /boot/menu.rc): >=20 > \ Set kernel paths (see menu_caption[2] below) > set kernel_prefix=3D"/kernels/" > \ NOTE: We like to keep our kernels in `/kernels' > set kernel[0]=3D"FIS-i386-8.1p1" > set kernel[1]=3D"GENERIC-i386-8.1p1" > set kernel_suffix=3D".kgz" > \ NOTE: This is on our CD/DVD, so kernels are kgzip(8)'d >=20 > \ Set default boot kernel > set kernel=3D"${kernel_prefix}${kernel[0]}${kernel_suffix}" >=20 > \ Initialize main menu constructs (variables are read by `menu.4th') >=20 > set menu_caption[1]=3D"Boot [ENTER]" > set menu_command[1]=3D"boot" >=20 > set menu_caption[2][0]=3D"Kernel: ${kernel[0]} (1of2)" > set menu_caption[2][1]=3D"Kernel: ${kernel[1]} (2of2)" > set menu_caption[2]=3D"${menu_caption[2][0]}" > set menu_command[2]=3D"cycle_kernel" >=20 > \ ... rest of menu ... >=20 > The magic is the "cycle_kernel" command (see `/boot/menu.4th'). The `cycl= e_kernel' command is a wrapper to the `cycle_menuitem' command (similar to = how `toggle_verbose', `toggle_acpi', and `toggle_singleuser' are wrappers t= o the `toggle_menuitem' command). Like the `toggle_menuitem' command, the `= cycle_menuitem' command uses a system of internal state variables to track = which menuitem text is to be displayed for that individual menuitem. Wherea= s the `toggle_menuitem' command automatically toggles the text of a menuite= m between the `menu_caption[x]' and `toggled_text[x]' variables, the `cycle= _menuitem' command automatically cycles through the `menu_caption[x][y]' va= riables, cycling back to y=3D0 when it gets to an undefined `y' value. >=20 > However, hard-coding an alternate kernel choice is something that I would= n't condone for an actual release. Instead, what I would recommend is to dy= namically allocate the kernel menu if/when multiple kernels are discovered/= configured. That's something that is currently not coded (dynamic detection= of kernels in /boot). >=20 > > Or even better > > work together with Kris Moore so we don't have two solutions for the sa= me task? >=20 > I'd like to open a discussion with Kris Moore on how we could go about de= tecting additional kernels. >=20 > Off the top of my head, here's a couple thoughts: >=20 > a. We could test a battery of different kernel names (kernel, kernel.bak,= kernel.orig, etc.) > b. We could allow the user to set kernel1, kernel2, kernel3, etc. in load= er.conf(5) > c. We could allow the user to set kernel=3D"kernel1;kernel2;kernel3;..." = in loader.conf(5) > d. Some combination of the above. > --=20 > Devin >=20 > P.S. I think it'd also be nice to someday offer the user a choice of boot= ing into a memory filesystem for rescue purposes. We've offered this to our= users for years with the following configuration: >=20 > set root[0]=3D"" > set root[1]=3D"rescue_mfsroot" > set menu_caption[7][0]=3D"Root Image: Default (1of2)" > set menu_caption[7][1]=3D"Root Image: Rescue (2of2)" > set menu_caption[7]=3D"${menu_caption[7][0]}" > set menu_command[7]=3D"cycle_root" >=20 Good idea! :-) --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk3JIv0ACgkQKc512sD3afgsfgCglYcx/GeumkOv3PQRZIuQbXFD whIAoMZRb8ToOT2NCkx0jgO35k0a4y2o =ipog -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw--