Date: Sun, 7 Oct 2012 14:58:46 -0700 From: Devin Teske <devin.teske@fisglobal.com> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Devin Teske <dteske@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: New Boot Loader Menu Message-ID: <D2025767-BF06-442D-8A44-316ED91EA0CD@fisglobal.com> In-Reply-To: <20121007220100.00002d21@unknown> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <20121007183433.000026a6@unknown> <DB1B1B71-84B3-4096-BE52-7630CB74762F@fisglobal.com> <20121007220100.00002d21@unknown>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 7, 2012, at 1:01 PM, Alexander Leidinger wrote: > On Sun, 7 Oct 2012 11:44:25 -0700 Devin Teske > <devin.teske@fisglobal.com> wrote: >=20 >> On Oct 7, 2012, at 9:34 AM, Alexander Leidinger wrote: >>=20 >>> On Sat, 6 Oct 2012 16:48:50 -0700 Devin Teske >>> <devin.teske@fisglobal.com> wrote: >>>=20 >>>> Hello, >>>>=20 >>>> I've been working on a new boot loader menu system. >>>>=20 >>>> This is what is in HEAD, CURRENT, and RELENG_9 at the moment: >>>>=20 >>>> http://twitpic.com/b1pkll/full >>>> in color: http://twitpic.com/b1pkz1/full >>>>=20 >>>>=20 >>>> I'd like to propose the following replacement to the above: >>>>=20 >>>> http://twitpic.com/b1pll5/full >>>> in color: http://twitpic.com/b1plxi/full >>>>=20 >>>> The boot options have been whisked away into a sub-menu (see >>>> below): >>>>=20 >>>> http://twitpic.com/b1pm51/full >>>> in color: http://twitpic.com/b1pme8/full >>>>=20 >>>>=20 >>>> What does everybody think? >>>=20 >>> IMO single user mode should be in the first level. I never had to >>> use the other options, but I often used single-user mode. Another >>> reson is that we tell to install the world in single-user mode. >>> While I've always installed the world in multi-user mode, we should >>> make it easy/fast to do it the recommended way. >>>=20 >>=20 >> The documentation on how to get into single-user mode would need to >> be changed from: >>=20 >> Press 's' and 'ENTER' >>=20 >> to instead: >>=20 >> Press 'o' then 's' then 'ENTER' >=20 >> Please note that 16+ months ago we had to update the documentation >> for my last enhancement to the loader menu. It used to be: >>=20 >> Press 's' >>=20 >> and changed to: >>=20 >> Press 's' then 'ENTER' >=20 > I failed to notice this, due to lack of need to go into single-user > mode since then respectively lack of need to have a look at the boot > menu when booting. Please see below for my opinion of this. >=20 >> because we went from a stateless menu system to a stateful menu >> system. The driving force behind that was indeed the fact that with >> the old stateless menu, you could not ever boot with >> combinations-of-options (but rather you could only boot with options >> that were presented -- unless of course you dropped to the >> interactive prompt and did the dirty work yourself). >=20 > Let me rephrase my previous mail a little bit: >=20 > Personally I agree that safe mode and ACPI can be moved to a submenu, > but single-user mode does not belong into the same submenu. >=20 > While technically they may be similar (setting some options in the > loader which based upon this does something behind the scenes), > conceptually they are not the same thing for an user, so from an > usability point of view they do not belong into the same submenu. >=20 How right you are. > IMO single-user mode shouldn't be an option, but a top-level item like > "boot". Conceptually it falls within boot and reboot in my point of > view (similar would be "boot from network" in case we would add this > possibility to the loader). It's not really a small modification of the > boot like with safe mode and verbose booting, it's big change in the > outcome of the operation. >=20 You really hit it home with this one, I believe. > You told in another mail that there is a technical limitation to the > number of items, so I assume your interest in moving out as much > options as possible is based upon this. You've already made room by > moving 3 items out to the submenu. It would be great if "boot > single-user" would be along boot and reboot, the rest can be put into a > submenu. Even if we are challenged in the future regarding space, we > can always put "More" (or similar) as a 5th item and have all the > submenus behind "More". >=20 Absolutely! Talking further about the "More" concept, I used to lie awake at night wond= ering, "what if there are more than a handful of devices to display in a me= nu w/respect to the ``select root device'' proposition". I came to the same= conclusion=85 the last menu item is a "more" (after all, the latest enhanc= ement brings in support for 65535 submenus, which ought to be enough "more"= functionality to enumerate all devices in even the beefiest of systems). Hanging the same logic onto the "Options" and/or "Expert Options" functiona= lity is downright logical. I like it. > I've also seen your mail where you tell to think about the situation > where a poor victim is sitting in front of FreeBSD as a remote hand. > Having a top-level entry for single-user mode there and all the rest > somewhere else would help in this situation too. It's not uncommon to > ask a remote hand to boot to single-user, and this would clash with > your hint at putting those other options out of the mind of the poor > victim. >=20 You make a great point. In that spirit, I do very much like the idea of hav= ing "Boot Single =85" in the "actions" section atop the main menu. > So basically I propose something like this: >=20 > Main menu: > 1. Boot > 2. Escape > 3. Reboot > 4. Boot to single-user mode > 5. Expert options > (order and numbering doesn't matter, feel free to shuffle around at > will) I like the ordering. I also like the fact that you took care to handle the edge-case that they "= meant to hit #1 but hit #2 by accident". If the single-user mode option was= #2, they'd end up at a SUM prompt (and if they are unaware that they hit #= 2 by accident, they _may_ think their FreeBSD is b0rk3d). Opposed to the ab= ove ordering, if they hit #2 by accident when they meant to hit #1, no harm= (they're given a message stating "type menu and hit ENTER to get back to t= he menu" before being dumped to the interactive loader prompt). The ordering is good. I feel it. >=20 > Expert menu: > 1. Boot options (what you have in the current submenu except > single-user) > 2. Change Root FS / BE / kernel to boot / whatever you name it > (order and numbering... shuffle around at will) >=20 > The rationale of having different submenus for changing the root FS and > the other boot options are twofold. I wholly agree. > The first one is a tribute to the > poor victim which gives a helping hand, he will not see the boot > options in case the request is made to change the root FS. The second > one is that the boot options are modifying the behavior of a given > kernel (verbose messages, safe mode, acpi), while the root-fs/BE/kernel > item is choosing a different kernel to boot. >=20 I wholly agree with the separation into 2 submenus and _why_, however... Let's be careful here. Be careful to not include "kernel" in that mix. In reality, the kernel is loaded by the "start" FICL word provided by loade= r.4th and this is done: a. before the menu is loaded and b. irrespective of the menu (done regardless of whether the menu is enabled= or not, perhaps via setting beastie_disable=3DYES in loader.conf(5)) So by the time the menu is invoked, the only way to change the kernel is to= "unload" and subsequently load the new kernel. It should be noted that DruidBSD does not load a kernel before the menu. Th= us in DruidBSD, we _do_ have a kernel selection menu (the overloaded "boot"= FICL word in DruidBSD is coded to load $kernel right before doing the real= boot whereas FreeBSD's overloaded "boot" FICL word simply invokes the alre= ady-loaded kernel that was loaded before the menu ever started). Many people over the years (in passing) have asked me about whether FreeBSD= could support a kernel selection menu to allow easily running (say, for ex= ample) "kernel.old". I don't always answer with the full breadth of this th= read, but the answer is always "sure, that's very do-able" when in reality = (as I state here and now in this thread) the fundamental fact that FreeBSD = always loads $kernel (as configured in loader.conf(5)) prior to starting th= e menu has to change before this can become a possibility. It's perhaps good that we're having this discussion out in the open now, be= cause I actually (as of yet) do not know if jpaetzel, avg, mav and iX compa= ny have plans to (attempt) to allow kernel swapping in the loader menu. If = that is the case, we'll have to broach the topic of changing that functiona= lity to match what DruidBSD does (defers kernel loading until "boot" is inv= oked). > I'm trying to improve the usability / understandability of the boot > process from an user point of view. Awesome! Something I agree is worthwhile. > I've tried to forget the technical > details and tried to focus on action items an user / minion would like > to do. >=20 Thank you! I think we'll all benefit from this endeavor of discussing these= enhancements in such a clear state. --=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?D2025767-BF06-442D-8A44-316ED91EA0CD>