New Boot Loader Menu

[Devin Teske]

On Oct 7, 2012, at 1:01 PM, Alexander Leidinger wrote:

> On Sun, 7 Oct 2012 11:44:25 -0700 Devin Teske
> <devin.teske at fisglobal.com> wrote:
> 
>> On Oct 7, 2012, at 9:34 AM, Alexander Leidinger wrote:
>> 
>>> On Sat, 6 Oct 2012 16:48:50 -0700 Devin Teske
>>> <devin.teske at fisglobal.com> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> I've been working on a new boot loader menu system.
>>>> 
>>>> This is what is in HEAD, CURRENT, and RELENG_9 at the moment:
>>>> 
>>>> http://twitpic.com/b1pkll/full
>>>> in color: http://twitpic.com/b1pkz1/full
>>>> 
>>>> 
>>>> I'd like to propose the following replacement to the above:
>>>> 
>>>> http://twitpic.com/b1pll5/full
>>>> in color: http://twitpic.com/b1plxi/full
>>>> 
>>>> The boot options have been whisked away into a sub-menu (see
>>>> below):
>>>> 
>>>> http://twitpic.com/b1pm51/full
>>>> in color: http://twitpic.com/b1pme8/full
>>>> 
>>>> 
>>>> What does everybody think?
>>> 
>>> 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.
>>> 
>> 
>> The documentation on how to get into single-user mode would need to
>> be changed from:
>> 
>> Press 's' and 'ENTER'
>> 
>> to instead:
>> 
>> Press 'o' then 's' then 'ENTER'
> 
>> Please note that 16+ months ago we had to update the documentation
>> for my last enhancement to the loader menu. It used to be:
>> 
>> Press 's'
>> 
>> and changed to:
>> 
>> Press 's' then 'ENTER'
> 
> 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.
> 
>> 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).
> 
> Let me rephrase my previous mail a little bit:
> 
> 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.
> 
> 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.
> 

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.
> 

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".
> 

Absolutely!

Talking further about the "More" concept, I used to lie awake at night wondering, "what if there are more than a handful of devices to display in a menu w/respect to the ``select root device'' proposition". I came to the same conclusion… the last menu item is a "more" (after all, the latest enhancement 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" functionality 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.
> 

You make a great point. In that spirit, I do very much like the idea of having "Boot Single …" in the "actions" section atop the main menu.



> So basically I propose something like this:
> 
> 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 above 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 the menu" before being dumped to the interactive loader prompt).

The ordering is good. I feel it.



> 
> 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)
> 
> 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.
> 

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 loader.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=YES 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. Thus 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 already-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 example) "kernel.old". I don't always answer with the full breadth of this thread, 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 the 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, because I actually (as of yet) do not know if jpaetzel, avg, mav and iX company 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 functionality to match what DruidBSD does (defers kernel loading until "boot" is invoked).



> 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.
> 

Thank you! I think we'll all benefit from this endeavor of discussing these enhancements in such a clear state.
-- 
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.