On Nov 5, 2013, at 9:28 AM, Nathan Whitehorn wrote: > On 11/05/13 11:06, Kurt Lidl wrote: >> >>> You can try enabling the beastie menu on sparc64 by editing >>> /boot/loader.rc: >>> >>> === Change #1 in /boot/loader.rc to enable beastie menu === >>> >>> Find: >>> \ Reads and processes loader.conf variables >>> \ NOTE: Change to `initialize' if you enable the below boot menu >>> start >>> >>> Change "start" to "initialize" as shown below: >>> \ Reads and processes loader.conf variables >>> \ NOTE: Change to `initialize' if you enable the below boot menu >>> initialize >>> >>> === Change #2 in [same file] to enable beastie menu === >>> >>> Find: >>> \ Uncomment to enable boot menu >>> \ include /boot/beastie.4th >>> \ beastie-start >>> >>> Uncomment "beastie-start" as shown below: >>> \ Uncomment to enable boot menu >>> \ include /boot/beastie.4th >>> beastie-start >>> >>> ====== >>> >>> If you find that making those two trivial changes, that you are able >>> to load >>> the menu... then maybe it's time for us to start thinking about >>> enabling the >>> beastie menu by-default for the sparc64 architecture. >> >> Seems to work just fine. I tested by booting, toggling through the >> different kernel choices (/boot/kernel/kernel /boot/kernel.old/kernel) >> and both worked correctly. >> >> (Although I uncommented the "include /boot/beastie.4th" line too.) >> >>> Does anybody else have any thoughts on enabling it for sparc64? >> >> Well, I'd probably be in support of this change - it sure beats having >> to interrupt the normal boot sequence and typing: >> unload >> load /boot/kernel.old/kernel >> load /boot/kernel.old/opensolaris.ko >> load /boot/kernel.old/zfs.ko >> boot >> When I need to get back to the prior version of the kernel. > > Is there a way to make this work even without the beastie menu? A way to > interrupt the boot before kernel load (even holding down a key) would be > really valuable, even on systems that do not support fancy terminals > with colors and such. Nathan, Can you drop into your /boot/loader.conf: loader_delay=3 And reboot? I'm trying to think how we could use that to our advantage. I'm interested in creative applications thereof. For more skinny on what that does... "man delay.4th", it spills the beans on a "delayed command execution" module that I added a few years ago. For example... Here's my idea of making things easier on the user that wants to load a different kernel, but *without* using a menu... 1. We have loader_delay default to 3 2. Dots are displayed for 3 seconds before we do anything (like load a kernel) 3. User presses ENTER during those 3 seconds, and the delay is truncated 4. User presses Ctrl-C during those 3 seconds (or ESC) and they get a prompt (before the kernel has loaded). Then here's what I would do (as to not have to load separate modules)... set kernel=kernel.old boot + The forth code figures out that the kernel is in /boot + If loader.conf had opensolaris_load=YES and + zfs_load=YES then the forth code also loads those from kernel.old But let's say loader.conf was bare, you could do: set kernel=kernel.old set opensolaris_load=YES set zfs_load=YES boot NB: The reason this works is because you would not call "start" in your loader.rc (which actually loads things), but instead "initialize" (which only loads loader.conf et. al.) followed by dc_execute to fire off "autoboot" in 3 seconds (with the aforementioned allowed interrupt ability). Is that what you were thinking? Will that work? Bonus: It would be extremely trivial to implement. -- 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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC