[UPDATE] New Boot-Loader Menu -- version 1.4

[Lars Engels]

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 at 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
> > 
> > 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).
> > >
> > 
> > Hi Devin,
> > 
> > PC-BSD also has a slightly patched loader menu compared to the stock FreeBSD
> > version.
> 
> Does PC-BSD have CVSweb that I can browse? Link?

http://trac.pcbsd.org/browser/pcbsd/current/system-overlay/boot

> 
> > 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?
> 
> No need. The basic constructs are there already, we just need to expand on them.
> 
> Here's how I've implemented a hard-coded list of kernels to choose from for our systems (to be implemented in /boot/menu.rc):
> 
> \ Set kernel paths (see menu_caption[2] below)
> set kernel_prefix="/kernels/"
> 	\ NOTE: We like to keep our kernels in `/kernels'
> set kernel[0]="FIS-i386-8.1p1"
> set kernel[1]="GENERIC-i386-8.1p1"
> set kernel_suffix=".kgz"
> 	\ NOTE: This is on our CD/DVD, so kernels are kgzip(8)'d
> 
> \ Set default boot kernel
> set kernel="${kernel_prefix}${kernel[0]}${kernel_suffix}"
> 
> \ Initialize main menu constructs (variables are read by `menu.4th')
> 
> set menu_caption[1]="Boot [ENTER]"
> set menu_command[1]="boot"
> 
> set menu_caption[2][0]="Kernel: ${kernel[0]} (1of2)"
> set menu_caption[2][1]="Kernel: ${kernel[1]} (2of2)"
> set menu_caption[2]="${menu_caption[2][0]}"
> set menu_command[2]="cycle_kernel"
> 
> \ ... rest of menu ...
> 
> The magic is the "cycle_kernel" command (see `/boot/menu.4th'). The `cycle_kernel' command is a wrapper to the `cycle_menuitem' command (similar to how `toggle_verbose', `toggle_acpi', and `toggle_singleuser' are wrappers to 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. Whereas the `toggle_menuitem' command automatically toggles the text of a menuitem between the `menu_caption[x]' and `toggled_text[x]' variables, the `cycle_menuitem' command automatically cycles through the `menu_caption[x][y]' variables, cycling back to y=0 when it gets to an undefined `y' value.
> 
> However, hard-coding an alternate kernel choice is something that I wouldn't condone for an actual release. Instead, what I would recommend is to dynamically 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).
> 
> > Or even better
> > work together with Kris Moore so we don't have two solutions for the same task?
> 
> I'd like to open a discussion with Kris Moore on how we could go about detecting additional kernels.
> 
> Off the top of my head, here's a couple thoughts:
> 
> 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 loader.conf(5)
> c. We could allow the user to set kernel="kernel1;kernel2;kernel3;..." in loader.conf(5)
> d. Some combination of the above.
> -- 
> Devin
> 
> P.S. I think it'd also be nice to someday offer the user a choice of booting into a memory filesystem for rescue purposes. We've offered this to our users for years with the following configuration:
> 
> set root[0]=""
> set root[1]="rescue_mfsroot"
> set menu_caption[7][0]="Root Image: Default (1of2)"
> set menu_caption[7][1]="Root Image: Rescue (2of2)"
> set menu_caption[7]="${menu_caption[7][0]}"
> set menu_command[7]="cycle_root"
> 

Good idea! :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20110510/6d75008d/attachment.pgp