Re: ACPI panic on boot with new Lua loader and other minor issues

[Devin Teske]

> On Feb 19, 2018, at 4:32 PM, Warner Losh <i...@bsdimp.com> wrote:
> 
> 
> 
>> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske <dte...@freebsd.org> wrote:
>> 
>> 
>> > On Feb 19, 2018, at 2:21 PM, Kyle Evans <kev...@freebsd.org> wrote:
>> >
>> > It seems that the Forth loader might be doing something sneaky and
>> > replacing the standard common "boot" with a Forth boot that handles
>> > this a lot better. CC'ing dteske@ so they can confirm.
>> 
>> I can indeed confirm this as fact.
>> 
>> Not able to help much because I am driving cross-country (San Francisco to 
>> Orlando) right now with the spouse and dog.
>> 
>> We get back March 3rd, but I will be checking-in from time to time for 
>> sporadic responses during downtime.
> 
> The command in loader.4th is defined as:
> 
> : boot
>   0= if ( interpreted ) get_arguments then
> 
>   \ Unload only if a path was passed
>   dup if
> >r over r> swap
> c@ [char] - <> if
>   0 1 unload drop
> else
>   s" kernelname" getenv? if ( a kernel has been loaded )
> try-menu-unset
> bootmsg 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup if exit then
>   try-menu-unset
>   bootmsg 0 1 boot exit
> then
>   else
> s" kernelname" getenv? if ( a kernel has been loaded )
>   try-menu-unset
>   bootmsg 1 boot exit
> then
> load_kernel_and_modules
> ?dup if exit then
> try-menu-unset
> bootmsg 0 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup 0= if bootmsg 0 1 boot then
> ; 
> 
> The thing to know here is when you see 'boot' as part of above script, it's 
> calling the 'boot' cli command, not itself recursively.
> 

What is actually going on is that when the “boot” function is compiled, the 
reference to “boot” inside it is to the already-existing word defined 
previously. Forth allows you to have multiply-defined names. The “boot” command 
inside the “boot” function is replaced with the address of previous boot during 
function compilation because the function is m not defined and given an address 
in the dictionary until it is completed (last line compiled).
— 
Devin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Devin Teske]

> On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
> 
> It seems that the Forth loader might be doing something sneaky and
> replacing the standard common "boot" with a Forth boot that handles
> this a lot better. CC'ing dteske@ so they can confirm.

I can indeed confirm this as fact.

Not able to help much because I am driving cross-country (San Francisco to 
Orlando) right now with the spouse and dog.

We get back March 3rd, but I will be checking-in from time to time for sporadic 
responses during downtime.
— 
Cheers,
Devin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: I/O semantics of pipe and FIFO.

[Devin Teske]

Problem we had found was:

Executing dd with a closed stdout and stderr would cause the summary messages 
printed at the end to go into the destination output file.

For example,

dd if=/dev/zero of=/tmp/foo bs=1m count=1

Works fine, but the following:

dd if=/dev/zero of=/tmp/foo bs=1m count=1 >&- 2>&-

Will cause the summary statistics of dd to appear in /tmp/foo instead of on the 
console.

The issue is that the summary statistics are send to fd1, which if you close 
down stdout and stdin, fd1 is actually the output file since it got the lowest 
file descriptor available when open(2) was called on the output file.

This was never fixed because it was deemed “silly developer, don’t close stdout 
and stderr before invoking dd”.

The argument has been made by Jilles T. that it is generally a bad idea to 
close down any of the standard file descriptors because it cannot be predicted 
how a particular UNIX utility will react (e.g., in the case of dd, causing a 
simple printf(3) to go to an unexpected location).
— 
Devin


> On Mar 4, 2017, at 8:12 PM, Alfred Perlstein  wrote:
> 
> Devin and I found this when we worked together.  I think it was due to some 
> situation in dd(1) where short reads would exit pre-maturely, however I may 
> be mis-remembering.  Devin, do you recall the specifics?
> 
> 
> On 3/4/17 7:44 PM, Julian Elischer wrote:
>> 
>> an interesting point to discuss? is our behaviour in this test right?
>>   from: "austin-group mailng list (posix standard discussion)"
>> 
>> -- rest of email is quoted ---
>> On 5/3/17 5:48 am, Stephane Chazelas wrote:
>> 
>> 2017-03-04 13:14:08 +, Danny Niu:
>>> Hi all.
>>> 
>>> I couldn't remember where I saw it saying, that when reading
>>> from a pipe or a FIFO, the read syscall returns the content of
>>> at most one write call. It's a bit similar to the
>>> message-nondiscard semantics of dear old STREAM.
>>> 
>>> Currently, I'm reading through the text to find out a bit
>>> more, and I appreciate a bit of pointer on this.
>> [...]
>> 
>> (echo x; echo y) | (sleep 1; dd count=1 2> /dev/null)
>> 
>> outputs both x and y in all of Linux, FreeBSD and Solaris in my
>> tests.
>> 
>> That a read wouldn't read what's currently in the pipe would be
>> quite surprising.
>> 
>> I also wouldn't expect pipes to store the writes as individual
>> separate message but use one buffer.
>> 
>> In:
>> 
>> (
>>  dd bs=4 count=1 if=/dev/zero 2> /dev/null
>>  echo first through >&2
>>  dd bs=4 count=1 if=/dev/zero 2> /dev/null
>>  echo second through >&2
>> ) | (sleep 1; dd bs=10 count=1 2> /dev/null) | wc -c
>> 
>> That is where the second write blocks because the pipe is full,
>> the reading dd still reads both writes in Linux and Solaris in
>> my tests (on Solaris (10 on amd64 at least), reduce to 2
>> instead of 4 or both writes would block).
>> 
>> On FreeBSD, I get only the first write (using 8000 followed by
>> 1 for instance).
>> 
>> FreeBSD is also the only one of the three where
>> 
>> dd bs=100 count=1 if=/dev/zero | dd bs=100 count=1 | wc -c
>> 
>> Doesn't output 100. The others schedule both processes back
>> and forth during their write() and read() system call while the
>> pipe is being filled and emptied several times.
>> 
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: revisiting tunables under Safe Mode menu option

[Devin Teske]

Found this old mail between avg@ and myself and just had to laugh

The boot loader is so much more levels of awesome now, but I had forgotten how 
much thought I had put into it.

Awesome sauce! ;D
-- 
Cheers,
Devin


> On Mar 1, 2012, at 9:06 AM, Andriy Gapon <a...@freebsd.org> wrote:
> 
> on 01/03/2012 18:52 Devin Teske said the following:
>> 
>> 
>>> -Original Message-
>>> From: Andriy Gapon [mailto:a...@freebsd.org]
>>> Sent: Thursday, March 01, 2012 12:39 AM
>>> To: Devin Teske
>>> Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske
>>> Subject: Re: revisiting tunables under Safe Mode menu option
>>> 
>>> on 01/03/2012 03:34 Devin Teske said the following:
>>>> 
>>>> +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe
>>>> Mode knows about ACPI but only acts on it when being enabled).
>>> 
>>> Can you explain why?
>>> +1 for having both menu items and each doing its own thing without any
>>> entanglement :-)
>>> 
>> 
>> First, I realize that this may sound entirely *dumb*, but here-goes:
>> 
>> In transitioning from an old release (sans-menu; 4.11 for example) to a newer
>> release (with menu; 6.x for example), one of the first thing that is noticed 
>> is
>> "Safe Mode".
>> 
>> I know that when I first saw this, I scratched my head and wondered what it 
>> did
>> and what it might be useful for. To this day, I still have never used it.
>> 
>> When I created the new menu for 9.x/higher, I had to rewrite that portion of 
>> the
>> code and eventually learned what Safe Mode does when used. Still can't say 
>> that
>> I've ever used it, however, at the point that I saw that it disabled ACPI 
>> among
>> other things, that it is more of a blanket option for anything and everything
>> that might be useful if/when you're having problems (*cough* still can't say
>> that I've ever used it, as when I have problems I'm usually slogging through 
>> the
>> kernel code, not relying on safe mode to fix some problem).
>> 
>> That being said, I felt that it was a huge improvement to the UI to have the
>> Safe Mode option divulge a little bit of its secret by visibly diddling the 
>> ACPI
>> menu item (giving a clue to people that *haven't* read the code that this 
>> option
>> is indeed not independent but instead conglomerate in-nature).
>> 
>> Indeed, I've watched field engineers when exploring the menu options and 
>> their
>> eyes light-up when they see that "Safe Mode" toggles ACPI off when enabled.
>> Extrapolating on their surprise, they appear to have an "Aha!"-moment as
>> previously... this field engineer had no idea what on God's green Earth what
>> "Safe Mode" did (or didn't) as he didn't know about "kenv" and certainly
>> couldn't read "Forth". At that point, he may not have had a full 
>> understanding
>> of all the options that Safe Mode  diddled, but at that point he at least 
>> knew
>> that Safe Mode is a multi-option that does many things -- which is more than
>> 6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe Mode
>> option is selected and does nothing to explain what it is that Safe Mode is
>> doing (which would in-turn properly calibrate the user's expectations).
>> 
>> Making the menu items completely independent would be take away the (however
>> slight) above value-add that was brought in by entwining these two 
>> menu-items.
>> I'm not saying that this would be a grave travesty, but would in-fact be a
>> value-loss.
> 
> Devin,
> 
> you did a great job with boot menu enhancement in general and in this area in
> particular.  You greatly improved usability while preserving the historic 
> behavior
> and put a lot of work and creativity into that.  Thank you!
> 
> But the argument is that the historic behavior is no longer useful.  I see 
> that
> removing the historic behavior also kills a little bit of your code (and a 
> little
> bit of magic).  That's true, that's a loss in the code.
> 
> But I still believe that it would be an improvement from the point of view of
> usability end-users.
> 
> Having a whole sub-menu where multiple parameters could be tweaked 
> individually
> would be even greater improvement.  But that's not as easy to do.
> 
> -- 
> Andriy Gapon

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

[Devin Teske]

> On Aug 8, 2016, at 12:39 PM, Bernard Spil <bern...@bachfreund.nl> wrote:
> 
> Hi Devin,
> 
> This resource documents the choices pretty well I think
> https://stribika.github.io/2015/01/04/secure-secure-shell.html 
> <https://stribika.github.io/2015/01/04/secure-secure-shell.html>
> Author has made some modifications up to Jan 2016
> https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md
>  
> <https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md>
> 
> The short answer then is ed25519 or rsa4096, disable both dsa and ecdsa.
> 
> Even 6.5p1 shipped with 9.3 supports ed25519.
> 
> Cheers,
> 
> Bernard.
> 

Thanks for confirming, Bernard!
-- 
Cheers,
Devin


> On 2016-08-08 19:56, Devin Teske wrote:
>> Which would you use?
>> ECDSA?
>> https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 
>> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography>
>> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 
>> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography>>
>> "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover
>> operation", cryptography experts have also expressed concern over the
>> security of the NIST recommended elliptic curves,[31]
>> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#cite_note-31 
>> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#cite_note-31>>
>> suggesting a return to encryption based on non-elliptic-curve groups.
>> ""
>> Or perhaps RSA? (as des@ recommends)
>> (not necessarily to Glen but anyone that wants to answer)
>> --
>> Devin
>>> On Aug 4, 2016, at 6:59 PM, Glen Barber <g...@freebsd.org> wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH,
>>> and will be deprecated effective 11.0-RELEASE (and preceeding RCs).
>>> Please see r303716 for details on the relevant commit, but upstream no
>>> longer considers them secure.  Please replace DSA keys with ECDSA or RSA
>>> keys as soon as possible, otherwise there will be issues when upgrading
>>> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the
>>> 11.0-RELEASE build.
>>> Glen
>>> On behalf of:   re@ and secteam@
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2
>>> iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb
>>> kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK
>>> rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl
>>> GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR
>>> TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u
>>> c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs
>>> 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c
>>> QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8
>>> 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r
>>> mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL
>>> kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx
>>> bLbbH2fh5bxDmDXDMdCF
>>> =LLtP
>>> -END PGP SIGNATURE-
>>> ___
>>> freebsd-annou...@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-announce
>>> To unsubscribe, send any mail to "freebsd-announce-unsubscr...@freebsd.org"
>> ___
>> freebsd-sta...@freebsd.org <mailto:freebsd-sta...@freebsd.org> mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable 
>> <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org 
>> <mailto:freebsd-stable-unsubscr...@freebsd.org>"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

[Devin Teske]

Which would you use?

ECDSA?

https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 


"" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover 
operation", cryptography experts have also expressed concern over the security 
of the NIST recommended elliptic curves,[31] 
 
suggesting a return to encryption based on non-elliptic-curve groups. ""

Or perhaps RSA? (as des@ recommends)

(not necessarily to Glen but anyone that wants to answer)
-- 
Devin


> On Aug 4, 2016, at 6:59 PM, Glen Barber  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH,
> and will be deprecated effective 11.0-RELEASE (and preceeding RCs).
> 
> Please see r303716 for details on the relevant commit, but upstream no
> longer considers them secure.  Please replace DSA keys with ECDSA or RSA
> keys as soon as possible, otherwise there will be issues when upgrading
> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the
> 11.0-RELEASE build.
> 
> Glen
> On behalf of: re@ and secteam@
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb
> kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK
> rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl
> GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR
> TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u
> c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs
> 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c
> QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8
> 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r
> mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL
> kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx
> bLbbH2fh5bxDmDXDMdCF
> =LLtP
> -END PGP SIGNATURE-
> ___
> freebsd-annou...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-announce
> To unsubscribe, send any mail to "freebsd-announce-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 11.0-BETA4 Now Available

[Devin Teske]

> On Aug 8, 2016, at 8:02 AM, Lars Engels  wrote:
> 
> On Mon, Aug 08, 2016 at 02:44:05PM +, Glen Barber wrote:
>> On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote:
>>> On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:
 -BEGIN PGP SIGNED MESSAGE-
>>> 
 o The new system hardening options have been fixed to avoid overwriting
  other options selected during install time.
>>> 
>>> Can those options also get added to "bsdconfig"?
>> 
>> You would have to ask the bsdconfig maintainer(s).
>> 
> 
> Cc'ing dteske.
> 

What aspects of bsdconfig need updating?
-- 
Devin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Error: stack underflow

[Devin Teske]

> On Apr 20, 2016, at 1:24 AM, Andriy Gapon  wrote:
> 
> 
> I see this message "Error: stack underflow" when a loader menu is presented.
> It seems that it comes from ficl.  This is on a quite recent (< 2 weeks) head.
> How can I debug this problem?
> 
> I have one local modification to forth files, but I'm not sure if the problem 
> is
> caused by it or by something in my boot configuration files.
> 
> diff --git a/sys/boot/forth/menu-commands.4th 
> b/sys/boot/forth/menu-commands.4th
> index 9adf30a46b661..813cbf12e9655 100644
> --- a/sys/boot/forth/menu-commands.4th
> +++ b/sys/boot/forth/menu-commands.4th
> @@ -243,6 +243,21 @@ also menu-namespace also menu-command-helpers
>   TRUE \ loop menu again
> ;
> 
> +: toggle_gui ( N -- N TRUE )
> + toggle_menuitem
> + menu-redraw
> +
> + \ Now we're going to make the change effective
> +
> + dup toggle_stateN @ 0= if
> + s" inhibit_gui" unsetenv
> + else
> + s" set inhibit_gui=1" evaluate
> + then
> +
> + TRUE \ loop menu again
> +;
> +
> \
> \ Escape to Prompt
> \
> diff --git a/sys/boot/forth/menu.rc b/sys/boot/forth/menu.rc
> index 3c7de7138b8ad..ddeccc9679fea 100644
> --- a/sys/boot/forth/menu.rc
> +++ b/sys/boot/forth/menu.rc
> @@ -126,6 +126,13 @@ set optionsmenu_keycode[6]=118
> set optionsansi_caption[6]="^[1mV^[merbose. ^[34;1mOff^[m"
> set optionstoggled_ansi[6]="^[1mV^[merbose. ^[32;7mOn^[m"
> 
> +set optionsmenu_caption[7]="Inhibit [G]UI. off"
> +set optionstoggled_text[7]="Inhibit [G]UI. On"
> +set optionsmenu_command[7]="toggle_gui"
> +set optionsmenu_keycode[7]=103
> +set optionsansi_caption[7]="Inhibit GUI. Off"
> +set optionstoggled_ansi[7]="Inhibit GUI. On"
> +
> \
> \ BOOT ENVIRONMENT MENU
> \
> 

I'll look into this. Thanks for bring it to our/my attention.
-- 
Cheers,
Devin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Does anyone use kgzip / kgzldr?

[Devin Teske]

> On Nov 23, 2015, at 6:35 PM, Ed Maste  wrote:
> 
> Hiya, I wanted to forward this to you in case you're not reading -current at 
> the moment so you don't miss it. A PR of yours from 2013 is the only recent 
> evidence I found of someone using kgzldr :-)
> 

Not on -current -- didn't get the original (thanks for the forward).

> 
> -- Forwarded message --
> From: Ed Maste >
> Date: 23 November 2015 at 20:25
> Subject: Does anyone use kgzip / kgzldr?
> To: FreeBSD Current  >
> 
> 
> I disconnected kgzldr from the build in r291113 because I thought
> kgzip was already disconnected. As it happens kgzip was disconnected
> only from the release builds, in r281658.
> 

nods.


> kgzip / kgzldr only works on i386, and for quite some time the
> recommended way to use a compressed kernel has been via loader(8). Is
> there a compelling use case for kgzldr and loader(8)-less i386 boot?

Custom media used by some enterprises. It certainly is not the norm, I'll say,
but it does work. Being "i386 only" isn't of much concern for, say, my previous
employer whereat I had modified the installer (sysinstall) to more-aggressively
sandbox itself, allowing it to do things like boot/execute i386 but lay down an
amd64 release (so long as a little bit of CPUID x86 ASM yielded a positive hit
on CPU LongMode).


> I'll reconnect kgzldr (on i386 only) if it's useful, or otherwise
> continue with the removal.
> 

I'd like to see it reconnected. I think that's what
we had discussed last.
-- 
Cheers,
Devin


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Nothing can boot anymore - video issues

[Devin Teske]

 On Apr 8, 2015, at 8:18 AM, Shawn Webb shawn.w...@hardenedbsd.org wrote:
 
 On Mon, 2015-04-06 at 16:55 -0700, Devin Teske wrote:
 
 On Apr 6, 2015, at 1:35 PM, Shawn Webb shawn.w...@hardenedbsd.org
 wrote:
 
 On Mon, 2015-04-06 at 13:59 -0400, Shawn Webb wrote:
 On Sun, 2015-04-05 at 12:07 -0700, Rui Paulo wrote:
 On Apr 5, 2015, at 09:11, Shawn Webb
 shawn.w...@hardenedbsd.org wrote:
 
 So I just updated my laptop and desktop to a recent HEAD. Both
 machines
 boot using gptzfsboot. The boot spinner shows, then when it's
 supposed to
 transition to the Beastie logo screen, the monitor funks out.
 Booting never
 finishes. Below is a link to a picture of my laptop.
 
 http://imgur.com/l3mLDBX
 
 Try reverting the Forth changes.  That's all that comes to mind.
 
 --
 Rui Paulo
 
 I'm going through commit-by-commit from April 3rd to March 31st,
 which
 will take a big chunk of time. It's really weird that no one else
 has
 reported this since even my VirtualBox VMs have this same issue.
 
 Thanks,
 
 Shawn
 
 I've figured out the commit that caused the breakage. Looks like the
 boot Forth changes are pretty bad. The commit that caused the
 breakage,
 as far as I can tell is, r280974. Reverting that and the two commits
 above that revision regarding sys/boot/forth allowed me to boot
 again.
 
 Now the boot screen looks like this: http://imgur.com/I9SVHfT
 
 I can now boot, but as you see, the boot screen's messed up.
 
 
 
 
 Why the screen looks that way (no brand and no logo):
 You were caught in a small window of broken-ness.
 
 
 Window was between:
 https://svnweb.freebsd.org/base?view=revisionrevision=280933
 and
 https://svnweb.freebsd.org/base?view=revisionrevision=281002
 
 
 A window of approximately 2 days.
 
 
 As for why the screen got wonky … well… your comp and my
 comp don’t agree on ANSI sequences. I’ve reverted the offending
 changes so that we may once-again agree on ANSI codes. ;D
 
 It now appears that the problem was specific to HardenedBSD: we had a
 custom loader_version setting in sys/boot/forth/loader.conf. I'm unsure
 which commit caused the breakage, but now having a custom loader_version
 will break booting.
 

Thanks for narrowing it further. Let me do some additional testing and
I’ll report back what I find.
— 
Devin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFC] Add GELI Passphrase: prompt to boot loader

