Kris Moore CC'ed
On Mon, May 09, 2011 at 10:41:40AM -0700, Devin Teske wrote: > > -----Original Message----- > > From: Lars Engels [mailto:lars.eng...@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! :-)
pgpRnhpUhwmGX.pgp
Description: PGP signature
