[RELEASE] New Boot-Loader Menu -- version 1.5

Sat May 14 18:53:28 UTC 2011

On May 14, 2011, at 8:14 AM, Mehmet Erol Sanliturk <m.e.sanliturk at gmail.com> wrote:

> On Sat, May 14, 2011 at 3:15 AM, Michael Reifenberger <mike at reifenberger.com> wrote:
> Hi,
> this looks very promising!
> 
> While you are working on the loader front currently,
> would it be possible to implement a "Boot kernel.old"
> menue item that unloads all current loaded modules and re-loads
> everithing from /boot/kernel.old?
> 
> Its difficult to handle manually in the loader (esp. handling the zpool.cache file ) and I got bitten by this issue recently in a ZFS only environment.
> 
> Thanks in advance!
> 
> Bye/2
> ---
> Michael Reifenberger
> Michael at Reifenberger.com
> http://www.Reifenberger.com
> 
> 

There have been suggestions from many regarding "kernel selection" and even "root selection" options. I've responded in earnest on at least one such suggestion (stating that there are plans to incorporate these features at some later date), though I have been short on details (compared to my normal verbosity).

These suggestions will have to be slated for a different commit and cannot make it into the initial one. A subset of the technical reasons are enumerated below:

1. Currently, the "start" FICL word provided by /usr/src/sys/boot/forth/loader.4th -- which reads in /boot/defaults/loader.conf and later /boot/loader.conf (if it exists), among other things -- pre-loads the configured kernel.

This would need to change. We still want to call "start" from the onset of /boot/loader.rc to pick up any variables configured in loader.conf(5), but we don't want to load the kernel yet (though modules may be OK). I would change the overloaded "boot" word to load the kernel prior to calling the built-in boot ( N -- ) construct.

2. A non-trivial amount of Forth will need to be written to probe for a list of kernels to be presented.

Again, that is just a subset of the technical affronts we'll face. I'd like to see this functionality pushed to a later SVN rev -- perhaps after MFC of the current rev planned for the current state.

> Many of the Unix/Linux operating systems are utilizing a Kernel Selection ( let's call it Selection instead of Loader ) menu , such as GRUB or LILO , or ,
> in FreeBSD , when Kernel Selection menu is selected instead of booting directly from boot sector .
> 
> Actually , a Kernel Selection menu in front of the Boot Loader menu is a more flexible method :
> First select kernel , then select its booting structure with the above described Boot Loader menu .
> 
> My opinion is that , they should NOT be COMBINED into one single menu , because , in the same system , even there may be other kernels to be booted .

This would be technically simple to achieve but I'm wondering if the community would tolerate having a 2x 10-second timeout (one for kernel selection menu, and another for the boot/option menu). Then, if later a root-selection is provided, would that go into the kernel selection menu or a new menu (now requiring 30-seconds to boot without a human present).

I want the menu with the "Boot" option to be front-and-center, continuing to allow the user to boot immediately with a single key ('1', 'b', or ENTER) if present (and desired), or if not present boot after a single 10-second timeout.

ASIDE: There are more boot toggles/variables mentioned in loader(8) than are knobs in the boot menu (both old and new -- and more than can fit on a single screen even). Such as boot_ddb, boot_gdb, boot_multicons, boot_mute, boot_pause, boot_serial, and comconsole_speed. That's 7 additional options that would likely be a good candidate for a "side menu" (perhaps a "More Options" menuitem off the main menu).

ASIDE: A root-selection menuitem could potentially present the normal root in addition to "ask", "cdrom" and "embedded". Each of which would set (respectively) "boot_askname", "boot_cdrom" and "boot_dfltroot". See loader(8) for additional details.

> Some operating systems , such as OpenSolaris and Mandriva Linux , after updating the kernel , they are keeping previous kernel in the Kernel Selection menu , under the new kernel name item .

I've often felt that this could be improved upon by the Linux community. IMHO neither Grub nor LiLo present a user-friendly way of setting options for the selected kernel and concurrently leaves many Linux desktop-users befuddled and uninterested. The use-case is taking a box into single-user mode: FreeBSD achieves this with either one keystroke (current loader menu) or two (code being committed to HEAD; e.g., s, ENTER); compare that with the steps required to boot Linux into single-user mode from either LiLo or Grub (disclaimer: this might have been updated in some of the later Linux distros).

NOTE: If you have a pre-configured Grub or LiLo entry for easily entering into single-user mode, note that not everybody is so fortunate (either because of their distro or due to lack of manual configuration). Even still, a variable amount of cursor/arrow keys must be depressed which unless you've ordered your single-user entry at the top of the list, is still likely to exceed the amount of keystrokes required by FreeBSD to achieve the same feat.

> Such a system may be employed for the FreeBSD : If a kernel.old is generated , it may be inserted into Kernel Selection menu automatically .

I'm more interested in perhaps crawling the "bootfile" environment variable customizable by loader.conf(5) (a semi-colon delimited list of bootable kernels).

By default, $bootfile is simply set to "kernel" (see /boot/defaults/loader.conf). However, if a user desires, they could add something like:

	bootfile="kernel;kernel.old;kernel.sav"

to /boot/loader.conf and the menu would then test for the existence of each of those (note: not implemented yet for technical reasons stated above). If more than one kernel exists, the menuitem would be present (allowing them to cycle through each of the existing kernels). Once boot is invoked, the desired kernel is loaded and then executed.

The functionality for all this is (as previously mentioned) is already in menu.4th (see "cycle_menuitem", "cycle_kernel", and "cycle_root"). The part that's not done yet is to dynamically build the menu construct based off the existence of those files. Though, currently you can manually configure a menuitem for kernels/roots so-long as you modify the overloaded "boot" functionality to load the kernel prior to execution (opposed to having loader.4th's "start" load the kernel which preempts any user selection event; as mentioned above).

> If , at present , there is no kernel selection menu but boot sector is used directly ,
> kernel build system may modify that structure also to utilize a Kernel Selection menu .

Can you clarify on "boot sector is used directly?" I'm unaware of any loader(8) scenario in FreeBSD would do this. The normal behavior is to load the kernel and then execute said kernel. Not selecting a kernel is not an option, if I recall correctly.
-- 
Devin

_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________