[Devin Teske]

 On Apr 6, 2015, at 10:52 AM, Eric van Gyzen vangy...@freebsd.org wrote:
 
 On 04/06/2015 13:39, Devin Teske wrote:
 
 On Apr 6, 2015, at 10:24 AM, Eric van Gyzen e...@vangyzen.net wrote:
 
 On 04/06/2015 12:58, Devin Teske wrote:
 Hi -current,
 
 I have a pending enhancement to the boot loader that Colin P. and I
 have been working on together.
 
 URL: https://reviews.freebsd.org/D2105 https://reviews.freebsd.org/D2105
 
 The nature of the patch is to cause the boot loader to prompt for the
 GELI passphrase and then pass that on (through a kenv(1) variable)
 to Colin’s code in geom_eli.ko where it will be:
 
 (a) picked up for-use as the initial passphrase attempt(s)
 (b) zeroed after being picked-up so “kenv kern.geom.eli.passphrase”
 returns nothing
 
 NB: Actually, “kenv kern.geom.eli.passphrase” generates the error
 “kenv: unable to get kern.geom.eli.passphrase”
 
 The problem that I (we) need help in solving is:
 
 If the geom_eli.ko module doesn’t get loaded, then the variable
 (kern.geom.eli.passphrase) is not zeroed.
 
 While I do think that this is of minimal concern (not loading the GELI
 module means you won’t be able to get past the mountroot prompt in
 the case where GELI is required to boot), I discussed with Colin and
 I think we are in consensus that the resetting of the variable should
 perhaps be moved to another section of the kernel to prevent leakage
 of this sensitive information being passed through kenv(1) variable(s).
 
 Issue for me is, I’m not sure where the best place to move this to.
 Here’s the code that needs to be moved (Lines 108-109 of g_eli.c):
 
 https://svnweb.freebsd.org/base?view=revisionrevision=273489 
 https://svnweb.freebsd.org/base?view=revisionrevision=273489
 
 
 108 
 https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?annotate=273489pathrev=273489#l108
  /* Wipe the passphrase from the 
 environment. */
 109 
 https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?annotate=273489pathrev=273489#l109
  kern_unsetenv(kern.geom.eli.passphrase);
 
 Need to move that preferably to some place in the kernel that is NOT
 optional in the compilation process. Suggestions?
 
 How about putting it right after a successful mount of the root file 
 system? 
 (I've never used GELI, so this could be as right out as five.)
 
 
 I think that’s an excellent idea.
 
 /me rummages through source
 
 I’m thinking that the best place might be where we deal with the registered
 event handler for mountroot.
 
 
 One place that I crawled upon that looks particularly sexy is in start_init()
 of sys/kern/init_main.c:
 
 ### BEGIN SNIPPET ###
 /*
 * Start the initial user process; try exec’ing each pathname in init_path.
 * The program is invoked with one argument containing the boot flags.
 */
 static void
 start_init(void *dummy)
 {
  vm_offset_t addr;
  struct execve_args args;
  int options, error;
  char *var, *path, *next, *s;
  char *ucp, **uap, *arg0, *arg1;
  struct thread *td;
  struct proc *p;
 
  mtx_lock(Giant);
 
  GIANT_REQUIRED;
 
  td = furthered;
  p = td-td_proc;
 
  vfs_mountroot();
 
  ### RFC for code placement ###
  /* XXX Put reset of kern.geom.eli.passphrase here XXX */
  ##
 
  /*
   * Need just enough stack to hold the faked-up “execve()” arguments.
   */
  // snip rest //
 ### END SNIPPET ###
 
 Or can you think of a better place?
 
 That looks good to me, although I'm no expert in this area, so you might wait
 for more opinions.
 

Kk. In the meantime, I’ve updated the patch in D2105 to reflect the new 
potential
outcome. Worth noting, that I left the kern_unsetenv() call in 
sys/geom/eli/geom_eli.c
in-tact (didn’t see any harm in calling kern_unsetenv() on the same variable 
twice; no
real conerns of removing it, just didn’t see any harm in leaving it).

Would like feedback on phabricator.
https://reviews.freebsd.org/D2105 https://reviews.freebsd.org/D2105
— 
Cheers,
Devin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFC] Add GELI Passphrase: prompt to boot loader

[Devin Teske]

 On Apr 6, 2015, at 10:24 AM, Eric van Gyzen e...@vangyzen.net wrote:
 
 On 04/06/2015 12:58, Devin Teske wrote:
 Hi -current,
 
 I have a pending enhancement to the boot loader that Colin P. and I
 have been working on together.
 
 URL: https://reviews.freebsd.org/D2105 https://reviews.freebsd.org/D2105
 
 The nature of the patch is to cause the boot loader to prompt for the
 GELI passphrase and then pass that on (through a kenv(1) variable)
 to Colin’s code in geom_eli.ko where it will be:
 
 (a) picked up for-use as the initial passphrase attempt(s)
 (b) zeroed after being picked-up so “kenv kern.geom.eli.passphrase”
 returns nothing
 
 NB: Actually, “kenv kern.geom.eli.passphrase” generates the error
 “kenv: unable to get kern.geom.eli.passphrase”
 
 The problem that I (we) need help in solving is:
 
 If the geom_eli.ko module doesn’t get loaded, then the variable
 (kern.geom.eli.passphrase) is not zeroed.
 
 While I do think that this is of minimal concern (not loading the GELI
 module means you won’t be able to get past the mountroot prompt in
 the case where GELI is required to boot), I discussed with Colin and
 I think we are in consensus that the resetting of the variable should
 perhaps be moved to another section of the kernel to prevent leakage
 of this sensitive information being passed through kenv(1) variable(s).
 
 Issue for me is, I’m not sure where the best place to move this to.
 Here’s the code that needs to be moved (Lines 108-109 of g_eli.c):
 
 https://svnweb.freebsd.org/base?view=revisionrevision=273489 
 https://svnweb.freebsd.org/base?view=revisionrevision=273489
 
 
 108 
 https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?annotate=273489pathrev=273489#l108
/* Wipe the passphrase from the environment. */
 109 
 https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?annotate=273489pathrev=273489#l109
kern_unsetenv(kern.geom.eli.passphrase);
 
 Need to move that preferably to some place in the kernel that is NOT
 optional in the compilation process. Suggestions?
 
 How about putting it right after a successful mount of the root file system? 
 (I've never used GELI, so this could be as right out as five.)
 

I think that’s an excellent idea.

/me rummages through source

I’m thinking that the best place might be where we deal with the registered
event handler for mountroot.


One place that I crawled upon that looks particularly sexy is in start_init()
of sys/kern/init_main.c:

### BEGIN SNIPPET ###
/*
 * Start the initial user process; try exec’ing each pathname in init_path.
 * The program is invoked with one argument containing the boot flags.
 */
static void
start_init(void *dummy)
{
vm_offset_t addr;
struct execve_args args;
int options, error;
char *var, *path, *next, *s;
char *ucp, **uap, *arg0, *arg1;
struct thread *td;
struct proc *p;

mtx_lock(Giant);

GIANT_REQUIRED;

td = furthered;
p = td-td_proc;

vfs_mountroot();

### RFC for code placement ###
/* XXX Put reset of kern.geom.eli.passphrase here XXX */
##

/*
 * Need just enough stack to hold the faked-up “execve()” arguments.
 */
// snip rest //
### END SNIPPET ###

Or can you think of a better place?
— 
Devin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Nothing can boot anymore - video issues

[Devin Teske]

 On Apr 6, 2015, at 1:35 PM, Shawn Webb shawn.w...@hardenedbsd.org wrote:
 
 On Mon, 2015-04-06 at 13:59 -0400, Shawn Webb wrote:
 On Sun, 2015-04-05 at 12:07 -0700, Rui Paulo wrote:
 On Apr 5, 2015, at 09:11, Shawn Webb shawn.w...@hardenedbsd.org wrote:
 
 So I just updated my laptop and desktop to a recent HEAD. Both machines
 boot using gptzfsboot. The boot spinner shows, then when it's supposed to
 transition to the Beastie logo screen, the monitor funks out. Booting never
 finishes. Below is a link to a picture of my laptop.
 
 http://imgur.com/l3mLDBX
 
 Try reverting the Forth changes.  That's all that comes to mind.
 
 --
 Rui Paulo
 
 I'm going through commit-by-commit from April 3rd to March 31st, which
 will take a big chunk of time. It's really weird that no one else has
 reported this since even my VirtualBox VMs have this same issue.
 
 Thanks,
 
 Shawn
 
 I've figured out the commit that caused the breakage. Looks like the
 boot Forth changes are pretty bad. The commit that caused the breakage,
 as far as I can tell is, r280974. Reverting that and the two commits
 above that revision regarding sys/boot/forth allowed me to boot again.
 
 Now the boot screen looks like this: http://imgur.com/I9SVHfT
 
 I can now boot, but as you see, the boot screen's messed up.
 

Why the screen looks that way (no brand and no logo):
You were caught in a small window of broken-ness.

Window was between:
https://svnweb.freebsd.org/base?view=revisionrevision=280933 
https://svnweb.freebsd.org/base?view=revisionrevision=280933
and
https://svnweb.freebsd.org/base?view=revisionrevision=281002 
https://svnweb.freebsd.org/base?view=revisionrevision=281002

A window of approximately 2 days.

As for why the screen got wonky … well… your comp and my
comp don’t agree on ANSI sequences. I’ve reverted the offending
changes so that we may once-again agree on ANSI codes. ;D
— 
Cheers,
Devin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[RFC] Add GELI Passphrase: prompt to boot loader

[Devin Teske]

Hi -current,

I have a pending enhancement to the boot loader that Colin P. and I
have been working on together.

URL: https://reviews.freebsd.org/D2105 https://reviews.freebsd.org/D2105

The nature of the patch is to cause the boot loader to prompt for the
GELI passphrase and then pass that on (through a kenv(1) variable)
to Colin’s code in geom_eli.ko where it will be:

(a) picked up for-use as the initial passphrase attempt(s)
(b) zeroed after being picked-up so “kenv kern.geom.eli.passphrase”
returns nothing

NB: Actually, “kenv kern.geom.eli.passphrase” generates the error
“kenv: unable to get kern.geom.eli.passphrase”

The problem that I (we) need help in solving is:

If the geom_eli.ko module doesn’t get loaded, then the variable
(kern.geom.eli.passphrase) is not zeroed.

While I do think that this is of minimal concern (not loading the GELI
module means you won’t be able to get past the mountroot prompt in
the case where GELI is required to boot), I discussed with Colin and
I think we are in consensus that the resetting of the variable should
perhaps be moved to another section of the kernel to prevent leakage
of this sensitive information being passed through kenv(1) variable(s).

Issue for me is, I’m not sure where the best place to move this to.
Here’s the code that needs to be moved (Lines 108-109 of g_eli.c):

https://svnweb.freebsd.org/base?view=revisionrevision=273489 
https://svnweb.freebsd.org/base?view=revisionrevision=273489


108 
https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?annotate=273489pathrev=273489#l108
  /* Wipe the passphrase from the environment. */
109 
https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?annotate=273489pathrev=273489#l109
  kern_unsetenv(kern.geom.eli.passphrase);

Need to move that preferably to some place in the kernel that is NOT
optional in the compilation process. Suggestions?
— 
Cheers,
Devin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Phabricator -- can't update review

[Devin Teske]

 On Mar 31, 2015, at 7:56 PM, Devin Teske dte...@freebsd.org wrote:
 
 
 On Mar 31, 2015, at 7:39 PM, Devin Teske dte...@freebsd.org wrote:
 
 Hi,
 
 I’ve been beating my head on the below issue for an hour now.
 I’m getting frustrated and don’t understand what it is trying to say.
 
 head $ arc diff —update D2105
 Exception
 Field “revisionID” occurs twice in commit message!
 
 
 So I go and look at the commit message. I think it is confused.
 
 I am at an impasse. I’m starting to consider closing D2105 and
 creating a new entry ;(
 
 Trace available upon request, but it’s pretty boring stuff. Could
 use some help here.
 
 Full trace here:
 http://pastebin.com/NzBvDruM http://pastebin.com/NzBvDruM
Eitan found it.

I needed to remove Differential Review:” line from my commit message.
What was non-obvious was that — when using SVN — you can’t see that
this line is already being added by the arc template (iirc from Eitan).

Removing the Differential Review line from the commit message makes it
appear as the line is no longer there (using svn; using hg or git you can
see that it is appended to the end of the summary).

Just need to take it on Faith that it’s there even if not displayed (you’ll get
a warning if it’s not there, so no harm no fowl).

All is good now.
Thanks again Eitan!
— 
Devin


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Phabricator -- can't update review

[Devin Teske]

 On Mar 31, 2015, at 7:39 PM, Devin Teske dte...@freebsd.org wrote:
 
 Hi,
 
 I’ve been beating my head on the below issue for an hour now.
 I’m getting frustrated and don’t understand what it is trying to say.
 
 head $ arc diff —update D2105
 Exception
 Field “revisionID” occurs twice in commit message!
 
 
 So I go and look at the commit message. I think it is confused.
 
 I am at an impasse. I’m starting to consider closing D2105 and
 creating a new entry ;(
 
 Trace available upon request, but it’s pretty boring stuff. Could
 use some help here.

Full trace here:
http://pastebin.com/NzBvDruM

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Phabricator -- can't update review

[Devin Teske]

Hi,

I’ve been beating my head on the below issue for an hour now.
I’m getting frustrated and don’t understand what it is trying to say.

head $ arc diff —update D2105
Exception
Field “revisionID” occurs twice in commit message!


So I go and look at the commit message. I think it is confused.

I am at an impasse. I’m starting to consider closing D2105 and
creating a new entry ;(

Trace available upon request, but it’s pretty boring stuff. Could
use some help here.
— 
Thanks in advance,
Devin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: bsdinstall and current (possible stable) snapshots

[Devin Teske]

 On Mar 22, 2015, at 10:47 PM, Sergey V. Dyatko sergey.dya...@gmail.com 
 wrote:
 
 Hi Devin,
 
 Recently I'm trying to install FreeBSD CURRENT from bootonly image
 ( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
 on IBM HS22 blade via bladecenter's kvm but I faced with problem on checksum
 stage, bootonly doesn't contain base, kernel,etc distributions but it contain
 manifest file. 
 On mirrors we have  pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
 MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
 fetched files. I suppose it will be fine with RELEASE bootonly iso but not 
 with
 stable/current.
 there is 2 ways how we can handle it:
 1) download remote MANIFEST if spotted checksum mismatch and trying to use it
 2) allow user to continue installation with 'broken' distributions 
 
 I had to first put 10.1 then update it to HEAD :(
 
 What do you think ?

When I get some time I’ll have a look and see what I can do.
— 
Cheers,
Devin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

RE: Error when adding user with multiple groups with bsdconfig

[Devin Teske]

 -Original Message-
 From: Lundberg, Johannes [mailto:johan...@brilliantservice.co.jp]
 Sent: Thursday, January 9, 2014 11:38 PM
 To: David Chisnall
 Cc: FreeBSD Current
 Subject: Re: Error when adding user with multiple groups with bsdconfig
 
 On Fri, Jan 10, 2014 at 4:33 PM, David Chisnall
thera...@freebsd.orgwrote:
 
  On 10 Jan 2014, at 00:37, Lundberg, Johannes 
  johan...@brilliantservice.co.jp wrote:
 
   Creating a user who is only added to one group (for example wheel)
   works fine.
 
  I created a user with bsdconfig for the first time yesterday and found
  that their new home directory was owned by root.  Did you experience
  this, or is it just me?
 
 
 At least all dot files were owned by root if I remember correctly. I think
there is
 a PR for this.
 

http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/184681

Will address this in the rewrite of usermgmt (mirroring the
recent rewrite of groupmgmt -- ala SVN revisions 262904
262908 - 262910).
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 9.1-RC3 LiveCD missing features

[Devin Teske]

On Dec 8, 2012, at 12:09 PM, Garrett Cooper wrote:

 On Sat, Dec 8, 2012 at 9:42 AM, Ian Lepore
 free...@damnhippie.dyndns.org wrote:
 
 ...
 
 It shouldn't require rc.initdiskless; just the fact that rc.d/var
 detects it can't write to /var should cause it to automatically create a
 memory fileystem for it, and minimally populate it.  As far as I know,
 this is automatic unless you use rc.conf knobs to disable it.
 
 That doesn't solve other things like hostid, rc.conf, ssh/*, etc not
 being writable. I've had to use LiveCDs (post 9.0) a few times and the
 amount of hoops that I have to go through in order to get a working
 system is silly.
 
 Plus, it would be nice if it used an mfsroot, like another PR I filed
 said (it sucks having to wait 3 minutes for the USB CD to probe before
 I can mountroot over IPMI on Supermicro machines).
 

Never fear… as discussed at November's DevSummit…
I'm both extremely dediated-to (and designated whipping boy for) bringing 
mfsroot back as an option.

It's going to take awhile tho.

The roadmap essentially looks like:

1. Use bsdconfig as a dumping ground for migrating sysinstall features such as 
scriptability (working on that now; aim is that the scripting engine can run 
sysinstall scripts, achieving backward compatibility with  15+ years of past 
functionality).

2. When bsdconfig has the aforementioned scripting engine, the media framework 
(working on that right now, simultaneously with the scripting engine), the 
packages module (which will be pkgng based -- requires the completion of the 
media framework first), and has the distributions module then there will be a 
bsdconfig 1.0 release. Correspondingly at that time the WITH_BSDCONFIG hook 
will dissolve and no-longer be required (and thusly bsdconfig(8) will be 
available in releng distributions).

3. With the release of bsdconfig and general availability, I can then start the 
process of linking bsdinstall to bsdconfig.

4. bsdinstall will become i18n-ready.

5. bsdinstall will inherit the media selection dialog from bsdconfig (which is 
based on sysinstall's media selection dialog)

NOTE: And I'm sure other things will happen to bsdinstall under my wing, but 
I'm not ready to commit to more than that at this time

6. I will then calculate the dependencies of bsdinstall/bsdconfig to create an 
mfsroot

7. Leave the existing releng Makefile alone, but make a 
release/Makefile.bsdinstall that generates an mfsroot

And then we'll start down the road of testing mfsroot-based bsdinstall media.

Right now I'm at #1, working to get to #2. bsdconfig in ports is at 0.7.x. When 
I complete the media framework (well over 2,000 lines of code so far -- 
restructuring and growing daily, trying to get to a stable point of commit that 
reflects a working media selection dialog with ALL permutations that sysinstall 
supported), I'll release a 0.8.x port. Beyond that, when I finish the packages 
module (pkgng based of course), I'll release a 0.9.x port (all of these being 
just frozen snapshots of HEAD's usr.sbin/bsdconfig/ dir). Last (and completing 
step #2 above), I'll quickly generate the distributions module which will 
conclude the entirety of scope -- replicating sysinstall's Post-Install 
Configuration menu (and thus, 1.0 release and unleashing).
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 9.1-RC3 LiveCD missing features

[Devin Teske]

On Dec 7, 2012, at 2:30 PM, CeDeROM wrote:

 Hello Chuck :-)
 
 DD cannot perform non-destructive test.. unless I do dd if=/dev/ada0s2a
 of=/dev/ada0s2a :-) Do you think drives are now smart enough to remap
 badblocks this way? What is the probability that there are no badblocks or
 badblocks are not detected this way?
 

SpinRite is one way to find/correct bad blocks non-destructively (it will even 
do its best to resurrect data from bad blocks using intense heuristic analysis).

NOTE: SpinRite is not free (see grc.com)

Also, maybe I should mention my own LiveCD/Rescue disc (which does have the 
badblocks program you're looking for):

FreeBSD-9.0_Druid-1.0b60.iso
or
FreeBSD-8.3_Druid-1.0b60.iso

(the former for 9.x and the latter for 8.x).



 Which pattern is better for format 0x00 or 0xFF or one after another or
 dont care? I think badblocks is quite useful in this case even in
 destructive mode..
 
 Btw. I have moved discussion to freebsd-stable , sorry for a mess :-)
 
 Best regards :-)
 Tomek
 
 --
 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 9.1-RC3 LiveCD missing features

[Devin Teske]

On Dec 7, 2012, at 2:39 PM, Devin Teske wrote:

 
 On Dec 7, 2012, at 2:30 PM, CeDeROM wrote:
 
 Hello Chuck :-)
 
 DD cannot perform non-destructive test.. unless I do dd if=/dev/ada0s2a
 of=/dev/ada0s2a :-) Do you think drives are now smart enough to remap
 badblocks this way? What is the probability that there are no badblocks or
 badblocks are not detected this way?
 
 
 SpinRite is one way to find/correct bad blocks non-destructively (it will 
 even do its best to resurrect data from bad blocks using intense heuristic 
 analysis).
 
 NOTE: SpinRite is not free (see grc.com)
 
 Also, maybe I should mention my own LiveCD/Rescue disc (which does have the 
 badblocks program you're looking for):
 
 FreeBSD-9.0_Druid-1.0b60.iso
 or
 FreeBSD-8.3_Druid-1.0b60.iso
 
 (the former for 9.x and the latter for 8.x).
 

D'Oh, actually.. I don't have badblocks … just badsect (different programs with 
different purposes).
-- 
Devin


 
 
 Which pattern is better for format 0x00 or 0xFF or one after another or
 dont care? I think badblocks is quite useful in this case even in
 destructive mode..
 
 Btw. I have moved discussion to freebsd-stable , sorry for a mess :-)
 
 Best regards :-)
 Tomek
 
 --
 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: can't open '/boot/menusets.4th'

[Devin Teske]

On Nov 12, 2012, at 3:50 PM, Glen Barber wrote:

 On Mon, Nov 12, 2012 at 06:11:43PM -0500, Darrel wrote:
 Hello,
 
 Today I booted r242670 from the console and noticed this error message:
 can't open '/boot/menusets.4th':  no such file of directory
 
 Error while including /boot/menu-commands.4th, in the line
 include /boot/menusets.4th
 
 Error while including /boot/menu.rc, in the line
 include /boot/menu-commands.4th
 
 Anyone seen this before?
 
 
 Yes.  This is fixed a few hours after it was introduced.
 

and a few moments (minutes) after the fix, I sent an e-mail to -current warning 
everyone.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: HEADS UP: Forth Optimizations

[Devin Teske]

On Nov 11, 2012, at 5:30 PM, Peter Jeremy wrote:

 On 2012-Nov-10 16:53:10 -0800, Devin Teske devin.te...@fisglobal.com wrote:
 Can someone help review this for the commit log?
 
 I've had a look through the proposed patch and my comments follow.
 Other than that, it looks good to me.
 

Thanks Peter!

Replies inline below.


 Index: menu-commands.4th
 ===
 --- menu-commands.4th(revision 242835)
 +++ menu-commands.4th(working copy)
 ...
 @@ -185,21 +240,21 @@ variable root_state
 ...
  s set kernel=${kernel_prefix}${kernel[N]}${kernel_suffix}
 -  \ command to assemble full kernel-path
 --rot tuck 36 + c! swap\ replace 'N' with array index value
 -evaluate  \ sets $kernel to full kernel-path
 +36 +c! \ replace 'N' with ASCII numeral
 +evaluate
 
 I think the sets $kernel to full kernel-path comment is worth keeping.
 

Updated, thx.


  s set root=${root_prefix}${root[N]}${root_suffix}
 -  \ command to assemble root image-path
 --rot tuck 30 + c! swap\ replace 'N' with array index value
 -evaluate  \ sets $kernel to full kernel-path
 +30 +c! \ replace 'N' with ASCII numeral
 +evaluate
 
 Likewise, this could do with a (corrected) comment that it sets $root
 to the full path to root.
 

Likewise, updated.


 Index: menu.4th
 ===
 --- menu.4th (revision 242835)
 +++ menu.4th (working copy)
 @@ -184,18 +223,15 @@ create init_text8 255 allot
 
  \ base name of environment variable
  loader_color? if
 -s ansi_caption[x]
 +dup ansi_caption[x]
  else
 -s menu_caption[x]
 +dup menu_caption[x]
  then
 
 Could this be simplified to
 
 = dup
 = loader_color? if
 = ansi_caption[x]
 = else
 = menu_caption[x]
 = then
 

Sure, done. Actually, found two occurrences of this that I corrected.


 Or, at a higher level, should this whole block be pulled into a new
 word (along with similar words for toggled_{ansi,text}[x] and
 {ansi,menu}_caption[x][y]?
 

I looked at the uses where ansi* is used in place of non-ansi* and it's not 
just within loader_color? blocks (that was in-fact the minority of cases). 
Cooking it down further would make things more complicated I fear.

If I come up with a cute way to simplify this, I'll try it out in another 
commit.



 @@ -227,36 +263,26 @@ create init_text8 255 allot
 ...
  getenv dup -1  if
  \ Assign toggled text to menu caption
 
 Some comments on stack contents around here would make it somewhat
 easier to follow what is going on.
 

Done. I also made updates to cycle_menuitem for similarly-dense code.


 @@ -329,19 +340,18 @@ create init_text8 255 allot
 ...
  \ This is highly unlikely to occur, but to make
  \ sure that things move along smoothly, allocate
  \ a temporary NULL string
 
 +drop ( getenv cruft )
  s 
  then
  then
 
 Is this the memory leak?  If so, can I suggest that this be commited
 separately since it is a simple change and is distinct from the other
 changes you are proposing.

You got it. Committed as r242923


 
 @@ -357,14 +367,14 @@ create init_text8 255 allot
  \ 
  \ Let's perform what we need to with the above.
 
 -\ base name of menuitem caption var
 +\ Assign array value text to menu caption
 +4 pick
 
 According to the docementation just above this hunk, there are only 4
 items on the stack, so 4 pick seems wrong, though it is consistent
 with my understanding of the old code.  The 2 pick [char] 0 you
 added earlier seems to similarly be out-by-one, though consistent.
 

My mistake was that the comments need to be updated to say C-Addr/U not C-Addr 
(the C-Addr/U counts to make 5 items on the stack, satisfying the 4 pick). 
I've updated the comment to reflect the stack contents more accurately.


 @@ -521,17 +528,20 @@ create init_text8 255 allot
 
  \ If this is the ACPI menu option, act accordingly.
  dup menuacpi @ = if
 -acpimenuitem ( -- C-Addr/U | -1 )
 +dup acpimenuitem ( n -- n n c-addr/u | n n -1 )
 +dup -1  if
 +13 +c! ( n n c-addr/u -- n ) \ replace 'x'
 
 I think the stack here should be ( n n c-addr/u -- n c-addr/u )
 

Good catch! Updated.



 @@ -950,100 +914,43 @@ create init_text8 255 allot
 
  49 \ Iterator start (loop range 49 to 56; ASCII '1' to '8')
  begin
 -\ Unset variables in-order of appearance in menu.4th(8)
 
 Does the order matter

HEADS UP: Forth Optimizations

[Devin Teske]

Hi Everybody,

Adrian (my co-mentor) wanted some additional eyes/names for review on a patch 
I'm making to sys/boot/forth (patch attached as patch.txt).

The patch makes no changes to user experience or functionality (but _does_ fix 
one incident of stack leakage -- among other things).

I wrote/tested this over a 2-day period using (as usual) VMware. I booted up 
several times (10+) and fiddled with many things (twiddled every knob, dropped 
to the loader prompt and went back to the menu several times, tried throwing 
various options like boot_single=YES and boot_verbose=YES into 
loader.conf(5) to make sure dynamic initialization is still working etc.).

The only thing I noticed after applying the patch was a drop in heap usage (one 
of the goals of the patch), showing that the optimizations did their job to 
make a leaner running menu. Also, the code is a lot more readable and got 
slightly reduced in size during the process.

Can someone help review this for the commit log?
-- 
Devin

===

+ This patch does not change user experience or functionality
+ Cleanup syntax, slim-down code, and make things more readable
+ Introduce new +c! operator and ilk to reduce heap usage/allocations
+ Fix a stack leak in [unused] cycle_menuitem function while we're here
 (required misconfiguration and/or missing environment vars to occur)
+ Add safemode_enabled? safemode_enable and safemode_disable functions
+ Add singleuser_enabled? singleuser_enable singleuser_disable functions
+ Add verbose_enabled? verbose_enable and verbose_disable functions
+ Centralize strings (also to reduce heap usage)

PR:
Submitted by:
Reviewed by:Your_Name_Here, adrian (co-mentor) [pending his/your review]
Approved by:adrian (co-mentor) [pending his approval]
Obtained from:
MFC after:
Security:
--This line, and those below, will be ignored--
 Description of fields to fill in above: 76 columns --|
 PR:If a GNATS PR is affected by the change.
 Submitted by:  If someone else sent in the change.
 Reviewed by:   If someone else reviewed your modification.
 Approved by:   If you needed approval for this commit.
 Obtained from: If the change is from a third party.
 MFC after: N [day[s]|week[s]|month[s]].  Request a reminder email.
 Security:  Vulnerability reference (one per line) or description.
 Empty fields above will be automatically removed.

Mforth/menu-commands.4th
Mforth/menu.4th

_
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: menu-commands.4th
===
--- menu-commands.4th   (revision 242835)
+++ menu-commands.4th   (working copy)
@@ -31,6 +31,10 @@ include /boot/menusets.4th
 variable kernel_state
 variable root_state
 
+\ 
+\ ACPI
+\ 
+
 : acpi_enable ( -- )
s set acpi_load=YES evaluate \ XXX deprecated but harmless
s set hint.acpi.0.disabled=0 evaluate
@@ -58,9 +62,38 @@ variable root_state
TRUE \ loop menu again
 ;
 
+\ 
+\ Safe Mode
+\ 
+
+: safemode_enabled? ( -- flag )
+   s kern.smp.disabled getenv -1  dup if
+   swap drop ( c-addr flag -- flag )
+   then
+;
+
+: safemode_enable ( -- )
+   s set kern.smp.disabled=1 evaluate
+   s set hw.ata.ata_dma=0 evaluate
+   s set hw.ata.atapi_dma=0 evaluate
+   s set hw.ata.wc=0 evaluate
+   s set hw.eisa_slots=0 evaluate
+   s set kern.eventtimer.periodic=1 evaluate
+   s set kern.geom.part.check_integrity=0 evaluate
+;
+
+: safemode_disable ( -- )
+   s kern.smp.disabled unsetenv
+   s hw.ata.ata_dma unsetenv
+   s hw.ata.atapi_dma unsetenv
+   s hw.ata.wc unsetenv
+   s hw.eisa_slots unsetenv
+   s kern.eventtimer.periodic unsetenv
+   s kern.geom.part.check_integrity unsetenv
+;
+
 : init_safemode ( N -- N )
-   s kern.smp.disabled getenv -1  if
-   drop ( n c-addr -- n ) \ unused
+   safemode_enabled? if
toggle_menuitem ( n -- n )
then
 ;
@@ -70,25 +103,10 @@ variable root_state
 
\ Now we're going to make the change effective
 
-   s toggle_stateN @  \ base name of toggle state var
-   -rot 2dup 12 + c! rot\ replace 'N' with ASCII numeral
-
-   evaluate 0= if
-   s kern.smp.disabled unsetenv
-   s hw.ata.ata_dma unsetenv
-   s hw.ata.atapi_dma unsetenv
-   s hw.ata.wc unsetenv
-   s hw.eisa_slots unsetenv
-   s kern.eventtimer.periodic unsetenv
-   s kern.geom.part.check_integrity unsetenv
+   dup toggle_stateN 

[HEAD] SVN r242667 and r242688 missing .4th file in /boot

[Devin Teske]

For a brief 6 hours and 48 minutes (time between r242667 and r242688), if you 
updated your HEAD source tree, please update it again (to bring 
base/head/sys/boot/ up to r242688 or higher).

r242667 introduced a bugette wherein if you reboot your system you'll get the 
error can't open '/boot/menusets.4th': no such file or directory.

Updating to r242688 fixes the problem by installing the missing .4th file.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [IMPORT] bsdconfig(8)

[Devin Teske]

On Jul 14, 2012, at 2:34 AM, Bruce Cran wrote:

 On 14/07/2012 03:48, Devin Teske wrote:
 I'm [re-]announcing that (after much delay from the first announcement) that 
 I am finally importing bsdconfig(8) into HEAD.
 
 I've noticed a couple of issues:
 
 The welcome page mentions setting the root password and the time zone, but 
 bsdinstall will have already done that.
 

The goal is to have bsdinstall drop those functionalities and instead link to 
bsdconfig.


 ...look at the 'Packages' item in this menu. and on the main page - Most 
 importantly, you can use the Packages utility... - I don't see a Packages 
 entry in the menu.
 

This will be added before MFC and before switching WITH_BSDCONFIG to 
WITHOUT_BSDCONFIG.

bsdconfig needs to replicate package installation because sysinstall had it… 
but bsdconfig is going to use pkgng instead of the legacy tools. This will 
greatly improve the abilities of the tool (you'll be able to perform remote 
package queries, etc. -- something you couldn't ever do in sysinstall).

However, in order to build a more full-and-complete package management tool 
based on pkgng, we needed the help of bapt (and he's agreed to help -- later). 
Right now, bsdconfig and pkgng are maturing side-by-side without knowledge of 
each other. As they both slow down a bit, integration becomes a closer reality 
and less of a moving target.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [IMPORT] bsdconfig(8)

[Devin Teske]

On Jul 14, 2012, at 1:06 PM, Bruce Cran wrote:

 On 14/07/2012 20:49, Devin Teske wrote:
 The goal is to have bsdinstall drop those functionalities and instead link 
 to bsdconfig.
 
 Won't that mean it'll be possible to end up with an installation without a 
 root password set?
 

No.

The implication is that bsdconfig and bsdinstall will forever live side-by-side 
once linked together. That includes having bsdconfig live on the installation 
media so that bsdinstall can utilize it during the installation to (among other 
things) set the root password.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [IMPORT] bsdconfig(8)

[Devin Teske]

On Jul 14, 2012, at 1:52 PM, Bruce Cran wrote:

 On 14/07/2012 21:17, Devin Teske wrote:
 The implication is that bsdconfig and bsdinstall will forever live 
 side-by-side once linked together. That includes having bsdconfig live on 
 the installation media so that bsdinstall can utilize it during the 
 installation to (among other things) set the root password.
 
 Doesn't that mean that bsdconfig would be invoked as bsdconfig password 
 which would bypass the welcome screen and so by the time the user does see it 
 the root password (and timezone) will have been set?
 

No.

In 8.x, when you're performing the guided install, will prompt you to set the 
root password among many other things. At the very end, it prompts you as to 
whether you'd like to visit the configuration menu one more time.

In 9.x and higher, bsdinstall (taking the place of sysinstall) in a similar 
manner asks you to set the root password among many other things, but does not 
ask you if you'd like to visit the configuration menu one more time (because 
there isn't one).

So think of it this way… bsdinstall has these functionalities but no menu to 
invoke them.

By removing these functionalities from bsdinstall and instead using bsdconfig 
for these functionalities, the scenario now becomes…

bsdinstall asks to set the root password (by either executing bsdconfig 
password -- in which a transition is only noticeable because the --backtitle 
changes from FreeBSD Installer to bsdconfig -- or bsdinstall could instead 
include /usr/libexec/bsdconfig/040.password/include/password.subr and call the 
f_dialog_input_password() function where it can control --backtitle to make the 
usage even more seemless; making bsdconfig's functionality look like 
bsdinstall's). After asking to set the root password, bsdinstall can now (like 
sysinstall) ask the user if they'd like to visit the configuration menu one 
last time to make any additional changes (and bsdconfig -- no arguments -- 
would provide that menu).
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [IMPORT] bsdconfig(8)

[Devin Teske]

On Jul 14, 2012, at 2:46 PM, Bruce Cran wrote:

 On 14/07/2012 22:07, Devin Teske wrote:
 bsdinstall asks to set the root password (by either executing bsdconfig 
 password -- in which a transition is only noticeable because the 
 --backtitle changes from FreeBSD Installer to bsdconfig -- or bsdinstall 
 could instead include 
 /usr/libexec/bsdconfig/040.password/include/password.subr and call the 
 f_dialog_input_password() function where it can control --backtitle to make 
 the usage even more seemless; making bsdconfig's functionality look like 
 bsdinstall's). After asking to set the root password, bsdinstall can now 
 (like sysinstall) ask the user if they'd like to visit the configuration 
 menu one last time to make any additional changes (and bsdconfig -- no 
 arguments -- would provide that menu).
 
 You forgot to explain the 'express' mode that bypasses the bsdconfig 
 password step.
 

Did I? When one starts discussing 'Express Install', we're clearly in the realm 
of bsdinstall, not bsdconfig.

Like you stated, in that case bsdinstall would not use bsdconfig.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [IMPORT] bsdconfig(8)

[Devin Teske]

On Jul 14, 2012, at 3:32 PM, Bruce Cran wrote:

 On 14/07/2012 22:58, Devin Teske wrote:
 Did I? When one starts discussing 'Express Install', we're clearly in the 
 realm of bsdinstall, not bsdconfig.
 
 Like you stated, in that case bsdinstall would not use bsdconfig.
 
 I'm getting really confused here. Either bsdconfig password gets run before 
 the post-install configuration menu is shown and therefore the text saying to 
 set the root password in the welcome screen is unnecessary, or it doesn't get 
 run and it's possible to quit bsdconfig without setting the root password.
 

Ok, it's more clear to me that the concern is with the welcome screen.

1. The welcome screen _text_ was ripped straight from sysinstall except with 
one difference… s/Pascal/Firefox/ (updating it for the current generations).

2. Currently this text is shoved in your face but it won't always be. The text 
will be moved to a Help screen.

So, in a way you're absolutely right… you've highlighted a conundrum (the 
welcome screen contains text which is not suitable for a welcome screen) 
because bsdinstall did something differently than sysinstall in this one case  
(reasons below; solution above -- get rid of the welcome screen).

The reason why we (Ron and I) chose to not implement the help-text in the same 
way that sysinstall does (go to the Configure top-level menu and then press 
F1) is that bsdconfig strives to be compatible with both dialog(1) and 
[purported drop-in replacement] Xdialog(1) -- and the latter doesn't support 
hooking into F1.

However, it's agreed that the welcome screen is not the right way to 
re-implement the configure.help file from sysinstall (actually rescuing _all_ 
of the *.help files from the clutches of the Attic -- further 
internationalizing them in the process too).

The envisioned construct right now is to add a third button labeled Help. 
This can be done in both dialog(1) and Xdialog(1) (see bsdconfig 
startup_rcconf and the Details button -- except instead of dangling a menu 
off of it, it will produce a box with the desired help-text.

Of course, making this scalable and usable is a challenge so we haven't yet 
migrated away from the welcome screen before the import to HEAD.

It will be dealt with before MFC and also before WITH_BSDCONFIG becomes 
WITHOUT_BSDCONFIG.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[IMPORT] bsdconfig(8)

[Devin Teske]

Hello -current,

I'm [re-]announcing that (after much delay from the first announcement) that I 
am finally importing bsdconfig(8) into HEAD. Here's what to expect from the 
import:

1. The Makefile for usr.sbin will not automatically descend into the new 
usr.sbin/bsdconfig directory.

2. To add bsdconfig(8) to your system, define WITH_BSDCONFIG=YES (either on the 
make line with -D or in src.conf(5) for convenience).

3. After the import, not only is it possible but-encouraged to test the HEAD 
code on RELENG_9 (but no-lower than 9.0-R as this is the lowest compatible 
release and RELENG_9 is the lowest target MFC).

4. Aside from the following [tiny] patches, everything lives in 
usr.sbin/bsdconfig/

tools/build/options/WITH_BSDCONFIG
share/mk/bsd.own.mk
usr.sbin/Makefile

Please report any problems, kudos, comments to me at-will.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports)

[Devin Teske]

On Jul 2, 2012, at 6:24 PM, Devin Teske wrote:

 
 On Jun 30, 2012, at 3:47 PM, Bruce Cran wrote:
 
 On 28/06/2012 00:11, Devin Teske wrote:
 I'd like to announce that I intend to import bsdconfig(8) today.
 
 I haven't seen this get committed yet - was there a problem?
 
 
 No problems. A long weekend put the damper on the process but it has picked 
 up again.
 
 By week's end there should be more info.

Just committed! See SVN r238438

http://svnweb.FreeBSD.org/base?limit_changes=0view=revisionrevision=238438

In the additional time that was taken many people were spoken with. The only 
thing that has really changed is that phk recommended adding a WITH_BSDCONFIG 
hook, and so that was done.

Happy Day!
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports)

[Devin Teske]

On Jun 30, 2012, at 3:47 PM, Bruce Cran wrote:

 On 28/06/2012 00:11, Devin Teske wrote:
 I'd like to announce that I intend to import bsdconfig(8) today.
 
 I haven't seen this get committed yet - was there a problem?
 

No problems. A long weekend put the damper on the process but it has picked up 
again.

By week's end there should be more info.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities

[Devin Teske]

On Jun 27, 2012, at 8:58 AM, Bruce Cran wrote:

 On 27/06/2012 02:11, Devin Teske wrote:
 Fixed.
 
 Thanks!
 The mouse daemon flags text still seems to have an upper-case 'S' ('Please 
 Specify').
 

Oops, forgot that one. Thanks Bruce!

Fixed.
-- 
Devin

NOTE: I probably won't be rushing to roll a new port version for this change; 
just know that it will make it into the next snapshot (and has been made to the 
tree that will be imported to HEAD later, if there aren't any other issues 
reported by end-of-day).

_
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports)

[Devin Teske]

Hi All,

I'd like to announce that I intend to import bsdconfig(8) today.

===

Run-up…

Q. What is bsdconfig(8)?
A. dialog(1) based post-install configuration utility for configuring/managing 
various aspects of FreeBSD.

Q. What does it look like?
A. No screenshots, but I do have a graphic illustrating the menu layout…

http://druidbsd.sf.net/download/bsdconfig/bsdconfig-0.7.0-ic.svg

Q. Why do we need this in base?
A. Because this functionality was exactly produced by sysinstall(8) which has 
been deprecated (will not exist in FreeBSD 10). FreeBSD-9 is where bsdinstall 
is being evaluated as a replacement for the install functionality of 
sysinstall(8) meanwhile bsdconfig is to replace the configuration/management 
functionalities of sysinstall.

Q. Did you discuss this with anyone?
A. Everyone that would listen in the past 6 months as we run up to the 9.1 code 
freeze.

Q. Did anyone test this?
A. Ron, myself, and about 8 others in the community did both high-level 
testing, low-level review, and more over the past 6 months.

Q. If it doesn't go well, can we back it out?
A. Sure -- it's entirely self contained. src/usr.sbin/bsdconfig is the only 
directory being touched (oh, and the Makefile in the parent directory to add 
the new SUBDIR).

Any other questions, don't hesitate to ask.

===

Heads-up…

Code will land in src/usr.sbin/bsdconfig and _nowhere_ else.

The code will be voluminous (~20k LOC across ~150 files including ~30 
Makefiles).

The code is entirely in sh(1) (don't knock it until you've seen it).

The code used in this tool and all sub-modules was developed primarily over a 
150-day period, but in reality contains code developed and revised over the 
past 5 years, entirely BSD licensed!

All code was written by Ron McDowell and myself.

===

If there are no complaints by End-Of-Day (EOD), I'll go ahead and import.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities

[Devin Teske]

Hi Bruce,

On Jun 24, 2012, at 5:14 PM, Bruce Cran wrote:

 On 21/06/2012 00:40, Devin Teske wrote:
 If you have the time and/or energy, please test and report any issues that 
 you experience.
 
 I've noticed a few typos and other minor issues:
 
 In bsdconfig(8):
  Contains a link to itself under SEE ALSO.
  bsdconfig takes a commands as an argument - should be command.
 

Fixed.


 bsdconfig mouse:
  Typo se Configuration menu.
  Please Specify the mouse daemon flags - don't need upper-case S.
 

Fixed.


 bsdconfig hostname:
  The example should probably be in the example.com domain.
 

Replaced with full.example.com


 bsdconfig netdev:
  Select a TCP/IP network interface to configure doesn't need TCP/IP.
 

Done.


 bsdconfig nameservers:
  Please enter the new TCP/IP address of the DNS nameserver should just be 
 IP address. TCP/IP is being used where just IP was needed in other 
 places too.
 

Done.


 'bsdconfig command -h' doesn't always work:
 

Enough people complained about this, that… it too is fixed (though I argue 
that there's absolutely nothing wrong with having -h be invalid to getopts -- 
the end result is the same with exception to the illegal option -h extra-line 
of output that everybody seems to complain about. Also mind you, that much of 
the FreeBSD Operating System suffers from this bug


  bsdconfig hostname -h
 Illegal option -h
 

Like tzsetup -h and many others that are this way. I just can't win 
(inconsistencies everywhere in the system w/respect to this).
-- 
Devin

P.S. Fixes are in the up-coming 0.7.3 PORTVERSION of sysutils/bsdconfig.

_
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities

[Devin Teske]

On Jun 21, 2012, at 3:53 AM, Vitaly Magerya wrote:

 Devin Teske wrote:
 Toggle Startup Services dialog shows sendmail_enable and
 sendmail_msp_queue_enable variables, but doesn't seem to show
 sendmail_submit_enable and sendmail_outbound_enable. Is this
 by design?
 
 What does the following produce:
 
  service sendmail rcvar
 
 Now what does this say:
 
  grep sendmail /var/run/bsdconfig/startup_rcvar_map.cache
 
 Do they agree?
 
 OK, both list sendmail_enable and sendmail_msp_queue_enable only. It
 appears that /etc/rc.d/sendmail only registers sendmail_submit_enable
 and sendmail_outbound_enable if they are enabled (and enabling or
 disabling one of the four affects the status of others).
 
 That behavior combined with the fact that bsdconfig does not recompute
 rcvars each time you make modifications means that you can't manipulate
 (i.e. disable) sendmail from bsdconfig.
 

I wouldn't say that.

I'd say that because the output of rcvar is conditional, you can't [fully] 
manipulate sendmail. (i.e. you can't toggle sendmail_outbound_enable using 
bsdconfig).

BTW, if rcvar map cache was regenerated every time a variable got toggled, the 
menu would be unusable on my VM (which takes ~6-7 seconds to generate the cache 
-- passing rcvar to each rc.d script).


 I think the right thing to do is to fix /etc/rc.d/sendmail, but I don't
 know how: removing the conditions around sendmail_submit_enable and
 sendmail_outbound_enable parts fixes rcvar, but probably breaks other
 commands.
 
 Any ideas how to fix this?
 

I'll have a look at it, but the situation is thus:

Sysinstall's startup menu (replicated as-is in bsdconfig startup_misc) is a 
hard-coded list with a hard-coded set of actions for each item.

I thought we could do better, and that's where bsdconfig startup_rcvar comes 
in.

I knew that startup_rcvar could not work perfectly because what's missing is a 
map of relational dependence between each of the rcvar's. In example, there's 
no way for me to know that toggling variable X will cause variables Y and Z to 
appear on the subsequent rcvar call to the rc.d script. Furthermore (and 
similarly), there's no way for me to tell if, while toggling a given service, 
that any other service should be toggled at the same time.

The former is a real issue, while the latter could perhaps be gleaned from 
reading the rcorder bits from the rc.d script to see if anything else needs to 
be toggled (ignoring the fake REQUIRES such as FILESYSTEMS, NETWORK, etc.).

Either way, I do feel that the initial offering is light years ahead of 
sysinstall(8)'s Startup menu even if it's not perfect.

Other options on the table are:
1. Change the rcvar output (of all scripts) to indicate dependency relationships
2. Change bsdconfig's startup_rcvar module to use a static list of variables 
(less desirable imho)
3. Fix sendmail's rcvar output to simply report all variables (haven't looked 
at the script yet to see how hard this will be -- but I'm leaning on this one 
first)


 The nature of this bug is that if the item that you select in the
 menu is evenly divisible by both 2 and 3 landing on a boundary,
 the item works as expected, otherwise you can only toggle the item
 ON (not off).
 
 Sounds interesting; there must be some really hairy stuff inside
 bsdconfig if this is the kind of edge cases it has.

Well, it doesn't sound so hairy when I explain it…

dialog(1) (and Xdialog(1) too) support two different modes for menu-list 
widgets.

Item/Value pair's (this is the default)
and
Item/Value/Help triplets (enabled by passing --item-help)

The latter functionality is used on the bsdconfig main menu as well as many of 
the menus in the Startup module to offer additional information at the bottom 
of the screen (or bottom of the window when using Xdialog).

The nature of the bug was that I was using f_dialog_menutag2item to translate 
the user's selection back into the value for said chosen-item. Problem was that 
this function expects item/value pairs, so I had to create a new API routine, 
f_dialog_menutag2item_with_help which does the same thing but expects 
item/value/help triplets.

So you can see why (when you're sending a list of sets-of-3 to a function that 
expects sets-of-2) the nature of the bug was that only the menu items that were 
evenly bounded worked as-expected while others did not.

Oh, and the reason for only being able to enable the broken items (but not 
disable) was because the fallback case for the mapped value was to to set to 
YES while we only set to NO when the mapped value has it's checkmark 
displayed (and since the mapped-value was NULL 2 out of 3 times, this resulted 
in not detecting the checkmark, defaulting to enabling the item).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner

Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities

[Devin Teske]

New minor revision 0.7.1 committed to ports.

Bugfix:
- Certain services in Toggle Startup Services (under the Startup menu) 
could not be toggled off.

If you have already installed 0.7.0, portupgrade should make short work of 
updating to the latest version.
-- 
Devin

P.S. Sorry for top-post.
P.P.S. Thanks goes to Vitaly Magerya for the bug report.
P.P.P.S. Thanks to wxs@ for help in ports.

On Jun 20, 2012, at 4:40 PM, Devin Teske wrote:

 Hi Folks,
 
 This is a call for testing of the new sysutils/bsdconfig port.
 
 Back in February, Ron McDowell and myself together decided we were going to 
 take-on the task of salvaging sysinstall(8)'s Configure menu while 
 simultaneously rewriting it into a system of shell scripts (making it similar 
 to bsdinstall) so that sysinstall(8) could be safely and quietly put to 
 pasture (meanwhile contradictorily _increasing_ functionality due to several 
 enhancements performed in the process).
 
 After talking with a lot of other developers and really helpful folks, we 
 decided to shoot for the 9.1-R freeze to coincide with other new features 
 like pkgng. Currently, bsdconfig cannot do what sysinstall is known most for 
 (package installation), but that is because we have a plan to _start_ with 
 pkgng (and it just works better if pkgng can mature before the integration).
 
 If the thought of losing sysinstall has ever made you uneasy because unique 
 functionality not found elsewhere, please try the sysutils/bsdconfig port to 
 help get it some testing.
 
 With ~25,000 lines of code, we really need to get some testing on this before 
 adding this to HEAD and I've turned the source into a port to make the 
 testing process easier and to widen the audience.
 
 If you have the time and/or energy, please test and report any issues that 
 you experience.
 
 If things go well, we can get this MFC'd from HEAD before the 9.1 freeze.
 -- 
 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-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities

[Devin Teske]

Hi Folks,

This is a call for testing of the new sysutils/bsdconfig port.

Back in February, Ron McDowell and myself together decided we were going to 
take-on the task of salvaging sysinstall(8)'s Configure menu while 
simultaneously rewriting it into a system of shell scripts (making it similar 
to bsdinstall) so that sysinstall(8) could be safely and quietly put to 
pasture (meanwhile contradictorily _increasing_ functionality due to several 
enhancements performed in the process).

After talking with a lot of other developers and really helpful folks, we 
decided to shoot for the 9.1-R freeze to coincide with other new features like 
pkgng. Currently, bsdconfig cannot do what sysinstall is known most for 
(package installation), but that is because we have a plan to _start_ with 
pkgng (and it just works better if pkgng can mature before the integration).

If the thought of losing sysinstall has ever made you uneasy because unique 
functionality not found elsewhere, please try the sysutils/bsdconfig port to 
help get it some testing.

With ~25,000 lines of code, we really need to get some testing on this before 
adding this to HEAD and I've turned the source into a port to make the testing 
process easier and to widen the audience.

If you have the time and/or energy, please test and report any issues that you 
experience.

If things go well, we can get this MFC'd from HEAD before the 9.1 freeze.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities

[Devin Teske]

On Jun 20, 2012, at 5:16 PM, Vitaly Magerya wrote:

 Devin Teske devin.te...@fisglobal.com wrote:
 If you have the time and/or energy, please test and report any issues that
 you experience.
 
 Toggle Startup Services dialog shows sendmail_enable and
 sendmail_msp_queue_enable variables, but doesn't seem to show
 sendmail_submit_enable and sendmail_outbound_enable. Is this
 by design?
 

What does the following produce:

service sendmail rcvar

Now what does this say:

grep sendmail /var/run/bsdconfig/startup_rcvar_map.cache

Do they agree?

The list is generated dynamically. If there's a variable that's missing, it's 
because it wasn't reported by the rc.d script.


 It also hangs if I try to toggle sendmail_msp_queue_enable.
 
 (Tell me if you can't reproduce this easily, I'll provide more
 details).

Wow, that was an obscure bug! Thanks for finding that!

The nature of this bug is that if the item that you select in the menu is 
evenly divisible by both 2 and 3 landing on a boundary, the item works as 
expected, otherwise you can only toggle the item ON (not off).

Details are too boring to explain, I'll have to roll a new version.

Thank you so very much for finding this bug. I'll try to have it fixed today in 
the next hour or so.

Other areas should be unaffected.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities

[Devin Teske]

On Jun 20, 2012, at 6:24 PM, Devin Teske wrote:

 
 On Jun 20, 2012, at 5:16 PM, Vitaly Magerya wrote:
 

[snip]

 It also hangs if I try to toggle sendmail_msp_queue_enable.
 
 (Tell me if you can't reproduce this easily, I'll provide more
 details).
 
 Wow, that was an obscure bug! Thanks for finding that!
 

[snip]

  I'll try to have it fixed today in the next hour or so.
 
 Other areas should be unaffected.

Fixed, and I filed ports/169280.

As soon as someone commits that, you'll be able to portupgrade to the fixed 
version.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: make delete-old performance.

[Devin Teske]

On May 16, 2012, at 4:06 PM, Peter Jeremy wrote:

 I recently ran make delete-old on a -current box and felt it was
 rather slow.  That prompted me to do some more careful experiments.
 
 On one box where I have both 8-stable and 9-stable available, there
 was a ~30x slowdown (based on 5 runs, ignoring the first).  I don't
 have a -current world on that box so I can't directly compare but on
 another pair of fairly similar boxes, I get a ~180x slowdown between
 8-stable and -current (and that figure is probably optimistic since
 the -current box was idle whereas the 8-stable box was fairly busy).
 
 I realise that make delete-old isn't something you nede to do every
 day but going from sub-second to multi-minute duration is quite
 noticable.  Can anyone suggest what has caused the change?
 
 -- 
 Peter Jeremy

Right now, I believe the most useful comparison between systems is (assuming 
UFS is in play) the output of tunefs -p for the filesystem that the slowness 
is appearing on.

SoftUpdates (and whether it's enabled or disabled) can play a huge difference 
in how fast file-deletions are.

Also note that SU+J may be interesting if-set in 9 (while not available in 8).
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

RE: Switching on/off 5V power to a USB port

[Devin Teske]

 -Original Message-
 From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
 curr...@freebsd.org] On Behalf Of Ron McDowell
 Sent: Tuesday, April 03, 2012 3:14 PM
 To: freebsd-current
 Subject: Switching on/off 5V power to a USB port
 
 I just got a little USB powered fan and it sure would be nice if I could
 have cron on my FreeBSD box turn it on or off at certain times by
 switching off the 5V line on a USB port.  Anyone know how I can do
 that?  Thanks.

Alternatively, you could just plug your USB fan into your monitor.

A fellow engineer and I discovered that most monitors power-down the USB ports
when entering power-save mode (with Dell, HP, and Viewsonic, this is whenever
the screen blanks due to inactivity; are you using DPMS and/or greensaver?).

Walking away from the PC will cause the fan to [eventually] turn off, while
waggling the mouse brings it back to life.


 BTW this is a pretty decent fan for the money. :)
 http://www.amazon.com/gp/product/B0033WSDOM/

We didn't have a USB powered fan, so we actually wired an internal case-fan to
the 5V lead and went that route. Nice fan though.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

RE: revisiting tunables under Safe Mode menu option

[Devin Teske]

 -Original Message-
 From: Andriy Gapon [mailto:a...@freebsd.org]
 Sent: Thursday, March 01, 2012 12:39 AM
 To: Devin Teske
 Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske
 Subject: Re: revisiting tunables under Safe Mode menu option
 
 on 01/03/2012 03:34 Devin Teske said the following:
 
  +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe
  Mode knows about ACPI but only acts on it when being enabled).
 
 Can you explain why?
 +1 for having both menu items and each doing its own thing without any
 entanglement :-)
 

First, I realize that this may sound entirely *dumb*, but here-goes:

In transitioning from an old release (sans-menu; 4.11 for example) to a newer
release (with menu; 6.x for example), one of the first thing that is noticed is
Safe Mode.

I know that when I first saw this, I scratched my head and wondered what it did
and what it might be useful for. To this day, I still have never used it.

When I created the new menu for 9.x/higher, I had to rewrite that portion of the
code and eventually learned what Safe Mode does when used. Still can't say that
I've ever used it, however, at the point that I saw that it disabled ACPI among
other things, that it is more of a blanket option for anything and everything
that might be useful if/when you're having problems (*cough* still can't say
that I've ever used it, as when I have problems I'm usually slogging through the
kernel code, not relying on safe mode to fix some problem).

