From owner-freebsd-hackers@FreeBSD.ORG Sat May 14 18:53:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42B67106566B for ; Sat, 14 May 2011 18:53:28 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id EFB388FC0A for ; Sat, 14 May 2011 18:53:27 +0000 (UTC) Received: from SBHFISLREXT03 ([10.132.254.62]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id p4EIrQIW030705; Sat, 14 May 2011 13:53:26 -0500 Received: from SBHFISLTCGW04.FNFIS.COM (Not Verified[10.132.248.123]) by SBHFISLREXT03 with MailMarshal (v6, 5, 4, 7535) id ; Sat, 14 May 2011 13:53:45 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by SBHFISLTCGW04.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 May 2011 13:53:26 -0500 Received: from [10.0.0.105] ([10.132.254.136]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 May 2011 13:53:25 -0500 References: <00b601cc11d5$5c83f5c0$158be140$@vicor.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8H7) Message-Id: <24057187-9777-4CFF-92D1-1D6103B35280@vicor.com> X-Mailer: iPad Mail (8H7) From: Devin Teske Date: Sat, 14 May 2011 11:53:56 -0700 To: Mehmet Erol Sanliturk X-OriginalArrivalTime: 14 May 2011 18:53:25.0831 (UTC) FILETIME=[34C7CD70:01CC1268] Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-hackers@freebsd.org" Subject: Re: [RELEASE] New Boot-Loader Menu -- version 1.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 18:53:28 -0000 On May 14, 2011, at 8:14 AM, Mehmet Erol Sanliturk wrote: > On Sat, May 14, 2011 at 3:15 AM, Michael Reifenberger 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. _____________