Date: Sat, 14 May 2011 11:53:56 -0700 From: Devin Teske <dteske@vicor.com> To: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: [RELEASE] New Boot-Loader Menu -- version 1.5 Message-ID: <24057187-9777-4CFF-92D1-1D6103B35280@vicor.com> In-Reply-To: <BANLkTimUz28twamVDDt=-TxWfJc%2B2nEpJQ@mail.gmail.com> References: <00b601cc11d5$5c83f5c0$158be140$@vicor.com> <alpine.BSF.2.00.1105140904310.11775@gw.reifenberger.com> <BANLkTimUz28twamVDDt=-TxWfJc%2B2nEpJQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 14, 2011, at 8:14 AM, Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com= > wrote: > On Sat, May 14, 2011 at 3:15 AM, Michael Reifenberger <mike@reifenberger.= com> wrote: > Hi, > this looks very promising! >=20 > 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? >=20 > Its difficult to handle manually in the loader (esp. handling the zpool.c= ache file ) and I got bitten by this issue recently in a ZFS only environme= nt. >=20 > Thanks in advance! >=20 > Bye/2 > --- > Michael Reifenberger > Michael@Reifenberger.com > http://www.Reifenberger.com >=20 >=20 There have been suggestions from many regarding "kernel selection" and even= "root selection" options. I've responded in earnest on at least one such s= uggestion (stating that there are plans to incorporate these features at so= me 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 enumera= ted below: 1. Currently, the "start" FICL word provided by /usr/src/sys/boot/forth/loa= der.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 ch= ange the overloaded "boot" word to load the kernel prior to calling the bui= lt-in boot ( N -- ) construct. 2. A non-trivial amount of Forth will need to be written to probe for a lis= t 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 o= f 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 di= rectly from boot sector . >=20 > 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 de= scribed Boot Loader menu . >=20 > My opinion is that , they should NOT be COMBINED into one single menu , b= ecause , 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 commun= ity 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-selectio= n 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 t= o 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 ar= e knobs in the boot menu (both old and new -- and more than can fit on a si= ngle screen even). Such as boot_ddb, boot_gdb, boot_multicons, boot_mute, b= oot_pause, boot_serial, and comconsole_speed. That's 7 additional options t= hat would likely be a good candidate for a "side menu" (perhaps a "More Opt= ions" 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 (resp= ectively) "boot_askname", "boot_cdrom" and "boot_dfltroot". See loader(8) f= or additional details. > Some operating systems , such as OpenSolaris and Mandriva Linux , after u= pdating the kernel , they are keeping previous kernel in the Kernel Selecti= on menu , under the new kernel name item . I've often felt that this could be improved upon by the Linux community. IM= HO neither Grub nor LiLo present a user-friendly way of setting options for= the selected kernel and concurrently leaves many Linux desktop-users befud= dled and uninterested. The use-case is taking a box into single-user mode: = FreeBSD achieves this with either one keystroke (current loader menu) or tw= o (code being committed to HEAD; e.g., s, ENTER); compare that with the ste= ps required to boot Linux into single-user mode from either LiLo or Grub (d= isclaimer: 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 i= nto single-user mode, note that not everybody is so fortunate (either becau= se of their distro or due to lack of manual configuration). Even still, a v= ariable amount of cursor/arrow keys must be depressed which unless you've o= rdered your single-user entry at the top of the list, is still likely to ex= ceed 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 genera= ted , 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 ke= rnels). By default, $bootfile is simply set to "kernel" (see /boot/defaults/loader.= conf). However, if a user desires, they could add something like: bootfile=3D"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). I= f 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 m= enu.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 th= e existence of those files. Though, currently you can manually configure a = menuitem for kernels/roots so-long as you modify the overloaded "boot" func= tionality to load the kernel prior to execution (opposed to having loader.4= th's "start" load the kernel which preempts any user selection event; as me= ntioned above). > If , at present , there is no kernel selection menu but boot sector is us= ed directly , > kernel build system may modify that structure also to utilize a Kernel Se= lection menu . Can you clarify on "boot sector is used directly?" I'm unaware of any loade= r(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 optio= n, if I recall correctly. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24057187-9777-4CFF-92D1-1D6103B35280>