That being said, I felt that it was a huge improvement to the UI to have the
Safe Mode option divulge a little bit of its secret by visibly diddling the ACPI
menu item (giving a clue to people that *haven't* read the code that this option
is indeed not independent but instead conglomerate in-nature).

Indeed, I've watched field engineers when exploring the menu options and their
eyes light-up when they see that Safe Mode toggles ACPI off when enabled.
Extrapolating on their surprise, they appear to have an Aha!-moment as
previously... this field engineer had no idea what on God's green Earth what
Safe Mode did (or didn't) as he didn't know about kenv and certainly
couldn't read Forth. At that point, he may not have had a full understanding
of all the options that Safe Mode  diddled, but at that point he at least knew
that Safe Mode is a multi-option that does many things -- which is more than
6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe Mode
option is selected and does nothing to explain what it is that Safe Mode is
doing (which would in-turn properly calibrate the user's expectations).

Making the menu items completely independent would be take away the (however
slight) above value-add that was brought in by entwining these two menu-items.
I'm not saying that this would be a grave travesty, but would in-fact be a
value-loss.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

RE: revisiting tunables under Safe Mode menu option

[Devin Teske]

 -Original Message-
 From: Scott Long [mailto:sco...@samsco.org]
 Sent: Thursday, March 01, 2012 9:13 AM
 To: Devin Teske
 Cc: 'Andriy Gapon'; 'John Baldwin'; freebsd-current@FreeBSD.org; 'Devin Teske'
 Subject: Re: revisiting tunables under Safe Mode menu option
 
 
 On Mar 1, 2012, at 9:52 AM, Devin Teske wrote:
 
 
 
  -Original Message-
  From: Andriy Gapon [mailto:a...@freebsd.org]
  Sent: Thursday, March 01, 2012 12:39 AM
  To: Devin Teske
  Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske
  Subject: Re: revisiting tunables under Safe Mode menu option
 
  on 01/03/2012 03:34 Devin Teske said the following:
 
  +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe
  Mode knows about ACPI but only acts on it when being enabled).
 
  Can you explain why?
  +1 for having both menu items and each doing its own thing without any
  entanglement :-)
 
 
  First, I realize that this may sound entirely *dumb*, but here-goes:
 
  In transitioning from an old release (sans-menu; 4.11 for example) to a
