From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 21:58:50 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 002AC1065675; Sun, 7 Oct 2012 21:58:49 +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 B66AE8FC1A; Sun, 7 Oct 2012 21:58:49 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa05.fnfis.com (8.14.4/8.14.4) with ESMTP id q97LwnLY003339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 16:58:49 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 7 Oct 2012 16:58:48 -0500 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <20121007220100.00002d21@unknown> Date: Sun, 7 Oct 2012 14:58:46 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <20121007183433.000026a6@unknown> <20121007220100.00002d21@unknown> To: Alexander Leidinger X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-07_05:2012-10-06, 2012-10-07, 1970-01-01 signatures=0 Cc: Devin Teske , freebsd-arch@freebsd.org Subject: Re: New Boot Loader Menu X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 21:58:50 -0000 On Oct 7, 2012, at 1:01 PM, Alexander Leidinger wrote: > On Sun, 7 Oct 2012 11:44:25 -0700 Devin Teske > 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 >>> 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.