Re: disadvantages of running 8.3 kernel on freebsd 8.2 system
On Jan 17, 2013, at 4:06 AM, Ali Okan YÜKSEL wrote: I know for UPDATING, it s not correct way, but i tried and 8.2 system works with 8.3 kernel (copied 8.3 /boot/kernel directory to freebsd 8.2 /boot/kernel) and it s not good solution but i want to know; - What are specific disadvantages that i can see clearly, running 8.3 kernel on freebsd 8.2? A couple user land tools might barf on you (listed below). Other than that, it's generally considered very safe. The quintessential test-case is running an 8.2 jail under an 8.3 host. We do this all the time with various releases (again, most-problematic utilities listed below). - What are user land tools those not match with 8.3 kernel on freebsd 8.2 system…? top and ps might complain about procsize mismatch. netstat has been known to have problems if the gap is too wide. That's about all that I can think off the top of my head. The quick solution is to just grab the 8.3-R copies of top, ps, and netstat *IFF* they cause problems (e.g., ps immediately dies with procsize mismatch error). -- Devin P.S. Been doing this kind of mismatching of kernel/userland for YEARS (all the way back to 4.4/4.8) and top and ps always prove to be problematic. _ 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: disadvantages of running 8.3 kernel on freebsd 8.2 system
On Jan 17, 2013, at 8:03 AM, John Baldwin wrote: On Thursday, January 17, 2013 10:57:01 am Devin Teske wrote: On Jan 17, 2013, at 4:06 AM, Ali Okan YÜKSEL wrote: I know for UPDATING, it s not correct way, but i tried and 8.2 system works with 8.3 kernel (copied 8.3 /boot/kernel directory to freebsd 8.2 /boot/kernel) and it s not good solution but i want to know; - What are specific disadvantages that i can see clearly, running 8.3 kernel on freebsd 8.2? A couple user land tools might barf on you (listed below). Other than that, it's generally considered very safe. The quintessential test-case is running an 8.2 jail under an 8.3 host. We do this all the time with various releases (again, most-problematic utilities listed below). - What are user land tools those not match with 8.3 kernel on freebsd 8.2 system…? top and ps might complain about procsize mismatch. netstat has been known to have problems if the gap is too wide. These generally do not have problems in recent release branches. top and ps haven't complained about procsize since the 4.x days as 5.0 introduced a new kinfo_proc structure that the kernel exports and it hasn't changed in size since 5.0. The mfiutil issue dhw@ mentioned is real and is due to an mfi(4) driver change. I merged a fix for the panics to 8-stable, but it just makes old mfiutil binaries not work at all. You're the perfect person to help us figure out why when we: 1. back-port mfi(4) from stable/8 into releng/8.3 (8.3-RELEASE-p5 at the time of back-port) 2. Succeed in getting 8.3 to boot on Thunderbolt card 3. mfiutil produces Inappropriate ioctl for device Even after… 4. Recompiling mfiutil from stable/8 (albeit in a releng/8.3 build environment -- back ported headers applied for new macros even) Any hints on where to go next to restore mfiutil access? -- 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: disadvantages of running 8.3 kernel on freebsd 8.2 system
On Jan 17, 2013, at 11:14 AM, Steven Hartland wrote: - Original Message - From: Devin Teske devin.te...@fisglobal.com You're the perfect person to help us figure out why when we: 1. back-port mfi(4) from stable/8 into releng/8.3 (8.3-RELEASE-p5 at the time of back-port) 2. Succeed in getting 8.3 to boot on Thunderbolt card 3. mfiutil produces Inappropriate ioctl for device Even after… 4. Recompiling mfiutil from stable/8 (albeit in a releng/8.3 build environment -- back ported headers applied for new macros even) Any hints on where to go next to restore mfiutil access? You also need to backport mfiutil too. I have a patch set for 8.3 which include latest mfi driver, mfiutil and a large set of mfi driver fixes, even head has some rather serious issues although mainly around error handling on tbolt cards. We're running this in production so believe its a good stable set. If you would like the patch set just let me know. I can't resist when you combine words like production and 8.3 (smiles) I'm definitely interested in the patch. Can you send it our way, please? -- 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: kgzip(1) is broken
On Jan 15, 2013, at 5:07 PM, Steven Hartland wrote: - Original Message - From: dte...@freebsd.org To: 'Ian Lepore' free...@damnhippie.dyndns.org Cc: freebsd-hackers@freebsd.org; dte...@freebsd.org Sent: Wednesday, January 16, 2013 12:56 AM Subject: RE: kgzip(1) is broken -Original Message- From: Ian Lepore [mailto:free...@damnhippie.dyndns.org] Sent: Tuesday, January 15, 2013 4:43 PM To: Devin Teske Cc: dte...@freebsd.org; freebsd-hackers@freebsd.org Subject: RE: kgzip(1) is broken On Tue, 2013-01-15 at 16:10 -0800, Devin Teske wrote: -Original Message- From: Devin Teske [mailto:devin.te...@fisglobal.com] On Behalf Of dte...@freebsd.org Sent: Tuesday, January 15, 2013 3:10 PM To: 'Ian Lepore' Cc: freebsd-hackers@freebsd.org; dte...@freebsd.org Subject: RE: kgzip(1) is broken -Original Message- From: Ian Lepore [mailto:free...@damnhippie.dyndns.org] Sent: Tuesday, January 15, 2013 3:05 PM To: dte...@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: kgzip(1) is broken On Tue, 2013-01-15 at 13:27 -0800, dte...@freebsd.org wrote: Hello, I have been sad of-late because kgzip(1) no longer produces a usable kernel. All versions of 9.x suffer this. And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this recently broke in the 8.x series. I haven't tried the 7 series lately, but if whatever is making the rounds gets MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. Here are some possible candidates from the things that were MFC'd to 8 in that timeframe. I haven't looked at what these do, they're just changes that affect files related to booting. r233211 r233377 r233469 r234563 Thanks Ian! I'll test each one individually to see if regressing any one (or all) addresses the problem. Progress... Looks like I found the culprit. Turns out it's a back-ported bxe(4) driver (back-ported from 9 -- where kgzip seems to never work). I wonder why back-porting bxe(4) from stable/9 to releng/8.3 would cause kgzip to produce non-working kernels. Yeah, it'll be interesting to see how a device driver can lead to the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader, which I took to mean before seeing the copyright or anything. Indeed... loader throws up the syms and upon execution *KABOOM* (screen goes black and back to POST) The copyright never appears. I'm emailing the maintainers (davidch + other Broadcom folk) The current dossier is even more interesting... the back-ported driver (with zero modifications mind you from stable/9 to stable/8) exhibits memory failures (example below), and causes terminals to become wedged when attempting to (for example) scp a file over an existing configured network (igb-based -- presumably unrelated to bxe but in practice loading bxe causes igb to misbehave). $ ifconfig bxe0 inet 192.168.1.5/24 bxe0: ../../../dev/bxe/if_bxe.c(10939): Memory allocation failure! Cannot fill fp[00] RX chain. bxe0: ../../../dev/bxe/if_bxe.c(3921): NIC initialization failed, aborting! $ ifconfig bxe1 inet 192.168.1.6/24 bxe1: ../../../dev/bxe/if_bxe.c(10939): Memory allocation failure! Cannot fill fp[00] RX chain. bxe1: ../../../dev/bxe/if_bxe.c(3921): NIC initialization failed, aborting! (as expected, also sent mail off to maintainers w/respect to above notes/errors) Sounds like you may be out of mbufs which is easy, on a box with 4 igb's simply booting without tuning with cause this so, if you have igb's and bxe's this could be your cause. Try adding the following to loader.conf and see if it helps:- kern.ipc.nmbclusters=51200 Sorry for delayed response -- we had to go through a power cycle. I haven't yet tried bumping the value as suggested, but I suspect it will indeed help greatly -- I noticed that I got 18% into the scp before things took a dive for the worse (hanging terminals and such). Another thing worth noting about the uplifted bxe(4) plopped into RELENG_8… when we rebooted: bxe0: ../../../dev/bxe/if_bxe.c(6419): Slowpath queue is full! bxe0: -- Begin crash dump -- bxe0: -- End crash dump -- bxe0: ../../../dev/bxe/if_bxe.c(6419): Slowpath queue is full! bxe0: -- Begin crash dump -- bxe0: -- End crash dump -- bxe0: ../../../dev/bxe/if_bxe.c(3262): fp[01] client ramrod halt failed! Heh. The machine had to be hard cycled. -- 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
Re: off topic but no idea where to ask
On Jan 15, 2013, at 10:18 AM, Wojciech Puchar wrote:
does anyone know a PXE image (just like /boot/pxeboot) that can be placed on
tftp server and the only thing it will do would be loading first sector from
first local disk at 0x07c00 and booting as with normal hard drive.
what i need is to be able to decide from server side if given computer boots
from NFS or hard disk.
Yeah, no prob.
NOTE: Our PXE server is Linux (*blech) but I assure you the only thing that
changes is the paths (/etc/dhcpd.conf becomes /usr/local/etc/dhcpd.conf for
example -- the pxelinux.0 image works fine served-up by ISC dhcpd on FreeBSD).
First part of the recipe:
$ awk '/filename/!/^[[:space:]]*(#|$)/{print}' /etc/dhcpd.conf
filename pxelinux.0;
$ ls -l /tftpboot/pxelinux.0
lrwxrwxrwx 1 root root 15 May 15 2012 /tftpboot/pxelinux.0 - pxelinux.0-3.84
$ file /tftpboot/pxelinux.0-3.84
/tftpboot/pxelinux.0-3.84: data
Next part of the recipe… The /etc/pxelinux.cfg/default file:
DISPLAY /boot/include/boot.msg
DEFAULT wpuchar_nfs
PROMPT 1
ONTIMEOUT hdd
TIMEOUT 50
TOTALTIMEOUT 6000
LABEL hdd
LOCALBOOT 0x80
LABEL wpuchar_nfs
… your nfs boot config …
Last but not least, …
$ cat /tftpboot/boot/include/boot.msg
Press ENTER to boot from WPuchar's NFS server (defaulting to HDD boot in 5
seconds)...
--
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: kgzip(1) is broken
-Original Message- From: Devin Teske [mailto:devin.te...@fisglobal.com] On Behalf Of dte...@freebsd.org Sent: Tuesday, January 15, 2013 3:10 PM To: 'Ian Lepore' Cc: freebsd-hackers@freebsd.org; dte...@freebsd.org Subject: RE: kgzip(1) is broken -Original Message- From: Ian Lepore [mailto:free...@damnhippie.dyndns.org] Sent: Tuesday, January 15, 2013 3:05 PM To: dte...@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: kgzip(1) is broken On Tue, 2013-01-15 at 13:27 -0800, dte...@freebsd.org wrote: Hello, I have been sad of-late because kgzip(1) no longer produces a usable kernel. All versions of 9.x suffer this. And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this recently broke in the 8.x series. I haven't tried the 7 series lately, but if whatever is making the rounds gets MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. Here are some possible candidates from the things that were MFC'd to 8 in that timeframe. I haven't looked at what these do, they're just changes that affect files related to booting. r233211 r233377 r233469 r234563 Thanks Ian! I'll test each one individually to see if regressing any one (or all) addresses the problem. Progress... Looks like I found the culprit. Turns out it's a back-ported bxe(4) driver (back-ported from 9 -- where kgzip seems to never work). I wonder why back-porting bxe(4) from stable/9 to releng/8.3 would cause kgzip to produce non-working kernels. I'm emailing the maintainers (davidch + other Broadcom folk) -- 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: loader and ficl/Forth help
On Sun, Feb 24, 2008 at 14:21:24 -0800, Jeremy Chadwick wrote: On Sun, Feb 24, 2008 at 02:01:14PM -0800, Jeremy Chadwick wrote: ... I'll submit a PR for the whole thing. We can hash out details/improvements there. http://www.freebsd.org/cgi/query-pr.cgi?pr=121064 I've made some improvements to the supplied patch. Said improvements should address the previous issues that were preventing this from going in. Can someone test the newly-attached patch.txt and get back to me? -- Cheers, 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: loader and ficl/Forth help
Thanks for testing Jaakko. Can you re-test with the attached patch? I cleaned things up a bit while addressing the problem that a later call to f_double was un-doing the previous installation of the ASCII charset. This new patch should work (and I re-tested, having had ample sleep this time). -- Thanks in advance, 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. Index: support.4th === --- support.4th (revision 242835) +++ support.4th (working copy) @@ -201,6 +201,42 @@ create last_module_option sizeof module.next allot : getenv? getenv -1 = if false else drop true then ; +\ determine if a word appears in a string, case-insensitive +: contains? ( addr1 len1 addr2 len2 -- 0 | -1 ) + 2 pick 0= if 2drop 2drop true exit then + dup 0= if 2drop 2drop false exit then + begin + begin + swap dup c@ dup 32 = over 9 = or + over 10 = or over 13 = or swap drop + while 1+ swap 1- repeat + swap 2 pick 1- over + while + 2over 2over drop over compare-insensitive 0= if + 2 pick over = if 2drop 2drop true exit then + 2 pick tuck - -rot + swap over c@ dup 32 = + over 9 = or over 10 = or over 13 = or + swap drop if 2drop 2drop true exit then + then begin + swap dup c@ + dup 32 = over 9 = or over 10 = or over 13 = or + swap drop if false else true then 2 pick 0 and + while 1+ swap 1- repeat + swap + repeat + 2drop 2drop false +; + +: boot_serial? ( -- 0 | -1 ) + s console getenv dup -1 if + s comconsole 2swap contains? + else drop false then + s boot_serial getenv dup -1 if + s YES compare-insensitive 0= + else drop false then + or ( true if either console contains comconsole or boot_serial=YES ) +; + \ Private definitions vocabulary support-functions Index: frames.4th === --- frames.4th (revision 242835) +++ frames.4th (working copy) @@ -12,6 +12,11 @@ variable rt_el variable rb_el variable fill +\ ASCII frames (used when serial console is detected) + 45 constant ascii_dash +124 constant ascii_pipe + 43 constant ascii_plus + s arch-pc98 environment? [if] \ Single frames 149 constant sh_el @@ -63,7 +68,17 @@ s arch-pc98 environment? [if] loop ; +: f_ascii ( -- ) ( -- ) \ set frames to ascii + ascii_dash h_el ! + ascii_pipe v_el ! + ascii_plus lt_el ! + ascii_plus lb_el ! + ascii_plus rt_el ! + ascii_plus rb_el ! +; + : f_single ( -- ) \ set frames to single + boot_serial? if f_ascii exit then sh_el h_el ! sv_el v_el ! slt_el lt_el ! @@ -73,6 +88,7 @@ s arch-pc98 environment? [if] ; : f_double ( -- ) \ set frames to double + boot_serial? if f_ascii exit then dh_el h_el ! dv_el v_el ! dlt_el lt_el ! On Dec 7, 2012, at 2:28 AM, Jaakko Heinonen wrote: On 2012-12-07, Devin Teske wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=121064 I've made some improvements to the supplied patch. Said improvements should address the previous issues that were preventing this from going in. Can someone test the newly-attached patch.txt and get back to me? I tried the latest patch in the PR and it didn't work for me. I have the following line in my /boot/loader.conf: console=comconsole Attached is a screenshot from the menu. It's still using non-ASCII characters. -- Jaakko menu.png ___ 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: loader and ficl/Forth help
On Dec 7, 2012, at 11:50 AM, Garrett Cooper wrote: On Fri, Dec 7, 2012 at 1:07 AM, Devin Teske devin.te...@fisglobal.com wrote: ... I've made some improvements to the supplied patch. Said improvements should address the previous issues that were preventing this from going in. Can someone test the newly-attached patch.txt and get back to me? The patch seems to be missing a few checks (boot_multicons, boot -D, etc). I really wish this stuff was properly consolidated/cleaned up -- loader.conf's console stuff is a hodgepodge mess of duplicated/obfuscated user knobs. Thanks, -Garrett I'll look into boot_multicons. However, w/respect to boot -D, I believe that would be after the menu, so is past the point at which we need the functionality (in drawing frames from frames.4th). Also, you replied to an earlier e-mail in the thread, do note that there's an updated patch that centralizes the logic to boot_serial? function which returns boolean based on multiple conditions (currently takes $console and $boot_serial into consideration -- should be trivial to add a check for boot_multicons). -- 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: loader and ficl/Forth help
On Dec 7, 2012, at 12:33 PM, Garrett Cooper wrote:
On Fri, Dec 7, 2012 at 12:07 PM, Devin Teske devin.te...@fisglobal.com
wrote:
...
I'll look into boot_multicons.
However, w/respect to boot -D, I believe that would be after the menu, so
is past the point at which we need the functionality (in drawing frames from
frames.4th).
Also, you replied to an earlier e-mail in the thread, do note that there's
an updated patch that centralizes the logic to boot_serial? function which
returns boolean based on multiple conditions (currently takes $console and
$boot_serial into consideration -- should be trivial to add a check for
boot_multicons).
You're correct; boot -D is for after boot and this only affects loader(8):
-Dboot with the dual console configuration. In the
single configuration, the console will be either
the internal display or the serial port, depending
on the state of the -h option below. In the dual
console configuration, both the internal display
and the serial port will become the console at the
same time, regardless of the state of the -h
option.
Rereading loader(8)'s entry on multicons, it might be a non-issue as
well, given that it's only saying kernel:
boot_multicons
Enables multiple console support in the kernel early on boot.
In a running system, console configuration can be manipulated
by the conscontrol(8) utility.
A grep of sys/boot suggests it's an alias for -D:
$ grep -r multicons .
./userboot/userboot/bootinfo.c:{boot_multicons, RB_MULTIPLE},
./sparc64/loader/metadata.c:{boot_multicons, RB_MULTIPLE},
./forth/loader.conf:#boot_multicons= # -D: Use multiple consoles
^^^
./powerpc/ofw/metadata.c:{boot_multicons, RB_MULTIPLE},
./powerpc/ps3/metadata.c:{boot_multicons, RB_MULTIPLE},
./i386/libi386/comconsole.c:getenv(boot_multicons) != NULL) {
./i386/libi386/bootinfo.c:{boot_multicons,RB_MULTIPLE},
./i386/efi/bootinfo.c: { boot_multicons, RB_MULTIPLE},
./pc98/libpc98/comconsole.c:getenv(boot_multicons) != NULL) {
./common/loader.8:.It Va boot_multicons
./common/help.common:# Tset Sboot_multicons DUse multiple consoles
./common/help.common: set boot_multicons
./ia64/common/bootinfo.c: { boot_multicons, RB_MULTIPLE},
./uboot/common/metadata.c: {boot_multicons, RB_MULTIPLE},
However, sys/boot/i386/libi386/comconsole.c is doing some matching
based on the environment variable, so I'd need to look into the call
flow further to better understand what's being achieved.
Can you review the following patch for inclusion to HEAD?
I do believe this new patch gets us where we need to be…
_
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.
Index: support.4th
===
--- support.4th (revision 242835)
+++ support.4th (working copy)
@@ -201,6 +201,46 @@ create last_module_option sizeof module.next allot
: getenv? getenv -1 = if false else drop true then ;
+\ determine if a word appears in a string, case-insensitive
+: contains? ( addr1 len1 addr2 len2 -- 0 | -1 )
+ 2 pick 0= if 2drop 2drop true exit then
+ dup 0= if 2drop 2drop false exit then
+ begin
+ begin
+ swap dup c@ dup 32 = over 9 = or
+ over 10 = or over 13 = or swap drop
+ while 1+ swap 1- repeat
+ swap 2 pick 1- over
+ while
+ 2over 2over drop over compare-insensitive 0= if
+ 2 pick over = if 2drop 2drop true exit then
+ 2 pick tuck - -rot + swap over c@ dup 32 =
+ over 9 = or over 10 = or over 13 = or
+ swap drop if 2drop 2drop true exit then
+ then begin
+ swap dup c@
+ dup 32 = over 9 = or over 10 = or over 13 = or
+ swap drop if false else true then 2 pick 0 and
+ while 1+ swap 1- repeat
+ swap
+ repeat
+ 2drop 2drop false
+;
+
+: boot_serial? ( -- 0 | -1 )
+ s console getenv dup -1 if
+ s comconsole 2swap contains?
+ else drop false then
+ s boot_serial getenv dup -1
Re: old style kernel configuration
On Nov 22, 2012, at 12:27 PM, Chris Rees wrote: On 22 Nov 2012 18:56, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: How is it simpler? Chris strange question i thought it is obviously clear. $EDITOR config config kernel cd ../compile/kernel make depend make make install that's all. and no need to keep whole /usr/src, just sys what is wrong in it? I was only confused because you had asserted that six commands was simpler-- I can relate to Mr Puchar's vantage point. It's not the number of commands, it's the pathos. Memorizing how to configure a custom kernel, one can memorize two different pathos: === A === I have to make a config file I have to use the make(1) utility within a full src-tree to produce the kernel from that config I can't remember the arguments to make === B === I have to make a config file I have to use the config(1) utility on my config file The config(1) utility tells me what to do after I run it, I do what config(1) tells me == In both A and B, we start with a config file. Things differ from there. I do buy the argument that B is simpler than A, despite the fact that B requires more commands than A. B can be thought-of as simpler because I only have to memorize three things to get a kernel: (1) start with a config file, (2) run config with said file (3) follow the instructions that config gives me. Meanwhile, in comparison, A requires the memorization of different and arguably less accessible information. One might even be able to argue that the pathos of B is simpler because it relies on a purpose-built tool (config(1)) to get you where you want to be versus a multi-purpose tool (make(1)). Just my tuppence. -- 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: old style kernel configuration
On Nov 21, 2012, at 5:58 PM, Eitan Adler wrote: I've been working on removing obsolete information various documents. While going through older articles I noticed a few references to the old style kernel configuration involving running config(1) manually. I always build kernels with config(1) because it allows me to embed the _entire_ kernel config into the kernel (by using the -C option to config(1)). Otherwise, if I rely only on the INCLUDE_CONFIG_FILE parameter, the comments are stripped from my config prior to embedding (and this is undesirable and thus why we always configure our kernel by executing config -C -g configname). Is there any value in keeping this documented as an alternative to make buildkernel or should it be treated as an implementation detail? Value: ability to embed entire config (comments and all) into the kernel Maybe this difference/value should be documented. -- 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: Custom FreeBSD usb memstick
Slowly working my way to HEAD. 9.0-R is the latest I've done (and still waiting patiently for 9.1-R). Druid is unique in that you can create a custom USB memstick that also can be burned to CD or DVD (with zero modifications). When getting started, keep in mind that you can do these steps on Mac OS X, Linux, Cygwin, and (uh) FreeBSD :) 1. Find/Browse the code here… http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druidbsd/ 2. Get the code… In Tarball form (22.6MB): http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druidbsd/?view=tar or Instructions on how to download with CVS: http://sourceforge.net/projects/druidbsd/develop NOTE: When logging in anonymously, simply press ENTER when prompted for a password NOTE: Use a modulename of druidbsd/druidbsd when checking out the code NOTE: Downloaded module measures about 30MB in size 3. Execute the following: cd druidbsd ./configure NOTE: If you went the CVS route, the first command is instead: cd druidbsd/druidbsd 4. Dependency checks: In the output of configure from step 3 above (which is rather small), make sure no commands have been mapped /bin/false (except for false itself, naturally). Basically, you'll need GNU make, mkisofs, and a few basic shell utilities. 5. [Optional] Customize: If you want to customize the kernel that is used, it's in mdroot/kernels/ NOTE: If you change the name of the kernel, edit the file mdroot/boot/menu.rc (kernel paths are at the top) NOTE: You can load multiple kernels if you want (and configure the menu to display them for selection) If you want to customize the boot menu, that's in mdroot/boot/menu.rc If you want to add kernel modules, those go into mdroot/boot/modules/ If you want to customize the mfsroot, there's a whole framework for that in dep/freebsd/mfsroot/ (however, you'll need a FreeBSD host to customize that portion). If you want to simply add new commands to DruidBSD, dump new binaries into src/freebsd/rescue/ NOTE: There's a corresponding src/freebsd/rescue/lib/ for you to dump library dependencies. If you want to add other miscellaneous files, just dump them into src/freebsd/. 6. Produce an ISO for mastering to USB stick: make NOTE: Sorry, this has to be GNU make (so on FreeBSD, say gmake instead). NOTE: This produces the ISO file (image) of your custom FreeBSD memstick 7. Play Use the instructions here to get your ISO onto physical media: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/src/tools/ NOTE: Start with README NOTE: There are many methods for many operating systems documented and even some tools for download (such as a Win32 GUI tool for imaging the ISO onto USB stick). Remember, that ISO can be burned to optical media _and_ imaged to USB stick (or any hard disk for that matter) without changing anything about the ISO (that's the nature of the DRUID architecture). I demonstrated much of this at the last DevSummit, but it's not part of FreeBSD. If you have any questions, let me know. -- Devin On Nov 8, 2012, at 3:36 PM, Robison, Dave wrote: Druid is Devin's baby so I will CC him I do not think he has done HEAD on druid yet... but it's not a bad idea. Dave On 11/08/2012 15:35, Sam Fourman Jr. wrote: On Thu, Nov 8, 2012 at 4:11 PM, Robison, Dave david.robi...@fisglobal.com wrote: If you're just looking for a release on memstick, check out druidbsd http://druidbsd.sourceforge.net/ If you're doing it to learn the process, I'm sure you can learn a few things from druidbsd anyway... Enjoy Dave Thank you Dave, do you build a version of DruidBSD based on HEAD? im really trying to learn the process, and id like to know how to alter the install image size.. then ill start with customization from there. -- Dave Robison Sales Solution Architect II FIS Banking Solutions 510/621-2089 (w) 530/518-5194 (c) 510/621-2020 (f) da...@vicor.com david.robi...@fisglobal.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: Ways to promote FreeBSD?
On May 4, 2012, at 8:42 PM, Mike Meyer wrote: On Fri, 04 May 2012 15:11:10 -0400 Dieter BSD dieter...@engineer.com wrote: *WHY* is Linux so much more popular than the BSDs? My newsbyte answer is: BSD is Unix for people who love quality software. Linux is Unix for people who hate Microsoft. My favorite comparison-quote is from the former (x3) CEO of our company from way-way back (circa '95-'96): ``Linux is for Windows users that want to learn UNIX. FreeBSD is for UNIX users that want to use affordable hardware.'' _ 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: Ways to promote FreeBSD?
On May 4, 2012, at 9:15 PM, Devin Teske wrote: On May 4, 2012, at 8:42 PM, Mike Meyer wrote: On Fri, 04 May 2012 15:11:10 -0400 Dieter BSD dieter...@engineer.com wrote: *WHY* is Linux so much more popular than the BSDs? My newsbyte answer is: BSD is Unix for people who love quality software. Linux is Unix for people who hate Microsoft. My favorite comparison-quote is from the former (x3) CEO of our company from way-way back (circa '95-'96): ``Linux is for Windows users that want to learn UNIX. FreeBSD is for UNIX users that want to use affordable hardware.'' (adding to the above) Which I don't necessarily think accurately describes FreeBSD today; that quote was circa pre 1.0-R (ref) to 2.x. Today, FreeBSD works on some of the most powerful equipment in the world. Equipment where price is hardly an issue. We have a great many to thank for 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: [PREVIEW] bsdconfig(8)
On Mar 6, 2012, at 1:10 AM, Alexander Best wrote: great work. a few questions or rather suggestions: [snip] 2) the highlighted first letters suggest that these are shortcuts. they work great for the actual menu items, but for OK and Exit bsdconfig, pressing O and E doesn't work. in fact E is already taken by Startup. It's since been discovered that --visit-items achieves the desired behavior (and is accepted by Xdialog(1) so seems safe to use unconditionally). -- 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: [PREVIEW] bsdconfig(8)
-Original Message- From: Alexander Best [mailto:arun...@freebsd.org] Sent: Tuesday, March 06, 2012 1:10 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; Ron McDowell Subject: Re: [PREVIEW] bsdconfig(8) On Mon Mar 5 12, Devin Teske wrote: [snip] Some here may already know that Ron McDowell and I have been hard at- work developing the replacement for sysinstall(8)'s Configure menu -- which we have named bsdconfig(8). [snip] 3) when bsdconfig starts the note regarding the packages shouldn't state Pascal. most people probably don't know what pascal is. ;) how about VirtualBox or chromium? these packages are probably used by a lot more users. 4) do we really need fdisk and disklabel? hasn't freebsd moved onto gpart and glabel? Both of these issues are addressed in the latest snapshot tarball... http://druidbsd.sf.net/download/bsdconfig/ Latest is bsdconfig.120307.txz -- Thanks Alex, 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: [PREVIEW] bsdconfig(8)
Hi Alex, Thanks for your feedback! Thoughts inline below... -Original Message- From: Alexander Best [mailto:arun...@freebsd.org] Sent: Tuesday, March 06, 2012 1:10 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; Ron McDowell Subject: Re: [PREVIEW] bsdconfig(8) On Mon Mar 5 12, Devin Teske wrote: Hiya fellow -hackers@ Many have complained that bsdinstall(8) does only a fraction of sysinstall(8). This complaint is generally understood to be in-relation to the Configure menu of sysinstall(8). Some here may already know that Ron McDowell and I have been hard at- work developing the replacement for sysinstall(8)'s Configure menu -- which we have named bsdconfig(8). bsdconfig(8), together with already-existing bsdinstall(8), should fill the gap(s) when sysinstall(8) goes-away in FreeBSD-10. bsdconfig(8) is being designed with the intention of being MFC'd to 9, so that sysinstall(8) and bsdconfig(8) can co-exist side-by-side while the bugs are worked out in RELENG_9. Later down the road, 10.0 would have only bsdinstall(8) and bsdconfig(8) (sysinstall(8) would no longer be provided). Thus, allowing a smooth transition away from sysinstall(8). With all that being said, without further ado, let me introduce the latest preview: http://druidbsd.sf.net/download/bsdconfig/ NOTE: As of this writing, latest version is bsdconfig.120305.txz obtainable from the above directory PRE-REQUISITES: You need an already-checked-out version of the FreeBSD source tree (preferably 9.0 or higher). INSTRUCTIONS: 1. cd /usr/src Correction... cd /usr/src/usr.sbin 2. fetch http://druidbsd.sf.net/download/bsdconfig/bsdconfig.120305.txz 3. tar zxf bsdconfig.120305.txz 4. cd bsdconfig 5. sudo make install HOW TO USE: bsdconfig -h bsdconfig NOTE: If sudo(8) is installed, no need to run as root (bsdconfig will handle this for you -- if/when root privileges are needed, you'll be prompted for your sudo(8) credentials). If you have an X11 display and have xauth(1) installed, try this in an X11 session: bsdconfig -X Some other things to try for fun: bsdconfig hostname # jump directly to hostname configuration bsdconfig users # jump directly to user management bsdconfig networking # jump directly to network management bsdconfig defaultrouter # jump directly to defaultrouter configuration bsdconfig nameservers # jump directly to DNS nameserver configuration bsdconfig docsinstall # jump directly to documentation installation bsdconfig timezone # jump directly to timezone configuration bsdconfig timezone -X # Configure the timezone using X11 GUI bsdconfig timezone -h # See timezone usage (for which there are many options) ERRATA: Documentation Installation is fully functional Network Management is fully functional Time Zone is fully functional and Login/Group Management is mostly functional (group add/edit/delete not done yet) Rest of the remaining modules are not functional yet. We continue to work very hard on this every day and look forward to any/all feedback, comments, suggestions, and snide remarks. great work. a few questions or rather suggestions: 1) why are there two ways to exit bsdconfig? one being X Exit and the other one being Exit bsdconfig? If we change the label back to its default value of Cancel, is it any different? What exactly would one be cancelling (as nothing has been selected yet)? I rather like the renamed Cancel button. Oh, and there's a lot more than 2 ways to exit bsdconfig(8): (from the main menu) 1. Choose Exit 2. Select Exit bsdconfig 3. Press ESC on the keyboard 4. (X11-only) Click the X close widget 5. (bug) If TERM is set to something other than cons25, pressing SHIFT+TAB will cause exit 6. (bug; Apple X11 only) If using X11 Forwarding to a Mac running Apple's X11 App, attempting to scroll a menu that is not scrollable with the mouse wheel (including two-finger up/down gesture) will cause exit. #5 remains as an open FreeBSD bug on the command-line and has already been filed as PR bin/151229). #6 remains as an open Apple bug in X11. Other bugs also exist in Apple X11 (like the fact that pressing ENTER to dismiss a dialog causes subsequent dialogs to be immediately dismissed as though the user is holding ENTER, though is not; work-around is to only use the mouse when interacting with Xdialog(1) via Apple's X11 App). I don't see a problem with giving the user multiple ways out (and labeling each correctly as such). 2) the highlighted first letters suggest that these are shortcuts. they work great for the actual menu items, but for OK and Exit bsdconfig, pressing O and E doesn't work
Re: [PREVIEW] bsdconfig(8)
On Mar 5, 2012, at 5:03 PM, Devin Teske wrote: -Original Message- From: Robison, Dave [mailto:david.robi...@fisglobal.com] Sent: Monday, March 05, 2012 5:00 PM To: freebsd-hackers@freebsd.org Cc: r...@fuzzwad.org; Devin Teske Subject: Re: [PREVIEW] bsdconfig(8) On 03/05/2012 16:44, Devin Teske wrote: We continue to work very hard on this every day and look forward to any/all feedback, comments, suggestions, and snide remarks. When editing user info via X dialogue it doesn't prompt with a save option like it does in ncurses. Woo hoo, first to complain! Thanks DaveR! I'll get right on that. Fixed in the latest download: http://druidbsd.sf.net/download/bsdconfig/ Latest is bsdconfig.120306.txz Preview Instructions (to get you up and running; again, requires checked-out src-tree): cd /usr/src/usr.sbin fetch http://druidbsd.sf.net/download/bsdconfig/bsdconfig.120306.txz tar zxf bsdconfig.120306.txz cd bsdconfig make sudo make install /usr/sbin/bsdconfig -h /usr/sbin/bsdconfig Thanks DaveR! -- 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
[PREVIEW] bsdconfig(8)
Hiya fellow -hackers@ Many have complained that bsdinstall(8) does only a fraction of sysinstall(8). This complaint is generally understood to be in-relation to the Configure menu of sysinstall(8). Some here may already know that Ron McDowell and I have been hard at-work developing the replacement for sysinstall(8)'s Configure menu -- which we have named bsdconfig(8). bsdconfig(8), together with already-existing bsdinstall(8), should fill the gap(s) when sysinstall(8) goes-away in FreeBSD-10. bsdconfig(8) is being designed with the intention of being MFC'd to 9, so that sysinstall(8) and bsdconfig(8) can co-exist side-by-side while the bugs are worked out in RELENG_9. Later down the road, 10.0 would have only bsdinstall(8) and bsdconfig(8) (sysinstall(8) would no longer be provided). Thus, allowing a smooth transition away from sysinstall(8). With all that being said, without further ado, let me introduce the latest preview: http://druidbsd.sf.net/download/bsdconfig/ NOTE: As of this writing, latest version is bsdconfig.120305.txz obtainable from the above directory PRE-REQUISITES: You need an already-checked-out version of the FreeBSD source tree (preferably 9.0 or higher). INSTRUCTIONS: 1. cd /usr/src 2. fetch http://druidbsd.sf.net/download/bsdconfig/bsdconfig.120305.txz 3. tar zxf bsdconfig.120305.txz 4. cd bsdconfig 5. sudo make install HOW TO USE: bsdconfig -h bsdconfig NOTE: If sudo(8) is installed, no need to run as root (bsdconfig will handle this for you -- if/when root privileges are needed, you'll be prompted for your sudo(8) credentials). If you have an X11 display and have xauth(1) installed, try this in an X11 session: bsdconfig -X Some other things to try for fun: bsdconfig hostname # jump directly to hostname configuration bsdconfig users # jump directly to user management bsdconfig networking # jump directly to network management bsdconfig defaultrouter # jump directly to defaultrouter configuration bsdconfig nameservers # jump directly to DNS nameserver configuration bsdconfig docsinstall # jump directly to documentation installation bsdconfig timezone # jump directly to timezone configuration bsdconfig timezone -X # Configure the timezone using X11 GUI bsdconfig timezone -h # See timezone usage (for which there are many options) ERRATA: Documentation Installation is fully functional Network Management is fully functional Time Zone is fully functional and Login/Group Management is mostly functional (group add/edit/delete not done yet) Rest of the remaining modules are not functional yet. We continue to work very hard on this every day and look forward to any/all feedback, comments, suggestions, and snide remarks. -- Cheers, 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: [PREVIEW] bsdconfig(8)
-Original Message- From: Robison, Dave [mailto:david.robi...@fisglobal.com] Sent: Monday, March 05, 2012 5:00 PM To: freebsd-hackers@freebsd.org Cc: r...@fuzzwad.org; Devin Teske Subject: Re: [PREVIEW] bsdconfig(8) On 03/05/2012 16:44, Devin Teske wrote: We continue to work very hard on this every day and look forward to any/all feedback, comments, suggestions, and snide remarks. When editing user info via X dialogue it doesn't prompt with a save option like it does in ncurses. Woo hoo, first to complain! Thanks DaveR! I'll get right on 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: [PREVIEW] bsdconfig(8)
On Mar 5, 2012, at 6:20 PM, Andrzej Tobola wrote: On Mon, Mar 05, 2012 at 04:44:53PM -0800, Devin Teske wrote: INSTRUCTIONS: 1. cd /usr/src cd /usr/src/usr.sbin ? Sorry… /usr/src/usr.bin You don't need to be root to run it, so it's going into /usr/bin, not sbin. Thanks for catching that! -- Devin 2. fetch http://druidbsd.sf.net/download/bsdconfig/bsdconfig.120305.txz 3. tar zxf bsdconfig.120305.txz 4. cd bsdconfig 5. sudo make install -a _ 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: [PREVIEW] bsdconfig(8)
On Mar 5, 2012, at 10:49 PM, Doug Barton wrote: On 3/5/2012 8:24 PM, Devin Teske wrote: On Mar 5, 2012, at 6:20 PM, Andrzej Tobola wrote: On Mon, Mar 05, 2012 at 04:44:53PM -0800, Devin Teske wrote: INSTRUCTIONS: 1. cd /usr/src cd /usr/src/usr.sbin ? Sorry… /usr/src/usr.bin You don't need to be root to run it, so it's going into /usr/bin, not sbin. That's not the dividing line, please read hier(7). Your right. /usr/sbin fits best. Thanks Doug! This should be introduced as a port in /usr/local/sbin to start with, and then we'll see how it goes from there. Of course and naturally. -- 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: Never forget a special trick...
On Mar 4, 2012, at 12:29 PM, Phillip Spring wrote: Dear anonymous open-source enthusiasts friends, How to echo a string backwards into a terminal? For example (or something like this): # echo @_foo_$ oof Or it could be something else (that's because I forgot it): # echo $_bar_@ rab Someone told me how to do it but I can't remember this trick. I just remember the date it happened: Oct-13-2011 You're looking for rev(1) Example: # echo foo | rev oof -- 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: nologin size
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Ansar Mohammed Sent: Wednesday, February 15, 2012 11:29 AM To: freebsd-hackers@freebsd.org Subject: nologin size Hello all, I am trying to build a minimal size FreeBSD 9 installation and I noticed that the size of nologin is almost 200k. I built FreeBSD from source so I checked the distribution, and it's also 200k. So I went back to the source and just compiled nologin.c and it came up to 5k. Can anyone explain why this executable is so large? Dynamic versus static executable. 200K version: % ldd /usr/sbin/nologin ldd: /usr/sbin/nologin: not a dynamic ELF executable 5K version (produced manually by compiling/linking oneself -- shown below): % cd /usr/src/usr.sbin/nologin % sudo cc -c nologin.c -o nologin.o % sudo cc -g nologin.o -o nologin % ldd nologin nologin: libc.so.7 = /lib/libc.so.7 (0x2809) -- 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: xargs short-circuit
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Matthew Story Sent: Tuesday, February 14, 2012 10:35 AM To: freebsd-hackers@freebsd.org Subject: xargs short-circuit After reading the man-page, and browsing around the internet for a minute, I was just wondering if there is an option in (any) xargs to short-circuit on first failure of [utility [arguments]]. e.g. $ jot - 1 10 | xargs -e -n1 sh -c 'echo $*; echo exit 1' worker || echo $? 1 1 such that any non-0 exit code in a child process would cause xargs to stop processing. seems like this would be a nice feature to have. You can achieve this quite easily with a sub-shell: As a bourne-shell script: #!/bin/sh jot - 1 10 | ( while read ARG1 REST; do sh -c 'echo $*; exit 1' worker $ARG1 || exit $? shift 1 done ) Or interactively in sh/bash: $ jot - 1 10 | ( while read ARG1 REST; do sh -c 'echo $*; exit 1' worker $ARG1 || exit $?; shift 1;done ) Or interactively in csh/tcsh: % jot - 1 10 | /bin/sh -c 'while read ARG1 REST; do sh -c '\''echo $*; exit 1'\'' worker $ARG1 || exit $?; shift 1; done' -- 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: xargs short-circuit
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Matthew Story Sent: Tuesday, February 14, 2012 11:18 AM To: freebsd-hackers@freebsd.org Subject: Re: xargs short-circuit On Tue, Feb 14, 2012 at 2:05 PM, Devin Teske devin.te...@fisglobal.comwrote: -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Matthew Story Sent: Tuesday, February 14, 2012 10:35 AM To: freebsd-hackers@freebsd.org Subject: xargs short-circuit After reading the man-page, and browsing around the internet for a minute, I was just wondering if there is an option in (any) xargs to short-circuit on first failure of [utility [arguments]]. e.g. $ jot - 1 10 | xargs -e -n1 sh -c 'echo $*; echo exit 1' worker || echo $? 1 1 such that any non-0 exit code in a child process would cause xargs to stop processing. seems like this would be a nice feature to have. You can achieve this quite easily with a sub-shell: As a bourne-shell script: #!/bin/sh jot - 1 10 | ( while read ARG1 REST; do sh -c 'echo $*; exit 1' worker $ARG1 || exit $? shift 1 done ) read is often not sufficient for a variety of reasons, the most notable of them is that new-lines are valid in file names on most file systems. Your original example/post neither requested nor implied that such functionality was required. If you need such functionality, then you should be using awk, perl, or some other heavier-lifting code (can even be sh(1), but you'll sacrifice speed). -- 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: OS support for fault tolerance
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Julian Elischer Sent: Tuesday, February 14, 2012 3:02 PM To: Rayson Ho Cc: Maninya M; freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance On 2/14/12 9:27 AM, Rayson Ho wrote: On Tue, Feb 14, 2012 at 11:57 AM, Julian Elischerjul...@freebsd.org wrote: but I'm interested in any answers people may have The way other OSes handle this is by detecting any abnormal amounts of faults (sometimes it's not the fault of the hardware - eg. when a partical from the outerspace hits a core and flips the bit), then the disable the core(s). Solaris mainframe (z/OS) handle it this way, but you should google and find more info since I don't remember all the details. Also, see this presentation: Getting to know the Solaris Fault Management Architecture (FMA): http://www.prefetch.net/presentations/SolarisFaultManagement_Presentation .pdf True, but you can't guarantee that a cpu is going to fail in a way that you can detect like that. what if the clock just stops.. I believe that even those systems that support cpu deactivation on error only catch some percentage of the problems, and that sometimes it was more of bring up the system without cpu X after it all crashed in flames. tandem and other systems in the old day s used to be able to cope with dying cpus pretty well but they had support from to to bottom and the software was written with 'clustering' in mind. Nowadays NEC has a their sixth-generation Fault Tolerant (FT) Series servers which are pretty much like the tandem servers. We got a live demo of [simulated] CPU failure and the system kept chugging along. But as Julian says, it's not guaranteed that the CPU will always fail in a predictable way (however, NEC has produced a VERY nice redundant package with 256-bit backplane to keep everything nice and lock-step). -- 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: Parallels v4 regression (aka ada(4) oddity) in RELENG_9
On Jan 25, 2012, at 4:50 AM, Dimitry Andric d...@freebsd.org wrote: On 2012-01-23 19:46, Ed Maste wrote: ... Do you have the reproduction steps documented somewhere (and if not, can you write them up)? In order to have working automated installs we need to be able to unconditionally reinit a drive w/o having behavoiur depend on what happens to be left behind. Maybe just zero the first and last N sectors of the drive, where N is 10,000 or greater? gpart destroy -F adaX Worked. -- 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
Parallels v4 regression (aka ada(4) oddity) in RELENG_9
I have a Parallels virtual machine and it runs FreeBSD 4 through 8 just swimmingly. However, in RELENG_9 I notice something different. My once ad0 is now showing up as ada0. However, something even stranger is that devfs is providing both ad0 family devices AND ada0 family devices. What's worse is that I can't seem to partition the disk with MBR+disklabel scheme. My procedure goes something like this: 1. Boot from RELENG_9 LiveCD 2. Execute: sysctl -n kern.disks 3. Notice two items: cd0 ada0 4. Look in /dev 5. Notice several items: ad0 ad0p1 ad0p2 ad0p3 ada0 ada0p1 ada0p2 ada0p3 6. Wipe partition table by executing: dd if=/dev/zero of=/dev/ada0 bs=512k count=256 7. Look in /dev 8. Notice less items now: ad0 ada0 9. Execute: sysctl -n kern.disks 10. Notice nothing changed: cd0 ada0 11. Write out standard whole disk MBR slice 12. Look in /dev 13. Notice that nothing changed: ad0 ada0 NOTE: Where is ad0s1 or ada0s1? 14. Use fdisk to make sure everything was written successfully 15. Notice everything looks good (slice 1 is of type FreeBSD, slice 2, 3, and 4 are unused) 16. Reboot 17. Boot back into RELENG_9 LiveCD 18. Look in /dev 19. Notice that the old devices are back!: ad0 ad0p1 ad0p2 ad0p3 ada0 ada0p1 ada0p2 ada0p3 20. Use fstab to look at MBR partition table 21. Notice that things look good (with respect to fdisk'ing): slice 1 is FreeBSD, 2, 3, and 4 are still unused 22. Notice /dev still doesn't have ad0s1 or ada0s1 23. Use gpart to look at ada0 24. Notice GPT [CORRUPT] ... OK!?!? ... Use same exact RELENG_9 LiveCD on either a physical machine or VMware Virtual machine. SUCCESS!! Go back to Parallels 4 FAILURE!! Go back to RELENG_8 LiveCD with Parallels 4 SUCCESS!! What's going on here? I think ada(4) is my problem. Can someone please provide feedback? Willing to dig further and provide any/all feedback to help fix this regression. -- 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: Parallels v4 regression (aka ada(4) oddity) in RELENG_9
-Original Message- From: Garrett Cooper [mailto:yaneg...@gmail.com] Sent: Monday, January 23, 2012 10:16 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: Parallels v4 regression (aka ada(4) oddity) in RELENG_9 On Mon, Jan 23, 2012 at 10:06 AM, Devin Teske devin.te...@fisglobal.com wrote: I have a Parallels virtual machine and it runs FreeBSD 4 through 8 just swimmingly. However, in RELENG_9 I notice something different. My once ad0 is now showing up as ada0. However, something even stranger is that devfs is providing both ad0 family devices AND ada0 family devices. What's worse is that I can't seem to partition the disk with MBR+disklabel scheme. My procedure goes something like this: 1. Boot from RELENG_9 LiveCD 2. Execute: sysctl -n kern.disks 3. Notice two items: cd0 ada0 4. Look in /dev 5. Notice several items: ad0 ad0p1 ad0p2 ad0p3 ada0 ada0p1 ada0p2 ada0p3 6. Wipe partition table by executing: dd if=/dev/zero of=/dev/ada0 bs=512k count=256 7. Look in /dev 8. Notice less items now: ad0 ada0 9. Execute: sysctl -n kern.disks 10. Notice nothing changed: cd0 ada0 11. Write out standard whole disk MBR slice 12. Look in /dev 13. Notice that nothing changed: ad0 ada0 NOTE: Where is ad0s1 or ada0s1? 14. Use fdisk to make sure everything was written successfully 15. Notice everything looks good (slice 1 is of type FreeBSD, slice 2, 3, and 4 are unused) 16. Reboot 17. Boot back into RELENG_9 LiveCD 18. Look in /dev 19. Notice that the old devices are back!: ad0 ad0p1 ad0p2 ad0p3 ada0 ada0p1 ada0p2 ada0p3 20. Use fstab to look at MBR partition table 21. Notice that things look good (with respect to fdisk'ing): slice 1 is FreeBSD, 2, 3, and 4 are still unused 22. Notice /dev still doesn't have ad0s1 or ada0s1 23. Use gpart to look at ada0 24. Notice GPT [CORRUPT] ... OK!?!? ... Use same exact RELENG_9 LiveCD on either a physical machine or VMware Virtual machine. SUCCESS!! Go back to Parallels 4 FAILURE!! Go back to RELENG_8 LiveCD with Parallels 4 SUCCESS!! What's going on here? I think ada(4) is my problem. Can someone please provide feedback? Willing to dig further and provide any/all feedback to help fix this regression. The 'bug' is in gpart/geom and the 'issue' is present in prior versions of FreeBSD. The backup partition is now more of a thorn in everyone's side than previous versions. gpart delete'ing all the partitions, then doing gpart destroy is probably what you want (there isn't a simple one-liner that would do this). So dd if=/dev/zero of=/dev/ada0 bs=512k count=256 is not enough to wipe out the backup partition (presumably created by prior-usage of bsdinstall guided/auto partitioning)?? -- 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: Parallels v4 regression (aka ada(4) oddity) in RELENG_9
-Original Message- From: Ian Lepore [mailto:free...@damnhippie.dyndns.org] Sent: Monday, January 23, 2012 10:17 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: Parallels v4 regression (aka ada(4) oddity) in RELENG_9 On Mon, 2012-01-23 at 10:06 -0800, Devin Teske wrote: I have a Parallels virtual machine and it runs FreeBSD 4 through 8 just swimmingly. However, in RELENG_9 I notice something different. My once ad0 is now showing up as ada0. However, something even stranger is that devfs is providing both ad0 family devices AND ada0 family devices. What's worse is that I can't seem to partition the disk with MBR+disklabel scheme. My procedure goes something like this: 1. Boot from RELENG_9 LiveCD 2. Execute: sysctl -n kern.disks 3. Notice two items: cd0 ada0 4. Look in /dev 5. Notice several items: ad0 ad0p1 ad0p2 ad0p3 ada0 ada0p1 ada0p2 ada0p3 6. Wipe partition table by executing: dd if=/dev/zero of=/dev/ada0 bs=512k count=256 7. Look in /dev 8. Notice less items now: ad0 ada0 9. Execute: sysctl -n kern.disks 10. Notice nothing changed: cd0 ada0 11. Write out standard whole disk MBR slice 12. Look in /dev 13. Notice that nothing changed: ad0 ada0 NOTE: Where is ad0s1 or ada0s1? 14. Use fdisk to make sure everything was written successfully 15. Notice everything looks good (slice 1 is of type FreeBSD, slice 2, 3, and 4 are unused) 16. Reboot 17. Boot back into RELENG_9 LiveCD 18. Look in /dev 19. Notice that the old devices are back!: ad0 ad0p1 ad0p2 ad0p3 ada0 ada0p1 ada0p2 ada0p3 20. Use fstab to look at MBR partition table 21. Notice that things look good (with respect to fdisk'ing): slice 1 is FreeBSD, 2, 3, and 4 are still unused 22. Notice /dev still doesn't have ad0s1 or ada0s1 23. Use gpart to look at ada0 24. Notice GPT [CORRUPT] ... OK!?!? ... Use same exact RELENG_9 LiveCD on either a physical machine or VMware Virtual machine. SUCCESS!! Go back to Parallels 4 FAILURE!! Go back to RELENG_8 LiveCD with Parallels 4 SUCCESS!! What's going on here? I think ada(4) is my problem. Can someone please provide feedback? Willing to dig further and provide any/all feedback to help fix this regression. I've experienced the part of that scenario where changing a drive from gpt to mbr scheme results in all the gpt partitions reappearing after a reboot. I concluded (but didn't take time to be absolutely certain) that during boot the geom layer was seeing the backup gpt partition info at the end of the disk Ah! There's a backup partition at the END of the disk! /me is new to GPT and concluding that it needed to ignore the mbr and use the backup gpt info instead. Once I quit using dd and similar tools and consistantly used gpart destroy to wipe out the gpt before changing to mbr, it stopped happening. Ah! Thanks Ian (and Garrett in another reply)! I'll give gpart destroy a try -- 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: Parallels v4 regression (aka ada(4) oddity) in RELENG_9
-Original Message- From: Alexander Motin [mailto:mav...@gmail.com] On Behalf Of Alexander Motin Sent: Monday, January 23, 2012 3:52 PM To: Devin Teske Cc: freebsd-hackers@freebsd.org Subject: Re: Parallels v4 regression (aka ada(4) oddity) in RELENG_9 On 01/23/12 20:06, Devin Teske wrote: I have a Parallels virtual machine and it runs FreeBSD 4 through 8 just swimmingly. However, in RELENG_9 I notice something different. My once ad0 is now showing up as ada0. However, something even stranger is that devfs is providing both ad0 family devices AND ada0 family devices. That is compatibility shims. You can disable them if you want by adding to /boot/loader.conf line: kern.cam.ada.legacy_aliases=0 Ah, thanks Alexander! -- 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: Change of ftp download server's dir layout, from 9
On Jan 22, 2012, at 8:01 AM, rank1see...@gmail.com wrote: Example: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.0-RELEASE/ Refering to KERNEL: 8 - kernels 9 - kernel (It was supposed to be 'kernels.txz', in order to preserve naming scheme) 9 - manpages is a NO MORE Where are CHECKSUM.MD5 and CHECKSUM.SHA256 for *.txz ?!? You want the new MANIFEST file for such info. Though, it's unclear merely by just looking at the hash what digest it is (looks long enough to be sha256). -- Devin This confused my script, so I'm all in filling additional IFs statements for 9 PS: I do welcome .txz ;) Domagoj Smolčić ___ 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 -- 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: FreeBSD has serious problems with focus, longevity, and lifecycle
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Robert Huff Sent: Thursday, January 19, 2012 8:35 AM To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Igor Mozolevsky writes: Wouldn't this discourage even more people from helping? Would this not separate people who have a genuine interest in contributing from tinker-monkeys? Did I miss a previous definition of tinker-monkey? And is it anything like a tinker-tailor? -- 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: FreeBSD has serious problems with focus, longevity, and lifecycle
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Julian Elischer Sent: Tuesday, January 17, 2012 10:56 AM To: Mark Felder Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle [snip] Where I used to work (Devin Teske is now there) we used to use the 'stable' branch and rolll our own releases. the criticality of those systems was hard to over-emphasize. In 2005 we worked out we processed 1.5 trillion dollars of transactions on those systems. Got new stats. In 2011 we ran $1.61T USD through FreeBSD. Separately, we ran another $0.05T USD through Linux in the same year. Kinda says something about, doesn't it? -- 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: FreeBSD has serious problems with focus, longevity, and lifecycle
-Original Message- From: mozolev...@gmail.com [mailto:mozolev...@gmail.com] On Behalf Of Igor Mozolevsky Sent: Wednesday, January 18, 2012 9:12 AM To: Devin Teske Cc: Julian Elischer; Mark Felder; freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle On 18 January 2012 17:06, Devin Teske devin.te...@fisglobal.com wrote: -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Julian Elischer Sent: Tuesday, January 17, 2012 10:56 AM To: Mark Felder Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle [snip] Where I used to work (Devin Teske is now there) we used to use the 'stable' branch and rolll our own releases. the criticality of those systems was hard to over-emphasize. In 2005 we worked out we processed 1.5 trillion dollars of transactions on those systems. Got new stats. In 2011 we ran $1.61T USD through FreeBSD. Separately, we ran another $0.05T USD through Linux in the same year. Kinda says something about, doesn't it? Sorry to burst your bubble but this is utterly meaningless statistic. You show nothing but correlation and in no way a causation. Back in the days when the UK banks ran ATMs, c on Windows NT (I have no idea what they are running now) they went through a lot more value than that---means absolutely nothing... No worries... you're not bursting anyone's bubble here. We are limited as to what metrics we can publish in this open forum. If there's some information that would better put this into perspective, feel free to ask, but we are always at liberty to decline if the published information would violate any federal laws. -- 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: Getting PRs fixed (was: Re: ...focus, longevity, and lifecycle)
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Dieter BSD Sent: Wednesday, January 18, 2012 4:58 PM To: freebsd-hackers@freebsd.org Subject: Getting PRs fixed (was: Re: ...focus, longevity, and lifecycle) Andriy writes: And dealing with PRs is not always exciting. Neither is brushing your teeth or cleaning the kitchen, but most of us manage to do them at least occasionally. Part of being a grown up. Instead of looking for a stick to hold over developers to get them to fix PRs, let's look for carrots to make fixing PRs more appealing. Idea 1: Fix 'n' PRs, get a tee-shirt, fridge magnet, plush daemon, ... +1 (!) But careful not to incentivize those that raise PRs to split a single PR into multiples purely for metrics. We probably won't care that this might also incentivize committers to raise PRs for the commits they would normally make without one (wait, does that happen?) Idea 2: Give it status. Set up a web page with PR fixing stats name/handle..total PRs fixed...fixed in last 12 months...average fixed/year Sheldon..150...9072 Leonard..131..11067 Howard...104...2052 Raj...80...8080 +1 -- 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: Getting PRs fixed (was: Re: ...focus, longevity, and lifecycle)
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Igor Mozolevsky Sent: Wednesday, January 18, 2012 6:06 PM To: Dieter BSD Cc: freebsd-hackers@freebsd.org Subject: Re: Getting PRs fixed (was: Re: ...focus, longevity, and lifecycle) On 19 January 2012 00:57, Dieter BSD dieter...@engineer.com wrote: Idea 2: Give it status. Set up a web page with PR fixing stats name/handle..total PRs fixed...fixed in last 12 months...average fixed/year Sheldon..150...9072 Leonard..131..11067 Howard...104...2052 Raj...80...8080 You mean something like: http://people.freebsd.org/~edwin/gnats/ ? ;-) I'd want to know more about how the metrics for the top responsibles is gathered, because its current state may represent a tell-tale problem if PRs are idling too-often in their generic assignments (rather than being disbursed in a timely fashion to more-appropriate owners). -- 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: Getting PRs fixed (was: Re: ...focus, longevity, and lifecycle)
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Igor Mozolevsky Sent: Wednesday, January 18, 2012 6:06 PM To: Dieter BSD Cc: freebsd-hackers@freebsd.org Subject: Re: Getting PRs fixed (was: Re: ...focus, longevity, and lifecycle) On 19 January 2012 00:57, Dieter BSD dieter...@engineer.com wrote: Idea 2: Give it status. Set up a web page with PR fixing stats name/handle..total PRs fixed...fixed in last 12 months...average fixed/year Sheldon..150...9072 Leonard..131..11067 Howard...104...2052 Raj...80...8080 You mean something like: http://people.freebsd.org/~edwin/gnats/ ? ;-) Sure would be nice if the colors used in each graph were actually defined (just sayin'). -- 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: Build Option Survey results
Thanks Bjoern! -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Bjoern A. Zeeb Sent: Wednesday, January 11, 2012 11:46 PM To: FreeBSD current mailing list Cc: freebsd-hackers@freebsd.org Subject: Build Option Survey results Hey, after two years I had the opportunity to run the build option survey, initially done by phk, again. The number of options seems to have grown quite a bit it felt. I have not even looked at the results yet but here they are fresh off the machine: http://people.freebsd.org/~bz/build_option_survey_20120106/ With respect to the results of the build-survey linked-to above... I submitted 4x PR's to restore the failed WITHOUT_OPENSSL build option: misc/164206: [PATCH] buildworld WITHOUT_OPENSSL stops at lib/libarchive http://www.FreeBSD.org/cgi/query-pr.cgi?pr=164206 misc/164208: [PATCH] buildworld WITHOUT_OPENSSL stops at lib/libbsnmp/libbsnmp http://www.FreeBSD.org/cgi/query-pr.cgi?pr=164208 misc/164209: [PATCH] buildworld WITHOUT_OPENSSL stops at usr.sbin/wpa/hostapd http://www.FreeBSD.org/cgi/query-pr.cgi?pr=164209 misc/164210: [PATCH] buildworld WITHOUT_OPENSSL stops at usr.sbin/wpa/wpa_supplicant http://www.FreeBSD.org/cgi/query-pr.cgi?pr=164210 -- Devin Special thanks go to np, sbruno and bhaga for bringing worm back to life. /bz PS: the last run from 2010 can still be found here: http://people.freebsd.org/~bz/build_option_survey_20100104/ -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Garrett Cooper Sent: Monday, January 16, 2012 4:07 PM To: wbent...@futurecis.com Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle On Mon, Jan 16, 2012 at 3:32 PM, William Bentley will...@futurecis.com wrote: I also echo John's sentiments here. Very excellent points made here. Thank you for voicing your opinion. I was beginning to think I was the only one who felt this way. I also have several FreeBSD installations spread across different development/production systems and it is not feasible to always upgrade to the latest and greatest. Part of why FreeBSD is difficult to adopt into more of the commercial/government sectors is because of this fast paced release cycle and most of the important patches/fixes are not backported far enough. This is why most of my customers decide to use Solaris or RedHat and not FreeBSD. (Not looking to start a flame war about the OS choice/etc just pointing out the Release cycle model). I would love to push FreeBSD harder but it is becoming increasingly difficult as of late. We seem to have lost our way around the release of FreeBSD 7. I am all in favor of new features but not at the risk of stability and proper life cycle management. Are me and John the only people that feel this way or are we among the minority? You aren't. There are other people like Devin Teske's group that feel the same (they're upgrading from 4.x to 8.2! Brave man.. and godspeed to him), Thanks! Actually, we're jumping from 4.11 to 8.1 (not 8.2 -- reason as follows). A lot of the problems we're having in 8.1 still exist in 8.2 (but will go-away in 8.3, according to what we're seeing already-committed to RELENG_8 tag beyond the RELENG_8_2_0_RELEASE tag -- that is, if 8.3 ever gets produced!). Therefore, we've seen no need to push 8.2 (in-fact, we've internally black-listed it because it doesn't fix anything we care about). So far, we've made over 10 patches to FreeBSD-8.1, and not a one of them would have been needed for 8.3, but all of them would still be needed for 8.2. I might add that we're doing an in-place binary migration from 4.11 to 8.1 using a very sophisticated sh(1) script named host_rebuild which we'll be releasing later this year. It allows binary migration both forwards, backwards, and even stationary (re-installing the same OS, to either migrate architecture or simply rebuild the OS). along with some development organizations that depend on long release cycles (IronPort, Isilon, etc). I brought this up in last weekend's BAFUG meeting... We're _very_ interested in replicating the long-lifecycle of the 4-series with a newer series. But which one? Right now, we're jumping to the 8-series, but after seeing that one of the major focal points for 9 is McKusick's SU+J (SoftUpdates Journaling -- tunefs -j enable), I'm ready to say that the 9-series should instead be the chosen outlier when it comes to picking one single release to have an ultra-wide lifecycle. The 9-series represents the first release to integrate a journaled filesystem by-default into the system (aka boot) filesystem(s). We were pleasantly surprised to see that the default installer enabled SU+J by-default when choosing guided and auto for disk partitioning. NOTE: We hated gjournal -- too clunky as a bolt-on solution. SU+J is a breath of fresh-air as it's truly integrated into the filesystem and recognized at the base FreeBSD level. -- Devin That being said. More people, more likelihood to succeed with what you need, like julian@ suggests. I like long release cycles too for stuff that I find critical and in production, like my router. My fileserver is a slightly different story, but I just got off the CURRENT bandwagon off on to the 9-STABLE bandwagon :). Cheers, -Garrett ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Julian Elischer Sent: Tuesday, January 17, 2012 10:56 AM To: Mark Felder Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle On 1/17/12 7:39 AM, Mark Felder wrote: Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to us that VMWare only supports -RELEASE and it took until ESX 5 to officially support 8.2! More releases / snapshots of -STABLE helps people on physical servers, but anyone who runs VMs on Xen or VMWare won't get any support for those versions because they didn't go through the QA process yet. FreeBSD is increasingly becoming a third world citizen thanks to virtualization efforts being focused on Linux, so I feel that more frequent releases won't help as many people as you think. I'm going to go both ways on this one. Where I used to work (Devin Teske is now there) we used to use the 'stable' branch and rolll our own releases. We still do this today, but have only further enhanced the procedure. Within FreeBSD announcing a new release, we can be ready to ship said-release within 3-6 weeks. However, that's not to say that our customers can take said-new-release every 3-6 weeks. Our largest customer is not-surprisingly the fastest at turn-around but at-best could only do maybe 2 releases at-most in a single year. Our smaller customers are taking OS upgrades much slower (every-other year if we're lucky; more like once every 3 years). For both our large and small customers, we actively back-port device support in-accordance with hardware manufacturing windows. This is to explain that our hardware suppliers notify us ahead-of time when a particular piece of hardware is about to become unavailable. At that time we are usually given a choice of hardware to evaluate as replacements for the existing EOM production-line. We're usually given at least 3-9 months prior-notice before our current production-line goes EOL. For each candidate replacement we try each FreeBSD release that we're currently using in production. If it doesn't work, we try another candidate hardware. If we can't seem to find a winning combo that works with our existing -RELEASE, we then start trying newer releases until we find drivers working for each/every required piece of hardware (network cards, RAID cards, serial ports/cards, Adaptec SCSI cards, Fibre HBAs, etc.). When we find a release that contains the necessary drivers, we back-port. At this time, it's worth noting that we use ONLY monolithic kernels and we deliver them via packages. When we back-port new device support, we just roll a new kernel, ship it via package, pkg_add, reboot. Similarly, if the patch is in userland, we package up the replaced binaries (produced by using the release engineering procedures documented in build(7) and [more importantly] release(7)). The net effect is that we run a -RELEASE with patches from either the same -STABLE, a higher -RELEASE, higher -STABLE, or (as a last-resort) -CURRENT or HEAD. We've been known to roll FreeBSD-4.11 kernels with bits back-ported from RELENG_8. So, I guess what I’m trying to say is that if you're going to take your production environment extremely seriously (as though 1.5-Trillion globally-economic-dollars depended on it) you-too would take a serious look at release(7) and the Release Engineer's handbook. It really is worth maintaining your own release, taking required fixes from -STABLE (preferred) or higher (as necessary) to satisfy your customers (which are nearly almost always going to have a different release schedule than that-of any OS, be-it FreeBSD, Linux, or other distribution). the criticality of those systems was hard to over-emphasize. In 2005 we worked out we processed 1.5 trillion dollars of transactions on those systems. I'm going to have to sit down with DaveR, JPL, and others to get an updated metric for 2011. I'd be willing to bet that we've increased transactional load over the years (with respect to FreeBSD, we brought on one new sizable customer since then and expanded the scope of existing FreeBSD customers to new overseas installations as well as several new sites in the States). The other side of the coin is that we had the resources to have someone (me) tracking the branch. That person is now (me) plus I have Dave Robison (DaveR) to lean on occasionally (and you're always a great help, DaveR). I'd argue that it's not the man-power... it's whether management sees the importance in allowing one (or two) persons to spin his/her wheels, developing a laudable solution to the problem at-hand (precisely what we've done; mitigating extra/busy work). However, sometimes you just have to take initiative. The company
RE: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi John, -Original Message- From: John Kozubik [mailto:j...@kozubik.com] Sent: Tuesday, January 17, 2012 3:52 PM To: Devin Teske Cc: 'Garrett Cooper'; wbent...@futurecis.com; freebsd-hackers@freebsd.org Subject: RE: FreeBSD has serious problems with focus, longevity, and lifecycle Hi Devin, On Tue, 17 Jan 2012, Devin Teske wrote: I brought this up in last weekend's BAFUG meeting... We're _very_ interested in replicating the long-lifecycle of the 4-series with a newer series. But which one? Right now, we're jumping to the 8-series, but after seeing that one of the major focal points for 9 is McKusick's SU+J (SoftUpdates Journaling -- tunefs -j enable), I'm ready to say that the 9-series should instead be the chosen outlier when it comes to picking one single release to have an ultra-wide lifecycle. The 9-series represents the first release to integrate a journaled filesystem by-default into the system (aka boot) filesystem(s). We were pleasantly surprised to see that the default installer enabled SU+J by-default when choosing guided and auto for disk partitioning. There's two parallel suggestions being put forth here, both of which are interesting: - Allow a related party to adopt a release (as I understand it) and provide a sub- community taht donates resources to tending and updating that release. - Picking a chosen release to really dive into, officially, and polish and extend it, like 4. If I had to pick, I'd say the second one, but I'm not sure either one is the right direction. I too am not sure. The latter (pick a chosen release) option seems a good route, but like you say, maybe a re-envisioning of the release procedure is what's needed for long-term. I think a more sustainable, balanced approach that can be extended for every release into the future would be best. I don't really want to see some semi-official fork, or extended release - it would duplicate a lot of existing effort as well as raise questions about how official it was. Would vmware support it as a real release ? Large organizations might disqualify it the same way they would STABLE. As for picking 8 or 9 to be the chosen exception - that would help me a lot in the short term, but if things are being done wrong, they should be fixed in the long run. I think the real choice that has to be made is when will we halt proclaiming two simultaneous releases as production ? and since 9 is already here, it can't be 8/9, it has to be 9/10. You could progress 8.x along its current trajectory, possibly building 8.4 a year or so from now and then be done with it, and then that would be the last short/unfocused release. I often have to deal with FUD at work, especially when the developers learn that FreeBSD has, for example, released FreeBSD 9.0 somewhat indicating that oh, no -- we're obsolete?! In which I've always had to then explain how FreeBSD has three versions running simultaneously at all times -- a legacy release, a stable release, and a future release, and they are happy with such an explanation. I usually then go on to explain back in the day it was 4/5/6, and now it's 8/9/10. Naturally, this is an over-simplified view of the situation, but it sure would be a nice view if it were absolutely true. There ought to be a charter that explicitly defines the types of things you can expect from each release (regardless of which release): For example, the legacy release (which might as well be 8.x now) should: a. Receive all security patches until deprecated b. Receive critical bug fixes until deprecated c. Benefit from trivial hardware device additions (e.g., developer adds 0x10de device identifier to if_bgereg.h to add new hardware support to bge(4)) Meanwhile, the stable release (which might as well be 9.x now) should: a. Receive all security patches b. Receive critical bug fixes c. Benefit from ALL hardware device changes except experimental ones and those that completely redesign the driver Last, the current release (which might as well be 10.x now) should: a. Be the landing zone for all new code, experimental or otherwise. Finally, the charter ought to also define when a current can become stable ... not define some arbitrary timeline which results in situations like that which was previously mentioned in this thread (9.0 shipped as stable release with completely broken gmultipath). Then you postpone 10.0-RELEASE until January 2017. Instead of having a legacy branch and two production branches, you would have legacy (8) production (9) and ... nothing. Or if you need to have it out there, 10 is the development branch. +1 Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15 at the end of the cycle. Ought we to have one timeline for stable (aka production) and a different timeline for legacy? Say, cut a new release in legacy 1-2 times a year and cut a new release in production 2-3 times
tzsetup(8) patches
Can someone please take a look at 3 patches I've filed against tzsetup(8)? bin/164039: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/164039 [PATCH] tzsetup(8): Don't write /var/db/zoneinfo either when -n is passed or when install_zoneinfo_file returns failure bin/164041: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/164041 [PATCH] tzsetup(8): Remove unnecessary code duplication and clean-up reinstall option bin/164042: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/164042 [PATCH] tzsetup(8): Fix VERBOSE to work with new UTC menu option I have other patches that are waiting on these. -- 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
14 month old regression (how?)
Looking at bin/164192... I'm left wondering to myself... How on Earth did a regression-by-typo introduced in SVN r214735 go 14 months without being noticed? Effected branches include: RELENG_9_0_RELEASE RELENG_9_0 affected for 2 months and 1 week RELENG_9 RELENG_9_0_BP affected for 3 months and 3 weeks MAIN RELENG_9_BP HEAD affected for 14 months and 2 weeks -- 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: 14 month old regression (how?)
-Original Message-
From: Garrett Cooper [mailto:yaneg...@gmail.com]
Sent: Tuesday, January 17, 2012 6:29 PM
To: Devin Teske
Cc: freebsd-hackers@freebsd.org
Subject: Re: 14 month old regression (how?)
On Tue, Jan 17, 2012 at 6:21 PM, Devin Teske devin.te...@fisglobal.com
wrote:
Looking at bin/164192...
I'm left wondering to myself...
How on Earth did a regression-by-typo introduced in SVN r214735 go 14
months without being noticed?
Very carefully. I've seen it happen before on paid products (in fact I've
fixed 15
year old bugs thanks to my colorized editor, and I'm sure someone's going to
find
bugs I've made 1, 5, 10, or 20 years in the future..).. people make mistakes
-- it's a
fact of life.
-Garrett
I found the reason why this typo wasn't noticed.
Appears that ${WPA_DISTDIR}/src/crypto is already being declared one-level-up
in the following file:
src/usr.sbin/wpa/Makefile.inc
Otherwise, buildworld would have failed in src/usr.sbin/wpa/wpa_supplicant
complaining about undefined references while linking wpa_supplicant.
The patch in bin/164192 still stands, but I'm going to amend the PR to explain
why this typo went unnoticed for 14 months.
--
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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Jan 17, 2012, at 7:05 PM, Matthew D. Fuller fulle...@over-yonder.net wrote: On Tue, Jan 17, 2012 at 06:49:02PM -0800 I heard the voice of Julian Elischer, and lo! it spake thus: 5 was not out on a limb for so long because it was a clusterfun, it was out there because it was a rework of how almost everything in the kernel worked. I'm not saying it was a cluster because it was a huge amount of very deep work; it's because that huge amount of very deep work completely gated our next release. Now, sure, changing external circumstances caught us with our pants down, and the tools we were using (like CVS) made it hard to do anything else. But that just means there were good reasons why it happened; doesn't make it less clusterfull :) The two circumstances (giant rework, and long period between major releases) are duals of each other. If we chop off giant piles of stuff to do for FreeBSD-next, it's going to take a very long time. And if we instead just set very long times (Jan 2017 for 10?! Insanity!) for -next, we're going to end up with giant reworks and huge differences. And _both_ faces are very bad. The one means we wait forever for any new work, and the other means that it takes enormous amounts of work as a user to transistion across the barrier. We could adopt a cycle similar to the Linux Kernel... Odd numbered releases are experimental while even numbered releases are stable (ducks for flying fruit) _ 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: [ANN] host-setup 4.0 released
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Eduardo Morras Sent: Wednesday, January 04, 2012 1:32 AM To: freebsd-hackers@freebsd.org Subject: Re: [ANN] host-setup 4.0 released At 18:59 03/01/2012, Garrett Cooper wrote: Other than that, I get lost because there isn't an IPv6 for dummies book (:P) out yet, You have TCP/IP for Dummies 6th Edition, edited on/in 2009. It covers IPv6 too ;) Have you read it? How does it compare to, say, Que or O'Reilly publications? Reason I ask, is that I usually find the * for Dummies books from IDG to be rather lacking. -- 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: [ANN] host-setup 4.0 released
-Original Message- From: Bob Bishop [mailto:r...@gid.co.uk] Sent: Wednesday, January 04, 2012 12:05 AM To: Garrett Cooper Cc: Rick Macklem; freebsd-hackers@freebsd.org; Dave Robison; Devin Teske; Devin Teske; Mohacsi Janos Subject: Re: [ANN] host-setup 4.0 released Hi, On 3 Jan 2012, at 17:59, Garrett Cooper wrote: ... Other than that, I get lost because there isn't an IPv6 for dummies book (:P) out yet [etc] I've found the following to be really useful: Author:Stockebrand, Benedikt. Title: IPv6 in practice : a Unixer's guide to the next generation Internet Published: New York : Springer, 2006. Details on author's site: http://www.benedikt-stockebrand.de/ipv6-in- practice_en.html I've read the colophon and it sounds excellent! I will definitely be picking up a copy of this one. Thanks much to Bob Bishop for dropping this tip. -- 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: [ANN] host-setup 4.0 released
-Original Message- From: Mohacsi Janos [mailto:moha...@niif.hu] Sent: Tuesday, January 03, 2012 3:59 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; Dave Robison; Devin Teske Subject: Re: [ANN] host-setup 4.0 released Hi Devin, I had a look at the code. It is very nice, Thank you. however there are same missing elements: - IPv6 support Open to suggestions. Maybe adding a ipaddr6 below ipaddr in the interface configuration menu. Also, do you happen to know what the RFC number is for IPv6 address format? I need to know all the special features (for example, I know you can specify ::1 for localhost, but can you simply omit octets at-will? e.g., ::ff:12:00::: ?) - VLAN tagging support - creation/deleting How is that done these days? and how might we present it in the user interface? -- Devin Best Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Mon, 2 Jan 2012, Devin Teske wrote: Hi fellow -hackers, I'd like to announce the release of a major new revision (4.0) of my FreeBSD setup utility host-setup. http://druidbsd.sourceforge.net/ Direct Link: http://druidbsd.sourceforge.net/download/host-setup.txt NOTE: Make sure to hit refresh to defeat the cache Major highlights of this version are listed on the druidbsd homepage. For those unfamiliar with my host-setup, it's a manly shell script designed to make it super-easy to configure the following: 1. Timezone 2. Hostname/Domain 3. Network Interface Settings 4. Default Router/Gateway 5. DNS nameservers All from an easy-to-use dialog(1) or Xdialog(1)* interface * Fully compatible and tested -- simply pass `-X' while in a usable X environment -- Devin P.S. Feedback most certainly is welcomed! _ 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: [ANN] host-setup 4.0 released
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Matthew Seaman Sent: Tuesday, January 03, 2012 10:07 AM To: freebsd-hackers@freebsd.org Subject: Re: [ANN] host-setup 4.0 released On 03/01/2012 17:59, Garrett Cooper wrote: 4. Prefixing the IPv6 address with fe80: generally means it's an IPv4 - IPv6 address (IIRC). Nope. That's a link-local address. Any NIC can configure itself with and address using that prefix and a host part generated from the MAC address completely automatically, and thus communicate on any locally attached network. (See RFC 5156 for the gory details.) IPv4 mapped addresses are like this: :::192.0.2.0 (or you can express the 32 bits of the IPv4 address as two colon-separated hex strings in the usual IPv6 idiom.) Out of curiousity, when did the spec change from single-octets to double-octets? I remember early-on seeing IPv6 addresses represented in a form that resembled MAC address specifications. -- 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: [ANN] host-setup 4.0 released
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Matthew Seaman Sent: Tuesday, January 03, 2012 10:01 AM To: freebsd-hackers@freebsd.org Subject: Re: [ANN] host-setup 4.0 released On 03/01/2012 16:52, Rick Macklem wrote: The basics are in RFC4291, but I think that inet_pton(3) knows how to deal with it. (I think :: can be used once to specify the longest # of 16bit fields that are all zeros.) RFC 4291 has a basic description of the textual representation of IPv6 addresses, but it is ambiguous: there are several different ways to present the same address according to the RFC 4291 rules. inet_pton(3) follows RFC 5952 which is a superset of the 4291 rules, only allowing a single, unambiguous representation for each IPv6 number. After inet_pton() has translated it to a binary address, then the macros in sys/netinet6/in6.h can be used to determine if the address is a loopback, etc. While 5952 describes how to correctly present an IPv6 address, there's still lots of important other stuff in 4291. For instance bit 70 in an IPv6 address flags that the address is derived from a number hardwired into the interface -- typically the ethernet MAC address, as is commonly done for SLAAC (StateLess Address Autoconfiguration: RFC 4862, rtsold(8), rtadvd(8)). So an arbitrarily invented address should have that bit set to zero. Bit 71 is also special, indicating manycast vs unicast, and should also be zero for the vast majority of uses. See http://www.infracaninophile.co.uk/articles/hotchpotch.html#rand-.pl for some perl code that operates in this area. Also of interest: RFC 5156 which lists IPv6 address ranges dedicated to special purpose usages, and RFC 4193 which roughly is the IPv6 equivalent to RFC 1918, but somewhat more complicated. You might find https://www.sixxs.net/tools/grh/ula/ relevant too, although actually using that as a registry is pretty pointless. Thank you ALL for such great feedback. We'll have to digest this information in entirety and also start playing with rtsold and rtadvd in the lab. When we do add IPv6 support, it will be robust and solid (we don't like to do things half-arsed). It might be awhile before host-setup supports IPv6 (only because we're not using it ourselves, just yet), but it does sound like something that is rather desired. -- 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
[ANN] host-setup 4.0 released
Hi fellow -hackers, I'd like to announce the release of a major new revision (4.0) of my FreeBSD setup utility host-setup. http://druidbsd.sourceforge.net/ Direct Link: http://druidbsd.sourceforge.net/download/host-setup.txt NOTE: Make sure to hit refresh to defeat the cache Major highlights of this version are listed on the druidbsd homepage. For those unfamiliar with my host-setup, it's a manly shell script designed to make it super-easy to configure the following: 1. Timezone 2. Hostname/Domain 3. Network Interface Settings 4. Default Router/Gateway 5. DNS nameservers All from an easy-to-use dialog(1) or Xdialog(1)* interface * Fully compatible and tested -- simply pass `-X' while in a usable X environment -- Devin P.S. Feedback most certainly is welcomed! _ 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
[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
[PATCH] Add /etc/rc.d/vimage startup script for creating vnet jails
Hi All,
I'd like to submit a patch for review (attached) that adds a new /etc/rc.d
script named vimage.
_
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.
_
vimage_rc.20110827104104.patch
Description: Binary data
Essentially, a hand-tweaked version of /etc/rc.d/jail with added/removed
features.
Here's how we're using it in /etc/rc.conf to successfully start up vimage jails
at boot time:
== BEGIN EXCERPT ==
#
# Vimages
#
vimage_enable=YES # Set to NO to disable starting of any vimages
vimage_list=
vnettest
# Space-separated list of names of vimages
clone_interfaces= # Initialize list of epair/bridge interfaces to create
#
# Global settings for all Vimages
#
vimage_services=sshd
### VIMAGE: vnettest
cloned_interfaces=$cloned_interfaces epair0 bridge0
ifconfig_bridge0=addm fxp0 addm epair0a
vimage_vnettest_rootdir=/usr/jails/vnettest # root directory
vimage_vnettest_hostname=vnettest.jbsd.vicor.com # hostname
vimage_vnettest_devfs_enable=YES # mount devfs
vimage_vnettest_vnets=epair0b # network interfaces
### VIMAGE: {name}
#cloned_interfaces=$cloned_interfaces epair{N} bridge{N}
#ifconfig_bridge{N}=addm {iface} addm epair{N}a
#vimage_{name}_rootdir=/usr/jails/{name} # root directory
#vimage_{name}_hostname={hostname}# hostname
#vimage_{name}_devfs_enable=YES # mount devfs
#vimage_{name}_vnets=epair{N}b# network interfaces
== END EXCERPT ==
--
Cheers,
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
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
[ANNOUNCE] tzdialog(8) -- tzsetup(8) translated from C to sh(1)
Hi fellow hackers, I'd like to share some work that I've been slaving over for the past 7 days. I've converted tzsetup(8) from a C program that relies on dialog(3) into an sh(1) script that relies on either dialog(1) or Xdialog(1). http://druidbsd.sourceforge.net/download/tzdialog.txt or http://druidbsd.sourceforge.net/ The advantages of this are two-fold: 1. Bring tzsetup(8) to the GUI 2. Bring tzsetup(8) to Linux This new script, I'm calling tzdialog(8). Major focal points were: 1. Speed (just as fast as tzsetup(8)) 2. Conciseness (the code is conceptually clean) 3. Closeness to original code (you can find a large amount in-common between the C code and sh(1) code). that is, in addition to the overall goals/reasons: 1. Act as a drop-in replacement for FreeBSD's tzsetup(8). 2. Provide a Graphical User Interface (GUI) via Xdialog(1) -- an X11-enabled drop-in replacement for dialog(1). 3. To bring tzsetup(8) to Linux (replacing tzselect(8)) and other systems that support dialog(1) and/or Xdialog(1). 4. Provide a single interface for both Linux and FreeBSD users without needing to ship two separate binaries. I'm very happy with the results. Whether I'm using tzdialog(8) on a Linux box, FreeBSD box, on the console, or in the GUI (either locally or via X11 forwarding), it's just like I would expect tzsetup(8) to behave (with some added bonuses -- such as the added `-v' flag). Please do let me know what you think. I'm not proposing that we replace tzsetup(8) in the base with this, rather I'm just asking that a few people could try it out and let me know what you think. -- 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
[RELEASE] lastdown(8) -- A utility to show you whom was logged on when a system went down
I've written a new script. It's called lastdown. What it does is pretty simple, but yet oh-so valuable to us for administering large clusters. 1. Use sysctl(8) to get the ``kern.boottime'' MIB 2. Parse the `sec' value from the above 3. Make optional adjustments 4. Pass value to date(1) to format it in CCYYddmmHHMM.SS format 5. Pass formatted date string to last(8)'s `-d' argument to... wait for it... List the users that were on that system during that time. At first, I just wrote this to see if last(8)'s manual was accurate. That is, I wanted to see what exactly it would have to say if I gave it a value. Well, after playing with it -- and then not -- I realized one of the more practical applications of it might be to list the state of the UTMP(5) log from just-before the system booted. Running this on a cluster is fun. You get to see all the people that (pardon my [non-]French, but) got screwed when last the system took a long walk in the desert (looking for it's horse no doubt *chuckles*). I just wanted to clean this up, release it under the BSD License for all, and then sleep on how to implement the next iteration (you'll notice it's internal version in the header states it's at 2.0 -- there was an uglier predecessor). If you head on over to http://druidbsd.sourceforge.net/ you'll see examples where the UTMP(5) log (that's the wtmp file) begins on a date that is after the boottime and you'll have to specific -f /var/log/wtmp.1 for example to query a log that knows about the state of the machine at boot time. I'm going to dream up ways to automatically when I should go back. The code can be had at: http://druidbsd.sourceforge.net/download/lastdown.txt or 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 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: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
On Apr 23, 2011, at 4:42 AM, Thomas Dickey wrote: On Sat, Apr 23, 2011 at 08:54:51AM +0100, Bruce Cran wrote: On Fri, 22 Apr 2011 09:52:44 -0700 Devin Teske dte...@vicor.com wrote: Looks like `--hline' is not supported anymore. Thinking this should either be patched or documented in ERRATA/UPGRADING. I think you mean UPDATING :) perhaps. But reporting bugs is nicer than long discussion threads. I've released a new version of my host-setup utility. Available here: http://druidbsd.sourceforge.net/download/host-setup.txt or here: http://druidbsd.sourceforge.net/ Now at version 3.2, here's the delta: - Added support for FreeBSD-9.x's new dialog(1) (which lacks `--hline' support). - Added support for /usr/ports/x11/Xdialog You can now execute this on the console or in X windows. Default is console, to execute in X windows, execute: host-setup -X -- 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 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 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 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
[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.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 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
-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
-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
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.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
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
-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
-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
-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
[UPDATE] New Boot-Loader Menu -- version 1.1
). 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_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. 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_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). 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. WWW: http://druidbsd.sourceforge.net/ == Once again, you can grab the updated code here: http://druidbsd.sourceforge.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.1.tgz -- 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: [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
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
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 http
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
-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
-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
-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: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
-Original Message- From: Alexander Best [mailto:arun...@freebsd.org] Sent: Thursday, April 28, 2011 12:27 AM To: Devin Teske Cc: 'Bruce Cran'; freebsd-hackers@freebsd.org; freebsd-questi...@freebsd.org; 'Teske, Devin' Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD On Fri Apr 22 11, Devin Teske wrote: -Original Message- From: Bruce Cran [mailto:br...@cran.org.uk] Sent: Friday, April 22, 2011 9:35 AM To: Alexander Best Cc: Devin Teske; freebsd-hackers@freebsd.org; freebsd-questi...@freebsd.org; 'Teske, Devin' Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD On Fri, 22 Apr 2011 15:41:46 + Alexander Best arun...@freebsd.org wrote: FreeBSD 9.0-CURRENT amd64 A new version of dialog was imported a few days ago - maybe something broke? Looks like `--hline' is not supported anymore. Thinking this should either be patched or documented in ERRATA/UPGRADING. what would be the equivalent to --hline in the new dialog(1) package? There are no equivalents to either the `--hline' or `--hfile' options. Compare the 8.2-RELEASE manual to the 9-CURRENT manual: 8.2-RELEASE: http://www.freebsd.org/cgi/man.cgi?query=dialogapropos=0sektion=0manpath=Free BSD+8.2-RELEASEformat=html 9-CURRENT: http://www.freebsd.org/cgi/man.cgi?query=dialogapropos=0sektion=0manpath=Free BSD+9-currentformat=html When comparing the above man-pages, issues include: OLD SYNTAX: --hline line NEW SYNTAX: Not available anymore?! ISSUE: No longer capable of setting string to be displayed at bottom of dialog box (exact opposite of --title). OLD SYNTAX: --hfile file NEW SYNTAX: Not available anymore?! ISSUE: No longer capable of setting a file to be displayed by pressing either ? or F1. OLD SYNTAX: --yesno text height width [yes|no] NEW SYNTAX: --yesno text height width ISSUE: Optional fourth argument to change default selection no longer accepted?! DISCUSS: Without fourth argument to change default selection, is the programmer expected to finagle this by using common-options `--no-label YES' and `--yes-label NO' and change logic to treat NO as YES and vice-versa? OLD SYNTAX: --prgbox command height width NEW SYNTAX: Not available anymore?! ISSUE: No longer capable of displaying output of command in dialog box? DISCUSS: As an alternative, I guess we could output the text to a temporary file and then use --textbox OLD SYNTAX: --ftree file FS text height width menu-height NEW SYNTAX: Not available anymore?! ISSUE: No longer capable of displaying a tree described by the data from `file' (which should contain find(1) output). DISCUSS: There appears to be no analog (this is an informational dialog that takes no user input opposed to --dselect and --fselect which are for taking user input in the new dialog; guess we're just out of luck on these ones). OLD SYNTAX: --tree FS text height width menu-height [ item ] ... NEW SYNTAX: Not available anymore?! ISSUE: No longer capable of displaying a tree described by a series of arguments? DISCUSS: Like --ftree, there appears to be no analog. Don't get me wrong... the new dialog *adds* more options than it takes away (or breaks). However, it's frustrating that backward compatibility is not being retained. On a side-note, I notice that my CentOS 4.7 system is running a dialog that matches syntax exactly with what was imported into RELENG_9 (this is a great thing -- meaning I can write dialog(1) based scripts that are compatible with both Linux and FreeBSD with very little effort). Though I'd still like to see the gaps filled so that we could also run legacy dialog(1) based scripts designed for the [8.x and] older dialog(1). -- Devin -- Bruce Cran _ 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. _ -- a13x _ 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 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
[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: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
-Original Message-
From: Alexander Best [mailto:arun...@freebsd.org]
Sent: Friday, April 22, 2011 7:55 AM
To: Devin Teske
Cc: freebsd-hackers@freebsd.org; freebsd-questi...@freebsd.org; Teske,
Devin
Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for
configuring FreeBSD
On Thu Apr 21 11, Devin Teske wrote:
Hi List Members!
I'm proud to announce the first update to my host-setup utility (a
dialog(1)-based host configurator for FreeBSD). The following changes
have been
made:
- fixed bug where /etc/resolv.conf would be created with 0600
permissions
- fixed bug when switching from one default gateway to NO default
gateway
- fixed typo in the title of netmask prompt and ifconfig options dialog
- fixed bug that prevented entry of netmask if no netmask is configured
You can get the updated version here:
http://druidbsd.sourceforge.net/download/host-setup.txt
otaku% sudo ./host-setup.txt
User cancelled.
otaku% echo $?
1
otaku%
Can you provide me with the output of uname -spr?
It's working fine for me on FreeBSD 8.1-RELEASE i386.
Where you're bombing out is line 2403:
[ $retval -eq 0 ] || die User cancelled.
Functionally, that is testing the return status of dialog(1) for the initial
menu. See if you can execute this (a rough approximation of the initial
menu):
dialog --clear --title foo --hline bar --menu abc 17 55 9 1 a 2 b 3 c 4 d 5
e X x 2 /tmp/dialog.menu.foo
A menu should appear. Select an item and then execute for me:
echo $?
If the above doesn't work, then I suspect that your dialog(1) is not working
properly. I'd then go and try this as a sanity check:
cd /usr/share/examples/dialog
sh menubox
echo $?
The result in both cases (as long as you actually select a menu item) should
be 0.
Also... (just as a sanity check for me) your /bin/sh is not a symlink to
bash is it?
--
Devin
or
http://druidbsd.sourceforge.net/download/host-setup.gz
or
http://druidbsd.sourceforge.net/
For those not familiar with my host-setup(1) utility, it is a 2,500+
line shell
script that utilizes the dialog(1) utility to walk the system
administrator
through setting up their TimeZone, Hostname, Network Interfaces, Default
Gateway, and DNS. Our custom FreeBSD installer sets this script as the
root
login shell, making it very easy for field engineers to quickly get a
system on
the network without having to use the command-line (and without having
to reboot
either). Underneath the hood - behind the system of prompts and dialogs
- this
script manages both the contents of /etc/rc.conf, /etc/resolv.conf, and
others
as well as utilizing ifconfig(8), route(8), and many other tools to
avoid
requiring a reboot, prompting you if you would like to make the new
changes
effective when values are changed from their active settings.
Here's the patch to show the details:
--- host-setup.3_0 2011-02-10 19:14:30.0 -0800
+++ host-setup 2011-04-21 13:38:58.0 -0700
@@ -2,12 +2,12 @@
# -*- tab-width: 4 -*- ;; Emacs
# vi: set tabstop=4 :: Vi/ViM
#
-# Revision: 3.0
+# Revision: 3.1
# Created: September 21st, 2010
-# Last Modified: December 6th, 2010
+# Last Modified: April 21st, 2011
COPYRIGHT
#
-# Devin Teske (c)2006-2010. All Rights Reserved.
+# Devin Teske (c)2006-2011. All Rights Reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
@@ -1353,8 +1353,10 @@ dialog_input_hostname()
# permissions and ownership to match resolv.conf(5) before
# we write it out and mv(1) it into place).
#
- quietly chmod $( stat -f '%#Lp' $RESOLV_CONF )
$tmpfile
- quietly chown $( stat -f '%u:%g' $RESOLV_CONF )
$tmpfile
+ local mode=$( stat -f '%#Lp' $RESOLV_CONF 2 /dev/null )
+ local owner=$( stat -f '%u:%g' $RESOLV_CONF 2 /dev/null
)
+ quietly chmod ${mode:-0644} $tmpfile
+ quietly chown ${owner:-root:wheel} $tmpfile
#
# Operate on resolv.conf(5), replacing only the last
@@ -1646,7 +1648,7 @@ dialog_input_netmask()
#
while :; do
- dialog --title $brand${band:+}${progname:-$0} \
+ dialog --title $brand${brand:+ }${progname:-$0} \
--hline Use numbers, punctuation, TAB or ENTER \
--inputbox $msg 10 50 \
$_netmask \
@@ -1664,7 +1666,7 @@ dialog_input_netmask()
[ $retval -eq $SUCCESS ] || return $retval
# Return success if NULL value was entered
- [ $_netmask ] || return $SUCCESS
dialog(1) changed in RELENG_9 (was RE: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD)
-Original Message- From: Alexander Best [mailto:arun...@freebsd.org] Sent: Friday, April 22, 2011 8:42 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; freebsd-questi...@freebsd.org; 'Teske, Devin' Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD On Fri Apr 22 11, Devin Teske wrote: -Original Message- From: Alexander Best [mailto:arun...@freebsd.org] Sent: Friday, April 22, 2011 7:55 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; freebsd-questi...@freebsd.org; Teske, Devin Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD On Thu Apr 21 11, Devin Teske wrote: Hi List Members! I'm proud to announce the first update to my host-setup utility (a dialog(1)-based host configurator for FreeBSD). The following changes have been made: - fixed bug where /etc/resolv.conf would be created with 0600 permissions - fixed bug when switching from one default gateway to NO default gateway - fixed typo in the title of netmask prompt and ifconfig options dialog - fixed bug that prevented entry of netmask if no netmask is configured You can get the updated version here: http://druidbsd.sourceforge.net/download/host-setup.txt otaku% sudo ./host-setup.txt User cancelled. otaku% echo $? 1 otaku% Can you provide me with the output of uname -spr? FreeBSD 9.0-CURRENT amd64 I haven't yet had a chance to pull that one down and install it yet. Hopefully you can help me out with this one here. It's working fine for me on FreeBSD 8.1-RELEASE i386. Where you're bombing out is line 2403: [ $retval -eq 0 ] || die User cancelled. Functionally, that is testing the return status of dialog(1) for the initial menu. See if you can execute this (a rough approximation of the initial menu): dialog --clear --title foo --hline bar --menu abc 17 55 9 1 a 2 b 3 c 4 d 5 e X x 2 /tmp/dialog.menu.foo doesn't work. :( Bummer! We'll have to fix that. otaku% echo $? 255 otaku% cat /tmp/dialog.menu.foo Error: Unknown option --hline. Use --help to list options. Aha! I think I remember seeing in the list a thread related to swapping out dialog(1) for something new. This must be it. otaku% taku% whereis dialog dialog: /usr/bin/dialog /usr/share/man/en.ISO8859-15/man1/dialog.1.gz /usr/src/gnu/usr.bin/dialog otaku% /usr/bin/dialog cdialog (ComeOn Dialog!) version 1.1-20100428 Copyright 2000-2007,2008 Thomas E. Dickey This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I can't recall as I don't have the thread in front of me, but why was dialog(1) replaced with cdialog? licensing? performance? I guess I could code my script to support this new dialog(1), but... can you see if the below works (I removed the --hline option): dialog --clear --title foo --menu abc 17 55 9 1 a 2 b 3 c 4 d 5 e X x 2 /tmp/dialog.menu.foo If that succeeds, then I can modify my script to not use `--hline' on RELENG_9 and higher (referencing `sysctl -n kern.osreldate` for example). [...] A menu should appear. Select an item and then execute for me: echo $? If the above doesn't work, then I suspect that your dialog(1) is not working properly. I'd then go and try this as a sanity check: cd /usr/share/examples/dialog otaku% cd /usr/share/examples/dialog cd: no such file or directory: /usr/share/examples/dialog Really? I would have thought that the examples in that directory (which are merely shell scripts) would have been recoded for cdialog rather than altogether removed. Maybe there was licensing issues there too. Was there? sh menubox echo $? The result in both cases (as long as you actually select a menu item) should be 0. Also... (just as a sanity check for me) your /bin/sh is not a symlink to bash is it? otaku% file /bin/sh /bin/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.0 (900034), stripped Cool. Though I'm still disappointed that my beloved dialog(1) has gone missing (rather, replaced with something doesn't accept the same arguments and/or options)(which is the problem that we're experiencing here). Is there anybody familiar with the changing-out dialog(1) that can bring me up to speed with reasoning and specifics for RELENG_9? Also, might it be prudent -- before cutting 9_0_RELEASE -- to add the fact that dialog(1) no longer accepts `--hline' to the UPGRADING and/or ERRATA documents? -- Devin -- Devin or http://druidbsd.sourceforge.net/download/host-setup.gz or http://druidbsd.sourceforge.net/ For those not familiar with my host-setup(1) utility, it is a 2,500+ line shell script that utilizes the dialog(1) utility
RE: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
-Original Message- From: Bruce Cran [mailto:br...@cran.org.uk] Sent: Friday, April 22, 2011 9:35 AM To: Alexander Best Cc: Devin Teske; freebsd-hackers@freebsd.org; freebsd-questi...@freebsd.org; 'Teske, Devin' Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD On Fri, 22 Apr 2011 15:41:46 + Alexander Best arun...@freebsd.org wrote: FreeBSD 9.0-CURRENT amd64 A new version of dialog was imported a few days ago - maybe something broke? Looks like `--hline' is not supported anymore. Thinking this should either be patched or documented in ERRATA/UPGRADING. -- Bruce Cran _ 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