newer
  release (with menu; 6.x for example), one of the first thing that is noticed
is
  Safe Mode.
 
  I know that when I first saw this, I scratched my head and wondered what it
did
  and what it might be useful for. To this day, I still have never used it.
 
 
 To be fair, I'm pretty sure that 'Safe Mode' was documented in one of the
 docbook manuals, though the FreeBSD project never, to my knowledge, had a
 quick install/troubleshooting guide' that documented the loader menu.  The
 name was inspired by Windows, but if you aren't familiar with that side of the
 world, then I can see how the name would have diminished meaning.  So I
 understand where you're coming from.
 
 I'd like to turn the discussion away from ACPI specifically.  What I'd like to
see
 improved is two things:
 
 1.  There are a number of knobs that can be manipulated to help enable a non-
 booting system boot, which in turn gives a system administrator a fighting
chance
 to figure out what's wrong.  ACPI is (or was) one of these options, but there
are
 several others, and up until your re-write of the menu system, they were
opaque
 to the user.  I'd like to explore the idea of having a sub-menu that exposes
these
 knobs and allows them to be individually controlled, but still have an
upper-level
 option that turns them all-on or all-off for ease of use.
 
 2.  There are a ton of kenv/TUNABLE knobs in any given kernel, and many of
 them are useful for sysadmins, even beyond just the 'safe mode' subset.  I'd
