Re: [PATCH] Fix kenv(1) output in w/respect to new boot loader variables
On 28 December 2011 05:26, Devin Teske devin.te...@fisglobal.com wrote: D'Oh! Attached wrong (OLD; already applied) patch. Please find appropriate patch attached! Hi. I committed your patch to head as svn r228985. Thank you! -Original Message- From: Devin Teske [mailto:devin.te...@fisglobal.com] Sent: Tuesday, December 27, 2011 5:24 PM To: 'freebsd-hackers@freebsd.org' Cc: Garrett Cooper; devin.te...@fisglobal.com Subject: [PATCH] Fix kenv(1) output in w/respect to new boot loader variables Garrett Cooper and a few others have requested that I write a patch to fix a regression w/respect to kenv(1) output in FreeBSD-9.0 and HEAD. The issue is with the new boot loader menu. It adds many loader variables including ones that contain ANSI color escapes. Obviously, these ANSI codes don't play well with serial consoles when kenv(1) is executed without arguments (reports vary as to what happens, but it's never pretty). Attached is a patch to the Forth code that clears-out the menu-associated variables before invoking the kernel. The net-effect is that kenv(1) no longer reports menu-related variables. In essence, kenv(1) output should now appear the same as on RELENG_8 (which lacks the new boot loader and didn't use any such variables). Thus, restoring serial console glory. -- 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. Great! -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[PATCH] Fix kenv(1) output in w/respect to new boot loader variables
Garrett Cooper and a few others have requested that I write a patch to fix a regression w/respect to kenv(1) output in FreeBSD-9.0 and HEAD. The issue is with the new boot loader menu. It adds many loader variables including ones that contain ANSI color escapes. Obviously, these ANSI codes don't play well with serial consoles when kenv(1) is executed without arguments (reports vary as to what happens, but it's never pretty). Attached is a patch to the Forth code that clears-out the menu-associated variables before invoking the kernel. The net-effect is that kenv(1) no longer reports menu-related variables. In essence, kenv(1) output should now appear the same as on RELENG_8 (which lacks the new boot loader and didn't use any such variables). Thus, restoring serial console glory. -- 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. --- sys/boot/forth/menu.4th.origSat May 28 01:50:38 2011 +++ sys/boot/forth/menu.4th Wed Aug 24 23:46:46 2011 @@ -742,11 +742,10 @@ else -rot 2drop - \ disable timeout if less than zero + \ boot immediately if less than zero dup 0 if drop - 0 menu_timeout_enabled ! - 0 ( assigned to menu_timeout below ) + 0 boot then then then --- sys/boot/forth/menu.4th.8.orig Sat May 28 01:50:38 2011 +++ sys/boot/forth/menu.4th.8 Wed Aug 24 23:45:57 2011 @@ -96,11 +96,15 @@ by default) unless a key is pressed. If set to .Dq Li NO -(case-insensitive) or -.Dq Li -1 , +(case-insensitive) .Ic menu-display will wait for user input and never execute .Ic menu_timeout_command . +If set to +.Dq Li -1 , +.Ic menu-display +will boot immediately, preventing both interruption of the autoboot process and +escaping to the loader prompt. Default is .Dq Li 10 . See ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [PATCH] Fix kenv(1) output in w/respect to new boot loader variables
D'Oh! Attached wrong (OLD; already applied) patch. Please find appropriate patch attached! -Original Message- From: Devin Teske [mailto:devin.te...@fisglobal.com] Sent: Tuesday, December 27, 2011 5:24 PM To: 'freebsd-hackers@freebsd.org' Cc: Garrett Cooper; devin.te...@fisglobal.com Subject: [PATCH] Fix kenv(1) output in w/respect to new boot loader variables Garrett Cooper and a few others have requested that I write a patch to fix a regression w/respect to kenv(1) output in FreeBSD-9.0 and HEAD. The issue is with the new boot loader menu. It adds many loader variables including ones that contain ANSI color escapes. Obviously, these ANSI codes don't play well with serial consoles when kenv(1) is executed without arguments (reports vary as to what happens, but it's never pretty). Attached is a patch to the Forth code that clears-out the menu-associated variables before invoking the kernel. The net-effect is that kenv(1) no longer reports menu-related variables. In essence, kenv(1) output should now appear the same as on RELENG_8 (which lacks the new boot loader and didn't use any such variables). Thus, restoring serial console glory. -- 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. --- src/sys/boot/forth/menu.4th.8.orig Tue Dec 27 11:36:25 2011 +++ src/sys/boot/forth/menu.4th.8 Tue Dec 27 11:41:08 2011 @@ -24,7 +24,7 @@ .\ .\ $FreeBSD: src/sys/boot/forth/menu.4th.8,v 1.2 2011/09/02 19:29:37 jh Exp $ .\ -.Dd Aug 29, 2011 +.Dd Dec 27, 2011 .Dt MENU.4TH 8 .Os .Sh NAME @@ -69,9 +69,13 @@ Calls .Ic menu-erase and then redraws the menu. +.It Ic menu-unset +Unsets the environment variables associated with individual menu items, +clearing the way for a new menu. .It Ic menu-clear -Unsets all possible environment variables used -to configure the menu and then calls +Calls +.Ic menu-unset +and then .Ic menu-erase . .El .Pp --- src/sys/boot/forth/menu.4th.origFri Dec 2 11:17:45 2011 +++ src/sys/boot/forth/menu.4th Tue Dec 27 17:09:04 2011 @@ -131,11 +131,11 @@ \ Print the value of menuidx loader_color? if - . [1m + . [1m ( [22m ) then menuidx @ . loader_color? if - . [37m + . [37m ( [39m ) then \ Move the cursor forward 1 column @@ -897,22 +897,60 @@ ; \ This function unsets all the possible environment variables associated with -\ creating the interactive menu. Call this when you want to clear the menu -\ area in preparation for another menu. +\ creating the interactive menu. \ -: menu-clear ( -- ) +: menu-unset ( -- ) 49 \ Iterator start (loop range 49 to 56; ASCII '1' to '8') begin - \ basename for caption variable - loader_color? if - s ansi_caption[x] - else - s menu_caption[x] - then + \ Unset variables in-order of appearance in menu.4th(8) + + s menu_caption[x] \ basename for caption variable -rot 2dup 13 + c! rot \ replace 'x' with current iteration unsetenv\ not erroneous to unset unknown var + s menu_command[x] \ command basename + -rot 2dup 13 + c! rot \ replace 'x' + unsetenv + + s menu_keycode[x] \ keycode basename + -rot 2dup 13 + c! rot \ replace 'x' + unsetenv + + s ansi_caption[x] \ ANSI caption basename + -rot 2dup 13 + c! rot \ replace 'x' + unsetenv + + s toggled_text[x] \ toggle_menuitem caption basename + -rot 2dup 13 + c! rot \ replace 'x' + unsetenv + + s toggled_ansi[x] \ toggle_menuitem ANSI caption basename + -rot 2dup 13 + c! rot \ replace 'x' + unsetenv + + s menu_caption[x][y] \ cycle_menuitem caption + -rot 2dup 13 + c! rot \ replace 'x' + 49 -rot + begin + 16 2over rot + c! \ replace 'y' + 2dup unsetenv + + rot 1+ dup 56 2swap rot + until + 2drop drop + + s ansi_caption[x][y] \ cycle_menuitem ANSI caption + -rot 2dup 13 + c! rot \ replace 'x' + 49 -rot + begin + 16 2over rot + c! \ replace 'y' + 2dup
Re: [RELEASE] New Boot-Loader Menu bugs?
On Monday, July 18, 2011 3:40:19 am Doug Barton wrote: On 07/17/2011 20:40, Devin Teske wrote: What release are you running? Recent HEAD I upgraded my desktop at home to HEAD yesterday and tested this via a 'boot kernel.GENERIC' at the loader prompt and it did the same as the previous loader (module_path was /boot/kernel.GENERIC;/boot/kernel;/boot/modules), so I think the new boot loader menus work fine in this regard. How exactly are you reproducing your broken case Doug? Do you have any settings in /boot/loader.conf or /boot/loader.conf.local? -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu bugs?
On 07/17/2011 20:40, Devin Teske wrote: What release are you running? Recent HEAD -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[RELEASE] New Boot-Loader Menu bugs?
Last Changed Rev: 224125 Not update share/examples/bootforth/* any files old version loader. file sys/boot/forth/loader.conf ## ### Loader settings ## not actual logo list #loader_logo=fbsdbw # Desired logo: fbsdbw, beastiebw, beastie, none need #loader_logo=orbbw# Desired logo: orb, orbbw, fbsdbw, beastiebw, beastie, none maybe over loader option. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
FW: [RELEASE] New Boot-Loader Menu bugs?
-Original Message- From: Devin Teske [mailto:dte...@vicor.com] Sent: Sunday, July 17, 2011 4:45 PM To: 'Andrey Fesenko'; 'freebsd-hackers@freebsd.org' Cc: Julian Elischer; Teske, Devin (devin.te...@fisglobal.com) Subject: RE: [RELEASE] New Boot-Loader Menu bugs? -Original Message- From: Andrey Fesenko [mailto:f0and...@gmail.com] Sent: Sunday, July 17, 2011 12:33 AM To: freebsd-hackers@freebsd.org; dte...@vicor.com Subject: [RELEASE] New Boot-Loader Menu bugs? Last Changed Rev: 224125 Are you sure that's the right rev? That rev (by dougb) appears to be related to default empty zones in `/etc/namedb/named.conf', and completely unrelated to my rev 222417 (which you appear to be referencing below). Not update share/examples/bootforth/* any files old version loader. file sys/boot/forth/loader.conf ## ### Loader settings ## not actual logo list #loader_logo=fbsdbw # Desired logo: fbsdbw, beastiebw, beastie, none need #loader_logo=orbbw # Desired logo: orb, orbbw, fbsdbw, beastiebw, beastie, none maybe over loader option. It took me awhile, but I think I see what you're saying. That the following patch needs to be applied to head/sys/boot/forth/loader.conf to be consistent with the changes that were made against head/sys/boot/forth/loader.conf.5 (in rev 222417): --- loader.conf.origSun Jul 17 16:37:35 2011 +++ loader.conf Sun Jul 17 16:38:09 2011 @@ -47,7 +47,8 @@ # escape to the loader prompt, set to # NO to disable autobooting #beastie_disable=NO # Turn the beastie boot menu on and off -#loader_logo=fbsdbw # Desired logo: fbsdbw, beastiebw, beastie, none +#loader_logo=orbbw # Desired logo: orb, orbbw, fbsdbw, beastiebw, + # beastie, none #comconsole_speed=9600 # Set the current serial console speed #console=vidconsole # A comma separated list of console(s) #currdev=disk1s1a# Set the current device Does anybody object to the above patch? -- 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FW: [RELEASE] New Boot-Loader Menu bugs?
There also seems to be a bug with the new boot loader that if you bounce out to the prompt and do 'boot kernel.other' the kern.module_path sysctl is not updated. It still lists /boot/kernel first; but that should be replaced by /boot/kernel.other. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu bugs?
On Jul 17, 2011, at 5:08 PM, Doug Barton wrote: There also seems to be a bug with the new boot loader that if you bounce out to the prompt and do 'boot kernel.other' Hmmm... The last change to the FICL word boot was 10 years, 9 months ago, by dcs in version 1.19 of sys/boot/forth/loader.4th. I know that I haven't touched that word, but I'll have to double-check to see if I'm overriding it in any way. I can see by the code in loader.4th that boot will automatically call unload for you if/when an argument is present (e.g., boot kernel.other). I personally have never used that syntax (I've always said unload before-hand), but I will take it from the code that this is supposed to work. the kern.module_path sysctl is not updated. If you want to change module_path for loader(8), you should set it in loader.conf(5). The FICL word start (as seen in /boot/loader.rc) will: (a) read loader.conf(5) and then (b) take your customized module_path and (c) search for a suitable kernel in those directories NOTE: that is, if kernel was not already set -- which it is, by default, to /boot/kernel sysctl(8) is not (and, IIRC, cannot be) influenced by loader environment variables. However, you can retrieve the loader(8) variables via kenv(1). If you wanted to, you could create an rc.d or RCNG script to use kenv(1) to do things with the loader(8) variables (such as drop them into loader.conf(5) or sysctl.conf(5)). Be careful though. It still lists /boot/kernel first; but that should be replaced by /boot/kernel.other. I'm not familiar with the latter behavior. -- 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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu bugs?
Hi Doug, On Jul 17, 2011, at 5:08 PM, Doug Barton wrote: There also seems to be a bug with the new boot loader that if you bounce out to the prompt and do 'boot kernel.other' the kern.module_path sysctl is not updated. It still lists /boot/kernel first; but that should be replaced by /boot/kernel.other. I had a chance to try this out in a VM. I just tested this in FreeBSD 8.1-RELEASE with my loader_menu applied (exactly what's available from rev 222417). The results I get are actually what you describe should happen. Here's the steps I took: 1. Made sure all kernel= and module_path= lines were commented out in loader.conf(5) 2. Moved my kernel to /boot/kernel/kernel 3. Made a copy of my kernel to /boot/kernel2/kernel 4. Rebooted. Didn't touch anything. Verified that when I came up, `sysctl -n kern.bootfile' was /boot/kernel/kernel. Good. We have a baseline operation that things are working as-expected without interrupting the boot-process (that is to say, that loader(8) loaded the kernel in it's default location). 5. Reboot again. This time, I press Escape to the drop to the loader(8) prompt. 6. I took boot /boot/kernel2 7. I see the new kernel being loaded. 8. The kernel executes. 9. My system boots as-expected. 10. The value of sysctl kern.module_path produces (drum roll): /boot/kernel2;/boot/kernel;/boot/modules What release are you running? I can't replicate the bug in 8.1-RELEASE with the new loader menu applied. It's possible that the bug was introduced some other way. -- 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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
On May 4, 2011, at 8:57 AM, Devin Teske wrote: On May 3, 2011, at 9:06 PM, Jason Hellenthal wrote: Devin, On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote: On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote: Devin, On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote: Would be nice: uname -v of the kernel it will boot. That's a bit more technically challenging. I'll have another look at the FICL words available, but I don't recall if there was a way to crawl the object space of the items loaded with ``load'' (looking for the uname). I'm open to suggestions if you had an idea of how to do this in Forth -- else I'd think this would need to be a loader(8) modification. How about forgetting a mention of unmae ... instead look into if we can support some sort of bootcode versioning to be displayed on the screen. This would serve to be very helpful in the future when for say a new version of bootcode for ZFS has to be installed then it would be easy for announce@ to simply say A new version of ZFS has been MFCd and requires boot version = X. To find out your version please see the bottom right hand corner of your boot screen. I would place a pretty good bet that loader(8) could be modified to export some sort of versioning of the bootcode to make this a easier stance for the user to gather information before a upgrade. Piece of cake! If you give me a loader(8) that exports a version environment variable, I'll give the Forth functionality in mere seconds. It's already been developed (but was not packaged). I have a module named version.4th which prints the value of the version environment variable at the bottom-right of the screen underneath the beastie logo. Since you mention this, I'll add the code to the next package and if/when loader(8) ever exports a version environment variable, it will just magically appear. How's that sound? Sounds perfect! One minor adjustment... can we make that environment variable loader_version instead of version? The code is already in for loader_version. Whatever string you export into that environment variable will be displayed on-screen at bottom-right, right-justified. The code for thew new menu has been committed to HEAD. http://svnweb.freebsd.org/base?view=revisionrevision=222417 Now... Who wants to make the necessary patch to loader(8) to export $loader_version text? Or maybe a suggestion on another list worth including on this? -- 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
On 5/29/11 2:53 PM, Devin Teske wrote: On May 4, 2011, at 8:57 AM, Devin Teske wrote: On May 3, 2011, at 9:06 PM, Jason Hellenthal wrote: Devin, On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote: On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote: Devin, On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote: Would be nice: uname -v of the kernel it will boot. That's a bit more technically challenging. I'll have another look at the FICL words available, but I don't recall if there was a way to crawl the object space of the items loaded with ``load'' (looking for the uname). I'm open to suggestions if you had an idea of how to do this in Forth -- else I'd think this would need to be a loader(8) modification. How about forgetting a mention of unmae ... instead look into if we can support some sort of bootcode versioning to be displayed on the screen. This would serve to be very helpful in the future when for say a new version of bootcode for ZFS has to be installed then it would be easy for announce@ to simply say A new version of ZFS has been MFCd and requires boot version= X. To find out your version please see the bottom right hand corner of your boot screen. I would place a pretty good bet that loader(8) could be modified to export some sort of versioning of the bootcode to make this a easier stance for the user to gather information before a upgrade. Piece of cake! If you give me a loader(8) that exports a version environment variable, I'll give the Forth functionality in mere seconds. It's already been developed (but was not packaged). I have a module named version.4th which prints the value of the version environment variable at the bottom-right of the screen underneath the beastie logo. Since you mention this, I'll add the code to the next package and if/when loader(8) ever exports a version environment variable, it will just magically appear. How's that sound? Sounds perfect! One minor adjustment... can we make that environment variable loader_version instead of version? The code is already in for loader_version. Whatever string you export into that environment variable will be displayed on-screen at bottom-right, right-justified. The code for thew new menu has been committed to HEAD. http://svnweb.freebsd.org/base?view=revisionrevision=222417 Now... Who wants to make the necessary patch to loader(8) to export $loader_version text? Or maybe a suggestion on another list worth including on this? I suggest this move to -current since it is checked on there, and a port be kept for 8.x/7.x Devin, a fix was made at 222450 as it was broken for ppc. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
On May 29, 2011, at 6:08 PM, Julian Elischer wrote: On 5/29/11 2:53 PM, Devin Teske wrote: On May 4, 2011, at 8:57 AM, Devin Teske wrote: On May 3, 2011, at 9:06 PM, Jason Hellenthal wrote: Devin, On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote: On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote: Devin, On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote: Would be nice: uname -v of the kernel it will boot. That's a bit more technically challenging. I'll have another look at the FICL words available, but I don't recall if there was a way to crawl the object space of the items loaded with ``load'' (looking for the uname). I'm open to suggestions if you had an idea of how to do this in Forth -- else I'd think this would need to be a loader(8) modification. How about forgetting a mention of unmae ... instead look into if we can support some sort of bootcode versioning to be displayed on the screen. This would serve to be very helpful in the future when for say a new version of bootcode for ZFS has to be installed then it would be easy for announce@ to simply say A new version of ZFS has been MFCd and requires boot version= X. To find out your version please see the bottom right hand corner of your boot screen. I would place a pretty good bet that loader(8) could be modified to export some sort of versioning of the bootcode to make this a easier stance for the user to gather information before a upgrade. Piece of cake! If you give me a loader(8) that exports a version environment variable, I'll give the Forth functionality in mere seconds. It's already been developed (but was not packaged). I have a module named version.4th which prints the value of the version environment variable at the bottom-right of the screen underneath the beastie logo. Since you mention this, I'll add the code to the next package and if/when loader(8) ever exports a version environment variable, it will just magically appear. How's that sound? Sounds perfect! One minor adjustment... can we make that environment variable loader_version instead of version? The code is already in for loader_version. Whatever string you export into that environment variable will be displayed on-screen at bottom-right, right-justified. The code for thew new menu has been committed to HEAD. http://svnweb.freebsd.org/base?view=revisionrevision=222417 Now... Who wants to make the necessary patch to loader(8) to export $loader_version text? Or maybe a suggestion on another list worth including on this? I suggest this move to -current since it is checked on there, and a port be kept for 8.x/7.x Devin, a fix was made at 222450 as it was broken for ppc. Regarding fix 222450: Oops. Slight oversight. Thanks for the one-liner fix. Looks like we'll have to do the same thing for the following: sys/boot/ia64/common/Makefile sys/boot/powerpc/ps3/Makefile sys/boot/sparc64/loader/Makefile Here's a patch that can be applied by anyone willing: http://druidbsd.sourceforge.net/download/loader_menu-1.6.1-HEAD20110521092952-fixup.patch -- 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[RELEASE] New Boot-Loader Menu -- version 1.6
Hi Hackers, I'm pleased to announce version 1.6 of my new boot loader menu software. NOTE: Version 1.6 has the same look and feel as version 1.5. No new screenshots needed. This is a general cleanup with the below notable changes: 1. Change chkpassword.4th to query password environment variable instead of loader_password (for backward compatibility) 2. Rename chkpasswd function in chkpassword.4th to check-password (for backward compatibility) 3. Rename chkpassword.4th to check-password.4th (for consistency) 4. Replace conflicting check-password function in /boot/loader.4th with include /boot/check-password.4th 5. Remove conflicting password routines from /boot/support.4th 6. [Re-]Implement beastie-start in beastie.4th (for backward compatibility) 7. Replace loader.rc in the package with the default version provided on i386-compatible installs 8. Remove default delay in loading /boot/menu.rc (still available by setting loader_delay in loader.conf(5) but disabled by default now) 9. Add $FreeBSD$ CVS keywords in preparation of commit to HEAD 10. Fix a couple typos in comments 11. Add support for autoboot_delay=NO or autoboot_delay=-1 in menu.4th to disable the menu timeout 12. Add missing cleanup routine to menu-clear in menu.4th 13. Add the following manpages: /usr/share/man/man8/beastie.4th.8.gz /usr/share/man/man8/brand.4th.8.gz /usr/share/man/man8/check-password.4th.8.gz /usr/share/man/man8/color.4th.8.gz /usr/share/man/man8/delay.4th.8.gz /usr/share/man/man8/menu.4th.8.gz /usr/share/man/man8/version.4th.8.gz 14. Update loader.conf.5 manpage to include documentation on new loader_logo values (``orb'' and ``orbbw''), also documenting the new default (orbbw). You can get your update from either: http://druidbsd.sourceforge.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.6.tgz -- 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu -- version 1.5
On Sat, May 14, 2011 at 9:36 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: My main idea is that the present Boot-Loader Menu -- version 1.5 is a very good menu . Instead of destroying its elegant structure , the already available FreeBSD Boot Loader ( actually Kernel selection ) menu could be improved and may be used IF IT IS SUITABLE for the USER ( otherwise the user may not select it during installation ) . I disagree entirely, the boot loader knows nothing of kernels, it only presents the bootable drives/partitions as the BIOS sees it. Calling the boot loader a kernel selection menu is disingenuous, since this is simply a by-product of having different kernels on different drives/partitions, whilst the most commonly desired kernel selection (kernel vs kernel.old) is not available via this method. Cheers Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu -- version 1.5
on 16/05/2011 14:34 Tom Evans said the following: I disagree entirely, the boot loader knows nothing of kernels Eh? Maybe I misunderstand what you are saying, but: set kernel=kernel.old boot IMHO, it shows that you can tell the loader about kernels. Having a kernel-choice sub-menu would be convenient. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu -- version 1.5
On Mon, May 16, 2011 at 1:50 PM, Andriy Gapon a...@freebsd.org wrote: on 16/05/2011 14:34 Tom Evans said the following: I disagree entirely, the boot loader knows nothing of kernels Eh? Maybe I misunderstand what you are saying, but: set kernel=kernel.old boot IMHO, it shows that you can tell the loader about kernels. Having a kernel-choice sub-menu would be convenient. s/boot loader/boot manager/ My bad for the confusion. The loader should definitely know about kernels; the boot manager, which knows about BIOS bootable drives/partitions only, should not. Cheers Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu -- version 1.5
Hi, this looks very promising! 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? Its difficult to handle manually in the loader (esp. handling the zpool.cache file ) and I got bitten by this issue recently in a ZFS only environment. Thanks in advance! Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu -- version 1.5
On Sat, May 14, 2011 at 3:15 AM, Michael Reifenberger m...@reifenberger.com wrote: Hi, this looks very promising! 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? Its difficult to handle manually in the loader (esp. handling the zpool.cache file ) and I got bitten by this issue recently in a ZFS only environment. Thanks in advance! Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com 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 directly from boot sector . 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 described Boot Loader menu . My opinion is that , they should NOT be COMBINED into one single menu , because , in the same system , even there may be other kernels to be booted . Some operating systems , such as OpenSolaris and Mandriva Linux , after updating the kernel , they are keeping previous kernel in the Kernel Selection menu , under the new kernel name item . Such a system may be employed for the FreeBSD : If a kernel.old is generated , it may be inserted into Kernel Selection menu automatically . If , at present , there is no kernel selection menu but boot sector is used directly , kernel build system may modify that structure also to utilize a Kernel Selection menu . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu -- version 1.5
On May 14, 2011, at 8:14 AM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com
wrote:
On Sat, May 14, 2011 at 3:15 AM, Michael Reifenberger m...@reifenberger.com
wrote:
Hi,
this looks very promising!
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?
Its difficult to handle manually in the loader (esp. handling the zpool.cache
file ) and I got bitten by this issue recently in a ZFS only environment.
Thanks in advance!
Bye/2
---
Michael Reifenberger
mich...@reifenberger.com
http://www.Reifenberger.com
There have been suggestions from many regarding kernel selection and even
root selection options. I've responded in earnest on at least one such
suggestion (stating that there are plans to incorporate these features at some
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 enumerated below:
1. Currently, the start FICL word provided by
/usr/src/sys/boot/forth/loader.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 change
the overloaded boot word to load the kernel prior to calling the built-in
boot ( N -- ) construct.
2. A non-trivial amount of Forth will need to be written to probe for a list 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 of 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
directly from boot sector .
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
described Boot Loader menu .
My opinion is that , they should NOT be COMBINED into one single menu ,
because , 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 community
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-selection 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 to
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 are
knobs in the boot menu (both old and new -- and more than can fit on a single
screen even). Such as boot_ddb, boot_gdb, boot_multicons, boot_mute,
boot_pause, boot_serial, and comconsole_speed. That's 7 additional options that
would likely be a good candidate for a side menu (perhaps a More Options
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
(respectively) boot_askname, boot_cdrom and boot_dfltroot. See loader(8)
for additional details.
Some operating systems , such as OpenSolaris and Mandriva Linux , after
updating the kernel , they are keeping previous kernel in the Kernel
Selection menu , under the new kernel name item .
I've often felt that this could be improved upon by the Linux community. IMHO
neither Grub nor LiLo present a user-friendly way of setting options for the
selected kernel and concurrently leaves many Linux desktop-users befuddled and
uninterested. The use-case is taking a box into single-user mode: FreeBSD
achieves this with either one keystroke (current loader menu) or two (code
being committed to HEAD; e.g., s, ENTER); compare that with the steps required
to boot Linux into single-user mode from either LiLo or Grub (disclaimer: 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 into
single-user mode, note that not everybody is so fortunate (either because of
their distro or due to lack of manual configuration). Even still, a variable
amount of cursor/arrow keys must be depressed
Re: [RELEASE] New Boot-Loader Menu -- version 1.5
On Sat, May 14, 2011 at 2:53 PM, Devin Teske dte...@vicor.com wrote:
On May 14, 2011, at 8:14 AM, Mehmet Erol Sanliturk
m.e.sanlit...@gmail.com wrote:
On Sat, May 14, 2011 at 3:15 AM, Michael Reifenberger m...@reifenberger.com
m...@reifenberger.com wrote:
Hi,
this looks very promising!
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?
Its difficult to handle manually in the loader (esp. handling the
zpool.cache file ) and I got bitten by this issue recently in a ZFS only
environment.
Thanks in advance!
Bye/2
---
Michael Reifenberger
mich...@reifenberger.commich...@reifenberger.com
http://www.Reifenberger.comhttp://www.Reifenberger.com
There have been suggestions from many regarding kernel selection and even
root selection options. I've responded in earnest on at least one such
suggestion (stating that there are plans to incorporate these features at
some 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
enumerated below:
1. Currently, the start FICL word provided by
/usr/src/sys/boot/forth/loader.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
change the overloaded boot word to load the kernel prior to calling the
built-in boot ( N -- ) construct.
2. A non-trivial amount of Forth will need to be written to probe for a
list 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 of
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
directly from boot sector .
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
described Boot Loader menu .
My opinion is that , they should NOT be COMBINED into one single menu ,
because , 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
community 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-selection 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
to 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
are knobs in the boot menu (both old and new -- and more than can fit on a
single screen even). Such as boot_ddb, boot_gdb, boot_multicons, boot_mute,
boot_pause, boot_serial, and comconsole_speed. That's 7 additional options
that would likely be a good candidate for a side menu (perhaps a More
Options 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
(respectively) boot_askname, boot_cdrom and boot_dfltroot. See
loader(8) for additional details.
Some operating systems , such as OpenSolaris and Mandriva Linux , after
updating the kernel , they are keeping previous kernel in the Kernel
Selection menu , under the new kernel name item .
I've often felt that this could be improved upon by the Linux community.
IMHO neither Grub nor LiLo present a user-friendly way of setting options
for the selected kernel and concurrently leaves many Linux desktop-users
befuddled and uninterested. The use-case is taking a box into single-user
mode: FreeBSD achieves this with either one keystroke (current loader menu)
or two (code being committed to HEAD; e.g., s, ENTER); compare that with
the steps required to boot Linux into single-user mode from either LiLo or
Grub (disclaimer: 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
into single-user mode, note that not everybody is so
[RELEASE] New Boot-Loader Menu -- version 1.5
Happy to bring to you version 1.5 of my loader_menu package. This version incorporates the suggestions first made by Lan Qing and then re-affirmed by (in-order) Alexander Leidinger, Dieter BSD, and Julian Elischer (whom brings word from the devsummit as well as Warner Losh): you guys want to separate the boot actions from the boot options, and now it's accomplished. Here's how the re-arrangement looks for each of the different loader environments... i386-compatible hardware with ACPI support: http://twitpic.com/4wvls8 http://twitpic.com/4wvn0f (color) i386-compatible hardware without ACPI support: http://twitpic.com/4wvmod http://twitpic.com/4wvn0f (color) non-i386 hardware (such as IA64, PPC, etc.): http://twitpic.com/4wvne3 http://twitpic.com/4wvod5 (color) Here's the links: http://druidbsd.sourceforge.net/download/loader_menu-1.5.tgz or http://druidbsd.sourceforge.net/ Here's a diff of the changes: diff -rNup loader_menu-1.4/+CONTENTS loader_menu-1.5/+CONTENTS --- loader_menu-1.4/+CONTENTS 2011-05-05 00:47:31.0 -0700 +++ loader_menu-1.5/+CONTENTS 2011-05-12 16:07:11.0 -0700 @@ -1,5 +1,5 @@ @comment PKG_FORMAT_REVISION:1.1 -@name loader_menu-1.4 +@name loader_menu-1.5 @comment ORIGIN:sysutils/loader_menu @cwd /boot beastie.4th @@ -17,9 +17,9 @@ loader.rc menu-commands.4th @comment MD5:0999bd50b8395098bd6bcf9165db4d7b menu.4th -@comment MD5:26a61c0ea268334687a63e07b0d708d8 +@comment MD5:3b97638b4a5608fab425e2751d386c14 menu.rc -@comment MD5:dcf2993118b991f57b4ab0659d2712ae +@comment MD5:f682160708bcf5a537421ab09ce51660 shortcuts.4th @comment MD5:9a5ed52548bbbaf67ad613e37d0e4b58 version.4th @@ -30,7 +30,7 @@ version.4th @comment MD5:69903862d8df34df77522792172b0999 @ignore +DESC -@comment MD5:d18419e5babe54b7cc195da7f7f5ac86 +@comment MD5:597ef7a6779d9e083140eaa985fc1ee1 @ignore +INSTALL @comment MD5:76c98eb5e084871d9fe5d4fa4511d8c5 diff -rNup loader_menu-1.4/+DESC loader_menu-1.5/+DESC --- loader_menu-1.4/+DESC 2011-05-04 12:11:31.0 -0700 +++ loader_menu-1.5/+DESC 2011-05-12 13:50:40.0 -0700 @@ -91,6 +91,11 @@ loader_delay=N until booting the loaded kernel). During the autoboot sequence, any key pressed except for ENTER will allow escaping to the loader prompt. +loader_menu_title=... + + Overrides the default title (Welcome to FreeBSD) displayed above the + dynamic menu. + WWW: http://druidbsd.sourceforge.net/ diff -rNup loader_menu-1.4/menu.4th loader_menu-1.5/menu.4th --- loader_menu-1.4/menu.4th2011-05-05 00:33:13.0 -0700 +++ loader_menu-1.5/menu.4th2011-05-12 16:07:06.0 -0700 @@ -75,7 +75,9 @@ variable menukey6 variable menukey7 variable menukey8 variable menureboot +variable menurebootadded variable menuacpi +variable menuoptions \ Menu timer [count-down] variables variable menu_timeout_enabled \ timeout state (internal use only) @@ -439,7 +441,10 @@ create init_text8 255 allot : menu-create ( -- ) \ Print the frame caption at (x,y) - 11 9 at-xy . FreeBSD Kernel Options + s loader_menu_title getenv dup -1 = if + drop s Welcome to FreeBSD + then + 24 over 2 / - 9 at-xy type \ Print our menu options with respective key/variable associations. \ `printmenuitem' ends by adding the decimal ASCII value for the @@ -478,8 +483,39 @@ create init_text8 255 allot then then + \ + \ Initialize the menu_options visual separator. + \ + 0 menuoptions ! + s menu_options getenv -1 if + c@ dup 48 over 57 and if ( '1' = c1 = '8' ) + menuoptions ! + else + drop + then + then + + \ Initialize Reboot menu state variable (prevents double-entry) + false menurebootadded ! + 49 \ Iterator start (loop range 49 to 56; ASCII '1' to '8') begin + \ If the Options: separator, print it. + dup menuoptions @ = if + \ Optionally add a reboot option to the menu + s menu_reboot getenv -1 if + drop + s Reboot printmenuitem menureboot ! + true menurebootadded ! + then + + menuX @ + menurow @ 2 + menurow ! + menurow @ menuY @ + + at-xy + . Options: + then + \ If this is the ACPI menu option, act accordingly. dup menuacpi @ = if acpimenuitem ( -- C-Addr | -1 ) @@ -520,14 +556,16 @@ create init_text8 255 allot drop \ iterator \ Optionally add a reboot option to the menu - s menu_reboot getenv -1 if - drop \ no need for the value - s Reboot \ menu
RE: [RELEASE] New Boot-Loader Menu -- version 1.5
-Original Message- From: Devin Teske [mailto:dte...@vicor.com] Sent: Friday, May 13, 2011 6:22 PM To: freebsd-hackers@freebsd.org Cc: '兰清'; 'Alexander Leidinger'; 'Dieter BSD'; Teske, Devin (devin.te...@fisglobal.com); Julian Elischer (jelisc...@fusionio.com); 'Warner Losh' Subject: [RELEASE] New Boot-Loader Menu -- version 1.5 Happy to bring to you version 1.5 of my loader_menu package. This version incorporates the suggestions first made by Lan Qing and then re-affirmed by (in- order) Alexander Leidinger, Dieter BSD, and Julian Elischer (whom brings word from the devsummit as well as Warner Losh): you guys want to separate the boot actions from the boot options, and now it's accomplished. Here's how the re-arrangement looks for each of the different loader environments... i386-compatible hardware with ACPI support: http://twitpic.com/4wvls8 http://twitpic.com/4wvm73 (color) i386-compatible hardware without ACPI support: http://twitpic.com/4wvmod http://twitpic.com/4wvn0f non-i386 (such as IA64, PPC, etc.): http://twitpic.com/4wvne3 http://twitpic.com/4wvod5 (color) NOTE: Previous links were incorrect. Above are the correct links to the correct images. -- 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [UPDATE] New Boot-Loader Menu -- version 1.3
On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote: Devin Teske dte...@vicor.com wrote: Hey all, Proud to bring you version 1.3 which completes the followup suggestions made by Olivier Smedts (use autoboot_delay instead of loader_menu_timeout and change dc_seconds to loader_delay) and a couple other minor enhancements/fixes. I think that brings everything up to speed with the phenomenal feedback provided so far. Really, thank you all very much. Get your update at http://druidbsd.sf.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz Devin, have you thought about writing a port [1]? I'd be happy to review it: [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html I'm going to see if I can't make it perfectly acceptable for base first. If the final version gets rejected for submission to base, I'll turn to ports. On a side-note, it'd be a pretty interesting port... considering the fact that I'm already distributing it as a FreeBSD package (what would the Makefile for that port look like... a call to fetch followed by a call to pkg_add ?? lol -- are there other ports that already work like that?). -- 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.3
On May 12, 2011, at 2:14 PM, Devin Teske wrote: On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote: Devin Teske dte...@vicor.com wrote: Hey all, Proud to bring you version 1.3 which completes the followup suggestions made by Olivier Smedts (use autoboot_delay instead of loader_menu_timeout and change dc_seconds to loader_delay) and a couple other minor enhancements/fixes. I think that brings everything up to speed with the phenomenal feedback provided so far. Really, thank you all very much. Get your update at http://druidbsd.sf.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz Devin, have you thought about writing a port [1]? I'd be happy to review it: [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html I'm going to see if I can't make it perfectly acceptable for base first. If the final version gets rejected for submission to base, I'll turn to ports. On a side-note, it'd be a pretty interesting port... considering the fact that I'm already distributing it as a FreeBSD package (what would the Makefile for that port look like... a call to fetch followed by a call to pkg_add ?? lol -- are there other ports that already work like that?). In the FreeBSD developer's summit today, there was broad support for bringing it into base for 9.0. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.3
On 5/12/11 2:14 PM, Devin Teske wrote: On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote: Devin Teskedte...@vicor.com wrote: Hey all, Proud to bring you version 1.3 which completes the followup suggestions made by Olivier Smedts (use autoboot_delay instead of loader_menu_timeout and change dc_seconds to loader_delay) and a couple other minor enhancements/fixes. I think that brings everything up to speed with the phenomenal feedback provided so far. Really, thank you all very much. Get your update at http://druidbsd.sf.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz Devin, have you thought about writing a port [1]? I'd be happy to review it: port would be good for 8 it'll be in 9 by default (we just decided a the devsummit) (if there are no roadblocks) [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html I'm going to see if I can't make it perfectly acceptable for base first. If the final version gets rejected for submission to base, I'll turn to ports. On a side-note, it'd be a pretty interesting port... considering the fact that I'm already distributing it as a FreeBSD package (what would the Makefile for that port look like... a call to fetch followed by a call to pkg_add ?? lol -- are there other ports that already work like that?). Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
Kris Moore CC'ed
On Mon, May 09, 2011 at 10:41:40AM -0700, Devin Teske wrote:
-Original Message-
From: Lars Engels [mailto:lars.eng...@0x20.net]
Sent: Monday, May 09, 2011 2:19 AM
To: Devin Teske
Cc: FreeBSD Hackers
Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On Thu, May 05, 2011 at 01:20:43AM -0700, Devin Teske wrote:
Hello fellow -hackers,
I'm so very proud to offer the latest update to my new boot loader
menu -- version 1.4 -- addressing ACPI detection, bringing it in-line
with HEAD.
It took some work and a few days, but I got it! Have a look below for
six different displays (three different scenarios -- i386 w/ ACPI,
i386 w/o ACPI, and non-i386 -- each in both BW and Color).
Hi Devin,
PC-BSD also has a slightly patched loader menu compared to the stock FreeBSD
version.
Does PC-BSD have CVSweb that I can browse? Link?
http://trac.pcbsd.org/browser/pcbsd/current/system-overlay/boot
I.E. you can also set unset verbose mode and ACPI with it.
Some days ago there was a proposal on a PC-BSD list to add an option to
boot a
different kernel if one is found in /boot.
Would it be possible to addi this function to your boot menu?
No need. The basic constructs are there already, we just need to expand on
them.
Here's how I've implemented a hard-coded list of kernels to choose from for
our systems (to be implemented in /boot/menu.rc):
\ Set kernel paths (see menu_caption[2] below)
set kernel_prefix=/kernels/
\ NOTE: We like to keep our kernels in `/kernels'
set kernel[0]=FIS-i386-8.1p1
set kernel[1]=GENERIC-i386-8.1p1
set kernel_suffix=.kgz
\ NOTE: This is on our CD/DVD, so kernels are kgzip(8)'d
\ Set default boot kernel
set kernel=${kernel_prefix}${kernel[0]}${kernel_suffix}
\ Initialize main menu constructs (variables are read by `menu.4th')
set menu_caption[1]=Boot [ENTER]
set menu_command[1]=boot
set menu_caption[2][0]=Kernel: ${kernel[0]} (1of2)
set menu_caption[2][1]=Kernel: ${kernel[1]} (2of2)
set menu_caption[2]=${menu_caption[2][0]}
set menu_command[2]=cycle_kernel
\ ... rest of menu ...
The magic is the cycle_kernel command (see `/boot/menu.4th'). The
`cycle_kernel' command is a wrapper to the `cycle_menuitem' command (similar
to how `toggle_verbose', `toggle_acpi', and `toggle_singleuser' are wrappers
to the `toggle_menuitem' command). Like the `toggle_menuitem' command, the
`cycle_menuitem' command uses a system of internal state variables to track
which menuitem text is to be displayed for that individual menuitem. Whereas
the `toggle_menuitem' command automatically toggles the text of a menuitem
between the `menu_caption[x]' and `toggled_text[x]' variables, the
`cycle_menuitem' command automatically cycles through the
`menu_caption[x][y]' variables, cycling back to y=0 when it gets to an
undefined `y' value.
However, hard-coding an alternate kernel choice is something that I wouldn't
condone for an actual release. Instead, what I would recommend is to
dynamically allocate the kernel menu if/when multiple kernels are
discovered/configured. That's something that is currently not coded (dynamic
detection of kernels in /boot).
Or even better
work together with Kris Moore so we don't have two solutions for the same
task?
I'd like to open a discussion with Kris Moore on how we could go about
detecting additional kernels.
Off the top of my head, here's a couple thoughts:
a. We could test a battery of different kernel names (kernel, kernel.bak,
kernel.orig, etc.)
b. We could allow the user to set kernel1, kernel2, kernel3, etc. in
loader.conf(5)
c. We could allow the user to set kernel=kernel1;kernel2;kernel3;... in
loader.conf(5)
d. Some combination of the above.
--
Devin
P.S. I think it'd also be nice to someday offer the user a choice of booting
into a memory filesystem for rescue purposes. We've offered this to our users
for years with the following configuration:
set root[0]=
set root[1]=rescue_mfsroot
set menu_caption[7][0]=Root Image: Default (1of2)
set menu_caption[7][1]=Root Image: Rescue (2of2)
set menu_caption[7]=${menu_caption[7][0]}
set menu_command[7]=cycle_root
Good idea! :-)
pgpRnhpUhwmGX.pgp
Description: PGP signature
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On Thu, May 05, 2011 at 01:20:43AM -0700, Devin Teske wrote: Hello fellow -hackers, I'm so very proud to offer the latest update to my new boot loader menu -- version 1.4 -- addressing ACPI detection, bringing it in-line with HEAD. It took some work and a few days, but I got it! Have a look below for six different displays (three different scenarios -- i386 w/ ACPI, i386 w/o ACPI, and non-i386 -- each in both BW and Color). Hi Devin, PC-BSD also has a slightly patched loader menu compared to the stock FreeBSD version. I.E. you can also set unset verbose mode and ACPI with it. Some days ago there was a proposal on a PC-BSD list to add an option to boot a different kernel if one is found in /boot. Would it be possible to addi this function to your boot menu? Or even better work together with Kris Moore so we don't have two solutions for the same task? Lars pgpTDrYVktqJU.pgp Description: PGP signature
RE: [UPDATE] New Boot-Loader Menu -- version 1.4
-Original Message-
From: Lars Engels [mailto:lars.eng...@0x20.net]
Sent: Monday, May 09, 2011 2:19 AM
To: Devin Teske
Cc: FreeBSD Hackers
Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On Thu, May 05, 2011 at 01:20:43AM -0700, Devin Teske wrote:
Hello fellow -hackers,
I'm so very proud to offer the latest update to my new boot loader
menu -- version 1.4 -- addressing ACPI detection, bringing it in-line
with HEAD.
It took some work and a few days, but I got it! Have a look below for
six different displays (three different scenarios -- i386 w/ ACPI,
i386 w/o ACPI, and non-i386 -- each in both BW and Color).
Hi Devin,
PC-BSD also has a slightly patched loader menu compared to the stock FreeBSD
version.
Does PC-BSD have CVSweb that I can browse? Link?
I.E. you can also set unset verbose mode and ACPI with it.
Some days ago there was a proposal on a PC-BSD list to add an option to boot a
different kernel if one is found in /boot.
Would it be possible to addi this function to your boot menu?
No need. The basic constructs are there already, we just need to expand on them.
Here's how I've implemented a hard-coded list of kernels to choose from for our
systems (to be implemented in /boot/menu.rc):
\ Set kernel paths (see menu_caption[2] below)
set kernel_prefix=/kernels/
\ NOTE: We like to keep our kernels in `/kernels'
set kernel[0]=FIS-i386-8.1p1
set kernel[1]=GENERIC-i386-8.1p1
set kernel_suffix=.kgz
\ NOTE: This is on our CD/DVD, so kernels are kgzip(8)'d
\ Set default boot kernel
set kernel=${kernel_prefix}${kernel[0]}${kernel_suffix}
\ Initialize main menu constructs (variables are read by `menu.4th')
set menu_caption[1]=Boot [ENTER]
set menu_command[1]=boot
set menu_caption[2][0]=Kernel: ${kernel[0]} (1of2)
set menu_caption[2][1]=Kernel: ${kernel[1]} (2of2)
set menu_caption[2]=${menu_caption[2][0]}
set menu_command[2]=cycle_kernel
\ ... rest of menu ...
The magic is the cycle_kernel command (see `/boot/menu.4th'). The
`cycle_kernel' command is a wrapper to the `cycle_menuitem' command (similar to
how `toggle_verbose', `toggle_acpi', and `toggle_singleuser' are wrappers to
the `toggle_menuitem' command). Like the `toggle_menuitem' command, the
`cycle_menuitem' command uses a system of internal state variables to track
which menuitem text is to be displayed for that individual menuitem. Whereas
the `toggle_menuitem' command automatically toggles the text of a menuitem
between the `menu_caption[x]' and `toggled_text[x]' variables, the
`cycle_menuitem' command automatically cycles through the `menu_caption[x][y]'
variables, cycling back to y=0 when it gets to an undefined `y' value.
However, hard-coding an alternate kernel choice is something that I wouldn't
condone for an actual release. Instead, what I would recommend is to
dynamically allocate the kernel menu if/when multiple kernels are
discovered/configured. That's something that is currently not coded (dynamic
detection of kernels in /boot).
Or even better
work together with Kris Moore so we don't have two solutions for the same
task?
I'd like to open a discussion with Kris Moore on how we could go about
detecting additional kernels.
Off the top of my head, here's a couple thoughts:
a. We could test a battery of different kernel names (kernel, kernel.bak,
kernel.orig, etc.)
b. We could allow the user to set kernel1, kernel2, kernel3, etc. in
loader.conf(5)
c. We could allow the user to set kernel=kernel1;kernel2;kernel3;... in
loader.conf(5)
d. Some combination of the above.
--
Devin
P.S. I think it'd also be nice to someday offer the user a choice of booting
into a memory filesystem for rescue purposes. We've offered this to our users
for years with the following configuration:
set root[0]=
set root[1]=rescue_mfsroot
set menu_caption[7][0]=Root Image: Default (1of2)
set menu_caption[7][1]=Root Image: Rescue (2of2)
set menu_caption[7]=${menu_caption[7][0]}
set menu_command[7]=cycle_root
_
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On Sun, 8 May 2011 13:45:55 -0700 Devin Teske dte...@vicor.com wrote: On May 8, 2011, at 12:13 PM, Alexander Leidinger wrote: On Sun, 8 May 2011 10:48:55 -0700 Devin Teske dte...@vicor.com wrote: I would like to see general consensus from the community for separating the items before moving ahead with such a non-trivial change. IMO: - I agree that there are two different types of actions - having 2 distinct blocks looks like a good idea to me (I didn't had a look at the code, if you only have the text in the variables and the numbers get added automatically, maybe you can add variables for inbetween items which are pure text and do not get a number, and they are not displayed if the variable is empty) - I do not think that we need two different namespaces here - reorder the items, use incrementing numbers no matter which type it is (ACPI would be number 4 in the example then) All-in-all, I love the suggestion. A few notes: - I also agree that there are two different types of actions - Significant changes would need to be made. - I'd like to take the gradual approach - You're right, it could be done without two different namespaces However, there's one very important fact... The current menu is numbers only which means that people that use the menu often will be impacted in a non-trivial way if we re-order the numbers. The gradual approach would have us accept a new menu (such as loader_menu-1.4) that enables the use of hotkeys. Get people used to using the hotkeys for awhile before re-ording (or perhaps even taking-away) the numbers. What do you think of the gradual approach? If you want to spend some years... IMO it's either - change now or - no change, never ever or - change if special variable is set I do not think it is really an option to change it only for new installs but keep the numbers for installed ones as they are (if there is a way to do this). I also think that there will always be some people which never switch to hotkeys. FYI: I never got the numbers into my brain, I always use SPACE to pause and then read which number to press. This could be because I do not (re)boot systems much, but I expect/hope that there are more people which do the same. With the hotkeys this may change, as they are easy to associate with the English word for the action. I'm all for gradual improvements, but there are things which can not be done gradually. This usability improvement is one of the later ones IMO. If nobody complains that such a separation is very hard to get and that it is too hard to press SPACE and that the ordering of the new entries can only be provided by someone with a twisted brain, I would do it, as it looks like very good and better understandable usability improvement which should get new users (to FreeBSD but maybe not to the Unix way) to better get suited with FreeBSD. Maybe an explicit variable to set to go back to the old order if there are too much voices which tell it would violate POLA? Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On Mon, 9 May 2011, Alexander Leidinger wrote: IMO it's either - change now or - no change, never ever or - change if special variable is set In case it hasn't already been suggested... Just make the loader read a template file that defines the menu. The port or base system can include a standard menu file, and everyone else can set it up however they want. As an example, see syslinux or grub or any number of similar boot menus. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On May 7, 2011, at 8:24 PM, 兰清 wrote: Hi Devin, Hi Lan, This loader menu is awesome! Thank you. But as I opinion, items (1,6,7) and (2,3,4,5) are two different thing. Hmmm. You're right. 1.Boot[Enter] 6.Escape to loader prompt 7.Reboot These options are booting action. Interesting idea to group them that way. 2.ACPI Support 3.Boot Safe Mode 4.Boot Single User 5.Boot Verbose These options are booting configures. I follow you so far. Separate them will be better, like this - | 1.Boot | | 2.Prompt | | 3.Reboot | | | |Configuration: | | 1.ACPI Support | | 2.Safe Mode | | 3.Single User Mode | | 4.Verbose Boot Mode | |---| Do you think so? That's an interesting idea, and I gave it some good thought... until... I realized that if you pressed 1 on the keyboard, would it boot or would it toggle ACPI Support. To implement a dual-menu system, either the numbers would have to go entirely, or the numbers would have to not overlap. The code is not currently situated to do any of the following which would be required to implement what you're recommending above (either as a single-menu or as a dual-menu with non-overlapping menuitem keycodes): 1. Not currently possible to display two menus simultaneously (only one getkey function can be waiting for keyboard input at once, so [a] either the menu-init or menu-create function would need to be rewritten to dynamically allocate variables rather than using static identifiers, [b] the menu-create function would need to change scope to allow multiple menus to be defined each with their own unique properties including captions and position, and [c] the menu-display function would need to test keycodes for multiple menus that were generated by menu-create -- all of which are contained within /boot/menu.4th). 2. Not currently possible (with a single menu) to display a gap. Even defining a NULL caption will still cause the number to be printed to the left of the menuitem. Though I'm sure with a trivial tweak to printmenuitem (in /boot/menu.4th), checking the length identifier of the C-Addr couplet to be non-zero on the stack prior to dropping the dup'd menuidx to screen should suffice. However, even if you do that, you would then come to your next challenge... 3. The menu does not support tiered captions. In your example above, you've got Configuration: as a header for the remaining four options. That header would have to be printed manually in fourth (e.g., ``: cap ( X Y -- ) at-xy . Configuration: ; 4 17 cap'') Numbers 2 and 3 are easy enough to overcome, but there's currently strong motivation to keep the menu recognizable and in the same order for long-time users. Given said motivation in-addition to the only two major short-comings of your proposal: - The two menus have overlapping numbers - The menu system does not support multiple (separate/simultaneous) menus I would like to see general consensus from the community for separating the items before moving ahead with such a non-trivial change. I thank you for your suggestion and appreciate the effort you put into it. -- Cheers, Devin At 2011-05-05 16:20:43，Devin Teske dte...@vicor.com wrote: Hello fellow -hackers, I'm so very proud to offer the latest update to my new boot loader menu -- version 1.4 -- addressing ACPI detection, bringing it in-line with HEAD. It took some work and a few days, but I got it! Have a look below for six different displays (three different scenarios -- i386 w/ ACPI, i386 w/o ACPI, and non-i386 -- each in both BW and Color). Running on i386-compatible hardware supporting ACPI: BW (standard): http://twitpic.com/4tlsin Color (loader_color=YES): http://twitpic.com/4tlt6l Running on i386-compatible hardware lacking ACPI support: BW (standard): http://twitpic.com/4tltp0 Color (loader_color=YES): http://twitpic.com/4tlu5w Running on non-i386 hardware: BW (standard): http://twitpic.com/4tluio Color (loader_color=YES): http://twitpic.com/4tluuy This version is feature complete with HEAD and backward compatible to 7.0-RELEASE. I do hope you like this latest version. You can get your update at: http://druidbsd.sourceforge.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.4.tgz -- Cheers
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On May 8, 2011, at 12:13 PM, Alexander Leidinger wrote: On Sun, 8 May 2011 10:48:55 -0700 Devin Teske dte...@vicor.com wrote: I would like to see general consensus from the community for separating the items before moving ahead with such a non-trivial change. IMO: - I agree that there are two different types of actions - having 2 distinct blocks looks like a good idea to me (I didn't had a look at the code, if you only have the text in the variables and the numbers get added automatically, maybe you can add variables for inbetween items which are pure text and do not get a number, and they are not displayed if the variable is empty) - I do not think that we need two different namespaces here - reorder the items, use incrementing numbers no matter which type it is (ACPI would be number 4 in the example then) All-in-all, I love the suggestion. A few notes: - I also agree that there are two different types of actions - Significant changes would need to be made. - I'd like to take the gradual approach - You're right, it could be done without two different namespaces However, there's one very important fact... The current menu is numbers only which means that people that use the menu often will be impacted in a non-trivial way if we re-order the numbers. The gradual approach would have us accept a new menu (such as loader_menu-1.4) that enables the use of hotkeys. Get people used to using the hotkeys for awhile before re-ording (or perhaps even taking-away) the numbers. What do you think of the gradual approach? -- 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On Sun, 8 May 2011 10:48:55 -0700 Devin Teske dte...@vicor.com wrote: I would like to see general consensus from the community for separating the items before moving ahead with such a non-trivial change. IMO: - I agree that there are two different types of actions - having 2 distinct blocks looks like a good idea to me (I didn't had a look at the code, if you only have the text in the variables and the numbers get added automatically, maybe you can add variables for inbetween items which are pure text and do not get a number, and they are not displayed if the variable is empty) - I do not think that we need two different namespaces here - reorder the items, use incrementing numbers no matter which type it is (ACPI would be number 4 in the example then) Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
There's really only room for one or two more menu items. Perhaps some items could be moved to a 2nd level menu? 1) boot multiuser mode ( default ) 2) boot single user mode 3) menu to set boot options 4) help Would be nice: a fix for having to lean on a key autorepeating for a couple seconds. Could you explain? I don't follow. On my Tyan Tomcat k8e 2865, just entering the number rarely if ever works. I have to either repeatedly bang away at the key or hold it down, letting the RS-232 terminal do the autorepeat thing, while hoping that it notices before the timer runs out. Is that with the current code that's in CVS? I'd love for you to try my code on that hardware. One of the things that I worked on in the very beginning was the responsiveness. That's with 6.x, 7,x and 8.x, currently running 8.2. I haven't looked to see if anything has changed in CVS since 8.2. I'll try your code, but I can't promise when. I'm swamped at the moment and windows when the machine is free keep getting smaller and less frequent. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re:[UPDATE] New Boot-Loader Menu -- version 1.4
Hi Devin, This loader menu is awesome! But as I opinion, items (1,6,7) and (2,3,4,5) are two different thing. 1.Boot[Enter] 6.Escape to loader prompt 7.Reboot These options are booting action. 2.ACPI Support 3.Boot Safe Mode 4.Boot Single User 5.Boot Verbose These options are booting configures. Separate them will be better, like this - |1.Boot | |2.Prompt | |3.Reboot | || |Configuration: | |1.ACPI Support| |2.Safe Mode| |3.Single User Mode| |4.Verbose Boot Mode| |---| Do you think so? At 2011-05-05 16:20:43，Devin Teske dte...@vicor.com wrote: Hello fellow -hackers, I'm so very proud to offer the latest update to my new boot loader menu -- version 1.4 -- addressing ACPI detection, bringing it in-line with HEAD. It took some work and a few days, but I got it! Have a look below for six different displays (three different scenarios -- i386 w/ ACPI, i386 w/o ACPI, and non-i386 -- each in both BW and Color). Running on i386-compatible hardware supporting ACPI: BW (standard): http://twitpic.com/4tlsin Color (loader_color=YES): http://twitpic.com/4tlt6l Running on i386-compatible hardware lacking ACPI support: BW (standard): http://twitpic.com/4tltp0 Color (loader_color=YES): http://twitpic.com/4tlu5w Running on non-i386 hardware: BW (standard): http://twitpic.com/4tluio Color (loader_color=YES): http://twitpic.com/4tluuy This version is feature complete with HEAD and backward compatible to 7.0-RELEASE. I do hope you like this latest version. You can get your update at: http://druidbsd.sourceforge.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.4.tgz -- Cheers, Devin Teske - FUN STUFF - -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+ D+(++) G++ e h r+++ z+++ --END GEEK CODE BLOCK-- http://www.geekcode.com/ - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - END TRANSMISSION - _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On May 5, 2011, at 7:21 PM, Devin Teske wrote: -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Ivan Voras Sent: Thursday, May 05, 2011 8:00 AM To: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 On 05/05/2011 15:40, Warren Block wrote: On Thu, 5 May 2011, Devin Teske wrote: Running on i386-compatible hardware supporting ACPI: BW (standard): http://twitpic.com/4tlsin Color (loader_color=YES): http://twitpic.com/4tlt6l Looks nice. Options 3, 4, and 5 could be changed to 3. Safe Mode 4. Single User Mode 5. Verbose On/Off or Enabled/Disabled might be bikeshedably better than Yes and No. If we're going to nitpick, then the style of *Enable* Safe Mode : *YES | NO* may be even better :) While at it, I'd also suggest aligning the YES | NO fields vertically for better readability. But these are minor suggestions, it is ok the way it is :) Suggestions are good. I'm always open to them. Both are good suggestions. It's with great undulating frivolity (think: Steve Ballmer or Billy Mays) that I invite anyone to simply edit the decidedly Forth-free /boot/menu.rc where the captions are configured simply as a series of carefully-named environment variables. If you find something you like, report back the values that you used and I'll test them out. If it's a definite improvement, I'll definitely make the change. The current boot loader menu, you have to go mucking through Forth to change the captions (which can be tricky with any stack-based language let alone a reverse polish one such as FICL). In general, I really like things becoming more modular. For FreeNAS's boot loader, I hacked a copy and put it as a patch to the FreeNAS build Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [UPDATE] New Boot-Loader Menu -- version 1.4
-Original Message- From: Warner Losh [mailto:i...@bsdimp.com] Sent: Friday, May 06, 2011 8:31 AM To: Devin Teske Cc: 'Ivan Voras'; freebsd-hackers@FreeBSD.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 On May 5, 2011, at 7:21 PM, Devin Teske wrote: -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Ivan Voras Sent: Thursday, May 05, 2011 8:00 AM To: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 On 05/05/2011 15:40, Warren Block wrote: On Thu, 5 May 2011, Devin Teske wrote: Running on i386-compatible hardware supporting ACPI: BW (standard): http://twitpic.com/4tlsin Color (loader_color=YES): http://twitpic.com/4tlt6l Looks nice. Options 3, 4, and 5 could be changed to 3. Safe Mode 4. Single User Mode 5. Verbose On/Off or Enabled/Disabled might be bikeshedably better than Yes and No. If we're going to nitpick, then the style of *Enable* Safe Mode : *YES | NO* may be even better :) While at it, I'd also suggest aligning the YES | NO fields vertically for better readability. But these are minor suggestions, it is ok the way it is :) Suggestions are good. I'm always open to them. Both are good suggestions. It's with great undulating frivolity (think: Steve Ballmer or Billy Mays) that I invite anyone to simply edit the decidedly Forth-free /boot/menu.rc where the captions are configured simply as a series of carefully-named environment variables. If you find something you like, report back the values that you used and I'll test them out. If it's a definite improvement, I'll definitely make the change. The current boot loader menu, you have to go mucking through Forth to change the captions (which can be tricky with any stack-based language let alone a reverse polish one such as FICL). In general, I really like things becoming more modular. For FreeNAS's boot loader, I hacked a copy and put it as a patch to the FreeNAS build Warner Awesome! Absolutely Fantastic! That's what the BSD license is all about! (although... maybe I should have released it under the Beerware license -- with a Guinuess clause, lol). -- 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[UPDATE] New Boot-Loader Menu -- version 1.4
Hello fellow -hackers, I'm so very proud to offer the latest update to my new boot loader menu -- version 1.4 -- addressing ACPI detection, bringing it in-line with HEAD. It took some work and a few days, but I got it! Have a look below for six different displays (three different scenarios -- i386 w/ ACPI, i386 w/o ACPI, and non-i386 -- each in both BW and Color). Running on i386-compatible hardware supporting ACPI: BW (standard): http://twitpic.com/4tlsin Color (loader_color=YES): http://twitpic.com/4tlt6l Running on i386-compatible hardware lacking ACPI support: BW (standard): http://twitpic.com/4tltp0 Color (loader_color=YES): http://twitpic.com/4tlu5w Running on non-i386 hardware: BW (standard): http://twitpic.com/4tluio Color (loader_color=YES): http://twitpic.com/4tluuy This version is feature complete with HEAD and backward compatible to 7.0-RELEASE. I do hope you like this latest version. You can get your update at: http://druidbsd.sourceforge.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.4.tgz -- Cheers, Devin Teske - FUN STUFF - -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+ D+(++) G++ e h r+++ z+++ --END GEEK CODE BLOCK-- http://www.geekcode.com/ - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - END TRANSMISSION - _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On Thu, 5 May 2011, Devin Teske wrote: Running on i386-compatible hardware supporting ACPI: BW (standard): http://twitpic.com/4tlsin Color (loader_color=YES): http://twitpic.com/4tlt6l Looks nice. Options 3, 4, and 5 could be changed to 3. Safe Mode 4. Single User Mode 5. Verbose On/Off or Enabled/Disabled might be bikeshedably better than Yes and No. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On 05/05/2011 15:40, Warren Block wrote: On Thu, 5 May 2011, Devin Teske wrote: Running on i386-compatible hardware supporting ACPI: BW (standard): http://twitpic.com/4tlsin Color (loader_color=YES): http://twitpic.com/4tlt6l Looks nice. Options 3, 4, and 5 could be changed to 3. Safe Mode 4. Single User Mode 5. Verbose On/Off or Enabled/Disabled might be bikeshedably better than Yes and No. If we're going to nitpick, then the style of *Enable* Safe Mode : *YES | NO* may be even better :) While at it, I'd also suggest aligning the YES | NO fields vertically for better readability. But these are minor suggestions, it is ok the way it is :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [UPDATE] New Boot-Loader Menu -- version 1.4
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Ivan Voras Sent: Thursday, May 05, 2011 8:00 AM To: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 On 05/05/2011 15:40, Warren Block wrote: On Thu, 5 May 2011, Devin Teske wrote: Running on i386-compatible hardware supporting ACPI: BW (standard): http://twitpic.com/4tlsin Color (loader_color=YES): http://twitpic.com/4tlt6l Looks nice. Options 3, 4, and 5 could be changed to 3. Safe Mode 4. Single User Mode 5. Verbose On/Off or Enabled/Disabled might be bikeshedably better than Yes and No. If we're going to nitpick, then the style of *Enable* Safe Mode : *YES | NO* may be even better :) While at it, I'd also suggest aligning the YES | NO fields vertically for better readability. But these are minor suggestions, it is ok the way it is :) Suggestions are good. I'm always open to them. Both are good suggestions. It's with great undulating frivolity (think: Steve Ballmer or Billy Mays) that I invite anyone to simply edit the decidedly Forth-free /boot/menu.rc where the captions are configured simply as a series of carefully-named environment variables. If you find something you like, report back the values that you used and I'll test them out. If it's a definite improvement, I'll definitely make the change. The current boot loader menu, you have to go mucking through Forth to change the captions (which can be tricky with any stack-based language let alone a reverse polish one such as FICL). -- 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.3
Devin Teske dte...@vicor.com wrote: Hey all, Proud to bring you version 1.3 which completes the followup suggestions made by Olivier Smedts (use autoboot_delay instead of loader_menu_timeout and change dc_seconds to loader_delay) and a couple other minor enhancements/fixes. I think that brings everything up to speed with the phenomenal feedback provided so far. Really, thank you all very much. Get your update at http://druidbsd.sf.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz Devin, have you thought about writing a port [1]? I'd be happy to review it: [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html Emanuel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.3
On May 3, 2011, at 8:45 PM, Jason Hellenthal wrote: Devin, On Mon, May 02, 2011 at 08:57:05PM -0700, Devin Teske wrote: [...] loader_brand=... Selects the BSD brand to display. Valid values are fbsd (displays FreeBSD) and dbsd (displays DruidBSD). An invalid value (such as none) will disable the display of any brand. The brand is displayed above the dynamic menu. The default is fbsd. [...] Speaking directly toward one of the many other version announcements where you mentioned approaching -core@ in delta D). I can't see DruidBSD making it into the tree. You might want to do some work to separate that for your own personal use. Replacing it with PC-BSD on the other hand or allowing user supplied text to just be there without all the checking is another option. Fair enough. I'll replace DruidBSD with PC-BSD. I'm sure the PC-BSD community would appreciate it. Out of curiousity, are FreeBSD and PC-BSD officially affiliated in some way? -- 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
On May 3, 2011, at 9:06 PM, Jason Hellenthal wrote: Devin, On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote: On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote: Devin, On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote: Would be nice: uname -v of the kernel it will boot. That's a bit more technically challenging. I'll have another look at the FICL words available, but I don't recall if there was a way to crawl the object space of the items loaded with ``load'' (looking for the uname). I'm open to suggestions if you had an idea of how to do this in Forth -- else I'd think this would need to be a loader(8) modification. How about forgetting a mention of unmae ... instead look into if we can support some sort of bootcode versioning to be displayed on the screen. This would serve to be very helpful in the future when for say a new version of bootcode for ZFS has to be installed then it would be easy for announce@ to simply say A new version of ZFS has been MFCd and requires boot version = X. To find out your version please see the bottom right hand corner of your boot screen. I would place a pretty good bet that loader(8) could be modified to export some sort of versioning of the bootcode to make this a easier stance for the user to gather information before a upgrade. Piece of cake! If you give me a loader(8) that exports a version environment variable, I'll give the Forth functionality in mere seconds. It's already been developed (but was not packaged). I have a module named version.4th which prints the value of the version environment variable at the bottom-right of the screen underneath the beastie logo. Since you mention this, I'll add the code to the next package and if/when loader(8) ever exports a version environment variable, it will just magically appear. How's that sound? Sounds perfect! One minor adjustment... can we make that environment variable loader_version instead of version? The code is already in for loader_version. Whatever string you export into that environment variable will be displayed on-screen at bottom-right, right-justified. -- 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.3
Devin, On Wed, May 04, 2011 at 08:38:07AM -0700, Devin Teske wrote: On May 3, 2011, at 8:45 PM, Jason Hellenthal wrote: Devin, On Mon, May 02, 2011 at 08:57:05PM -0700, Devin Teske wrote: [...] loader_brand=... Selects the BSD brand to display. Valid values are fbsd (displays FreeBSD) and dbsd (displays DruidBSD). An invalid value (such as none) will disable the display of any brand. The brand is displayed above the dynamic menu. The default is fbsd. [...] Speaking directly toward one of the many other version announcements where you mentioned approaching -core@ in delta D). I can't see DruidBSD making it into the tree. You might want to do some work to separate that for your own personal use. Replacing it with PC-BSD on the other hand or allowing user supplied text to just be there without all the checking is another option. Fair enough. I'll replace DruidBSD with PC-BSD. I'm sure the PC-BSD community would appreciate it. Out of curiousity, are FreeBSD and PC-BSD officially affiliated in some way? Just FreeBSD re-badged with a new installer frontend to make it easier on those looking to install FreeBSD as a desktop. -- Regards, (jhell) Jason Hellenthal pgpwVuTb7ViC6.pgp Description: PGP signature
Re: [UPDATE] New Boot-Loader Menu -- version 1.1
2011/5/3 Devin Teske dte...@vicor.com: The previous loader behavior when an unknown key was pressed was to reset the delay to the autoboot_delay value. I wasn't aware of that functionality (I'd always pressed SPACE to pause the timer). Maybe a dumb question, but why would anybody want to reset the timer? I can't think of a single scenario where I'd prefer a timer to be reset on keypress opposed to just stopping. I'm of the school of thought that there are only three reasonable scenarios where you'd want to abate auto-boot (listed below), all of which involve more time than just another 10 seconds gained by resetting the timer: 1. Slow readers (of which I am guilty of) 2. People that just want to bask in the glory of the boot-loader (also guilty) 3. Hackers that want to rewrite rogue(6) in FICL for the boot-loader (work in progress?) It surprised me and this loader booted the system while I didn't want, because : - I was accustomed of the previous behavior - I only had a 3 seconds delay to boot (I press a key when I want a longer delay, to read or find a key) - I wanted to see the new loader (you can count this as slow readers) - I don't have a qwerty keyboard, so finding the right keys for the loader can take some time Is this a serious concern (removing the reset timer on unknown key functionality)? And it also worked with, for examble, the arrow keys. I appreciated it, like I appreciate your Space to pause ! Arrow keys are funny. They produce a zero value by the key function, so detecting them is ... impossible. However, I was able to correct this behavior. Version 1.2 (just released right now) will cancel the timeout on ANY keypress, including keys that produce NULL keycodes (such as arrows, navigational keys, command sequences, and special key combinations). OK, I'll test it, now the behavior is more like the previous loader, or grub. It's ok (for me) not to reset the timer if at least it stops on all keys ! Do you know why this loader displays ACPI Support: Disabled on my 9-CURRENT amd64 computer when it really seems to be enabled ? Note acpi.ko is not loaded, it's in the GENERIC kernel. The previous version (1.0) had a hard-coded set acpi_load=YES in /boot/menu-commands.4th. This has been removed in favor of dynamically detecting acpi_load at boot time. This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. I would be willing to bet that your workstation -- while running the default boot loader -- displays Boot FreeBSD with ACPI enabled for option #2 (indicating that ACPI appears to be disabled from your system's perspective). No, it displays Boot FreeBSD with ACPI disabled. I didn't know this text was dynamic, are you sure it's not hard-coded ? I can provide screenshots of both loaders. As far as I know, the loader does not know that ACPI is compiled into your kernel. Rather the ACPI menuitem (both in the default boot-loader menu and in my version 1.1) hinges on whether acpi_load is defined (and is enabled). On a side-note, the same exact code is displaying ACPI as enabled for me (running under Parallels 4 on Mac OS X 10.6.7) at boot time. Yet, I do not have acpi_load in loader.conf(5), though I do have a kernel with ACPI built-in. My guess is that loader(8) is setting load_acpi=YES, which I verify immediately after executing loader(8) and the loader.4th start-word (which reads loader.conf(5) among other things). loader_menu_timeout=N Timeout in seconds (N) until the menu aborts, causing the system to autoboot with the displayed options. Default is 10 seconds. Pressing any key during the duration will cancel the timeout. Could you add a compatibility shim for the actual autoboot_delay variable ? I've decided to simply do-away with loader_menu_timeout and have it simply use autoboot_delay. This is effective as of version 1.2 (released today). dc_seconds=N By default, loader_menu introduces a 2-second delay before launching the menu for improved debugging abilities. This option customizes the duration (setting it to zero disables the delay). However, it is worth noting that pressing ENTER anytime during the delay will preempt the duration, launching the menu immediately upon keypress. For consistency with all the logo_* variables, what would you think of using something like loader_delay instead of dc_seconds ? (and yes, I know, autoboot_delay doesn't begin with loader_, but it was there before ;) I agree, however this will require a rewrite of that module. I'll try to get to that later
Re: [UPDATE] New Boot-Loader Menu -- version 1.3
2011/5/3 Devin Teske dte...@vicor.com: Hey all, Proud to bring you version 1.3 which completes the followup suggestions made by Olivier Smedts (use autoboot_delay instead of loader_menu_timeout and change dc_seconds to loader_delay) and a couple other minor enhancements/fixes. I think that brings everything up to speed with the phenomenal feedback provided so far. Really, thank you all very much. That was fast ! Get your update at http://druidbsd.sf.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz Installed here, on another computer. Added to /boot/loader.conf : loader_delay=0 loader_color=YES Removed : loader_logo=beastie Kept : autoboot_delay=3 I'm happy with it. The stop delay on all keys feature is great, I have an habit of using arrow keys to stop or reset delays in boot loaders because those keys usually don't have a special meaning like letters or space bar can have (except selecting another entry, in grub for example). But still, on this computer I've got 2. ACPI Support: Disabled, while the old loader offers me to boot with ACPI disabled. ACPI seems enabled after boot in both cases. I've got this behavior on 2 computers with different hardware, they both use 9-CURRENT (latest and few days old) amd64, compiled with clang. I'll try to investigate a little more. Cheers -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.1
On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote: This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. I would be willing to bet that your workstation -- while running the default boot loader -- displays Boot FreeBSD with ACPI enabled for option #2 (indicating that ACPI appears to be disabled from your system's perspective). As far as I know, the loader does not know that ACPI is compiled into your kernel. Rather the ACPI menuitem (both in the default boot-loader menu and in my version 1.1) hinges on whether acpi_load is defined (and is enabled). On a side-note, the same exact code is displaying ACPI as enabled for me (running under Parallels 4 on Mac OS X 10.6.7) at boot time. Yet, I do not have acpi_load in loader.conf(5), though I do have a kernel with ACPI built-in. My guess is that loader(8) is setting load_acpi=YES, which I verify immediately after executing loader(8) and the loader.4th start-word (which reads loader.conf(5) among other things). Err, note that the acpienabled stuff is all different in HEAD than in 7/8 since acpi.ko no longer exists. You should use the scheme from HEAD for handling ACPI present vs ACPI enabled/disabled. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.1
On May 3, 2011, at 4:45 AM, John Baldwin wrote: On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote: This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. Ugh. By current, I meant 8.1-RELEASE (wasn't expecting this stuff to be different in HEAD, which it is). Err, note that the acpienabled stuff is all different in HEAD than in 7/8 since acpi.ko no longer exists. You should use the scheme from HEAD for handling ACPI present vs ACPI enabled/disabled. -- John Baldwin Ok, I see the new acpipresent? word (which replaces the arch-i386 environment-test). Does this imply that we're going to support ACPI on non-i386 platforms (or already do)? I also see the rewritten acpienabled? word. Nice. I'll slurp it in to make my ACPI detection the same as HEAD. I also performed some backward compatibility tests. Looks like this will be backward compatible with 8.1-RELEASE (loader_version == 11). However, the code in HEAD appears to not work in 8.0-RELEASE (loader_version == 8). I'm thinking about adding the following test-case to the acpienabled? word to add backward compatibility: : acpienabled? ( -- flag ) \ BEGIN: Additional code for backward compatibility s loader_version environment? if 11 if \ older version of loader(8) s acpi_load getenv dup -1 = if drop false exit then s YES compare-insensitive 0 if false exit then then then \ END: Additional code for backward compatibility \ BEGIN: Existing code in HEAD s hiint.acpi.0.disabled getenv dup -1 if s 0 compare 0 if false exit then else drop then true \ END: Existing code in HEAD ; In-addition, I'm also thinking about adding the following test-case to the new acpipresent? word to add backward compatibility: : acpipresent? ( -- flag ) \ BEGIN: Additional code for backward compatibility s loader_version environment? if 11 if \ older version of loader(8) s arch-i386 environment? if drop true exit else false exit then then then \ END: Additional code for backward compatibility \ BEGIN: Existing code in HEAD s hint.acpi.0.rsdp getenv dup -1 = if drop false exit then 2drop true \ END: Existing code in HEAD ; What do you think? I'm actually thinking this would be a good change to incorporate HEAD. -- Cheers, Devin Teske - CONTACT INFORMATION - Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.te...@fisglobal.com - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - END TRANSMISSION - _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.1
On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote: On May 3, 2011, at 4:45 AM, John Baldwin wrote: On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote: This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. Ugh. By current, I meant 8.1-RELEASE (wasn't expecting this stuff to be different in HEAD, which it is). Err, note that the acpienabled stuff is all different in HEAD than in 7/8 since acpi.ko no longer exists. You should use the scheme from HEAD for handling ACPI present vs ACPI enabled/disabled. -- John Baldwin Ok, I see the new acpipresent? word (which replaces the arch-i386 environment-test). Does this imply that we're going to support ACPI on non-i386 platforms (or already do)? amd64 and ia64 have always supported ACPI. ia64 effectively requires it. However, hint.acpi.0.rsdp is set by biosacpi.c in the i386 loader bits, so other platforms will not set it, so the arch-i386 test is no longer needed. I also see the rewritten acpienabled? word. Nice. I'll slurp it in to make my ACPI detection the same as HEAD. I also performed some backward compatibility tests. Looks like this will be backward compatible with 8.1-RELEASE (loader_version == 11). However, the code in HEAD appears to not work in 8.0-RELEASE (loader_version == 8). Hmm, which part does not work in 8.0? arch-i386 has existed since at least 4.x I thought, and the ACPI bits have been setting hint.acpi.0.rsdp since 7.0 (sys/boot/i386/libi386/biosacpi.c CVS rev 1.12 added it). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [UPDATE] New Boot-Loader Menu -- version 1.1
From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 10:33 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote: On May 3, 2011, at 4:45 AM, John Baldwin wrote: On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote: This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. Ugh. By current, I meant 8.1-RELEASE (wasn't expecting this stuff to be different in HEAD, which it is). Err, note that the acpienabled stuff is all different in HEAD than in 7/8 since acpi.ko no longer exists. You should use the scheme from HEAD for handling ACPI present vs ACPI enabled/disabled. -- John Baldwin Ok, I see the new acpipresent? word (which replaces the arch-i386 environment-test). Does this imply that we're going to support ACPI on non-i386 platforms (or already do)? amd64 and ia64 have always supported ACPI. ia64 effectively requires it. However, hint.acpi.0.rsdp is set by biosacpi.c in the i386 loader bits, so other platforms will not set it, so the arch-i386 test is no longer needed. If hint.acpi.0.rsdp is only set in the i386 pieces, wouldn't that imply that the acpipresent? would return FALSE on IA64? I also see the rewritten acpienabled? word. Nice. I'll slurp it in to make my ACPI detection the same as HEAD. I also performed some backward compatibility tests. Looks like this will be backward compatible with 8.1-RELEASE (loader_version == 11). However, the code in HEAD appears to not work in 8.0-RELEASE (loader_version == 8). Hmm, which part does not work in 8.0? arch-i386 has existed since at least 4.x I thought, and the ACPI bits have been setting hint.acpi.0.rsdp since 7.0 (sys/boot/i386/libi386/biosacpi.c CVS rev 1.12 added it). -- John Baldwin I've got this 8.0-STABLE box. I don't know exactly when it was installed, but /boot/loader has a timestamp from June 2010 and when I execute: s loader_version environment? drop . I get 8, whereas when I boot the same exact hardware with 8.1-RELEASE, I get 11. When I boot 8.0-STABLE (loader_version 8), I do not have hint.acpi.0.rsdp whereas if I boot 8.1-RELEASE (loader_version 11), I do get hint.acpi.0.rsdp. (NOTE: this is on the exact same hardware, without changing any BIOS settings between boots). Is it possible that my 8.0-STABLE has a loader that is older than 7.0-RELEASE? I'm trying to figure out why this 8.0-STABLE box is not setting hint.acpi.0.rsdp. -- Cheers, Devin Teske - FUN STUFF - -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ W+++ b+++ DI+ D+(++) G++ e h r+++ z+++ --END GEEK CODE BLOCK-- Learn about the Geek Code: http://www.geekcode.com/ - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - END TRANSMISSION - _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.1
On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote: From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 10:33 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote: On May 3, 2011, at 4:45 AM, John Baldwin wrote: On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote: This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. Ugh. By current, I meant 8.1-RELEASE (wasn't expecting this stuff to be different in HEAD, which it is). Err, note that the acpienabled stuff is all different in HEAD than in 7/8 since acpi.ko no longer exists. You should use the scheme from HEAD for handling ACPI present vs ACPI enabled/disabled. -- John Baldwin Ok, I see the new acpipresent? word (which replaces the arch-i386 environment-test). Does this imply that we're going to support ACPI on non-i386 platforms (or already do)? amd64 and ia64 have always supported ACPI. ia64 effectively requires it. However, hint.acpi.0.rsdp is set by biosacpi.c in the i386 loader bits, so other platforms will not set it, so the arch-i386 test is no longer needed. If hint.acpi.0.rsdp is only set in the i386 pieces, wouldn't that imply that the acpipresent? would return FALSE on IA64? Yes. Right now the ACPI menu item is not displayed on ia64 and it never has been. You can't actually boot IA64 with ACPI disabled, so there's no reason for it to be in the menu. I also see the rewritten acpienabled? word. Nice. I'll slurp it in to make my ACPI detection the same as HEAD. I also performed some backward compatibility tests. Looks like this will be backward compatible with 8.1-RELEASE (loader_version == 11). However, the code in HEAD appears to not work in 8.0-RELEASE (loader_version == 8). Hmm, which part does not work in 8.0? arch-i386 has existed since at least 4.x I thought, and the ACPI bits have been setting hint.acpi.0.rsdp since 7.0 (sys/boot/i386/libi386/biosacpi.c CVS rev 1.12 added it). -- John Baldwin I've got this 8.0-STABLE box. I don't know exactly when it was installed, but /boot/loader has a timestamp from June 2010 and when I execute: s loader_version environment? drop . I get 8, whereas when I boot the same exact hardware with 8.1-RELEASE, I get 11. When I boot 8.0-STABLE (loader_version 8), I do not have hint.acpi.0.rsdp whereas if I boot 8.1-RELEASE (loader_version 11), I do get hint.acpi.0.rsdp. (NOTE: this is on the exact same hardware, without changing any BIOS settings between boots). Is it possible that my 8.0-STABLE has a loader that is older than 7.0-RELEASE? I'm trying to figure out why this 8.0-STABLE box is not setting hint.acpi.0.rsdp. What is the output of 'kenv | grep acpi' from your old loader? Hmm, sys/boot/i386/loader/version was bumped to 1.1 in 5.0 release. It was bumped to 1.0 in 5.0-CURRENT. It was last 0.8 (so 8) in 4.x. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [UPDATE] New Boot-Loader Menu -- version 1.1
-Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 12:20 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote: From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 10:33 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote: On May 3, 2011, at 4:45 AM, John Baldwin wrote: On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote: This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. Ugh. By current, I meant 8.1-RELEASE (wasn't expecting this stuff to be different in HEAD, which it is). Err, note that the acpienabled stuff is all different in HEAD than in 7/8 since acpi.ko no longer exists. You should use the scheme from HEAD for handling ACPI present vs ACPI enabled/disabled. -- John Baldwin Ok, I see the new acpipresent? word (which replaces the arch-i386 environment-test). Does this imply that we're going to support ACPI on non-i386 platforms (or already do)? amd64 and ia64 have always supported ACPI. ia64 effectively requires it. However, hint.acpi.0.rsdp is set by biosacpi.c in the i386 loader bits, so other platforms will not set it, so the arch-i386 test is no longer needed. If hint.acpi.0.rsdp is only set in the i386 pieces, wouldn't that imply that the acpipresent? would return FALSE on IA64? Yes. Right now the ACPI menu item is not displayed on ia64 and it never has been. You can't actually boot IA64 with ACPI disabled, so there's no reason for it to be in the menu. This raises a concern for my menu. Unlike the current menu, which blanks-out menuitem #2 for IA64, I've chosen instead to insert an inoperative menuitem with the text ACPI Support: N/A. What do you think would be an appropriate stand-in? Perhaps ACPI Support: Enabled (simply assume that it's enabled and do nothing if the user attempts to disable it) or ACPI Support: with no text (or maybe what I've got right now -- ACPI Support: N/A -- is already acceptable)? I also see the rewritten acpienabled? word. Nice. I'll slurp it in to make my ACPI detection the same as HEAD. I also performed some backward compatibility tests. Looks like this will be backward compatible with 8.1-RELEASE (loader_version == 11). However, the code in HEAD appears to not work in 8.0-RELEASE (loader_version == 8). Hmm, which part does not work in 8.0? arch-i386 has existed since at least 4.x I thought, and the ACPI bits have been setting hint.acpi.0.rsdp since 7.0 (sys/boot/i386/libi386/biosacpi.c CVS rev 1.12 added it). -- John Baldwin I've got this 8.0-STABLE box. I don't know exactly when it was installed, but /boot/loader has a timestamp from June 2010 and when I execute: s loader_version environment? drop . I get 8, whereas when I boot the same exact hardware with 8.1-RELEASE, I get 11. When I boot 8.0-STABLE (loader_version 8), I do not have hint.acpi.0.rsdp whereas if I boot 8.1-RELEASE (loader_version 11), I do get hint.acpi.0.rsdp. (NOTE: this is on the exact same hardware, without changing any BIOS settings between boots). Is it possible that my 8.0-STABLE has a loader that is older than 7.0-RELEASE? I'm trying to figure out why this 8.0-STABLE box is not setting hint.acpi.0.rsdp. What is the output of 'kenv | grep acpi' from your old loader? Hmm, sys/boot/i386/loader/version was bumped to 1.1 in 5.0 release. It was bumped to 1.0 in 5.0-CURRENT. It was last 0.8 (so 8) in 4.x. D'OH! Someone had slapped a 4.9.1 hard disk into this 8.0-STABLE box without me knowing. Turns out I was booting from the 4.9.1 disk and hence why the old loader. Thanks for helping me figure that one out. Back to the topic of backward compatibility. As it stands, it would seem that the new acpipresent? will not produce expected results on releases older than 7.0 (since hint.acpi.0.rsdp is not set in 6.x or older). The result would be that if used on FreeBSD 6.x or older, that the boot menu would always blank-out the ACPI option. This is not an issue for the FreeBSD release engineers, but for my package -- which might potentially be added to a FreeBSD-6 box -- in which case ACPI will not detect properly. So, I'm in a quandary over the new acpipresent
Re: [UPDATE] New Boot-Loader Menu -- version 1.1
On Tuesday, May 03, 2011 4:17:23 pm Devin Teske wrote: -Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 12:20 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote: From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 10:33 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote: On May 3, 2011, at 4:45 AM, John Baldwin wrote: On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote: This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. Ugh. By current, I meant 8.1-RELEASE (wasn't expecting this stuff to be different in HEAD, which it is). Err, note that the acpienabled stuff is all different in HEAD than in 7/8 since acpi.ko no longer exists. You should use the scheme from HEAD for handling ACPI present vs ACPI enabled/disabled. -- John Baldwin Ok, I see the new acpipresent? word (which replaces the arch-i386 environment-test). Does this imply that we're going to support ACPI on non-i386 platforms (or already do)? amd64 and ia64 have always supported ACPI. ia64 effectively requires it. However, hint.acpi.0.rsdp is set by biosacpi.c in the i386 loader bits, so other platforms will not set it, so the arch-i386 test is no longer needed. If hint.acpi.0.rsdp is only set in the i386 pieces, wouldn't that imply that the acpipresent? would return FALSE on IA64? Yes. Right now the ACPI menu item is not displayed on ia64 and it never has been. You can't actually boot IA64 with ACPI disabled, so there's no reason for it to be in the menu. This raises a concern for my menu. Unlike the current menu, which blanks-out menuitem #2 for IA64, I've chosen instead to insert an inoperative menuitem with the text ACPI Support: N/A. Hmm, I think you should just leave the menu item blank or not listed. It doesn't make sense to see a knob about ACPI support on a ppc box for example, and other platforms may grow platform-specific knobs in the future as well. The current menu item is only blank as a hack to avoid renumbering the items. If you are already changing that around, then I'd just leave it out altogether unless ACPI is detected by the loader. So what do you think I should do? a. Rewrite both acpipresent? and acpienabled? to be backward compatible with 6.x/older or b. embrace the future and simply warn about backward compatibility (or lack thereof) with respect to ACPI support. NOTE: Route (a) may not be possible unless the loader_version was bumped at the same time that hint.acpi.0.rsdp was added. (a) is not possible for the reason you mention. I wouldn't worry about supporting 6.x at this point, esp. if it is going to be a pain. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [UPDATE] New Boot-Loader Menu -- version 1.1
-Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 1:36 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 4:17:23 pm Devin Teske wrote: -Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 12:20 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote: From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 10:33 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote: On May 3, 2011, at 4:45 AM, John Baldwin wrote: On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote: This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. Ugh. By current, I meant 8.1-RELEASE (wasn't expecting this stuff to be different in HEAD, which it is). Err, note that the acpienabled stuff is all different in HEAD than in 7/8 since acpi.ko no longer exists. You should use the scheme from HEAD for handling ACPI present vs ACPI enabled/disabled. -- John Baldwin Ok, I see the new acpipresent? word (which replaces the arch-i386 environment-test). Does this imply that we're going to support ACPI on non-i386 platforms (or already do)? amd64 and ia64 have always supported ACPI. ia64 effectively requires it. However, hint.acpi.0.rsdp is set by biosacpi.c in the i386 loader bits, so other platforms will not set it, so the arch-i386 test is no longer needed. If hint.acpi.0.rsdp is only set in the i386 pieces, wouldn't that imply that the acpipresent? would return FALSE on IA64? Yes. Right now the ACPI menu item is not displayed on ia64 and it never has been. You can't actually boot IA64 with ACPI disabled, so there's no reason for it to be in the menu. This raises a concern for my menu. Unlike the current menu, which blanks-out menuitem #2 for IA64, I've chosen instead to insert an inoperative menuitem with the text ACPI Support: N/A. Hmm, I think you should just leave the menu item blank or not listed. It doesn't make sense to see a knob about ACPI support on a ppc box for example, and other platforms may grow platform-specific knobs in the future as well. The current menu item is only blank as a hack to avoid renumbering the items. If you are already changing that around, then I'd just leave it out altogether unless ACPI is detected by the loader. I too avoid renumbering of the items. Having never actually booted a PPC or IA64 FreeBSD installation... is it the case that the numbers displayed jump from 1 to 3 (no blank line in-between 1 and 3, correct)? I think that sounds like the sensible thing to do. -- 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.1
On Tuesday, May 03, 2011 4:47:26 pm Devin Teske wrote: -Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 1:36 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 4:17:23 pm Devin Teske wrote: -Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 12:20 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote: From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 10:33 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote: On May 3, 2011, at 4:45 AM, John Baldwin wrote: On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote: This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. Ugh. By current, I meant 8.1-RELEASE (wasn't expecting this stuff to be different in HEAD, which it is). Err, note that the acpienabled stuff is all different in HEAD than in 7/8 since acpi.ko no longer exists. You should use the scheme from HEAD for handling ACPI present vs ACPI enabled/disabled. -- John Baldwin Ok, I see the new acpipresent? word (which replaces the arch-i386 environment-test). Does this imply that we're going to support ACPI on non-i386 platforms (or already do)? amd64 and ia64 have always supported ACPI. ia64 effectively requires it. However, hint.acpi.0.rsdp is set by biosacpi.c in the i386 loader bits, so other platforms will not set it, so the arch-i386 test is no longer needed. If hint.acpi.0.rsdp is only set in the i386 pieces, wouldn't that imply that the acpipresent? would return FALSE on IA64? Yes. Right now the ACPI menu item is not displayed on ia64 and it never has been. You can't actually boot IA64 with ACPI disabled, so there's no reason for it to be in the menu. This raises a concern for my menu. Unlike the current menu, which blanks-out menuitem #2 for IA64, I've chosen instead to insert an inoperative menuitem with the text ACPI Support: N/A. Hmm, I think you should just leave the menu item blank or not listed. It doesn't make sense to see a knob about ACPI support on a ppc box for example, and other platforms may grow platform-specific knobs in the future as well. The current menu item is only blank as a hack to avoid renumbering the items. If you are already changing that around, then I'd just leave it out altogether unless ACPI is detected by the loader. I too avoid renumbering of the items. Having never actually booted a PPC or IA64 FreeBSD installation... is it the case that the numbers displayed jump from 1 to 3 (no blank line in-between 1 and 3, correct)? Actually, I think PPC/IA64, etc. do not display the ACPI menu item at all and they are numbered differently from i386 and amd64. The ACPI menu item is only blank if ACPI is not present on i386 and amd64. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [UPDATE] New Boot-Loader Menu -- version 1.1
-Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 2:01 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 4:47:26 pm Devin Teske wrote: -Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 1:36 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 4:17:23 pm Devin Teske wrote: -Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 12:20 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote: From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 10:33 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote: On May 3, 2011, at 4:45 AM, John Baldwin wrote: On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote: This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. Ugh. By current, I meant 8.1-RELEASE (wasn't expecting this stuff to be different in HEAD, which it is). Err, note that the acpienabled stuff is all different in HEAD than in 7/8 since acpi.ko no longer exists. You should use the scheme from HEAD for handling ACPI present vs ACPI enabled/disabled. -- John Baldwin Ok, I see the new acpipresent? word (which replaces the arch-i386 environment-test). Does this imply that we're going to support ACPI on non-i386 platforms (or already do)? amd64 and ia64 have always supported ACPI. ia64 effectively requires it. However, hint.acpi.0.rsdp is set by biosacpi.c in the i386 loader bits, so other platforms will not set it, so the arch-i386 test is no longer needed. If hint.acpi.0.rsdp is only set in the i386 pieces, wouldn't that imply that the acpipresent? would return FALSE on IA64? Yes. Right now the ACPI menu item is not displayed on ia64 and it never has been. You can't actually boot IA64 with ACPI disabled, so there's no reason for it to be in the menu. This raises a concern for my menu. Unlike the current menu, which blanks-out menuitem #2 for IA64, I've chosen instead to insert an inoperative menuitem with the text ACPI Support: N/A. Hmm, I think you should just leave the menu item blank or not listed. It doesn't make sense to see a knob about ACPI support on a ppc box for example, and other platforms may grow platform-specific knobs in the future as well. The current menu item is only blank as a hack to avoid renumbering the items. If you are already changing that around, then I'd just leave it out altogether unless ACPI is detected by the loader. I too avoid renumbering of the items. Having never actually booted a PPC or IA64 FreeBSD installation... is it the case that the numbers displayed jump from 1 to 3 (no blank line in-between 1 and 3, correct)? Actually, I think PPC/IA64, etc. do not display the ACPI menu item at all and they are numbered differently from i386 and amd64. The ACPI menu item is only blank if ACPI is not present on i386 and amd64. You're absolutely right. I looked closer at the Forth in HEAD, and indeed you're right. arch-i386 will always allocate a #2 to ACPI, but will only display it when hint.acpi.0.rsdp is set whereas non-i386 architectures will assign #2 to the next menuitem (Safe Mode). I'll make a new version that mimics this behavior. The overall goal is to: a. Satisfy everbody on -hackers. b. Announce final version on -questions and -announce for broader audience. c. Try to satisfy critical concerns. d. Approach -core about using it in base Think I have a shot at (d)? -- 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
Re: [UPDATE] New Boot-Loader Menu -- version 1.1
On Tuesday, May 03, 2011 5:22:20 pm Devin Teske wrote: -Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 2:01 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 4:47:26 pm Devin Teske wrote: -Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 1:36 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 4:17:23 pm Devin Teske wrote: -Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 12:20 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote: From: John Baldwin [mailto:j...@freebsd.org] Sent: Tuesday, May 03, 2011 10:33 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote: On May 3, 2011, at 4:45 AM, John Baldwin wrote: On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote: This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. Ugh. By current, I meant 8.1-RELEASE (wasn't expecting this stuff to be different in HEAD, which it is). Err, note that the acpienabled stuff is all different in HEAD than in 7/8 since acpi.ko no longer exists. You should use the scheme from HEAD for handling ACPI present vs ACPI enabled/disabled. -- John Baldwin Ok, I see the new acpipresent? word (which replaces the arch-i386 environment-test). Does this imply that we're going to support ACPI on non-i386 platforms (or already do)? amd64 and ia64 have always supported ACPI. ia64 effectively requires it. However, hint.acpi.0.rsdp is set by biosacpi.c in the i386 loader bits, so other platforms will not set it, so the arch-i386 test is no longer needed. If hint.acpi.0.rsdp is only set in the i386 pieces, wouldn't that imply that the acpipresent? would return FALSE on IA64? Yes. Right now the ACPI menu item is not displayed on ia64 and it never has been. You can't actually boot IA64 with ACPI disabled, so there's no reason for it to be in the menu. This raises a concern for my menu. Unlike the current menu, which blanks-out menuitem #2 for IA64, I've chosen instead to insert an inoperative menuitem with the text ACPI Support: N/A. Hmm, I think you should just leave the menu item blank or not listed. It doesn't make sense to see a knob about ACPI support on a ppc box for example, and other platforms may grow platform-specific knobs in the future as well. The current menu item is only blank as a hack to avoid renumbering the items. If you are already changing that around, then I'd just leave it out altogether unless ACPI is detected by the loader. I too avoid renumbering of the items. Having never actually booted a PPC or IA64 FreeBSD installation... is it the case that the numbers displayed jump from 1 to 3 (no blank line in-between 1 and 3, correct)? Actually, I think PPC/IA64, etc. do not display the ACPI menu item at all and they are numbered differently from i386 and amd64. The ACPI menu item is only blank if ACPI is not present on i386 and amd64. You're absolutely right. I looked closer at the Forth in HEAD, and indeed you're right. arch-i386 will always allocate a #2 to ACPI, but will only display it when hint.acpi.0.rsdp is set whereas non-i386 architectures will assign #2 to the next menuitem (Safe Mode). I'll make a new version that mimics this behavior. The overall goal is to: a. Satisfy everbody on -hackers. b. Announce final version on -questions and -announce for broader audience. c. Try to satisfy critical concerns. d. Approach -core about using it in base Think I have a shot at (d)? Well, for (d) you just need to find a committer who is excited about
Re: [UPDATE] New Boot-Loader Menu -- version 1.3
Devin, On Mon, May 02, 2011 at 08:57:05PM -0700, Devin Teske wrote: [...] loader_brand=... Selects the BSD brand to display. Valid values are fbsd (displays FreeBSD) and dbsd (displays DruidBSD). An invalid value (such as none) will disable the display of any brand. The brand is displayed above the dynamic menu. The default is fbsd. [...] Speaking directly toward one of the many other version announcements where you mentioned approaching -core@ in delta D). I can't see DruidBSD making it into the tree. You might want to do some work to separate that for your own personal use. Replacing it with PC-BSD on the other hand or allowing user supplied text to just be there without all the checking is another option. -- Regards, (jhell) Jason Hellenthal pgpwVTTnUBCzG.pgp Description: PGP signature
Re: [RELEASE] New Boot-Loader Menu
Devin, On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote: On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote: Devin, On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote: Would be nice: uname -v of the kernel it will boot. That's a bit more technically challenging. I'll have another look at the FICL words available, but I don't recall if there was a way to crawl the object space of the items loaded with ``load'' (looking for the uname). I'm open to suggestions if you had an idea of how to do this in Forth -- else I'd think this would need to be a loader(8) modification. How about forgetting a mention of unmae ... instead look into if we can support some sort of bootcode versioning to be displayed on the screen. This would serve to be very helpful in the future when for say a new version of bootcode for ZFS has to be installed then it would be easy for announce@ to simply say A new version of ZFS has been MFCd and requires boot version = X. To find out your version please see the bottom right hand corner of your boot screen. I would place a pretty good bet that loader(8) could be modified to export some sort of versioning of the bootcode to make this a easier stance for the user to gather information before a upgrade. Piece of cake! If you give me a loader(8) that exports a version environment variable, I'll give the Forth functionality in mere seconds. It's already been developed (but was not packaged). I have a module named version.4th which prints the value of the version environment variable at the bottom-right of the screen underneath the beastie logo. Since you mention this, I'll add the code to the next package and if/when loader(8) ever exports a version environment variable, it will just magically appear. How's that sound? Sounds perfect! -- Regards, (jhell) Jason Hellenthal pgpjXdkxfm4pB.pgp Description: PGP signature
[UPDATE] New Boot-Loader Menu -- version 1.1
NOTE: Apologies if this comes through multiple times. I'm having problems getting this e-mail to appear on the list. Hi again, fellow hackers, First, I'd like to thank all of you for the input and suggestions that you provided. Things are moving fast and nimble here. With over 1,000 lines of code changed (in one single 24-hour period), I'd like to announce an update to my advanced boot-loader menu. This version (1.1) attempts to address all community requests. You can grab the updated code here: http://druidbsd.sourceforge.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.1.tgz == Below is an itemized list of things addressed in this latest release (complete with attribution to the person(s) whom made the request): Mike Meyer: Individual menuitem hotkeys have been implemented. (ENTER = boot, a = ACPI, v = verbose, s = single-user, m = safe-mode, esc = escape to loader prompt). Paul Schenkeveld, Damien Fleuriot, Zhihao Yuan, and Warner Losh: Both numbers and hotkeys are supported. Freddie Cash: Customize beastie logo with loader.conf(5) variables (see below -- also documented in package description). Alexander Leidinger: When loader_color is enabled (see loader.conf(5) variables below -- also documented in package description), the hotkeys/mnemonics are bolded (sorry, underline is currently not implemented correctly in loader(8)). When loader_color is disabled (the default), the hotkeys/mnemonics appear in [square-brackets] (e.g. [ENTER], [A], [V], [M], [S], and [Esc]). Also, when loader_color is enabled, the numerical prefixes are also made bold (when loader_color is disabled, the numerical prefixes are displayed normally -- without square-brackets). Olivier SMEDTS: All loader.conf(5) variables that are supported by the current loader are now supported, including `loader_logo' and many many more (see loader.conf(5) variables below -- also documented in package description). Warren Block and Doug Barton: With respect to ANSI underline being a more standard UI choice for hotkey/mnemonics... sorry, ANSI underline is currently not implemented correctly in loader(8) as of RELENG_8 that I've tried. Going with ANSI bold when loader_color is enabled and square-brackets by default. Artem Belevich: The default layout should meet all VT100 requirements (that is to explain, that out of the box with no additional customizations in loader.conf(5), the menu should meet VT100 standards). Dieter BSD: In the out of box configuration (assuming the user doesn't have any existing customizations in loader.conf(5)), all of your previously-mentioned decrees have been met (no graphics, no color, no assumptions, etc. etc.). The only requirements are that you have an 80x24 screen and a basic keyboard with either letters 1-7 or A-Z+ENTER (or both). Jason Hellenthal (aka jhell): The ability to display the loader version at the bottom-right edge of the screen (right-justified) is enabled. However, currently the loader does not export the loader_version environment variable, and thus nothing will be displayed until then. Though, to test this feature, you can simply add a line to loader.conf(5) (see the loader.conf(5) variables below -- also documented in the package description). All: The initial delay introduced before loading the menu can be disabled/customized (see loader.conf(5) variables below -- also documented in package description). Mehmet Erol Sanliturk: You can customize the default 10-second menu timeout by adding `loader_menu_timeout' to loader.conf(5) (see the loader.conf(5) variables below -- also documented in the package description). You had stated a desire to increase the timeout to 255. Minor note: due to limited screen real-estate, the countdown timer will continue to display 9 seconds until the internal timer gets to a number that is below 9 (however, this should still meet your needs of dramatically increasing the timeout delay). == Here's the package description (+DESC: attainable via either `tar zxfO loader_menu-X.Y.tgz +DESC | less' or `pkg_info -dx loader_menu | less'): loader_menu is a modern boot loader for the FreeBSD Operating System. The following options can be added to loader.conf(5) to customize the behavior and/or appearance of the boot menu/process: loader_color=YES Enables the use of color in the boot menu. Not all devices support the display of ANSI color codes, and so the default is to not use them. loader_logo=... Selects which FreeBSD logo to display. Valid values are beastie, beastiebw, fbsdbw, orb, or orbbw. An invalid value (such as none) will disable the display of any logo. The logo is displayed to the right of the dynamic menu. loader_logo_x=N loader_logo_y=N Column (x) and row (y) placement of FreeBSD mascot placed to the right of the dynamic menu. Defaults are 46 (x) and 4 (y).
Re: [UPDATE] New Boot-Loader Menu -- version 1.1
2011/5/2 Devin Teske dte...@vicor.com: NOTE: Apologies if this comes through multiple times. I'm having problems getting this e-mail to appear on the list. Hi again, fellow hackers, First, I'd like to thank all of you for the input and suggestions that you provided. Things are moving fast and nimble here. With over 1,000 lines of code changed (in one single 24-hour period), I'd like to announce an update to my advanced boot-loader menu. This version (1.1) attempts to address all community requests. You can grab the updated code here: http://druidbsd.sourceforge.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.1.tgz Using it right now. Great :) What would you think of using the bw variant of a logo when loader_color=NO ? Oh forget that, I tried without a loader_logo setting, and it seems to be the case with the default orb. It was only strange with my previous setting of loader_logo=beastie, without the new loader_color setting. The previous loader behavior when an unknown key was pressed was to reset the delay to the autoboot_delay value. And it also worked with, for examble, the arrow keys. I appreciated it, like I appreciate your Space to pause ! Do you know why this loader displays ACPI Support: Disabled on my 9-CURRENT amd64 computer when it really seems to be enabled ? Note acpi.ko is not loaded, it's in the GENERIC kernel. loader_menu_timeout=N Timeout in seconds (N) until the menu aborts, causing the system to autoboot with the displayed options. Default is 10 seconds. Pressing any key during the duration will cancel the timeout. Could you add a compatibility shim for the actual autoboot_delay variable ? dc_seconds=N By default, loader_menu introduces a 2-second delay before launching the menu for improved debugging abilities. This option customizes the duration (setting it to zero disables the delay). However, it is worth noting that pressing ENTER anytime during the delay will preempt the duration, launching the menu immediately upon keypress. For consistency with all the logo_* variables, what would you think of using something like loader_delay instead of dc_seconds ? (and yes, I know, autoboot_delay doesn't begin with loader_, but it was there before ;) Many thanks ! -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [UPDATE] New Boot-Loader Menu -- version 1.1
UPDATE: New version 1.2 released right now. Get your update at: http://druidbsd.sourceforge.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.2.tgz Keep reading for details/discussion below. -Original Message- From: Olivier Smedts [mailto:oliv...@gid0.org] Sent: Monday, May 02, 2011 2:25 PM To: Devin Teske Cc: FreeBSD Hackers; m...@mired.org; m...@freebsd.org; me...@freebsd.org; war...@freebsd.org; l...@freebsd.org; fred...@freebsd.org; c...@freebsd.org; alexan...@freebsd.org; leidin...@freebsd.org; oliv...@freebsd.org; sme...@freebsd.org; war...@freebsd.org; bl...@freebsd.org; d...@freebsd.org; bar...@freebsd.org; ar...@freebsd.org; belev...@freebsd.org; die...@freebsd.org; b...@freebsd.org; ja...@freebsd.org; hellent...@freebsd.org; de...@freebsd.org; te...@freebsd.org; dam...@freebsd.org; fleur...@freebsd.org; zhi...@freebsd.org; y...@freebsd.org; p...@freebsd.org; schenkev...@freebsd.org; meh...@freebsd.org; e...@freebsd.org; sanlit...@freebsd.org; d...@freebsd.org; robi...@freebsd.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1 2011/5/2 Devin Teske dte...@vicor.com: NOTE: Apologies if this comes through multiple times. I'm having problems getting this e-mail to appear on the list. Hi again, fellow hackers, First, I'd like to thank all of you for the input and suggestions that you provided. Things are moving fast and nimble here. With over 1,000 lines of code changed (in one single 24-hour period), I'd like to announce an update to my advanced boot-loader menu. This version (1.1) attempts to address all community requests. You can grab the updated code here: http://druidbsd.sourceforge.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.1.tgz Using it right now. Great :) ^_^ What would you think of using the bw variant of a logo when loader_color=NO ? Oh forget that, I tried without a loader_logo setting, and it seems to be the case with the default orb. It was only strange with my previous setting of loader_logo=beastie, without the new loader_color setting. Right. I wanted it to function so that if you explicitly set loader_logo, that it would override the use of loader_color. If you don't set loader_logo, then playing with loader_color will automatically switch from orbbw to orb, whereas if you set it to something like beastie, you'll get that logo regardless of what loader_color is set to. The previous loader behavior when an unknown key was pressed was to reset the delay to the autoboot_delay value. I wasn't aware of that functionality (I'd always pressed SPACE to pause the timer). Maybe a dumb question, but why would anybody want to reset the timer? I can't think of a single scenario where I'd prefer a timer to be reset on keypress opposed to just stopping. I'm of the school of thought that there are only three reasonable scenarios where you'd want to abate auto-boot (listed below), all of which involve more time than just another 10 seconds gained by resetting the timer: 1. Slow readers (of which I am guilty of) 2. People that just want to bask in the glory of the boot-loader (also guilty) 3. Hackers that want to rewrite rogue(6) in FICL for the boot-loader (work in progress?) Is this a serious concern (removing the reset timer on unknown key functionality)? And it also worked with, for examble, the arrow keys. I appreciated it, like I appreciate your Space to pause ! Arrow keys are funny. They produce a zero value by the key function, so detecting them is ... impossible. However, I was able to correct this behavior. Version 1.2 (just released right now) will cancel the timeout on ANY keypress, including keys that produce NULL keycodes (such as arrows, navigational keys, command sequences, and special key combinations). Do you know why this loader displays ACPI Support: Disabled on my 9-CURRENT amd64 computer when it really seems to be enabled ? Note acpi.ko is not loaded, it's in the GENERIC kernel. The previous version (1.0) had a hard-coded set acpi_load=YES in /boot/menu-commands.4th. This has been removed in favor of dynamically detecting acpi_load at boot time. This version (1.1) works nearly identically to the standard menu that ships with FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually re-used the acpienabled? function verbatim from /boot/beastie.4th by Scott Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1 or higher) should be identical to the detection of the current boot-loader. I would be willing to bet that your workstation -- while running the default boot loader -- displays Boot FreeBSD with ACPI enabled for option #2 (indicating that ACPI appears to be disabled from your system's perspective). As far as I know, the loader does not know that ACPI is compiled into your kernel. Rather the ACPI menuitem (both in the default boot-loader menu and in my
[UPDATE] New Boot-Loader Menu -- version 1.3
Hey all, Proud to bring you version 1.3 which completes the followup suggestions made by Olivier Smedts (use autoboot_delay instead of loader_menu_timeout and change dc_seconds to loader_delay) and a couple other minor enhancements/fixes. I think that brings everything up to speed with the phenomenal feedback provided so far. Really, thank you all very much. Get your update at http://druidbsd.sf.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz Here's a dump of the latest pkg-descr (the pertinent parts that have changed are highlighted above and one additional paragraph added to the end about loader_delay): loader_menu is a modern boot loader for the FreeBSD Operating System. The following options can be added to loader.conf(5) to customize the behavior and/or appearance of the boot menu/process: autoboot_delay=N Timeout in seconds (N) until the menu aborts, causing the system to autoboot with the displayed options. Default is 10 seconds. Pressing any key during the duration will cancel the timeout. You can use values as high as you like, however due to limited screen real-estate (at a mere 24 rows x 80 columns for compatibility reasons) the counter will simply display 9 seconds while counting down internally. Once the final countdown is upon you, the numbers will finally start to move. A future version could overcome this limitation. loader_menu_timeout_x=N loader_menu_timeout_y=N Column (x) and row (y) placement of the menu timeout count-down text. Defaults are 4 (x) and 23 (y). loader_color=YES Enables the use of color in the boot menu. Not all devices support the display of ANSI color codes, and so the default is to not use them. loader_logo=... Selects which FreeBSD logo to display. Valid values are beastie, beastiebw, fbsdbw, orb, or orbbw. An invalid value (such as none) will disable the display of any logo. The logo is displayed to the right of the dynamic menu. loader_logo_x=N loader_logo_y=N Column (x) and row (y) placement of FreeBSD mascot placed to the right of the dynamic menu. Defaults are 46 (x) and 4 (y). loader_brand=... Selects the BSD brand to display. Valid values are fbsd (displays FreeBSD) and dbsd (displays DruidBSD). An invalid value (such as none) will disable the display of any brand. The brand is displayed above the dynamic menu. The default is fbsd. loader_brand_x=N loader_brand_y=N Column (x) and row (y) placement of the brand text (FreeBSD) placed above the dynamic menu. Defaults are 2 (x) and 1 (y). loader_password=... Sets a password (up to 16 characters long) that is required to be entered before the system is allowed to boot. Default is to not ask for a password if unset or NULL. loader_version=... Overrides the display of the loader's built-in version. Displays the text at the bottom-right edge of the screen (underneath beastie). The version text is right-justified when displayed. The current default is to not display any text. However, as-of RELENG_9, there may be plans to modify loader(8) to export this variable for display during the boot process, displaying the version of boot-loader for trouble-shooting purposes. loader_version_x=N loader_version_y=N Column (x) and row (y) placement of the loader's built-in version at the bottom-right edge of the screen. Defaults are 80 (x) and 24 (y). The version text is right-justified with the text ending at (x,y). loader_delay=N By default, loader_menu introduces a 2-second delay before launching the menu for improved debugging abilities. This option customizes the duration (setting it to zero disables the delay). However, it is worth noting that pressing ENTER anytime during the delay will preempt the duration, launching the menu immediately upon keypress. During this delay, a string of dots is displayed. The user can press Ctrl-C or Esc on the keyboard to prevent the loading of the dynamic menu system. After pressing either of these keys, the loader will drop to the usual autoboot sequence (counting down autoboot_delay seconds until booting the loaded kernel). During the autoboot sequence, any key pressed except for ENTER will allow escaping to the loader prompt. WWW: http://druidbsd.sourceforge.net/ -- Cheers, Devin Teske - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the
Re: [RELEASE] New Boot-Loader Menu
On Fri, 29 Apr 2011 16:55:12 -0700 Devin Teske dte...@vicor.com wrote: -Original Message- From: Alexander Leidinger [mailto:alexan...@leidinger.net] Sent: Friday, April 29, 2011 1:34 PM To: Devin Teske Cc: 'Mike Meyer'; 'FreeBSD Hackers' Subject: Re: [RELEASE] New Boot-Loader Menu On Fri, 29 Apr 2011 12:02:03 -0700 Devin Teske dte...@vicor.com wrote: I was thinking that what we ought to do is support *both* numbers *and* letters. Sounds good to me. I envision the menuitem numbers remaining unchanged (1-7), allowing those familiar with the numbers to use them. However, as for the letters, I'm thinking that we *BOLD* the mnemonic in the menuitem. For example (showing bolded items between asterisks): 1. Boot *[ENTER]* 2. *A*CPI Support: Enabled 3. Boot Safe Mode: NO 4. Boot *S*ingle User: NO 5. Boot *V*erbose: NO 6. *Esc*ape to loader prompt 7. *R*eboot This should indicate to the user, for example if they see that the V in Verbose is bolded, that they can press that key to activate that menuitem. Your below points are all valid arguments. However, I think they are a bit reaching. The types of people that know what it means to boot into Single-User and/or Verbose mode would not be prone to thinking in those ways. Maybe not single user, but maybe verbose. For me the first question is not how to improve this, my first question is if we need to improve this. I'm still leaning toward just making the V in Verbose and S in Single User bolded. Your initial proposal about the characters looked fine for me. Only making those two in bold looks looks like a step backwards to me. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
[ attempt #2 - grumble - sorry about the blank message, hope it works this time - grumble- ] I hope that works for serial console. VT100 may be a reasonable default in that case, but it would be good to make sure that menu works even on a dumb terminal. Perhaps we should put 'key' letter in brackets then? This needs to work, correctly, everywhere. This needs to be easy to understand by a stressed out user whose machine is having problems. Therefore: Thou shalt not assume graphics. Thou shalt not assume color. Thou shalt not assume VT100 or any specific terminal. Thou shalt not assume ability to display bold. Thou shalt not assume ability to underline text. Thou shalt not assume availability of multiple fonts. Thou shalt not assume more than 24x80 chars. Thou shalt not assume scrollback. Thou shalt not assume fancy cursor movements. Thou shalt not assume presence of function keys. Thou shalt not assume presence of arrow keys. Thou shalt not assume a fast interface. Thou shalt not assume the three-finger-salute works. Putting brackets around letters (and numbers) sounds good. If there is room, perhaps add a message explaining that the user should enter one of the choices in brackets. A help option would be useful, giving a reminder of what things like ACPI and APIC stand for, what safe mode does, etc. Would be nice: uname -v of the kernel it will boot. Would be nice: a user friendly way to boot from a different disk/partition/kernel. Without the user having to know the mapping between what the firmware calls disks and what FreeBSD calls disks. And without writing anything to disk. Would be nice: a fix for having to lean on a key autorepeating for a couple seconds. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [RELEASE] New Boot-Loader Menu
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Dieter BSD Sent: Saturday, April 30, 2011 12:28 PM To: freebsd-hackers@freebsd.org Subject: Re: [RELEASE] New Boot-Loader Menu [ attempt #2 - grumble - sorry about the blank message, hope it works this time - grumble- ] I hope that works for serial console. VT100 may be a reasonable default in that case, but it would be good to make sure that menu works even on a dumb terminal. Perhaps we should put 'key' letter in brackets then? This needs to work, correctly, everywhere. This needs to be easy to understand by a stressed out user whose machine is having problems. Therefore: Thou shalt not assume graphics. Thou shalt not assume color. Thou shalt not assume VT100 or any specific terminal. Thou shalt not assume ability to display bold. Thou shalt not assume ability to underline text. Thou shalt not assume availability of multiple fonts. Thou shalt not assume more than 24x80 chars. Thou shalt not assume scrollback. Thou shalt not assume fancy cursor movements. Thou shalt not assume presence of function keys. Thou shalt not assume presence of arrow keys. Thou shalt not assume a fast interface. Thou shalt not assume the three-finger-salute works. I agree with all those decrees. I'll make the next version will meet all those requirements in its out of the box configuration. If users want to make it colorized, I'll provide a knob that can be added to loader.conf(5) (how about ``loader_color=1'' ??). Already on the to-do list is to support ``loader_logo=...'' in /boot/loader.conf Putting brackets around letters (and numbers) sounds good. If there is room, perhaps add a message explaining that the user should enter one of the choices in brackets. I think I'm going to have to play with this and see what we come up with. I don't want to make it too busy if you know what I mean. That's with respect to the brackets. As for adding a messages... things are a bit tight and again, I'm afraid of making it too cluttered. I'll post some screenshots of some mock-ups tomorrow, incorporating the various requests. A help option would be useful, giving a reminder of what things like ACPI and APIC stand for, what safe mode does, etc. This is not altogether infeasible. Since this menu (unlike the current one) has the ability to be wiped from screen and then recalled completely in the original state is was left in ... implementing an F1 feature that reads text from a file would be very do-able. I was at one time experimenting with reading a version.inf file from disk to be displayed at the bottom-right of the screen (under beastie logo) ... a way of indicating the version of either loader, OS, both, or more (could be auto-generated as part of release(7) for each/every release). Would be nice: uname -v of the kernel it will boot. That's a bit more technically challenging. I'll have another look at the FICL words available, but I don't recall if there was a way to crawl the object space of the items loaded with ``load'' (looking for the uname). I'm open to suggestions if you had an idea of how to do this in Forth -- else I'd think this would need to be a loader(8) modification. Would be nice: a user friendly way to boot from a different disk/partition/kernel. Without the user having to know the mapping between what the firmware calls disks and what FreeBSD calls disks. And without writing anything to disk. That's also a bit technically challenging in Forth, I think. Open to suggestions, but again would likely be best implemented as a change to loader(8), no? Would be nice: a fix for having to lean on a key autorepeating for a couple seconds. Could you explain? I don't follow. -- Devin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
Already on the to-do list is to support ``loader_logo=...'' in /boot/loader.conf Including an option for no logo? (For consoles that are slow and/or small, and for people that just don't like the logos.) Putting brackets around letters (and numbers) sounds good. If there is room, perhaps add a message explaining that the user should enter one of the choices in brackets. I think I'm going to have to play with this and see what we come up with. I don't want to make it too busy if you know what I mean. That's with respect to the brackets. As for adding a messages... things are a bit tight and again, I'm afraid of making it too cluttered. I'll post some screenshots of some mock-ups tomorrow, incorporating the various requests. A help option would be useful, giving a reminder of what things like ACPI and APIC stand for, what safe mode does, etc. This is not altogether infeasible. Since this menu (unlike the current one) has the ability to be wiped from screen and then recalled completely in the original state is was left in ... implementing an F1 feature that reads text from a file would be very do-able. If there is a help option that the user can figure out how to execute, the explaination about brackets (if you go that route), entering numbers, letters, and such could be included in the help screen(s) instead of the main menu page. Would be nice: a fix for having to lean on a key autorepeating for a couple seconds. Could you explain? I don't follow. On my Tyan Tomcat k8e 2865, just entering the number rarely if ever works. I have to either repeatedly bang away at the key or hold it down, letting the RS-232 terminal do the autorepeat thing, while hoping that it notices before the timer runs out. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
Devin, On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote: Would be nice: uname -v of the kernel it will boot. That's a bit more technically challenging. I'll have another look at the FICL words available, but I don't recall if there was a way to crawl the object space of the items loaded with ``load'' (looking for the uname). I'm open to suggestions if you had an idea of how to do this in Forth -- else I'd think this would need to be a loader(8) modification. How about forgetting a mention of unmae ... instead look into if we can support some sort of bootcode versioning to be displayed on the screen. This would serve to be very helpful in the future when for say a new version of bootcode for ZFS has to be installed then it would be easy for announce@ to simply say A new version of ZFS has been MFCd and requires boot version = X. To find out your version please see the bottom right hand corner of your boot screen. I would place a pretty good bet that loader(8) could be modified to export some sort of versioning of the bootcode to make this a easier stance for the user to gather information before a upgrade. -- Regards, (jhell) Jason Hellenthal pgpSxMzRr5ZWy.pgp Description: PGP signature
Re: [RELEASE] New Boot-Loader Menu
On Apr 30, 2011, at 6:10 PM, Dieter BSD wrote: Already on the to-do list is to support ``loader_logo=...'' in /boot/loader.conf Including an option for no logo? (For consoles that are slow and/or small, and for people that just don't like the logos.) The current behavior -- with what's in CVS today -- is to draw a logo for all values of loader_logo except for none. My menu differs slightly, improving functionality by defaulting to not draw any logo for values we don't understand. Therefore none would have the desired effect (but so will NO, blank, johnnycat, billjoy, or even -- all produce a menu with no logo). NOTE: If NULL, we don't display the logo, however if unset, we'll default to displaying the chosen/sensible default (going for `orbbw' to comply with the aforementioned compatibility decrees -- of which I fully agree with). This is to facilitate the loader.conf(5) override ability. Currently, you'd make the change by altering the ``set logo=orb'' line in /etc/menu.rc (line 10). In the next release, I plan to change the environment variable from logo to loader_logo for backward compatibility (allowing loader.conf(5) override as previously mentioned). Putting brackets around letters (and numbers) sounds good. If there is room, perhaps add a message explaining that the user should enter one of the choices in brackets. I think I'm going to have to play with this and see what we come up with. I don't want to make it too busy if you know what I mean. That's with respect to the brackets. As for adding a messages... things are a bit tight and again, I'm afraid of making it too cluttered. I'll post some screenshots of some mock-ups tomorrow, incorporating the various requests. A help option would be useful, giving a reminder of what things like ACPI and APIC stand for, what safe mode does, etc. This is not altogether infeasible. Since this menu (unlike the current one) has the ability to be wiped from screen and then recalled completely in the original state is was left in ... implementing an F1 feature that reads text from a file would be very do-able. If there is a help option that the user can figure out how to execute, the explaination about brackets (if you go that route), entering numbers, letters, and such could be included in the help screen(s) instead of the main menu page. One of the decrees was that we shouldn't assume that there are function keys. I think that's a fair decree, so that puts me in a quandry with the Press F1 for Help model of presentation. Although convenient programmatically, it could potentially leave users without function-keys without an ability to read the carefully prepared messages awaiting their keypress. There's really only room for one or two more menu items. Perhaps we could introduce a new menuitem after the reboot item. A menuitem whose number is perhaps not a number, but instead the question-mark. The text for which could be [H]elp (keeping to the recent bracketed concept -- which could conceptually switch to underline if loader_color is set). Would be nice: a fix for having to lean on a key autorepeating for a couple seconds. Could you explain? I don't follow. On my Tyan Tomcat k8e 2865, just entering the number rarely if ever works. I have to either repeatedly bang away at the key or hold it down, letting the RS-232 terminal do the autorepeat thing, while hoping that it notices before the timer runs out. Is that with the current code that's in CVS? I'd love for you to try my code on that hardware. One of the things that I worked on in the very beginning was the responsiveness. -- Cheers, Devin Teske - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - FUN STUFF - -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+ D+(++) G++ e h r+++ z+++ --END GEEK CODE BLOCK-- http://www.geekcode.com/ - END TRANSMISSION - _ 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. _ ___ freebsd-hackers@freebsd.org mailing list
Re: [RELEASE] New Boot-Loader Menu
On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote: Devin, On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote: Would be nice: uname -v of the kernel it will boot. That's a bit more technically challenging. I'll have another look at the FICL words available, but I don't recall if there was a way to crawl the object space of the items loaded with ``load'' (looking for the uname). I'm open to suggestions if you had an idea of how to do this in Forth -- else I'd think this would need to be a loader(8) modification. How about forgetting a mention of unmae ... instead look into if we can support some sort of bootcode versioning to be displayed on the screen. This would serve to be very helpful in the future when for say a new version of bootcode for ZFS has to be installed then it would be easy for announce@ to simply say A new version of ZFS has been MFCd and requires boot version = X. To find out your version please see the bottom right hand corner of your boot screen. I would place a pretty good bet that loader(8) could be modified to export some sort of versioning of the bootcode to make this a easier stance for the user to gather information before a upgrade. Piece of cake! If you give me a loader(8) that exports a version environment variable, I'll give the Forth functionality in mere seconds. It's already been developed (but was not packaged). I have a module named version.4th which prints the value of the version environment variable at the bottom-right of the screen underneath the beastie logo. Since you mention this, I'll add the code to the next package and if/when loader(8) ever exports a version environment variable, it will just magically appear. How's that sound? -- Regards, (jhell) Jason Hellenthal -- Cheers, Devin Teske - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - FUN STUFF - -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+ D+(++) G++ e h r+++ z+++ --END GEEK CODE BLOCK-- http://www.geekcode.com/ - END TRANSMISSION - _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
On Sun, 24 Apr 2011 18:53:11 -0700 Devin Teske dte...@vicor.com wrote: Hello fellow hackers, I'd love to finally release (under the BSD license) my code for the revamped FreeBSD boot loader menu. Here's a detailed discussion of the release complete with pictures: http://devinteske.com/new-freebsd-boot-loader-menu Got it, nice simple install (as promised), and it worked like a charm. I'd like to revisit the numbers vs. letters for menu options. IIRC (and I may not), an earlier version used letters for the menu options, and people objected to that change. Since we're changing the menus, we ought to look at which is best for the end user, as opposed to just doing what feels comfortable to us as old users. In particular, there was a study done around '80 (I tried to find it but couldn't; I know of someone who can probably provide a reference if someone really wants it) that showed that menu selection with letters assigned mnemonically are easiest for users to memorize. Not really a major issue - you shouldn't be booting FreeBSD systems all that often, so it's not something I care very much about. However, I figure someone ought to at least speak up for using system that's better for new users rather than quietly doing it the old way since we're making a change anyway. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
Why not both? duck Warner On Apr 29, 2011, at 11:08 AM, Mike Meyer wrote: On Sun, 24 Apr 2011 18:53:11 -0700 Devin Teske dte...@vicor.com wrote: Hello fellow hackers, I'd love to finally release (under the BSD license) my code for the revamped FreeBSD boot loader menu. Here's a detailed discussion of the release complete with pictures: http://devinteske.com/new-freebsd-boot-loader-menu Got it, nice simple install (as promised), and it worked like a charm. I'd like to revisit the numbers vs. letters for menu options. IIRC (and I may not), an earlier version used letters for the menu options, and people objected to that change. Since we're changing the menus, we ought to look at which is best for the end user, as opposed to just doing what feels comfortable to us as old users. In particular, there was a study done around '80 (I tried to find it but couldn't; I know of someone who can probably provide a reference if someone really wants it) that showed that menu selection with letters assigned mnemonically are easiest for users to memorize. Not really a major issue - you shouldn't be booting FreeBSD systems all that often, so it's not something I care very much about. However, I figure someone ought to at least speak up for using system that's better for new users rather than quietly doing it the old way since we're making a change anyway. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
Very nice and functional, without adding a lot of extra verbosity or steps. I really appreciated the clean install via binary package. Well done. Only question I have is whether it's possible to use the Beastie ASCII image instead of the pointy-eared blob? The beastie.4th file is still present under /boot, but I don't know how to hook it into the new menu. -- Freddie Cash fjwc...@gmail.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [RELEASE] New Boot-Loader Menu
-Original Message- From: Mike Meyer [mailto:m...@mired.org] Sent: Friday, April 29, 2011 10:08 AM To: Devin Teske Cc: FreeBSD Hackers Subject: Re: [RELEASE] New Boot-Loader Menu On Sun, 24 Apr 2011 18:53:11 -0700 Devin Teske dte...@vicor.com wrote: Hello fellow hackers, I'd love to finally release (under the BSD license) my code for the revamped FreeBSD boot loader menu. Here's a detailed discussion of the release complete with pictures: http://devinteske.com/new-freebsd-boot-loader-menu Got it, nice simple install (as promised), and it worked like a charm. I'd like to revisit the numbers vs. letters for menu options. IIRC (and I may not), an earlier version used letters for the menu options, and people objected to that change. Looking at the CVS history of the Forth code that renders the menu, I'm noticing: a. FreeBSD-4.x and earlier didn't have a menu (after loading the kernel, the loader simply drops to autoboot). b. FreeBSD-5.x introduced the menu that is currently in-use today (rendered by `beastie.4th'). c. The current menu uses numbers, not letters. If there was an earlier version of the menu that used letters, I'm not seeing it in CVS. Since we're changing the menus, we ought to look at which is best for the end user, as opposed to just doing what feels comfortable to us as old users. I was thinking that what we ought to do is support *both* numbers *and* letters. I envision the menuitem numbers remaining unchanged (1-7), allowing those familiar with the numbers to use them. However, as for the letters, I'm thinking that we *BOLD* the mnemonic in the menuitem. For example (showing bolded items between asterisks): 1. Boot *[ENTER]* 2. *A*CPI Support: Enabled 3. Boot Safe Mode: NO 4. Boot *S*ingle User: NO 5. Boot *V*erbose: NO 6. *Esc*ape to loader prompt 7. *R*eboot This should indicate to the user, for example if they see that the V in Verbose is bolded, that they can press that key to activate that menuitem. In addition, represented above, the only non-numeric keys that do anything would be: ENTER to boot A to toggle ACPI support S to toggle Single User mode V to toggle Verbose boot Esc to escape to the loader prompt R to reboot Looking at a standard QWERTY keyboard, A and S are close to each other, but since the new menu is stateful (meaning that pressing the key merely changes the state of that option) rather than stateless (wherein pressing a key would immediately boot with that option), if you jam the wrong key, no worries (just jam it again to return it to its pre-toggled state). I'm open to discussion as to what the keys should be, though I'm pretty hard-set on S for single-user, and V for verbose (the others, besides ENTER-to-boot, are open for debate -- personally I think I'd be happy with nothing more than just ENTER, S and V and no others). In particular, there was a study done around '80 (I tried to find it but couldn't; I know of someone who can probably provide a reference if someone really wants it) that showed that menu selection with letters assigned mnemonically are easiest for users to memorize. I can believe that quite easily. However, currently the boot menu does not support such letters. I think this new loader menu is the perfect place to implement them. On another note, I have one other change that I'd like to get in... I noticed that (in CVS) the menu currently blanks-out option #2 if booting on a system where ACPI is disabled or unavailable. In my boot loader, I'd like to display ACPI Support: N/A rather than simply blanking out the menu item. -- Devin Not really a major issue - you shouldn't be booting FreeBSD systems all that often, so it's not something I care very much about. However, I figure someone ought to at least speak up for using system that's better for new users rather than quietly doing it the old way since we're making a change anyway. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [RELEASE] New Boot-Loader Menu
-Original Message- From: Freddie Cash [mailto:fjwc...@gmail.com] Sent: Friday, April 29, 2011 11:20 AM To: Devin Teske Cc: FreeBSD Hackers Subject: Re: [RELEASE] New Boot-Loader Menu Very nice and functional, without adding a lot of extra verbosity or steps. I really appreciated the clean install via binary package. Well done. Only question I have is whether it's possible to use the Beastie ASCII image instead of the pointy-eared blob? The beastie.4th file is still present under /boot, but I don't know how to hook it into the new menu. Glad you asked. This couldn't be easier. Open up `/boot/menu.rc' and look for the following lines (LINE 9-10): \ Customizations set logo=orb Feel free to play with any of the following drop-in replacements: set logo=beastie set logo=beastiebw set logo=fbsdbw set logo=orb set logo=orbbw Simply deleting the line or comment it out (by adding \ -- backslash-space -- to the beginning of the line) is equivalent to setting logo to beastie. Here's a short explanation of each value: NAMEDESCRIPTION beastie Color ``Helper Daemon'' mascot (19 rows x 34 columns) beastiebw B/W ``Helper Daemon'' mascot (19 rows x 34 columns) fbsdbw FreeBSD logo in B/W (13 rows x 21 columns) orb Color ``Orb'' mascot (15 rows x 30 columns) orbbw B/W ``Orb'' mascot (15 rows x 30 columns) I'm not sure what you meant by Beastie ASCII image, but I think you're either looking for beastie or fbsdbw. You should have to, but if you need to, you can add: set logoX=X set logoY=Y to force the row/column placement of beastie. -- Devin -- Freddie Cash fjwc...@gmail.com _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
On Fri, 29 Apr 2011 12:02:03 -0700 Devin Teske dte...@vicor.com wrote: -Original Message- From: Mike Meyer [mailto:m...@mired.org] I'd like to revisit the numbers vs. letters for menu options. IIRC (and I may not), an earlier version used letters for the menu options, and people objected to that change. Looking at the CVS history of the Forth code that renders the menu, I'm noticing: If there was an earlier version of the menu that used letters, I'm not seeing it in CVS. I was referring to your code, not the historical FreeBSD code. Didn't you originally propose using letters, not numbers, to toggle the boot options? If not, then possibly I'm remembering another proposal. In particular, there was a study done around '80 (I tried to find it but couldn't; I know of someone who can probably provide a reference if someone really wants it) that showed that menu selection with letters assigned mnemonically are easiest for users to memorize. I can believe that quite easily. However, currently the boot menu does not support such letters. I think this new loader menu is the perfect place to implement them. This seemed like a good time to change it if we were going to to me. On another note, I have one other change that I'd like to get in... I noticed that (in CVS) the menu currently blanks-out option #2 if booting on a system where ACPI is disabled or unavailable. In my boot loader, I'd like to display ACPI Support: N/A rather than simply blanking out the menu item. That would certainly make the numbers make more sense. Thanks, mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [RELEASE] New Boot-Loader Menu
-Original Message- From: Mike Meyer [mailto:m...@mired.org] Sent: Friday, April 29, 2011 12:24 PM To: Devin Teske Cc: 'FreeBSD Hackers' Subject: Re: [RELEASE] New Boot-Loader Menu On Fri, 29 Apr 2011 12:02:03 -0700 Devin Teske dte...@vicor.com wrote: -Original Message- From: Mike Meyer [mailto:m...@mired.org] I'd like to revisit the numbers vs. letters for menu options. IIRC (and I may not), an earlier version used letters for the menu options, and people objected to that change. Looking at the CVS history of the Forth code that renders the menu, I'm noticing: If there was an earlier version of the menu that used letters, I'm not seeing it in CVS. I was referring to your code, not the historical FreeBSD code. Didn't you originally propose using letters, not numbers, to toggle the boot options? If not, then possibly I'm remembering another proposal. You're recalling a response to the thread that I started on March 28th, 2011 (last month): THREAD-HEAD: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-March/034824.html The letters not numbers post that you're recalling was by Paul S. (below): http://lists.freebsd.org/pipermail/freebsd-hackers/2011-March/034830.html Although Paul makes a point that the letters would be helpful, his complaint about the numbers being changed is a red-herring (he saw the unreleased mock-up image of my boot-loader -- in the thread-head URL above -- presenting different numbers and complained that if the numbers change that sysadmins would be confused). However, the reality is that [a] the final release indeed matches the numbers with the existing boot loader and [b] the numbers have not changed in 7 years). Paul, ... supporting evidence to show that the numbers (1-7) have never changed since their initial commit to CVS on May 30th, 2003 (see the beastie-menu forth word in version 1.1 of beastie.4th circa RELENG_5_0): http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/forth/beastie.4th The case is merely that Paul would like to see this additional feature added (letters as mnemonics). I couldn't find any claims that any previous version (either of my code or official FreeBSD code) ever supported it in the past. So, I think that the grand-total comes to 5 people now that have requested hot-keys for the single-user and verbose menu items: Paul S. (msg #034830) Zhihao Y. (msg #034831) Damien F. (msg #034841) Yourself (Mike M.) (msg #035192 msg #035197) and Myself (Devin T. msg #035195) Let's see if we can't get that list a little higher. Keep in-mind, the proposal (at least for right now) is to have me extend my code to bold the S in Single User, bold the V in Verbose, and accept the S/V key as toggles for these features, all the while maintaining the current number scheme. NOTE: I'm going to wait a couple weeks before starting on this, as I've currently got a couple of other companies evaluating the boot loader in its current form and would like their feedback before moving forward on the next revision. In particular, there was a study done around '80 (I tried to find it but couldn't; I know of someone who can probably provide a reference if someone really wants it) that showed that menu selection with letters assigned mnemonically are easiest for users to memorize. I can believe that quite easily. However, currently the boot menu does not support such letters. I think this new loader menu is the perfect place to implement them. This seemed like a good time to change it if we were going to to me. I couldn't agree more. -- Devin On another note, I have one other change that I'd like to get in... I noticed that (in CVS) the menu currently blanks-out option #2 if booting on a system where ACPI is disabled or unavailable. In my boot loader, I'd like to display ACPI Support: N/A rather than simply blanking out the menu item. That would certainly make the numbers make more sense. Thanks, mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
Le 29 avr. 2011 à 21:17, Devin Teske dte...@vicor.com a écrit : -Original Message- From: Freddie Cash [mailto:fjwc...@gmail.com] Sent: Friday, April 29, 2011 11:20 AM To: Devin Teske Cc: FreeBSD Hackers Subject: Re: [RELEASE] New Boot-Loader Menu Very nice and functional, without adding a lot of extra verbosity or steps. I really appreciated the clean install via binary package. Well done. Only question I have is whether it's possible to use the Beastie ASCII image instead of the pointy-eared blob? The beastie.4th file is still present under /boot, but I don't know how to hook it into the new menu. Glad you asked. This couldn't be easier. Open up `/boot/menu.rc' and look for the following lines (LINE 9-10): \ Customizations set logo=orb Feel free to play with any of the following drop-in replacements: set logo=beastie set logo=beastiebw set logo=fbsdbw set logo=orb set logo=orbbw Would it be possible to support the curent loader settings present in /boot/loader.conf ? I've got something like : loader_logo=beastie autoboot_delay=0 And while the pre-menu delay of 2 seconds is great, is it possible to turn it off or adjust it ? Thanks ! Simply deleting the line or comment it out (by adding \ -- backslash-space -- to the beginning of the line) is equivalent to setting logo to beastie. Here's a short explanation of each value: NAMEDESCRIPTION beastieColor ``Helper Daemon'' mascot (19 rows x 34 columns) beastiebwB/W ``Helper Daemon'' mascot (19 rows x 34 columns) fbsdbwFreeBSD logo in B/W (13 rows x 21 columns) orbColor ``Orb'' mascot (15 rows x 30 columns) orbbwB/W ``Orb'' mascot (15 rows x 30 columns) I'm not sure what you meant by Beastie ASCII image, but I think you're either looking for beastie or fbsdbw. You should have to, but if you need to, you can add: set logoX=X set logoY=Y to force the row/column placement of beastie. -- Devin -- Freddie Cash fjwc...@gmail.com _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [RELEASE] New Boot-Loader Menu
-Original Message- From: Alexander Leidinger [mailto:alexan...@leidinger.net] Sent: Friday, April 29, 2011 1:34 PM To: Devin Teske Cc: 'Mike Meyer'; 'FreeBSD Hackers' Subject: Re: [RELEASE] New Boot-Loader Menu On Fri, 29 Apr 2011 12:02:03 -0700 Devin Teske dte...@vicor.com wrote: I was thinking that what we ought to do is support *both* numbers *and* letters. Sounds good to me. I envision the menuitem numbers remaining unchanged (1-7), allowing those familiar with the numbers to use them. However, as for the letters, I'm thinking that we *BOLD* the mnemonic in the menuitem. For example (showing bolded items between asterisks): 1. Boot *[ENTER]* 2. *A*CPI Support: Enabled 3. Boot Safe Mode: NO 4. Boot *S*ingle User: NO 5. Boot *V*erbose: NO 6. *Esc*ape to loader prompt 7. *R*eboot This should indicate to the user, for example if they see that the V in Verbose is bolded, that they can press that key to activate that menuitem. Your below points are all valid arguments. However, I think they are a bit reaching. The types of people that know what it means to boot into Single-User and/or Verbose mode would not be prone to thinking in those ways. And, even if they were, let's look at the consequences for each: Presented like this a naive first interpretion could be that the letters have to be entered as upper-case. I do not think someone wants to press shift there... Scenario: Naïve User presses Shift-V. Nothing happens. They then press v ... the menu toggles to YES. They press ENTER. Success -- the naïve user has managed to boot with the desired options. Having the characters in bold but the numbers not could also let someone think that only the characters matter. Scenario: Naïve user thinks that only the letters matter, and the only bold items on the menu are [ENTER], S, and V. Naïve user is left wondering how to activate menuitems 2, 3, 6, and 7 for which there are no bolded letters. Naïve user never figures out that the numbers are usable and eventually presses ENTER. The machine boots. Ok... you got me on this one ... this hypothetical [extremely] naïve user may not figure out how to use options 2, 3, 6, and 7, and thus cannot disable ACPI, cannot boot in Safe Mode (disabling both ACPI and APIC, etc.), nor escape to the loader prompt, nor reboot (assuming they don't know how the three-finger-solute or where the power button is). My concession to this user would be to bold the numbers to the left of each menuitem. The user would have to be beyond naïveté if they couldn't figure it out with bold numbers, IMHO. Having a text which tells that the numbers and lower-case characters work for chosing something, may be a solution here. Another solution is maybe 1/[ENTER]. Boot 2/a. ACPI Support... ... but I have to admit that the second solution is ugly. A third solution could be to have the numbers and the characters in bold. Yeah, that's no good. Too ugly. I'm still leaning toward just making the V in Verbose and S in Single User bolded. -- Devin Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [RELEASE] New Boot-Loader Menu
-Original Message- From: Olivier SMEDTS [mailto:oliv...@gid0.org] Sent: Friday, April 29, 2011 4:09 PM To: Devin Teske Cc: Freddie Cash; FreeBSD Hackers Subject: Re: [RELEASE] New Boot-Loader Menu Le 29 avr. 2011 à 21:17, Devin Teske dte...@vicor.com a écrit : -Original Message- From: Freddie Cash [mailto:fjwc...@gmail.com] Sent: Friday, April 29, 2011 11:20 AM To: Devin Teske Cc: FreeBSD Hackers Subject: Re: [RELEASE] New Boot-Loader Menu Very nice and functional, without adding a lot of extra verbosity or steps. I really appreciated the clean install via binary package. Well done. Only question I have is whether it's possible to use the Beastie ASCII image instead of the pointy-eared blob? The beastie.4th file is still present under /boot, but I don't know how to hook it into the new menu. Glad you asked. This couldn't be easier. Open up `/boot/menu.rc' and look for the following lines (LINE 9-10): \ Customizations set logo=orb Feel free to play with any of the following drop-in replacements: set logo=beastie set logo=beastiebw set logo=fbsdbw set logo=orb set logo=orbbw Would it be possible to support the curent loader settings present in /boot/loader.conf ? I've got something like : loader_logo=beastie autoboot_delay=0 Yeah, that's definitely possible. The new code already supports /boot/loader.conf, however I don't support loader_logo in that way (you'd have to use logo= instead of loader_logo= and you'd have to remove the set logo= line from /boot/menu.rc). I'll have to make the following modifications in the next version so that you can use loader_logo from /boot/loader.conf: 1. Change the default logo in /boot/beastie.4th from beastie to orb 2. Change /boot/menu.rc to remove the line: set logo=orb 3. Change /boot/beastie.4th to read the loader_logo environment variable instead of logo And while the pre-menu delay of 2 seconds is great, is it possible to turn it off or adjust it ? Right now, if you want to disable the 2 second delay, open up /boot/loader.rc and change the following line: set dc_seconds=2 to: set dc_seconds=0 In the next release, I'll rewrite it so that you add something to /boot/loader.conf to disable the delay. -- Devin Thanks ! Simply deleting the line or comment it out (by adding \ -- backslash-space -- to the beginning of the line) is equivalent to setting logo to beastie. Here's a short explanation of each value: NAMEDESCRIPTION beastieColor ``Helper Daemon'' mascot (19 rows x 34 columns) beastiebwB/W ``Helper Daemon'' mascot (19 rows x 34 columns) fbsdbwFreeBSD logo in B/W (13 rows x 21 columns) orbColor ``Orb'' mascot (15 rows x 30 columns) orbbwB/W ``Orb'' mascot (15 rows x 30 columns) I'm not sure what you meant by Beastie ASCII image, but I think you're either looking for beastie or fbsdbw. You should have to, but if you need to, you can add: set logoX=X set logoY=Y to force the row/column placement of beastie. -- Devin -- Freddie Cash fjwc...@gmail.com _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
On Fri, 29 Apr 2011 12:02:03 -0700 Devin Teske dte...@vicor.com wrote: I was thinking that what we ought to do is support *both* numbers *and* letters. Sounds good to me. I envision the menuitem numbers remaining unchanged (1-7), allowing those familiar with the numbers to use them. However, as for the letters, I'm thinking that we *BOLD* the mnemonic in the menuitem. For example (showing bolded items between asterisks): 1. Boot *[ENTER]* 2. *A*CPI Support: Enabled 3. Boot Safe Mode: NO 4. Boot *S*ingle User: NO 5. Boot *V*erbose: NO 6. *Esc*ape to loader prompt 7. *R*eboot This should indicate to the user, for example if they see that the V in Verbose is bolded, that they can press that key to activate that menuitem. Presented like this a naive first interpretion could be that the letters have to be entered as upper-case. I do not think someone wants to press shift there... Having the characters in bold but the numbers not could also let someone think that only the characters matter. Having a text which tells that the numbers and lower-case characters work for chosing something, may be a solution here. Another solution is maybe 1/[ENTER]. Boot 2/a. ACPI Support... ... but I have to admit that the second solution is ugly. A third solution could be to have the numbers and the characters in bold. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [RELEASE] New Boot-Loader Menu
On Fri, 29 Apr 2011, Devin Teske wrote: I'm still leaning toward just making the V in Verbose and S in Single User bolded. Why not just underline hotkey characters? That's already a well-known standard in lots of places. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
On 04/29/2011 20:34, Warren Block wrote: On Fri, 29 Apr 2011, Devin Teske wrote: I'm still leaning toward just making the V in Verbose and S in Single User bolded. Why not just underline hotkey characters? That's already a well-known standard in lots of places. Agreed, that's a much more standard UI. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
On Fri, Apr 29, 2011 at 8:37 PM, Doug Barton do...@freebsd.org wrote: On 04/29/2011 20:34, Warren Block wrote: On Fri, 29 Apr 2011, Devin Teske wrote: I'm still leaning toward just making the V in Verbose and S in Single User bolded. Why not just underline hotkey characters? That's already a well-known standard in lots of places. Agreed, that's a much more standard UI. I hope that works for serial console. VT100 may be a reasonable default in that case, but it would be good to make sure that menu works even on a dumb terminal. Perhaps we should put 'key' letter in brackets then? --Artem ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
On Sun, 24 Apr 2011 18:53:11 -0700 Devin Teske dte...@vicor.com wrote: I'd love to finally release (under the BSD license) my code for the revamped FreeBSD boot loader menu. Here's a detailed discussion of the release complete with pictures: http://devinteske.com/new-freebsd-boot-loader-menu Here's the download: http://druidbsd.sourceforge.net/download/loader_menu-1.0.tgz The download is a FreeBSD package. You can execute: fetch [aboveURL] pkg_add loader_menu-1.0.tgz reboot And upon your next boot will use the new loader menu. A feature-complete sophisticated boot menu designed from the ground up. Although I personally never use the boot menu it's nice to see someone trying to make it more usable for the average FreeBSD user. -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
On Apr 25, 2011, at 8:30 AM, Eitan Adler wrote: I'd love to finally release (under the BSD license) my code for the revamped FreeBSD boot loader menu. Woot! Community contributions under a useful license :-) Here's the download: http://druidbsd.sourceforge.net/download/loader_menu-1.0.tgz Painless installation - thanks! And upon your next boot will use the new loader menu. A feature-complete sophisticated boot menu designed from the ground up. The delay loading boot menu seems longer than it used to be. Perhaps this is because I never paid attention or maybe because the progress bar with the dots draws attention to it. Regardless this loader makes a lot more sense to me than the original. I've always wanted to be able to be into SUM verbose logging or other combinations. I tested this on a Lenovo G530 laptop and it seems to work fine with a few different combinations as well as at the prompt. Thanks for your work! double-w00t! Time for the cake and punch! Thank you for trying my work. -- Devin -- Eitan Adler _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
I'd love to finally release (under the BSD license) my code for the revamped FreeBSD boot loader menu. Woot! Community contributions under a useful license :-) Here's the download: http://druidbsd.sourceforge.net/download/loader_menu-1.0.tgz Painless installation - thanks! And upon your next boot will use the new loader menu. A feature-complete sophisticated boot menu designed from the ground up. The delay loading boot menu seems longer than it used to be. Perhaps this is because I never paid attention or maybe because the progress bar with the dots draws attention to it. Regardless this loader makes a lot more sense to me than the original. I've always wanted to be able to be into SUM verbose logging or other combinations. I tested this on a Lenovo G530 laptop and it seems to work fine with a few different combinations as well as at the prompt. Thanks for your work! -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[RELEASE] New Boot-Loader Menu
Hello fellow hackers, I'd love to finally release (under the BSD license) my code for the revamped FreeBSD boot loader menu. Here's a detailed discussion of the release complete with pictures: http://devinteske.com/new-freebsd-boot-loader-menu Here's the download: http://druidbsd.sourceforge.net/download/loader_menu-1.0.tgz The download is a FreeBSD package. You can execute: fetch [aboveURL] pkg_add loader_menu-1.0.tgz reboot And upon your next boot will use the new loader menu. A feature-complete sophisticated boot menu designed from the ground up. -- Cheers, Devin Teske P.S. This code has been developed since 2006 and has been booted on hundreds of machines thousands of times by a group of more than two dozen field engineers trained to install, trouble-shoot, and maintain FreeBSD. It is only after this success that we are so happy to release this to the general public under the BSD license. Should it make its way into the base distribution, we would be honored, but that is not a necessity. - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - FUN STUFF - -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+ D+(++) G++ e h r+++ z+++ --END GEEK CODE BLOCK-- http://www.geekcode.com/ - END TRANSMISSION - _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: New Boot-Loader
On Mar 28, 2011, at 5:04 AM, Andriy Gapon wrote: Would also be cool to have an option to boot something else (like e.g. memtest86). Maybe a special directory with loadable binaries and a special menu entry to select one of them. As surprising as this release is, I've actually got plans to one day release our ISOLINUX based boot loader configuration that we use to do this very thing. We use the vesamenu.c32 module to present a menu containing memtest86 and many many other tools and at the top of that menu is our entry for chain-loading to FreeBSD (as a default). Probably even better to have a mechanism for pluggable menu entries like a special directory that would have .4th files each of which would represent one extra menu option. So instead of hacking system .4th files, one could easily extend main menu with custom entries. My menu.4th module (that I released today -- see druidbsd.sf.net) does provide you with what you need to create not only an extended menu of your own design, but to create multiple menus through a system of separate .4th files. I in-fact actually used it to that very end in one of our custom boot menus. Each .4th file would call menu-clear and then set the appropriate menu_caption[N] variables, forming an array of values of 1-9 for N (9 is the maximum), before finally calling menu-create (which then read in the variables set in the environment and generating the menu). This is precisely one of the intended designs of my menu. It also has hooks for providing not only toggle-state menu options but cycle-state options (for example, setting kernel[0], kernel[1], and kernel[2], then having a menu item that upon keypress would allow cycling between the three (or more) options. Though these advanced features and topics are not used in the distributed code, I did not remove the underlying functions that are required/used to enable such extended functionality. For example, you'll still find cycle_menuitem in menu.4th, though it's not used by anything (waiting for some enterprising soul like yourself to put it to use -- though on a side-note, we're still using these functions in our custom boot menus on our automated installers where we change out the logos, mascots, colors, and use the higher level functions not required in the standard FreeBSD boot process). Just a dream... Not a dream. I somehow think you were channeling our progress. That or great minds think alike. -- Devin -- Andriy Gapon -- Cheers, Devin Teske - CONTACT INFORMATION - Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.te...@fisglobal.com - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - END TRANSMISSION - _ 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. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: New Boot-Loader
On Mon, Mar 28, 2011 at 01:50:20PM -0400, Andrew Duane wrote: -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Andriy Gapon Sent: Monday, March 28, 2011 8:00 AM To: Alexander Best Cc: FreeBSD Hackers Subject: Re: New Boot-Loader Please note that graphical loaders are not very serial console friendly ;-) -- Andriy Gapon Amen, and we have a whole lot of platforms that are only serial consoles (and 9600 baud at that). Also, I like the letters instead of numbers for boot options, for those of us that have known for years that s is single user mode, v is verbose, etc This can hardly be an argument, because on serial consoles even the current full-screen implementation isn't friendly at all. One of the first things I always do is to disable beastie-start. As long as it is still based on ficl and can be disabled to get the traditional linemode I don't see a problem. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: New Boot-Loader
On Tue Mar 29 11, Bernd Walter wrote: On Mon, Mar 28, 2011 at 01:50:20PM -0400, Andrew Duane wrote: -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Andriy Gapon Sent: Monday, March 28, 2011 8:00 AM To: Alexander Best Cc: FreeBSD Hackers Subject: Re: New Boot-Loader Please note that graphical loaders are not very serial console friendly ;-) -- Andriy Gapon Amen, and we have a whole lot of platforms that are only serial consoles (and 9600 baud at that). Also, I like the letters instead of numbers for boot options, for those of us that have known for years that s is single user mode, v is verbose, etc This can hardly be an argument, because on serial consoles even the current full-screen implementation isn't friendly at all. One of the first things I always do is to disable beastie-start. As long as it is still based on ficl and can be disabled to get the traditional linemode I don't see a problem. actually it's quite easy. there are two kind of people: 1) the ones that like it plain and simple and 2) the ones that fancy eye candy lets have a boot loader for 1) which supports serial consoles and firewire stuff and verbose booting and all that stuff one for 2). -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: New Boot-Loader
Hi, On Mon, Mar 28, 2011 at 1:50 PM, Andrew Duane adu...@juniper.net wrote: -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Andriy Gapon Sent: Monday, March 28, 2011 8:00 AM To: Alexander Best Cc: FreeBSD Hackers Subject: Re: New Boot-Loader Please note that graphical loaders are not very serial console friendly ;-) -- Andriy Gapon Amen, and we have a whole lot of platforms that are only serial consoles (and 9600 baud at that). FWIW, an interesting thing, from my point of view, would be to get rid of that 9600bps limitation due to the use of INT14 in the first stage bootloader to have access to more descent serial console speed in early boot stage. Also, I like the letters instead of numbers for boot options, for those of us that have known for years that s is single user mode, v is verbose, etc you can also have a thought to the people who are used to use numbers :) - Arnaud ... Andrew Duane Juniper Networks o +1 978 589 0551 m +1 603-770-7088 adu...@juniper.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: New Boot-Loader
On Mon, Mar 28, 2011 at 1:22 AM, Devin Teske dte...@vicor.com wrote: On Mar 27, 2011, at 9:53 PM, Super Bisquit wrote: And what if I need to boot into single user mode? I'll forgive the top-post, and I'll even forgive that you missed the below NOTE: The final release will have a single-user mode option. Here it is with single-user mode option: twitpic.com/4e6gu1 -- Devin On Mon, Mar 28, 2011 at 12:48 AM, Devin Teske dte...@vicor.com wrote: Hi fellow hackers, I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel that the existing options in the boot-loader menu today can be whittled down significantly with a stateful menu system rather than a single-action item menu system. In designing the new menu, I'd like to get your opinions. From old: FreeBSD 8.1-RELEASE: twitpic.com/4e485w to new: Replacement Boot-Loader: twitpic.com/4e46ol NOTE: The final release will have a single-user mode option. The new menu allows for more flexibility as selecting options 2 (Boot Verbose) or 3 (ACPI Support) independently toggles the status, updates the menu item, and redisplays the menu -- ever-waiting until the user ultimately presses ENTER, 1, or escapes to the prompt and types boot. Thus, one could potentially launch single-user mode with verbosity on and ACPI disabled (if one so desired). ... New menu is really good . One feature ( which is important for response ability ) is to increase down counter starting from at least 255 as default . This will not change anything toward bad because a few seconds later a prompt will appear and the computer will start to wait user response for logging . If the user will use an automatic login , it is obvious that he/she is knowing how to modify that counter to satisfy his/her needs . Instead of considering exceptions , please consider generally less experienced to modify that counter and/or having obstacles to respond immediately . Personally mostly I am becoming able to boot such menus after a few hard resets of power of the computer . My personal attitude toward this counter is a strong hate . After every operating system install , the first task I am doing is to disable that counter completely or increase it to at least 1000 . Default boot mode is not always the best and please assume that every one will not be able to respond immediately due to so many possibilities of reasons to cause a late response . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: New Boot-Loader
On Sun, Mar 27, 2011 at 09:48:03PM -0700, Devin Teske wrote: Hi fellow hackers, I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel that the existing options in the boot-loader menu today can be whittled down significantly with a stateful menu system rather than a single-action item menu system. In designing the new menu, I'd like to get your opinions. From old: FreeBSD 8.1-RELEASE: twitpic.com/4e485w to new: Replacement Boot-Loader: twitpic.com/4e46ol Very nice! Could you consider changing the number options to letters: v=verbose, a=acpi, s=single ... Having many (hundreds) of machines to manage it's confusing to need 6 for boot prompt on older versions and 5 on the newer where 6 on the newer reboots. Moving from digits to letters with digits resulting in either a beep or a pause saves a lot of frustration for sysadmins already annoyed by the ever increasing POST delay rapidly pressing ENTER ENTER 6 when the boot0 menu appears. Thanks for your work! Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: New Boot-Loader
On Mon, Mar 28, 2011 at 2:55 AM, Paul Schenkeveld free...@psconsult.nl wrote: On Sun, Mar 27, 2011 at 09:48:03PM -0700, Devin Teske wrote: Hi fellow hackers, I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel that the existing options in the boot-loader menu today can be whittled down significantly with a stateful menu system rather than a single-action item menu system. In designing the new menu, I'd like to get your opinions. From old: FreeBSD 8.1-RELEASE: twitpic.com/4e485w to new: Replacement Boot-Loader: twitpic.com/4e46ol Very nice! Could you consider changing the number options to letters: v=verbose, a=acpi, s=single ... I agree. Vim-like actions make sense here. And also, I want command completion... Having many (hundreds) of machines to manage it's confusing to need 6 for boot prompt on older versions and 5 on the newer where 6 on the newer reboots. Moving from digits to letters with digits resulting in either a beep or a pause saves a lot of frustration for sysadmins already annoyed by the ever increasing POST delay rapidly pressing ENTER ENTER 6 when the boot0 menu appears. Thanks for your work! Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Zhihao Yuan The best way to predict the future is to invent it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: New Boot-Loader
On Sun Mar 27 11, Warner Losh wrote: On Mar 27, 2011, at 10:48 PM, Devin Teske wrote: Replacement Boot-Loader: twitpic.com/4e46ol NOTE: The final release will have a single-user mode option. This looks really cool. Nice to see a fresh look for the boot loader... sorry if we have different opinions on this matter, but i don't quite see the fresh look. imo a modern boot loader looks like this http://www.dailycupoftech.com/wp-content/uploads/2006/08/ubuntu01.png or this http://images.linuxscreenshots.com/distro/opensuse/11.3/h400/01_boot_menu.png ... and not something made out of ascii chars like it's 1981. ;) The new menu allows for more flexibility as selecting options 2 (Boot Verbose) or 3 (ACPI Support) independently toggles the status, updates the menu item, and redisplays the menu -- ever-waiting until the user ultimately presses ENTER, 1, or escapes to the prompt and types boot. Thus, one could potentially launch single-user mode with verbosity on and ACPI disabled (if one so desired). In addition, I really tried to capture the essence of the new logo (spent months off-and-on using different conversion programs with different inputs). In the end, I found text-image.com produced the best result. I used the official freebsd.org/logo.html Standard Logo (black and white), cropped (to 122x123) and converted to jpeg with white background. I used an Image Width of 45 in their Convert into ASCII program available here: text-image.com/convert/ascii.html This looks cool... I would be distributing this as an installable package (perhaps in the ports tree if it gains popularity). That would be nice... Warner -- Cheers, Devin Teske - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - FUN STUFF - -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+ D+(++) G++ e h r+++ z+++ --END GEEK CODE BLOCK-- http://www.geekcode.com/ - END TRANSMISSION - ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: New Boot-Loader
on 28/03/2011 14:08 Alexander Best said the following: sorry if we have different opinions on this matter, but i don't quite see the fresh look. imo a modern boot loader looks like this http://www.dailycupoftech.com/wp-content/uploads/2006/08/ubuntu01.png or this http://images.linuxscreenshots.com/distro/opensuse/11.3/h400/01_boot_menu.png ... and not something made out of ascii chars like it's 1981. ;) There is/was a different project for that too: http://wiki.freebsd.org/OliverFromme/BootLoader Please note that graphical loaders are not very serial console friendly ;-) -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
