Date: Tue, 10 May 2011 13:35:25 +0200 From: Lars Engels <lars.engels@0x20.net> To: Devin Teske <dteske@vicor.com> Cc: 'FreeBSD Hackers' <freebsd-hackers@freebsd.org>, kmoore@pcbsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 Message-ID: <20110510113525.GA71959@e-new.0x20.net> In-Reply-To: <000601cc0e70$5e960dc0$1bc22940$@vicor.com> References: <65D3163B-427B-41F6-80B9-7BA4AF794939@vicor.com> <20110509091902.GR47109@e-new.0x20.net> <000601cc0e70$5e960dc0$1bc22940$@vicor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110510113525.GA71959>