like
 to see a post-processor run on the kernel build that collects all of the kenv
knobs
 in that kernel and puts them into a file that can be read by the boot menu
 system.  The system then dynamically turns these into another sub-menu of
 knobs that can be manipulated.
 
 So, how hard would it be to have nested sub-menus?  Would (1) be something
 feasible to do in the near term?  Would (2) be feasible to do in the long
term?
 

Sub-menus are not hard at all.

The menu.4th module released under 9.0-RELEASE already supports sub-menus and
hierarchical menus.

You don't have to change the Forth code in even the slightest, this can all be
done through rc files like menu.rc.

The magic of-course is achieved through the utilization of the menu-clear FICL
word (linked-to below):

http://svnweb.freebsd.org/base/release/9.0.0/sys/boot/forth/menu.4th?revision=22
9286view=markup

NOTE: menu-clear is the last function in the file at the very bottom.

The comment for which is thus:

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.

Further-more, I have full examples on how to implement (working) sub-menus,
hierarchical menus, and such.

However...

Design discussions would have to follow as we do have serious limitations.

First, each menu can have only 9 items (we are in-fact limited by screen
real-estate as we do indeed want to retain support for serial consoles during
boot).

Also, don't forget that we actually have three different types of menu items
that can be used for each item in each menu:

1. Normal action-items (like Boot)
2. Toggle items (like On/Off or Yes/No features)
3. Cyclic items (allowing selection of one kernel out of 5 different ones, for
example)

So creativity can probably find a graceful solution to however many items we
need to support.

(thinking out loud here: maybe such a discussion would be best shunted off to
hackers if/when we get to the point of discussing actual changes, patches, and
code)
-- 
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

RE: revisiting tunables under Safe Mode menu option

[Devin Teske]

 -Original Message-
 From: Andriy Gapon [mailto:a...@freebsd.org]
 Sent: Thursday, March 01, 2012 9:07 AM
 To: Devin Teske
 Cc: 'John Baldwin'; freebsd-current@FreeBSD.org; 'Scott Long'; 'Devin Teske'
 Subject: Re: revisiting tunables under Safe Mode menu option
 
 on 01/03/2012 18:52 Devin Teske said the following:
 
 
  -Original Message-
  From: Andriy Gapon [mailto:a...@freebsd.org]
  Sent: Thursday, March 01, 2012 12:39 AM
  To: Devin Teske
  Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske
  Subject: Re: revisiting tunables under Safe Mode menu option
 
  on 01/03/2012 03:34 Devin Teske said the following:
 
  +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe
  Mode knows about ACPI but only acts on it when being enabled).
 
  Can you explain why?
  +1 for having both menu items and each doing its own thing without any
  entanglement :-)
 
 
  First, I realize that this may sound entirely *dumb*, but here-goes:
 
  In transitioning from an old release (sans-menu; 4.11 for example) to a
newer
  release (with menu; 6.x for example), one of the first thing that is noticed
is
  Safe Mode.
 
  I know that when I first saw this, I scratched my head and wondered what it
did
  and what it might be useful for. To this day, I still have never used it.
 
  When I created the new menu for 9.x/higher, I had to rewrite that portion of
 the
  code and eventually learned what Safe Mode does when used. Still can't say
 that
  I've ever used it, however, at the point that I saw that it disabled ACPI
among
  other things, that it is more of a blanket option for anything and
everything
  that might be useful if/when you're having problems (*cough* still can't say
  that I've ever used it, as when I have problems I'm usually slogging through
the
  kernel code, not relying on safe mode to fix some problem).
 
  That being said, I felt that it was a huge improvement to the UI to have the
  Safe Mode option divulge a little bit of its secret by visibly diddling the
ACPI
  menu item (giving a clue to people that *haven't* read the code that this
 option
  is indeed not independent but instead conglomerate in-nature).
 
  Indeed, I've watched field engineers when exploring the menu options and
 their
  eyes light-up when they see that Safe Mode toggles ACPI off when enabled.
  Extrapolating on their surprise, they appear to have an Aha!-moment as
  previously... this field engineer had no idea what on God's green Earth what
  Safe Mode did (or didn't) as he didn't know about kenv and certainly
  couldn't read Forth. At that point, he may not have had a full
understanding
  of all the options that Safe Mode  diddled, but at that point he at least
knew
  that Safe Mode is a multi-option that does many things -- which is more than
  6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe Mode
  option is selected and does nothing to explain what it is that Safe Mode is
  doing (which would in-turn properly calibrate the user's expectations).
 
  Making the menu items completely independent would be take away the
 (however
  slight) above value-add that was brought in by entwining these two menu-
 items.
  I'm not saying that this would be a grave travesty, but would in-fact be a
  value-loss.
 
 Devin,
 
 you did a great job with boot menu enhancement in general and in this area in
 particular.  You greatly improved usability while preserving the historic
behavior
 and put a lot of work and creativity into that.  Thank you!
 

Thank you for your kind words! Really!


 But the argument is that the historic behavior is no longer useful.  I see
that
 removing the historic behavior also kills a little bit of your code (and a
little
 bit of magic).  That's true, that's a loss in the code.
 

(nods)

[snip]

 Having a whole sub-menu where multiple parameters could be tweaked
 individually
 would be even greater improvement.  But that's not as easy to do.
 

Actually, it is easy to do.

Since day one, menu.4th has supported sub-menus and hierarchical menus.

HINT: see menu-clear at the bottom of menu.4th

ASIDE: Before I do some mock-ups illustrating multiple rc files providing
sub-menus, we'll need to discuss what these menus will look like and how they'll
be generated (I heard of a hint of having build(7) generate something). I'm not
opposed to say, having a submenu.rc.in which is processed into submenu.rc
(obviously more-appropriately named than submenu) and hooked into a menu-item
visible in menu.rc. Mind you, menu.rc may have to be forked-off itself (for
reasons we won't discuss until we get down to the nitty-gritty; possibly on
-hackers).
-- 
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

RE: revisiting tunables under Safe Mode menu option

[Devin Teske]

 -Original Message-
 From: Julian Elischer [mailto:jul...@freebsd.org]
 Sent: Thursday, March 01, 2012 1:22 PM
 To: Devin Teske
 Cc: 'Andriy Gapon'; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin'
 Subject: Re: revisiting tunables under Safe Mode menu option
 
 On 3/1/12 8:52 AM, Devin Teske wrote:
  .
  Indeed, I've watched field engineers when exploring the menu options and
 their
  eyes light-up when they see that Safe Mode toggles ACPI off when enabled.
  Extrapolating on their surprise, they appear to have an Aha!-moment a ...
 
 they have all seen 'safe mode' on windows. They know what that does and
 they are assuming this does the same thing.
 Basically Windows safe mode disables all the bells and whistles of the
 installation
 and reverts to known safe defaults for everything it can reach.
 i.e. VGA screen, basic keyboard, IDE disk, no desktop extensions, all
 fancy CPU options turned off.
 

Right, making the assumption that FreeBSD's safe mode will do the same thing as
Windows' safe mode is a poor assumption.

As you point out, all those things that Windows safe mode does, FreeBSD does
not.

X11 drivers are not affected by safe mode.

Network is not affected by safe mode.

Services started at boot, are not affected...

So I would welcome discussions involving development of something better (and am
willing to help).
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

RE: revisiting tunables under Safe Mode menu option

[Devin Teske]

 -Original Message-
 From: Julian Elischer [mailto:jul...@freebsd.org]
 Sent: Thursday, March 01, 2012 1:28 PM
 To: Scott Long
 Cc: Devin Teske; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin';
 'Andriy Gapon'
 Subject: Re: revisiting tunables under Safe Mode menu option
 
 On 3/1/12 9:13 AM, Scott Long wrote:
 
  1.  There are a number of knobs that can be manipulated to help enable a
non-
 booting system boot, which in turn gives a system administrator a fighting
chance
 to figure out what's wrong.  ACPI is (or was) one of these options, but there
are
 several others, and up until your re-write of the menu system, they were
opaque
 to the user.  I'd like to explore the idea of having a sub-menu that exposes
these
 knobs and allows them to be individually controlled, but still have an
upper-level
 option that turns them all-on or all-off for ease of use.
 
  2.  There are a ton of kenv/TUNABLE knobs in any given kernel, and many of
 them are useful for sysadmins, even beyond just the 'safe mode' subset.  I'd
like
 to see a post-processor run on the kernel build that collects all of the kenv
knobs
 in that kernel and puts them into a file that can be read by the boot menu
 system.  The system then dynamically turns these into another sub-menu of
 knobs that can be manipulated.
 
  So, how hard would it be to have nested sub-menus?  Would (1) be something
 feasible to do in the near term?  Would (2) be feasible to do in the long
term?
 
 not only collecting stuff from am kernel build but from a running system.
 it would be nice fro example to be able to influence the /etc/rc.d
 system by disabling some functions.
 e.g. come up but don't turn on the window system, or networking..
 We can disable a device but how about specifying a different default
 route than that in /etc/rc.conf?
 
 if we extract the setup tha tthe machine eventually comes up to, we
 can allow that to be tuned as well.

I'm interested in which path you would choose amongst what I've seen mentioned
thus far:

a. Modifying the boot menu to offer fine-grain control over each aspect of Safe
Mode (wherein perhaps the Safe Mode option becomes a hook for a sub-menu rather
than its current setup as an On/Off toggle).

b. Keeping Safe Mode as an On/Off toggle, but shifting the fine-grain control to
userland (wherein loader(8) simply sets a safemode Boolean and the user is
dropped into something like single-user mode but with prompts for each feature)

c. Something else.
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

RE: revisiting tunables under Safe Mode menu option

[Devin Teske]

 -Original Message-
 From: Scott Long [mailto:sco...@samsco.org]
 Sent: Thursday, March 01, 2012 1:43 PM
 To: Devin Teske
 Cc: 'Julian Elischer'; freebsd-current@freebsd.org; 'Devin Teske'; 'John
Baldwin';
 'Andriy Gapon'
 Subject: Re: revisiting tunables under Safe Mode menu option
 
 
 On Mar 1, 2012, at 2:39 PM, Devin Teske wrote:
 
  I'm interested in which path you would choose amongst what I've seen
 mentioned
  thus far:
 
  a. Modifying the boot menu to offer fine-grain control over each aspect of
Safe
  Mode (wherein perhaps the Safe Mode option becomes a hook for a sub-
 menu rather
  than its current setup as an On/Off toggle).
 
 I would favor this.  Safe Mode (or whatever it gets renamed to) activates a
sub
 menu with N number of knobs plus an all-on/all-off option.

How many knobs are we talking about here?

I hope not more than 8, (the 9th menu being reserved for return to main menu).

If there's going to be more than 8, then we'll have to recode menu.4th or
envision a sub-sub-menu or start using cyclic menus, or worse... re-design
menu.4th completely to allow (say) scrolling menus with infinite items (e.g.,
there would be an indicator at the bottom of the menu that there is more than
can fit within the menu area; and pressing the down-arrow would slide the menu
view down to the next set of items).
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

RE: revisiting tunables under Safe Mode menu option

[Devin Teske]

 -Original Message-
 From: Julian Elischer [mailto:jul...@freebsd.org]
 Sent: Thursday, March 01, 2012 1:52 PM
 To: Devin Teske
 Cc: 'Andriy Gapon'; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin'
 Subject: Re: revisiting tunables under Safe Mode menu option
 
 On 3/1/12 1:35 PM, Devin Teske wrote:
  Right, making the assumption that FreeBSD's safe mode will do the same thing
 as
  Windows' safe mode is a poor assumption.
 
  As you point out, all those things that Windows safe mode does, FreeBSD does
  not.
 
  X11 drivers are not affected by safe mode.
 
  Network is not affected by safe mode.
 
  Services started at boot, are not affected...
 
  So I would welcome discussions involving development of something better
 (and am
  willing to help).
 
 but, with help from the rc people. it could..
 the kenv framework gives us a much more flexible way to implement the
 sysV runlevels that linux inherrited.
 
 here's what I would envision:
 
 a single safe mode switch
 a way to control what that does (either 'safe mode' drops you to
 another menu which includes
 boot safe mode: and configure safe mode (the second one drops you
 to yet another menu of check boxes).
 
 the result of this is a preconfigured set of kenv entries being dumped
 into the kenv space.
 
 The rc system can look at the kenv space for some key entries and act
 accordingly.
 it can also SAVE to /boot/safe_mode.conf the set of kenv entries
 selected when safe mode is used,
 and the forth code can load that and use it as a default on next
 'safe' mode usage.
 
 
 BTW do we use the forth boot stuff on all architectures?
 what of NFS boots?

Glad you asked.

There are architectures that don't use beastie.4th at all and thus simply fall
to the autoboot sequence after handling loader.conf.

These architectures lack a menu, so it would be nice if we accommodated them
with (at least) allowing manual configuration through environment variables
(later grabbed with kenv by the rc folks).

I don't think it's beyond scope to think we couldn't cleanly implement this with
(say) a well-crafted /etc/rc.d/safemode

Not exactly sure what service safemode start should do (BSD doesn't have the
same concept of runlevels as Linux does; so it's not exactly intuitive to think
we could go from multi-user mode *into* safe mode).

But service safemode status would be interesting.

Interestingly, it would perhaps be nice if service safemode stop brought the
system back to fully usable without need for reboot (something Windows doesn't
offer).
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: revisiting tunables under Safe Mode menu option

[Devin Teske]

On Feb 28, 2012, at 5:46 AM, John Baldwin wrote:

 On Tuesday, February 28, 2012 1:23:11 am Scott Long wrote:
 I still think that it's useful to be able to disable ACPI.  Just because 
 ACPI works well on modern hardware doesn't mean that everything crummy from 
 2000-2007 suddenly disappeared off the face of the earth.  But I agree that 
 turning it off on modern systems probably does more harm than good.  Hence my 
 suggestion for a finer control over this in the menu.  Maybe Devin Teske can 
 lend some help with this task?

.oO(uh oh, what'd I do now?)


  For extra credit, it should be possible to 
 write a simple static analysis tool that collects all of the tunables that 
 are 
 compiled into the kernel and generates a data file that the boot menu can 
 process and turn into interactive knobs for the user.
 
 Hmm, with the newer boot menu, can't one now toggle safe mode and ACPI 
 independently?

Semi-independently; ordered rather.

Toggling Safe Mode On will toggle ACPI Off. This is the only real example of 
one menu item reaching into another menu item, and it only happens when 
toggling Safe Mode on (not off).

Despite the above description, it is in-fact intuitive and the effects are 
as-expected.

Booting Safe Mode with ACPI enabled is no harder than toggling Safe Mode on 
[first] before [then] re-enabling ACPI (followed by ENTER).


  (Assuming we haven't removed the ability to disable ACPI from 
 the menu, if we have we should perhaps put that back). Having them be 
 orthogonal knobs would seem to the be the best approach.
 

+1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe Mode 
knows about ACPI but only acts on it when being enabled).
-- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fwd: Effect of Processor and Memory on KDE4 execution speed

[Devin Teske]

On Tue, 2012-02-21 at 14:42 -0800, Robison, Dave wrote:
 
 
  Original Message   
   Subject: 
 Effect of Processor and Memory on
 KDE4 execution speed
  Date: 
 Tue, 14 Feb 2012 09:39:36 -0500
  From: 
 Mehmet Erol Sanliturk
 m.e.sanlit...@gmail.com
To: 
 FreeBSD Current
 curr...@freebsd.org
 
 
 Dear All ,
 
 Today I have encountered a case which I think informing you about it may be
 useful .
 
 In my previous messages , I have mentioned very slowness of KDE4 .
 
 
 Onto another computer I have installed DruidBSD 9.0 b56 amd64 , and KDE4 .
 In that installation KDE4 worked surprisingly fast .
 

Great! Glad to hear it's fast!

Though, a couple corrections about the statement above.

First correction:

You meand FreeBSD Druid, not DruidBSD.

The FreeBSD Druid is a FreeBSD installer.
The DruidBSD is a micro distribution that can't/doesn't install
anything.

Second correction:

The FreeBSD Druid installs a vanilla, completely unmodified
RELENG_9_0_RELEASE copy of FreeBSD (albeit using sysinstall(8) instead
of bsdinstall(8)).


 To understand whether difference is among FreeBSD or DruidBSD , I have
 installed
 FreeBSD 9.0 Release amd64 and KDE4 on the same computer instead of DruidBSD
 .
 
 The KDE4 has worked flawlesly i.e. , means very fast .
 

Cool. Glad to hear it's fast there too (makes sense; see below)

With respect to the binaries that are being laid-down by the FreeBSD
Druid, there is no difference in comparison to the official installer.

However, the FreeBSD Druid does do some post-install configuration of
the system that the official installer does not (though none of these
customizations should have any effect on KDE in any way shape-or-form):

1. It enables sshd root login in /etc/ssh/sshd_config
2. It enables netwait in /etc/rc.conf (by adding netwait_enable=YES)
3. It installs perl-5.14 (as a package so if you don't want it, you can
pkg_delete it to get rid of it)
4. It sets the root password
5. It installs /usr/local/sbin/host-setup
6. It configures root login-shell to be /usr/local/sbin/host-setup for
easy setup on first-login (once exited, must be run manually henceforth)
7. It installs rsync (as a package, so if you don't want it you can
pkg_delete it)
8. It installs bonnie (as a package; don't want -- pkg_delete)
9. Enables SU+J on /tmp /var and /usr

None of these customizations should have any effect on system
performance whatsoever.

So I recommend not treating this as a FreeBSD Druid versus FreeBSD
problem.

NOTE: and again, DruidBSD is not an installable OS, only a micro Live
Distribution used for doing rescues or simply booting into a mfs
environment.



 To make equivalent the installations on both computers , I have installed
 FreeBSD 9.0 Release amd64 and KDE4 on the slow computer exactly as in fast
 computer .
 

I'm confused.

In the immediately-above paragraph you mention a fast computer and a
slow computer. But in the paragraphs that proceeded it, I only see
mention of fast-running KDE4.

If you read the previous paragraphs carefully, you're stating that both
installers (FreeBSD Druid and the official, both) produced fast-
running installations of KDE4.

Which is it?


 
 Starting times after first boot ( to eliminate initialization effects ) are
 the following
 ( All timings are from root ) :
 

Is this on the box that was installed with FreeBSD Druid or box
installed with official 9.0-RELEASE media?


 From startx ( which contains exec ... kde4 ... )
 to   appearance of KDE menu symbol at the bottom left corner :
 
 
 Fast computer : 8 GB : 0+ (  1 ) minute ( 4 x 2 GB )
 Slow computer : 4 GB : 2+ (  3 ) minutes ( 2 x 2 GB ) ( 2 x ! GB chips
 removed ) ,
 6 GB : 8+ (  9 ) minutes ( 2 x ( 2 , 1 ) GB ) .
 ( Memory chip installation conforms to main board manual . )
 ( The clock does not have second counter . )
 
 Fast Computer
   CPU : Intel Pentium Dual CPU E2220 @ 2.40 GHz ( 2397.65-MHz K-8class CPU )
   ACPI APIC Table :  INTEL DG965WH 
 
 Slow Computer
   CPU : Intel Core 2 QUAD CPU Q6600 @ 2.40 GHz ( 2397.65-MHz K-8class CPU )
   ACPI APIC Table :  INTEL DG965WH 
 
 ( The main boards are the same ) .
 ( All of the memory chips are the same : Kingston HyperX 800 MHz )
 

In your metrics above, which machine (fast vs slow) was installed with
which installer?



 I could not understand the reason(s) of the differences .
 

Disk partitions? (I'm guessing).

There's really no difference between what the official 9.0-RELEASE
installer installs and what the FreeBSD Druid installs. They were both
compiled from RELENG_9_0_RELEASE within a day from each other. The
likelihood that the binaries would differ with respect to code they were
compiled from is highly unlikely.

NOTE: The installed kernel should even have the same MD5 (can't say the
same for the rest of the system, because I did have to do a fresh

Re: Kernel Tracking Question.. regarding kernel and boot files

[Devin Teske]

On Apr 9, 2011, at 9:46 PM, Julian Elischer jul...@freebsd.org wrote:

 On 4/9/11 2:51 PM, Chris Richardson wrote:
 On Sat, Apr 9, 2011 at 10:34 PM, Chuck Swigercswi...@mac.com  wrote:
 
 Hi, Chris--
 
 [ ...Reply-to: set to direct towards the most appropriate list... ]
 
 On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote:
   I am totally new to FreeBSD. I was involved within project which will
 trace the kernel. I used ktrace but I could not get appropriate results
 about the files being opened. I don't see any of the boot files boot0-1
 or 2
 in the ktrace.out file. Where did they go?
 The bootstrap loader stages are what loads and runs the kernel.
 ktrace isn't available until afterwards, when the kernel is running.
 
 Is ktrace the best trace suite for freebsd kernel?
 Kinda depends on what you are doing.  Setting up good logging and making
 userland
 interfaces for getting to useful information (cf vmstat, ps, iostat, etc)
 is
 more likely to be useful over the longer run.
 
 
 What about if I wanna see the interaction between boot process and kernel
 loading.
 
 either you run it under an emulator that allows you to single step it.
 or you just add a lot of printf() to the boot loader.
 (some parts are required to fit in small code sizes to adding prints will 
 cause overflow..)
 best to read the docs and then the sources. then it wil become apparent to you
 what you want to find out.

You also have the option of writing Forth modules for the boot-loader. Even 
dropping to the ok prompt is enough to give you full access to the built-in 
Forth interpreter. You can query the variables that are set in the 
environment (which are different depending whether you've booted via pxeboot, 
cdboot, or other method). You can even do some limited device poking and 
file-io (both read and write).

The benefit of the forth modules is that you can use it to produce the 
necessary debug output whilst avoiding the overflow issue. That is to say, that 
one technique I've used is to add code to the loader to export some string or 
value of interest to a variable in the environment that I would then add 
something like 'echo debug == $debug' to loader.rc. Keeps the loader small 
and the human fluff off to the interpreter.

 
 
 What about going through source code .. Is it better to
 use Combination of Ecllipse/Qemu and FreeBSD Source tree?
 Eclipse is an editor.  If you like it in particular, free free to use it,
 otherwise pick something else you'd prefer to use for C code.

I use a combination of vim (as my editor) and CVSweb (URL is in the handbook) 
for historical research as necessary.

Just my tuppence.
-- 
Devin

 
 Does this method will provide us with someway to see how booting process
 invokes
 the kernel to memory ? Any help will be appreciated.
 You're asking about the process here:
 
 
 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html
 
 ...?  Frankly, none of these are especially big, start by reviewing the
 source
 code for 'em.
 
 
 Yeah. this file provides me with the stages in theoretical way. How about
 implementing it using qemu to emulate livecd to see what is going on boot0.
 Do you have an idea about that ?
 
 Good Luck,
 
 
 Regards,
 --
 -Chuck
 
 
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 
 
 ___
 freebsd-hack...@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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: vmware-tools-freebsd No drivers for x.org version: 7.6.5.

[Devin Teske]

On Apr 8, 2011, at 5:03 AM, Matthias Apitz g...@unixarea.de wrote:

 El día Friday, April 08, 2011 a las 12:17:03PM +0200, Dimitry Andric escribió:
 
 On 2011-04-08 10:42, Matthias Apitz wrote:
 I have FreeBSD 9-CURRENT up and running in a VMware Workstation 7.x and
 I tried to install the vmware-tools-freebsd of VMware to get the driver
 for Xorg, but it seems that X.org 7.6.5. is not supported. My other VM
 runs a 8-CURRENT with X.org 7.4_1 which works fine.
 
 Any idea how to solve this?

A co-worker and I recently went through this. Seems the trick is to install 
xf86-video-vmware-10.16.9 (we are using 8.1-RELEASE), then re-run the 
vmware-config.pl file that you un-packed from the vmware-tools tarball, then 
run X -configure (as root), then copy /root/xorg.conf.new to 
/etc/X11/xorg.conf (making appropriate backups first, of course). We were able 
to achieve 1600x1200 resolution.
-- 
Devin


 Should I go back to X.org 7.4_1 in
 9-CURRENT? Or should I fake the vmware-tools installer to see X.org as
 /.4 while it is 7.6.5?
 
 X.org 7.5 already has VMware drivers, so you can just install the
 x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware ports.
 
 Alternatively, run make config in x11-drivers/xorg-drivers, check the
 VMMOUSE and VMWARE entries, and rebuild this meta-port.
 
 Dimitry, 
 
 Thanks for your kind   fast answer; does this also mean that I could
 completely get rid of the VMware' vmware-tools-freebsd? I'm using on the
 8-CURRENT system the emulators/open-vom-tools and will install them in
 the 9-CURRENT too.
 
 Thanks again
 
matthias
 
 -- 
 Matthias Apitz
 t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
 e g...@unixarea.de - w http://www.unixarea.de/
 ___
 freebsd-questi...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to freebsd-questions-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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD Installer Roadmap

[Devin Teske]

On Feb 21, 2011, at 11:03 PM, Josh Paetzel wrote:

 On Monday, February 21, 2011 08:38:03 pm Devin Teske wrote:
 
 
 Really, the crux of the issue is that our organization is **just now**
 migrating off of FreeBSD-4 (yes, it's true... there are over 1,000
 FreeBSD-4.11 machines running in production at this very moment spanning
 the entire United States, parts of India, and parts of the Indo-pacific
 rim). Worse? We just added yet-another 200+ to those ranks in the past 2
 months.
 
 My hat is off to you sir... as I envy your position that you can be so
 free-moving. We are encumbered by entrenched methods and do not have the
 luxury of trying new things for the sake of change (case in-point, since
 bsdinstall brings nothing new to the table that we rely upon, it truly
 would be change for the sake of change in our organization).
 
 Fin de dialectics.
 
 
 
 
 --
 Cheers,
 Devin Teske
 
 Maintaining sysinstall for 4.x is indeed a NOOP, since features aren't being 
 added to it, and the featureset that sysinstall supports is pretty much in 
 line with the featureset in 4...no ZFS, no geom_*, etc etc etc.
 
 On the other hand, maintaining sysinstall for the next N years of new FreeBSD 
 releases seems hard

Actually, it's trivial to anyone that has mastered release engineering (see 
release(7) and the handbook).


 , when it's already missing features compared to what 
 FreeBSD supports,

That's the operative word here (supports). Lord help us when that changes to 
requires (that is to say, if/when the FreeBSD kernel becomes legacy-free with 
respect to supporting fdisk/disklabel partitioned disks).


 and that's likely to continue to grow.

We've yet to see a must have technology that would require us to shun 
sysinstall (as explained earlier, we have no desire whatsoever to boot from 
ZFS, gmirror, geli, GPT, or anything else missing from sysinstall).

One such possible motivation would be if we needed to create a boot partition 
that exceeds 4TB (the limits of MBR partitioning versus GPT). I just don't see 
that happening (workstations, servers, pedestals... why would we ever need 8GB 
for the operating system? all production data is being stored on enterprise 
class devices such as the NEC-D210, and being backed up with tapes such as LTO; 
In our organization every machine is expendable and we have disaster recovery 
procedures for any/all failures).


 
 I totally agree that for internal use, migrating thousands of lines of code 
 makes no sense whatsoever, especially if sysinstall meets your needs and you 
 don't care about the functionality it doesn't have.  Exporting that to the 
 community seems to be a questionable use of resources.
 
 I'm no stranger to large deployments.  With my ${WORK} hat on we can install 
 a 
 thousand FreeBSD systems in a week.  In my 16+ years of involvement with 
 FreeBSD I've written three automated installers...quite frankly, ditching 
 sysinstall for that happened really fast.

Good work.

However, it's a shame that you found the need to ditch sysinstall. We found no 
such need and have created an automated network installation process literally 
on the assembly line in a factory the size of a football stadium -- responsible 
for churning out thousands of machines per year with FreeBSD-4.11 pre-installed 
before they arrive on-site (all using sysinstall). The hardware gets assembled 
to-spec, slides down an assembly-line, a technician jacks power, network, video 
and keyboard to the box, netboots it by pressing F12, waits 5 minutes for the 
screen to finish installation, powers it off, and slides it down the line.



 I do admit to being a tad curious where you find systems that can run FreeBSD 
 4 at this point.

We're installing FreeBSD-4.11 onto modern systems, including:

Intel Server Chassis SC5299
Intel Server Chassis SR2500

just to name a couple.

Albeit, we've back-ported many drivers, such as mfi(3) from RELENG_6 to support 
the LSI MegaSAS controller.

We're no stranger to putting even the Operating System on Life Support for as 
long as it takes for our customers to bolster their budgets for an integrated 
upgrade strategy.

We have a very small yet largely talented group of individuals (including 
myself) within our organization that quickly and efficiently remediate lost 
functionality required to maintain hardware compatibility simply because our 
customers cannot stomach upgrading the OS every 18-months (or whatever the 
life-cycle may be). We can't be forcing our customers to upgrade their entire 
organization everytime the OS can't boot from some new controller -- not when 
adding the lost functionality into the OS is only a matter of a couple weeks 
work (at most).

So in earnest, I should have clarified that despite running FreeBSD-4.11 on 
thousands of machines... it's actually a highly customized kernel _and_ install 
process that allows us to run on modern hardware.



  A single socket intel shows up as 8 or 12 CPUs these days

Re: FreeBSD Installer Roadmap

[Devin Teske]

On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote:

 On 2011-Feb-22 02:50:54 -0800, Devin Teske dte...@vicor.com wrote:
 That's the operative word here (supports). Lord help us when that
 changes to requires (that is to say, if/when the FreeBSD kernel
 becomes legacy-free with respect to supporting fdisk/disklabel
 partitioned disks).
 
 When that does come, it will probably be driven by BIOS and hardware
 vendors dropping support for MBR.  Current disks are at the upper
 limit of what MBR can be support (and that's after several revamps of
 MBR).  Since GPT already provides a superior feature set without MBR's
 limits, the next step will be to just drop MBR support.  And when it
 does come, FreeBSD needs to be ready with an installer that can cope
 with non-MBR disks.

All very true.

Though admittedly we're [as a technological society] still a long long ways off 
from dropping support for MBR in even the most modern BIOS'.



 
 We've yet to see a must have technology that would require us to
 shun sysinstall (as explained earlier, we have no desire whatsoever
 to boot from ZFS, gmirror, geli, GPT, or anything else missing from
 sysinstall).
 
 Whilst _you_ might not be interested, lots of other people _are_
 interested in using these features - I personally use a mixture of
 gmirror, GPT and ZFS root on different systems.

Excellent. And the likes of us (enterprise) will be watching the likes of you 
(non-enterprise) for many years to come to see how you fare in your travels. 
From time to time we'll be checking in on the list and perusing list archives 
to see how well you fare.

I don't know if you remember, but I can remember 10+ years ago when ReiserFS 
(the *killer* filesystem -- sorry, I couldn't resist) hit the Linux scene. 
There were wild reports of comprehensive data loss even in the 3rd year of its 
production cycle. It was stories like that which kept down the rate of adoption 
because many enterprises adopt the same wait and see attitude. We call it the 
great shake out and all new technologies must have one before being adopted 
by the largest enterprises.


  Why should other
 people be forced to avoid these features just because you don't use
 them?

They shouldn't. We encourage others to dive head-long into the soupy mix and be 
our guinea pigs for us.

Innovation is no place for the enterprises that run the market place (or even 
the World).

(in a very serious tone) Would you rather your bank call you up and explain 
that because they tried some new technology that caused a crash in the data 
center, you won't have access to your bank account for the next few hours 
whilst they reboot the master server?

Just as I suspect your answer would be no, it should be self-evident that when 
a critical system goes down, there is not always the luxury of being able to 
drop to gdb/kdb and diagnose the root-cause (rather, disaster recovery 
procedures often demand focusing your efforts on getting said service -- if not 
the original machine, a replacement machine -- back online as fast as humanly 
possible). Whereas others may have the luxury of providing backtraces, core 
dumps, and swapfiles to the authors of some new kernel device driver to 
eventually have some critical bug fixed, the downtime required to cull those 
resources would decimate any profit-driven business model which relies on 
service uptime.

It's very easy to forget that -- while playing with new technologies is both 
fun _and_ exciting -- businesses that make the world go-'round demand more than 
just the promise of stability, they demand the numbers to prove it (and even 
then, may still require their own engineers to perform an in-house bake-out 
of their own which involves the added complexity of working with their own 
code). Rolling in any replacement anytime anywhere requires burn-in metrics 
to show that the technology can reproduce an acceptable fault-to-performance 
ratio. Of course, it goes without saying that said stringent testing requires 
both resources and man-hours.


  FreeBSD's installer should support the same features as FreeBSD
 itself for consistency.

I don't disagree. That's a laudable goal for all Operating Systems. Though with 
due respect, I don't think any one installer for any operating system allows 
you to achieve all permutations of which the OS itself supports.


 
 pedestals... why would we ever need 8GB for the operating system?
 all production data is being stored on enterprise class devices such
 as the NEC-D210, and being backed up with tapes such as LTO;
 
 Not everyone uses FreeBSD in the same environment as you.

Oh how society would stagnate if we _did_. Thank goodness we _don't_ operate in 
the same environments (for your sake and mine).



 
 We're no stranger to putting even the Operating System on Life
 Support for as long as it takes for our customers to bolster their
 budgets for an integrated upgrade strategy.
 
 Given that you've already said you are staying with FreeBSD

Re: FreeBSD Installer Roadmap

[Devin Teske]

On Feb 22, 2011, at 7:41 PM, Garrett Cooper wrote:

 On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske dte...@vicor.com wrote:
 
 On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote:
 
 On 2011-Feb-22 02:50:54 -0800, Devin Teske dte...@vicor.com wrote:
 That's the operative word here (supports). Lord help us when that
 changes to requires (that is to say, if/when the FreeBSD kernel
 becomes legacy-free with respect to supporting fdisk/disklabel
 partitioned disks).
 
 When that does come, it will probably be driven by BIOS and hardware
 vendors dropping support for MBR.  Current disks are at the upper
 limit of what MBR can be support (and that's after several revamps of
 MBR).  Since GPT already provides a superior feature set without MBR's
 limits, the next step will be to just drop MBR support.  And when it
 does come, FreeBSD needs to be ready with an installer that can cope
 with non-MBR disks.
 
 While I love a good discussion (and there have been a number of good
 points for either side on here), should we agree to switch the default
 over to bsdinstall, leave sysinstall in (lumps or no lumps), then over
 the period of the next 2~3 major (that amounts to 4~6 years) releases,
 and retire sysinstall to the happy hunting grounds? sysinstall didn't
 take up that much space on the release media I thought, and it might
 be doable to map both sets of media so that sysinstall can work in
 harmony on bsdinstall's release media?
 
 Preparing custom releases to use the sysinstall init_path isn't that
 bad, so it would at least give the legacy folks time to transition
 over while us guinea pigs burn in the new wax :)...
 
 Sound good?

Love it. Absolutely love it. You are a uniter, sir (tips hat)!



 
 Thanks!
 -Garrett

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

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD Installer Roadmap

[Devin Teske]

On Feb 21, 2011, at 2:12 PM, Josh Paetzel wrote:

 On Saturday, February 19, 2011 02:44:42 am Bruce Cran wrote:
 On Saturday 19 February 2011 03:04:39 Devin Teske wrote:
 There are many reasons for this, and none of them are selfish (although
 it remains possible to drum-up some selfish reason, all of the reasons
 behind our motivation are in-fact unselfish). Truth-be-told, I welcome
 the replacement of sysinstall but am very wary that ANY replacement will
 be able to exactly replicate the hardware compatibility that sysinstall
 currently enjoys. I do indeed envision a great celebration as FreeBSD-9
 bucks sysinstall but also at the same time have nightmares of receiving
 waves of calls from people having trouble (for example) installing
 FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a
 universe far-far-away. (yes, we do have data centers running that very
 equipment with uptime in the 1,000's of days).
 
 I think bsdinstall as it currently is is simple enough that there shouldn't
 be any compatibility issues: it uses gpart for partitioning, runs tools
 like tzsetup to configure settings etc. so there's far less to go wrong
 than sysinstall's custom code which for example could crash on the
 probing devices screen.
 
 pc-sysinstall has been used as the PC-BSD installer for quite a while now, 
 and 
 has done a lot of installs on a lot of different hardware platforms.  I'll 
 wager that the compatibility of the shell command gpart is a better bet than 
 the stick your thumbs in you ears and yell nananana while you scribble 1's 
 and 0's to a disk and voila, there's a disklabel approach that sysinstall 
 uses.

This is a common affront that can be assuaged simply by perusing sysinstall's 
code. Unfortunately, I may be truly-alone in my opinion that sysinstall is 
elegantly simple (but then again, I also have an innate understanding of why 
each/every line of code exists; bourne in-truth from a decadal melange of 
knowledge when it comes to ancient architectures -- that and I routinely read 
the 15+ years of commit logs for fun).

In reality, the _only_ thing, in my honest opinion, that sysinstall fails-at is 
its embracement of new technologies such as GPT, ZFS, and geli (just to name a 
few; all of which you mention below). However, this is not the position that I 
am (or we are, as a business collective) coming from. From the position at 
which we stand, sysinstall  is not [yet] deficient and despite your claims, 
neither does it resort to black-magic scribbl[ing] 1's and 0's to a disk and 
voila, there's a disklabel (by comparison standards, might one be able to say 
-- if taking the same naive tone -- that gpart scribble[s] 1's and 0's and 
voila, there's a [partition table]; the only distinction being perhaps your 
own bias of MBR versus GPT which if you conversely understood the limitations 
of MBR then you might not have such qualms against disklabels).

Just as it was stated by another in this thread that a system with 1,000+ days 
uptime may not be a good candidate for upgrade (entirely on the basis that such 
a system in its current state has proved its meddle), we make an argument along 
the same lines for the install process -- because sysinstall has served us *so 
exquisitely well* over the years (its meddle being proven) we are reluctant to 
blindly accept the new kid on the block without rigorous recension (note: in 
comparison by age, any technology is young when compared to sysinstall).


 
 That being said, sysinstall holds FreeBSD back in a lot of ways, using GPT 
 labeling, installing to ZFS, or gmirror, using geli, all require you to boot 
 to a shell and do an install by hand. I'm sure more people can chime in to 
 limitations in sysinstall than I can think of off the top of my head.

You are absolutely correct in highlighting the most prominent short-comings of 
sysinstall, but alas if you don't need those features then completely swapping 
out your installer for a new one begins to make less sense than sticking with 
what has served (and will continue to serve) you well.

The long and the short of this is, we don't use GPT, we don't (and wouldn't) 
use ZFS as a root partition scheme, and have no use for geli on the root disk 
(though may venture into using geli as a PCI solution -- 
pcisecuritystandards.org -- on secondary media mounted at boot-time).

Philosophically, innovation is bourne of necessity -- and we don't need any of 
the things that bsdinstall brings us ... so the only thing that bsdinstall 
represents is more work for me in migrating thousands upon thousands of lines 
of code to the new installer, vetting every aspect of the new installer in the 
process (note that we utilize sysinstall in ways that others could only dream 
of -- something you'll be able to see for yourself when I get back from Hong 
Kong to The States and start publishing our/my work).

That being said, if we _did_ need the features that are provided by bsdinstall 
versus what

Re: FreeBSD Installer Roadmap

[Devin Teske]

 homage to 
your roots).



 ___
 freebsd-sysinst...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-sysinstall
 To unsubscribe, send any mail to freebsd-sysinstall-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.

- FUN STUFF -
-BEGIN GEEK CODE BLOCK-
Version 3.12
GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E-
W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+
D+(++) G++ e h r+++ z+++
--END GEEK CODE BLOCK--
http://www.geekcode.com/

- END TRANSMISSION -

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFC] Rewriting sade(8)

[Devin Teske]

I too love the idea of generalizing (abstracting) the dirty-work to a
set of libraries and leaving the user interface up to the userland
applications. Thusly, an app in /usr/X11R6/bin can use said libraries in
plugging in functionality to an X11 GUI application, meanwhile an app
in /bin or /sbin (presumably, since we're talking about low-level system
utilities) could use the same libraries for plugging the same
functionality into a command-line interface (beit command-driven or
ncurses/libdialog driven).

However, I'm still wondering what that change would mean to our beloved
sysinstall when it comes time to place sysinstall into the mfsroot for
the CD-ROM installer.

Currently, the mfsroot contains very little in the ways of ELF binaries:

-sh, [ (test), arp, boot_crunch, camcontrol, cpio, dhclient, find,
fsck_4.2bsd, fsck_ffs, fsck_ufs, gunzip, gzip, hostname, ifconfig,
minigzip, mount_nfs, newfs, ppp, pwd, rm, route, rtsol, sed, sh,
sysinstall, test, tunefs, usbconfig, and zcat

Every last one of those is (a) statically linked and (b) hard-linked to
one-another (really, they are all hard-links to boot_crunch which is a
by-product of crunchgen(1)).

What might the landscape look like if we move down the road toward
separating the back-end from the front-end?

Presumably though, we could simply put the bits back together, no?
Currently, the following libraries are slurped into the crunchgen
configuration:

-ll, -ledit, -lutil, -lmd, -lcrypt, -lftpio, -lz, -lnetgraph, -ldialog,
-lncurses, -ldisk, -lcam, -lsbuf, -lufs, -ldevinfo, -lbsdxml, -larchive,
-lbz2, -lusb, and -ljail

Which I show to be these files in RELENG_8:

/usr/lib/libl.a
/usr/lib/libedit.a
/usr/lib/libutil.a
/usr/lib/libmd.a
/usr/lib/libcrypt.a
/usr/lib/libftpio.a
/usr/lib/libz.a
/usr/lib/libnetgraph.a
/usr/lib/libdialog.a
/usr/lib/libncurses.a
/usr/lib/libdisk.a
/usr/lib/libcam.a
/usr/lib/libsbuf.a
/usr/lib/libufs.a
/usr/lib/libdevinfo.a
/usr/lib/libbsdxml.a
/usr/lib/libarchive.a
/usr/lib/libbz2.a
/usr/lib/libusb.a
/usr/lib/libjail.a

I think I just answered my own question...

We should have no problem re-incorporating any heretofore developed
libraries (for the back-end functionality) *back into* the crunchgen
(1)'ed binaries.

In fact, if we, say for example, developed /usr/lib/libsysinstall.a
and /usr/lib/libsade.a , we could then simply just patch
`/usr/src/release/i386/boot_crunch.conf' in the following manner:

[dte...@push800 /usr/src/release/i386]$ diff -u boot_crunch.conf{.bak,}
--- boot_crunch.conf.bak2010-04-08 07:10:49.0 -0700
+++ boot_crunch.conf2010-04-08 07:10:27.0 -0700
@@ -46,3 +46,4 @@
 libs -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph
 libs -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo
 libs -lbsdxml -larchive -lbz2 -lusb -ljail
+libs -lsysinstall -lsade

Assuming of course that `release' (and intrinsically `buildworld') is
made to generate the libraries
at /R/stage/trees/base/usr/lib/libsysinstall.a
and /R/stage/trees/base/usr/lib/libsade.a (and respectively for
`buildworld', /usr/obj/usr/src/tmp/usr/lib/libsysinstall.a
and /usr/obj/usr/src/tmp/usr/lib/libsade.a).

So, I guess my fears of mucking up the install environment are
unfounded.

All-in-all, I'm right there with y'all on the idea of separating the
front-end from the back-end. It needs to be done (and will open up a
flurry of new installer interfaces and utilities that require low-end
stuff usually own made-available by sysinstall internals).
--
Devin

On Thu, 2010-04-08 at 16:19 +0200, Dag-Erling Smørgrav wrote:
 John Baldwin j...@freebsd.org writes:
  Dag-Erling Smørgrav d...@des.no writes:
   My suggestion is to add a sysinstall mode to sade where it
   operates under certain (minor) constraints and reports what it did
   in a format that sysinstall can parse, so sysinstall can just
   fork-exec sade instead of duplicating the code.
  Actually, I would rather have sysinstall just invoke sade to do the
  disk related stuff.
 
 ...which is exactly what I said - but in the sysinstall case, you may
 want to ask some additional questions (are you sure you want to proceed
 without a swap partition?) or place some additional constraints (such
 as don't allow the user to mount something on top of /mnt or /rescue),
 and sysinstall needs to know the outcome.
 
 DES
-- 
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

Re: [RFC] Rewriting sade(8)

[Devin Teske]

(( wishing that I hadn't un-CC'd the group on earlier e-mails ))

Some concerns that I have with separating the code into a back-end
versus front-end...

1. Is it currently the idea that -- when it comes down to the crunchgen
stuff -- we are going to re-work the code that generates the non-shared
binaries for mfsroot? or move away from the crunchgen/mfsroot paradigm?

2. If moving away from crunchgen/mfsroot, ... are we effectively making
the statement that we no longer support installing FreeBSD on your
floppy-enabled kitchen toaster? I'm not saying that there's an
overwhelming need to retain the ability to install FreeBSD via
floppy, ... but it uber-legacy support is something to be proud-of (just
as lack-thereof could perhaps be something to be ashamed of -- I can
fall into either camp channeling visions of Steve-Jobs-style mac-like
shunning of the floppy drive or even Bill Gates almost sickening legacy-
support of DOS).

3. We could abandon chrunchgen/mfsroot and simply load up all the back-
end bits with the front-end bits for sysinstall to function in the
installer environment ... but my quarrel is ... will it still fit on a
floppy? if not, are we prepared to deprecate that? otherwise, does
anyone care that the installer environment will be changing from a
collection of staticallly-linked binaries to a mess ?

I actually have a really nifty idea for deprecating mfsroot... and
that's to start using syslinux as the boot-loader (which as of version
3.84 supports booting *.iso files). We're doing that in our company
now... we have a CD-ROM that boots SYSLINUX and displays a menu with
many options (among them FreeBSD). Selecting FreeBSD from the menu
uses SYSLINUX's memdisk module to then boot `mdroot.iso' which
essentially an `mfsroot'. The benefit here is that the `mdroot.iso' can
be built cross-platform (matters not if you download our CVS tree to a
Linux box or FreeBSD box... as long as you have `mkisofs' you can
compile the disc and all incumbent file systems).

The further beauty of this method is that the resultant mdroot.iso can
be large (currently 14MB in our company ... but that's only because it
contains two monolithic custom kernels which -- because we have a custom
boot loader that allows us to cycle through any number of kernels at
boot time to select the proper one for the hardware in question).
--
Devin




On Thu, 2010-04-08 at 15:08 +0100, Rui Paulo wrote:
 On 8 Apr 2010, at 13:49, John Baldwin wrote:
 
  On Thursday 08 April 2010 5:05:34 am Dag-Erling Smørgrav wrote:
  Alexander Leidinger alexan...@leidinger.net writes:
  Please consider using SVN instead. A lot more users will be able to
  check out from there.
  
  We don't grant non-committers access to the Subversion repo.
  
  It looks like other people had a look at sysinstall, not at sade. As
  sysinstall is supposed to be used at installation time, and the intent
  for sade was to offer the functionality (or more) of the part of
  sysinstall which is useful after installation (and to prevent admins
  from using sysinstall after the installation to prevent some unwanted
  foot-shooting), I do not think that we need to think about a strong
  lock between sysinstall and sade.
  
  Yes we do.  Otherwise we'll just end up back where we are today, where
  if you want anything more complicated than a single-disk install you
  have to drop into the fixit shell and do it manually before running the
  installation procedure.  Anythig that sade can do, we want sysinstall to
  do as well, and we don't want to implement everything twice.
  
  My suggestion is to add a sysinstall mode to sade where it operates
  under certain (minor) constraints and reports what it did in a format
  that sysinstall can parse, so sysinstall can just fork-exec sade instead
  of duplicating the code.
  
  Actually, I would rather have sysinstall just invoke sade to do the disk 
  related stuff.  Also, I think sysinstall should allow for a back-door 
  mode 
  where a user can setup partitions however they like and mount them at /mnt 
  and 
  then let sysinstall use the setup the user created.  This will allow users 
  to 
  setup more complex setups that sysinstall/sade do not currently support and 
  allow sade to focus on simpler, common usage cases w/o having to handle 
  painful edge cases.  It would also allow for new modules to be added to 
  sade 
  over time w/o requiring it to support every possible disk layout from the 
  beginning.
 
 I couldn't agree more.
 
 Regards,
 --
 Rui Paulo
 
-- 
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

Re: [RFC] Rewriting sade(8)

[Devin Teske]

Randi and I were discussion the possibility of having sysinstall
remember what you did and then able to write out a suitable
`install.cfg' file that could be subsequently used to perform a human-
less automated install with the same settings.

To expand a little on that...

I'd like to draw a similarity to AppleScript. If you are familiar with
AppleScript, you know that one can launch on Macintoshes (going back as
far as Mac OS 7.0.1) an application known as the Script Editor which
had a Record button in the [then] top-left corner of the window. After
clicking that Record button, the system then recorded what you did
(including in the Desktop [Finder] and other 3rd-party programs) and
saved a series of scripted commands which could simply be Run (or
optionally saved into an executable script) to reproduce everything you
did at-once.

The way that this worked was by way of the developer plugging in
specific resources (if you're familiar with the ol' days, you'll
undoubtedly remember ResEdit -- specifically, a developer would add an
'aete' resource to the RSRC fork of the HFS file structure (among
others). Then, when a scriptable-action was performed within the
application, rather than calling some internally obscure sub-routine to
perform the task, the developer would have the application actually send
an AppleScript event to the MacOS which then sent it back to the
application. Therefore, when the ScriptEditor is recording, what it
records is the events being passed from the application to itself as you
go about clicking, dragging and typing things.

It is in this manner that I think we would be best served in
contemplating a self-scripting engine.

That is to say, that -- altogether now -- we:

a. separate the GUI front-end from the actual tasks that need to be
performed (back-end; for example, tasks to partition disks, perform
newfs, etc. etc.)

b. have either all commands in the library pass through a dispatcher
or only export a single dispatcher function from the library (requiring
all commands to pass through this single function)

Then it would then (I perceive) perhaps become a trivial task to have
the dispatcher record the events.

Another benefit of this would be that it wouldn't matter whom or what
performed anything at all... there would be a mechanism for recording
what was done regardless. And thus, we would usher in the age of being
even the lay user being able to script the installer to do his/her
bidding.

No?
--
Devin




On Thu, 2010-04-08 at 12:48 +, Kris Moore wrote:
 On 04/08/2010 16:30, Marian Hettwer wrote:
  On Thu, 08 Apr 2010 10:53:48 +, Kris Moorek...@pcbsd.org  wrote:
 
  It's not nice to hijack a topic, but this is way to interesting for me, so
  I do it anway :)
 
 :) I didn't mean to hijack either, was trying to discuss advantage of 
 having backend
 as a executable vs a library which can't be used standalone without 
 front-end.
 This would in effect lock you completely into front-end logic, which may 
 not meet
 a users specific needs, even though backend can do what user wants.
 
  This has a few advantages, in that the backend can be used stand-alone
  for scripted installations and also provide great flexibility
  to the front-end developer. They don't need to worry about performing
  any of the actual installation logic, they just provide a way
  for users to select their installation options, generate a configuration
   
 
  script, and let the backend run with it.
   
  scripted installation!
  Are you able to do a pxeboot, nfsroot and then scripted installation?
  Are those scripts portable to FreeBSD or PC-BSD only?
  Could you give me a hint where to find them?
 
  TIA,
  Marian
 
 
 Correct, every install it does is a fully-scripted installation, and
 it can be used with pxeboot, or in a custom mfsroot image easily.
 Supports ZFS, glabel, gmirror, geli, GPT, gpart, vanilla FreeBSD 
 installs, etc.
 
 http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall
 
 Checkout examples/README for all the gory details of config-file 
 generation.
 
 One caveat, the version in trunk is being very actively worked on by 
 myself at the
 moment to prepare for 8.1, needs more docs, etc ;)
 
-- 
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 -

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo