subject:"Re\: \[CFT\] Patch to bsdinstall to support root\-on\-ZFS and GELI"


On Oct 21, 2013, at 9:04 AM, Teske, Devin wrote:

> 
> On Oct 21, 2013, at 8:50 AM, Allan Jude wrote:
> 
>> On 2013-10-21 11:45, Johan Broman wrote:
>>> Hi!
>>> 
>>> Sorry for the delayed answer. I've patched zfsboot and rebuilt the
>>> release. I now get an error message that ada2 can't be used, which is
>>> correct. Good stuff! :)
>>> 
>>> ( I've recreated the test environment using a KVM guest with four SATA
>>> drives instead of the server I was using. I makes it easier to test
>>> stuff. )
>>> 
>>> Here's the screenshot:
>>> 
>>> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99
>>> 
>>> 
>>> Maybe one should be unable to select drives that are part of a graid
>>> in the first place? Or is that out-of-scope for bsdinstall at this
>>> point? (As I guess that requires too many changes/new lines)
>>> 
>>> 
>>> Cheers
>>> Johan
>>> 
>>> 
>>> On 19/10/13 22:20, Teske, Devin wrote:
 
 On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:
 
> I recreated the graid mirror on ada2 and ada3 and reran the
> installation. I'm unable to scroll the msgbox using PgDn or arrow
> keys. There is no indication that the action failed and I'm returned
> to the ZFS setup screen if I hit OK.
> 
> I have screen shots (taken with my phone) of the msgbox and "ps
> auxwww" output. Let me know what kind of debug info you would like.
> I've put the screen shots here:
> 
> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1
 
 I've added a patch to fix debugging in the zfsboot script...
 
 https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9
 
 Feedback welcome.
 
 Johan,...
 
 Can you see if the patch sheds some better light as to what's failing?
 
 The patch won't fix the problem, but it should give us an accurate error
 message so that we can learn what precisely is returning an error
 status.
 
 Thanks in advance.
 
>> I do notice that Devin's manually prefixing the error message with the
>> tool name, is partially redundancy when the tool does it it self, but we
>> can't always be sure it will do that.
>> 
> 
> The next patchset will fix that.
> 

And it's ready now.

Tarball:
http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/?view=tar

This patch takes debugging a leap beyond where it is now

NOTE: Only for the zfsboot script -- there is another separate effort to
improve the debugging in bsdinstall in-general; those patches are here:
http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/?view=tar
-- 
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] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 21, 2013, at 10:12 AM, Allan Jude wrote:

> On 2013-10-21 12:19, Teske, Devin wrote:
>> On Oct 21, 2013, at 9:06 AM, Allan Jude wrote:
>> 
>>> On 2013-10-21 12:04, Teske, Devin wrote:
 On Oct 21, 2013, at 8:50 AM, Allan Jude wrote:
 
> On 2013-10-21 11:45, Johan Broman wrote:
>> Hi!
>> 
>> Sorry for the delayed answer. I've patched zfsboot and rebuilt the
>> release. I now get an error message that ada2 can't be used, which is
>> correct. Good stuff! :)
>> 
>> ( I've recreated the test environment using a KVM guest with four SATA
>> drives instead of the server I was using. I makes it easier to test
>> stuff. )
>> 
>> Here's the screenshot:
>> 
>> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99
>> 
>> 
>> Maybe one should be unable to select drives that are part of a graid
>> in the first place? Or is that out-of-scope for bsdinstall at this
>> point? (As I guess that requires too many changes/new lines)
>> 
>> 
>> Cheers
>> Johan
>> 
>> 
>> On 19/10/13 22:20, Teske, Devin wrote:
>>> On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:
>>> 
 I recreated the graid mirror on ada2 and ada3 and reran the
 installation. I'm unable to scroll the msgbox using PgDn or arrow
 keys. There is no indication that the action failed and I'm returned
 to the ZFS setup screen if I hit OK.
 
 I have screen shots (taken with my phone) of the msgbox and "ps
 auxwww" output. Let me know what kind of debug info you would like.
 I've put the screen shots here:
 
 https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1
>>> I've added a patch to fix debugging in the zfsboot script...
>>> 
>>> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9
>>> 
>>> Feedback welcome.
>>> 
>>> Johan,...
>>> 
>>> Can you see if the patch sheds some better light as to what's failing?
>>> 
>>> The patch won't fix the problem, but it should give us an accurate error
>>> message so that we can learn what precisely is returning an error
>>> status.
>>> 
>>> Thanks in advance.
>>> 
> I do notice that Devin's manually prefixing the error message with the
> tool name, is partially redundancy when the tool does it it self, but we
> can't always be sure it will do that.
> 
 The next patchset will fix that.
 
 I'm dropping the tool name from the msgbox contents and putting it in
 the title (e.g., '"Error: gpart") that way... even if the tool spits out 
 its own
 name (or not), we'll know what exactly what was going on by looking
 at the title.
 
 
> the graid thing is rather hard to detect, especially when it is a
> faulted array that doesn't even appear in graid status etc.
> 
 I believe the idea behind the script is that whatever you tell it to use 
 will
 be destroyed.
 
 Allan, maybe perhaps we could add some code that attempts to dis-
 assemble a graid to make the disk usable?
 
 Johan, what would you be more apt to expect? That it killed your graid
 or that it gave an error? (/me thinks what the recourse to the error might
 entail -- going to partedit?)
>>> Your recourse would be switching to the shell (control+alt+f4) and
>>> destroying the graid.
>>> 
>>> I am a little hesitant to go destroying graids unprompted. If we had the
>>> geom.confxml parsing, we might be able to detect it and ask the user
>>> what to do
>>> 
>> Well, my concern with going and asking about each/every configuration
>> before we clear it...
>> 
>> Hasn't the user already answered a "Last Chance!" dialog giving the go-
>> ahead to nuke any/all data *and* configurations on a drive?
> I guess that makes sense, We offer the dialog to allow the user to
> investigate their disk in detail so they can be sure they picked the
> correct ones.
> 
> the graid thing is the biggest gotcha because it picks up metadata
> written by the motherboard raid system, so you can have a graid
> configuration even if you have never booted freebsd before.
> 

Hmmm... so what does one do in *that* situation?

Go into the motherboard B

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 21, 2013, at 10:18 AM, Allan Jude wrote:

> On 2013-10-21 13:14, Teske, Devin wrote:
>> On Oct 21, 2013, at 10:12 AM, Allan Jude wrote:
>> 
>>> On 2013-10-21 12:19, Teske, Devin wrote:
 On Oct 21, 2013, at 9:06 AM, Allan Jude wrote:
 
> On 2013-10-21 12:04, Teske, Devin wrote:
>> On Oct 21, 2013, at 8:50 AM, Allan Jude wrote:
>> 
>>> On 2013-10-21 11:45, Johan Broman wrote:
 Hi!
 
 Sorry for the delayed answer. I've patched zfsboot and rebuilt the
 release. I now get an error message that ada2 can't be used, which is
 correct. Good stuff! :)
 
 ( I've recreated the test environment using a KVM guest with four SATA
 drives instead of the server I was using. I makes it easier to test
 stuff. )
 
 Here's the screenshot:
 
 https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99
 
 
 Maybe one should be unable to select drives that are part of a graid
 in the first place? Or is that out-of-scope for bsdinstall at this
 point? (As I guess that requires too many changes/new lines)
 
 
 Cheers
 Johan
 
 
 On 19/10/13 22:20, Teske, Devin wrote:
> On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:
> 
>> I recreated the graid mirror on ada2 and ada3 and reran the
>> installation. I'm unable to scroll the msgbox using PgDn or arrow
>> keys. There is no indication that the action failed and I'm returned
>> to the ZFS setup screen if I hit OK.
>> 
>> I have screen shots (taken with my phone) of the msgbox and "ps
>> auxwww" output. Let me know what kind of debug info you would like.
>> I've put the screen shots here:
>> 
>> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1
> I've added a patch to fix debugging in the zfsboot script...
> 
> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9
> 
> Feedback welcome.
> 
> Johan,...
> 
> Can you see if the patch sheds some better light as to what's failing?
> 
> The patch won't fix the problem, but it should give us an accurate 
> error
> message so that we can learn what precisely is returning an error
> status.
> 
> Thanks in advance.
> 
>>> I do notice that Devin's manually prefixing the error message with the
>>> tool name, is partially redundancy when the tool does it it self, but we
>>> can't always be sure it will do that.
>>> 
>> The next patchset will fix that.
>> 
>> I'm dropping the tool name from the msgbox contents and putting it in
>> the title (e.g., '"Error: gpart") that way... even if the tool spits out 
>> its own
>> name (or not), we'll know what exactly what was going on by looking
>> at the title.
>> 
>> 
>>> the graid thing is rather hard to detect, especially when it is a
>>> faulted array that doesn't even appear in graid status etc.
>>> 
>> I believe the idea behind the script is that whatever you tell it to use 
>> will
>> be destroyed.
>> 
>> Allan, maybe perhaps we could add some code that attempts to dis-
>> assemble a graid to make the disk usable?
>> 
>> Johan, what would you be more apt to expect? That it killed your graid
>> or that it gave an error? (/me thinks what the recourse to the error 
>> might
>> entail -- going to partedit?)
> Your recourse would be switching to the shell (control+alt+f4) and
> destroying the graid.
> 
> I am a little hesitant to go destroying graids unprompted. If we had the
> geom.confxml parsing, we might be able to detect it and ask the user
> what to do
> 
 Well, my concern with going and asking about each/every configuration
 before we clear it...
 
 Hasn't the user already answered a "Last Chance!" dialog giving the go-
 ahead to nuke any/all data *and* configurations on a drive?
>>> I guess that makes sense, We offer the dialog to allow the user to
>>> investigate their disk in detail so they can be

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

On 2013-10-21 13:14, Teske, Devin wrote:
> On Oct 21, 2013, at 10:12 AM, Allan Jude wrote:
>
>> On 2013-10-21 12:19, Teske, Devin wrote:
>>> On Oct 21, 2013, at 9:06 AM, Allan Jude wrote:
>>>
 On 2013-10-21 12:04, Teske, Devin wrote:
> On Oct 21, 2013, at 8:50 AM, Allan Jude wrote:
>
>> On 2013-10-21 11:45, Johan Broman wrote:
>>> Hi!
>>>
>>> Sorry for the delayed answer. I've patched zfsboot and rebuilt the
>>> release. I now get an error message that ada2 can't be used, which is
>>> correct. Good stuff! :)
>>>
>>> ( I've recreated the test environment using a KVM guest with four SATA
>>> drives instead of the server I was using. I makes it easier to test
>>> stuff. )
>>>
>>> Here's the screenshot:
>>>
>>> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99
>>>
>>>
>>> Maybe one should be unable to select drives that are part of a graid
>>> in the first place? Or is that out-of-scope for bsdinstall at this
>>> point? (As I guess that requires too many changes/new lines)
>>>
>>>
>>> Cheers
>>> Johan
>>>
>>>
>>> On 19/10/13 22:20, Teske, Devin wrote:
 On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:

> I recreated the graid mirror on ada2 and ada3 and reran the
> installation. I'm unable to scroll the msgbox using PgDn or arrow
> keys. There is no indication that the action failed and I'm returned
> to the ZFS setup screen if I hit OK.
>
> I have screen shots (taken with my phone) of the msgbox and "ps
> auxwww" output. Let me know what kind of debug info you would like.
> I've put the screen shots here:
>
> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1
 I've added a patch to fix debugging in the zfsboot script...

 https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9

 Feedback welcome.

 Johan,...

 Can you see if the patch sheds some better light as to what's failing?

 The patch won't fix the problem, but it should give us an accurate 
 error
 message so that we can learn what precisely is returning an error
 status.

 Thanks in advance.

>> I do notice that Devin's manually prefixing the error message with the
>> tool name, is partially redundancy when the tool does it it self, but we
>> can't always be sure it will do that.
>>
> The next patchset will fix that.
>
> I'm dropping the tool name from the msgbox contents and putting it in
> the title (e.g., '"Error: gpart") that way... even if the tool spits out 
> its own
> name (or not), we'll know what exactly what was going on by looking
> at the title.
>
>
>> the graid thing is rather hard to detect, especially when it is a
>> faulted array that doesn't even appear in graid status etc.
>>
> I believe the idea behind the script is that whatever you tell it to use 
> will
> be destroyed.
>
> Allan, maybe perhaps we could add some code that attempts to dis-
> assemble a graid to make the disk usable?
>
> Johan, what would you be more apt to expect? That it killed your graid
> or that it gave an error? (/me thinks what the recourse to the error might
> entail -- going to partedit?)
 Your recourse would be switching to the shell (control+alt+f4) and
 destroying the graid.

 I am a little hesitant to go destroying graids unprompted. If we had the
 geom.confxml parsing, we might be able to detect it and ask the user
 what to do

>>> Well, my concern with going and asking about each/every configuration
>>> before we clear it...
>>>
>>> Hasn't the user already answered a "Last Chance!" dialog giving the go-
>>> ahead to nuke any/all data *and* configurations on a drive?
>> I guess that makes sense, We offer the dialog to allow the user to
>> investigate their disk in detail so they can be sure they picked the
>> correct ones.
>>
>> the graid thing is the biggest gotcha because it picks up metadata
>> written by the motherboard raid system, so you can have a graid
>> configuration

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

On 2013-10-21 12:19, Teske, Devin wrote:
> On Oct 21, 2013, at 9:06 AM, Allan Jude wrote:
>
>> On 2013-10-21 12:04, Teske, Devin wrote:
>>> On Oct 21, 2013, at 8:50 AM, Allan Jude wrote:
>>>
 On 2013-10-21 11:45, Johan Broman wrote:
> Hi!
>
> Sorry for the delayed answer. I've patched zfsboot and rebuilt the
> release. I now get an error message that ada2 can't be used, which is
> correct. Good stuff! :)
>
> ( I've recreated the test environment using a KVM guest with four SATA
> drives instead of the server I was using. I makes it easier to test
> stuff. )
>
> Here's the screenshot:
>
> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99
>
>
> Maybe one should be unable to select drives that are part of a graid
> in the first place? Or is that out-of-scope for bsdinstall at this
> point? (As I guess that requires too many changes/new lines)
>
>
> Cheers
> Johan
>
>
> On 19/10/13 22:20, Teske, Devin wrote:
>> On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:
>>
>>> I recreated the graid mirror on ada2 and ada3 and reran the
>>> installation. I'm unable to scroll the msgbox using PgDn or arrow
>>> keys. There is no indication that the action failed and I'm returned
>>> to the ZFS setup screen if I hit OK.
>>>
>>> I have screen shots (taken with my phone) of the msgbox and "ps
>>> auxwww" output. Let me know what kind of debug info you would like.
>>> I've put the screen shots here:
>>>
>>> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1
>> I've added a patch to fix debugging in the zfsboot script...
>>
>> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9
>>
>> Feedback welcome.
>>
>> Johan,...
>>
>> Can you see if the patch sheds some better light as to what's failing?
>>
>> The patch won't fix the problem, but it should give us an accurate error
>> message so that we can learn what precisely is returning an error
>> status.
>>
>> Thanks in advance.
>>
 I do notice that Devin's manually prefixing the error message with the
 tool name, is partially redundancy when the tool does it it self, but we
 can't always be sure it will do that.

>>> The next patchset will fix that.
>>>
>>> I'm dropping the tool name from the msgbox contents and putting it in
>>> the title (e.g., '"Error: gpart") that way... even if the tool spits out 
>>> its own
>>> name (or not), we'll know what exactly what was going on by looking
>>> at the title.
>>>
>>>
 the graid thing is rather hard to detect, especially when it is a
 faulted array that doesn't even appear in graid status etc.

>>> I believe the idea behind the script is that whatever you tell it to use 
>>> will
>>> be destroyed.
>>>
>>> Allan, maybe perhaps we could add some code that attempts to dis-
>>> assemble a graid to make the disk usable?
>>>
>>> Johan, what would you be more apt to expect? That it killed your graid
>>> or that it gave an error? (/me thinks what the recourse to the error might
>>> entail -- going to partedit?)
>> Your recourse would be switching to the shell (control+alt+f4) and
>> destroying the graid.
>>
>> I am a little hesitant to go destroying graids unprompted. If we had the
>> geom.confxml parsing, we might be able to detect it and ask the user
>> what to do
>>
> Well, my concern with going and asking about each/every configuration
> before we clear it...
>
> Hasn't the user already answered a "Last Chance!" dialog giving the go-
> ahead to nuke any/all data *and* configurations on a drive?
I guess that makes sense, We offer the dialog to allow the user to
investigate their disk in detail so they can be sure they picked the
correct ones.

the graid thing is the biggest gotcha because it picks up metadata
written by the motherboard raid system, so you can have a graid
configuration even if you have never booted freebsd before.

#destroyallofthethings

-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-21 Thread Johan Broman

On 21/10/13 18:06, Allan Jude wrote:

On 2013-10-21 12:04, Teske, Devin wrote:

On Oct 21, 2013, at 8:50 AM, Allan Jude wrote:

On 2013-10-21 11:45, Johan Broman wrote:

Hi!

Sorry for the delayed answer. I've patched zfsboot and rebuilt the
release. I now get an error message that ada2 can't be used, which is
correct. Good stuff! :)

( I've recreated the test environment using a KVM guest with four SATA
drives instead of the server I was using. I makes it easier to test
stuff. )

Here's the screenshot:

https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99

Maybe one should be unable to select drives that are part of a graid
in the first place? Or is that out-of-scope for bsdinstall at this
point? (As I guess that requires too many changes/new lines)

Cheers
Johan

On 19/10/13 22:20, Teske, Devin wrote:

On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:

I recreated the graid mirror on ada2 and ada3 and reran the
installation. I'm unable to scroll the msgbox using PgDn or arrow
keys. There is no indication that the action failed and I'm returned
to the ZFS setup screen if I hit OK.

I have screen shots (taken with my phone) of the msgbox and "ps
auxwww" output. Let me know what kind of debug info you would like.
I've put the screen shots here:

https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1

I've added a patch to fix debugging in the zfsboot script...

https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9

Feedback welcome.

Johan,...

Can you see if the patch sheds some better light as to what's failing?

The patch won't fix the problem, but it should give us an accurate error
message so that we can learn what precisely is returning an error
status.

Thanks in advance.

I do notice that Devin's manually prefixing the error message with the
tool name, is partially redundancy when the tool does it it self, but we
can't always be sure it will do that.

The next patchset will fix that.

I'm dropping the tool name from the msgbox contents and putting it in
the title (e.g., '"Error: gpart") that way... even if the tool spits out its own
name (or not), we'll know what exactly what was going on by looking
at the title.

the graid thing is rather hard to detect, especially when it is a
faulted array that doesn't even appear in graid status etc.

I believe the idea behind the script is that whatever you tell it to use will
be destroyed.

Allan, maybe perhaps we could add some code that attempts to dis-
assemble a graid to make the disk usable?

Johan, what would you be more apt to expect? That it killed your graid
or that it gave an error? (/me thinks what the recourse to the error might
entail -- going to partedit?)

Your recourse would be switching to the shell (control+alt+f4) and
destroying the graid.

I am a little hesitant to go destroying graids unprompted. If we had the
geom.confxml parsing, we might be able to detect it and ask the user
what to do

In this case I was unaware of the fact that the old disks I was using
had previously been used in a graid. So I just wanted it to destroy it
and move on :)

On the other hand, Allan has a valid point. The user does get a warning
(the "last chance" warning), but maybe raising and additional warning if
a graid is detected is a good thing?

My opinion - one warning saying (quite clearly) that the disks will be
destroyed should be enough :)

/my 5 cents :)

Cheers
Johan

___
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] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 21, 2013, at 9:06 AM, Allan Jude wrote:

> On 2013-10-21 12:04, Teske, Devin wrote:
>> On Oct 21, 2013, at 8:50 AM, Allan Jude wrote:
>> 
>>> On 2013-10-21 11:45, Johan Broman wrote:
 Hi!
 
 Sorry for the delayed answer. I've patched zfsboot and rebuilt the
 release. I now get an error message that ada2 can't be used, which is
 correct. Good stuff! :)
 
 ( I've recreated the test environment using a KVM guest with four SATA
 drives instead of the server I was using. I makes it easier to test
 stuff. )
 
 Here's the screenshot:
 
 https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99
 
 
 Maybe one should be unable to select drives that are part of a graid
 in the first place? Or is that out-of-scope for bsdinstall at this
 point? (As I guess that requires too many changes/new lines)
 
 
 Cheers
 Johan
 
 
 On 19/10/13 22:20, Teske, Devin wrote:
> On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:
> 
>> I recreated the graid mirror on ada2 and ada3 and reran the
>> installation. I'm unable to scroll the msgbox using PgDn or arrow
>> keys. There is no indication that the action failed and I'm returned
>> to the ZFS setup screen if I hit OK.
>> 
>> I have screen shots (taken with my phone) of the msgbox and "ps
>> auxwww" output. Let me know what kind of debug info you would like.
>> I've put the screen shots here:
>> 
>> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1
> I've added a patch to fix debugging in the zfsboot script...
> 
> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9
> 
> Feedback welcome.
> 
> Johan,...
> 
> Can you see if the patch sheds some better light as to what's failing?
> 
> The patch won't fix the problem, but it should give us an accurate error
> message so that we can learn what precisely is returning an error
> status.
> 
> Thanks in advance.
> 
>>> I do notice that Devin's manually prefixing the error message with the
>>> tool name, is partially redundancy when the tool does it it self, but we
>>> can't always be sure it will do that.
>>> 
>> The next patchset will fix that.
>> 
>> I'm dropping the tool name from the msgbox contents and putting it in
>> the title (e.g., '"Error: gpart") that way... even if the tool spits out its 
>> own
>> name (or not), we'll know what exactly what was going on by looking
>> at the title.
>> 
>> 
>>> the graid thing is rather hard to detect, especially when it is a
>>> faulted array that doesn't even appear in graid status etc.
>>> 
>> I believe the idea behind the script is that whatever you tell it to use will
>> be destroyed.
>> 
>> Allan, maybe perhaps we could add some code that attempts to dis-
>> assemble a graid to make the disk usable?
>> 
>> Johan, what would you be more apt to expect? That it killed your graid
>> or that it gave an error? (/me thinks what the recourse to the error might
>> entail -- going to partedit?)
> Your recourse would be switching to the shell (control+alt+f4) and
> destroying the graid.
> 
> I am a little hesitant to go destroying graids unprompted. If we had the
> geom.confxml parsing, we might be able to detect it and ask the user
> what to do
> 

Well, my concern with going and asking about each/every configuration
before we clear it...

Hasn't the user already answered a "Last Chance!" dialog giving the go-
ahead to nuke any/all data *and* configurations on a drive?
-- 
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] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 21, 2013, at 8:45 AM, Johan Broman wrote:

> Hi!
> 
> Sorry for the delayed answer. I've patched zfsboot and rebuilt the release. I 
> now get an error message that ada2 can't be used, which is correct. Good 
> stuff! :)
> 
> ( I've recreated the test environment using a KVM guest with four SATA drives 
> instead of the server I was using. I makes it easier to test stuff. )
> 
> Here's the screenshot:
> 
> http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png
> 

Thank you so much, definitely says we're headed in the right direction.

It was bothering me that the debugging wasn't "up to-par."



> 
> Maybe one should be unable to select drives that are part of a graid in the 
> first place? Or is that out-of-scope for bsdinstall at this point? (As I 
> guess that requires too many changes/new lines)
> 

Perhaps we just need to do a better job of clearing previous
configurations from the disks that are to be used in the pool.
-- 
Devin

> On 19/10/13 22:20, Teske, Devin wrote:
>> 
>> On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:
>> 
>>> I recreated the graid mirror on ada2 and ada3 and reran the installation. 
>>> I'm unable to scroll the msgbox using PgDn or arrow keys. There is no 
>>> indication that the action failed and I'm returned to the ZFS setup screen 
>>> if I hit OK.
>>> 
>>> I have screen shots (taken with my phone) of the msgbox and "ps auxwww" 
>>> output. Let me know what kind of debug info you would like. I've put the 
>>> screen shots here:
>>> 
>>> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=HwEpYSg1%2Bqv6o4vps1DECabNoHOTpZj5VxD1rbHI5jU%3D%0A&s=a27573c7279ac5bc926ca2dc872a18550ee8244421b91d85b9f51b202b23e168
>> 
>> I've added a patch to fix debugging in the zfsboot script...
>> 
>> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=HwEpYSg1%2Bqv6o4vps1DECabNoHOTpZj5VxD1rbHI5jU%3D%0A&s=195830666030a264348cc1f37355789cd9ada04e0851b8c5769ce6426403fa28
>> 
>> Feedback welcome.
>> 
>> Johan,...
>> 
>> Can you see if the patch sheds some better light as to what's failing?
>> 
>> The patch won't fix the problem, but it should give us an accurate error
>> message so that we can learn what precisely is returning an error status.
>> 
>> Thanks in advance.
>> 

_
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] Patch to bsdinstall to support root-on-ZFS and GELI

On 2013-10-21 12:04, Teske, Devin wrote:
> On Oct 21, 2013, at 8:50 AM, Allan Jude wrote:
>
>> On 2013-10-21 11:45, Johan Broman wrote:
>>> Hi!
>>>
>>> Sorry for the delayed answer. I've patched zfsboot and rebuilt the
>>> release. I now get an error message that ada2 can't be used, which is
>>> correct. Good stuff! :)
>>>
>>> ( I've recreated the test environment using a KVM guest with four SATA
>>> drives instead of the server I was using. I makes it easier to test
>>> stuff. )
>>>
>>> Here's the screenshot:
>>>
>>> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99
>>>
>>>
>>> Maybe one should be unable to select drives that are part of a graid
>>> in the first place? Or is that out-of-scope for bsdinstall at this
>>> point? (As I guess that requires too many changes/new lines)
>>>
>>>
>>> Cheers
>>> Johan
>>>
>>>
>>> On 19/10/13 22:20, Teske, Devin wrote:
 On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:

> I recreated the graid mirror on ada2 and ada3 and reran the
> installation. I'm unable to scroll the msgbox using PgDn or arrow
> keys. There is no indication that the action failed and I'm returned
> to the ZFS setup screen if I hit OK.
>
> I have screen shots (taken with my phone) of the msgbox and "ps
> auxwww" output. Let me know what kind of debug info you would like.
> I've put the screen shots here:
>
> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1
 I've added a patch to fix debugging in the zfsboot script...

 https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9

 Feedback welcome.

 Johan,...

 Can you see if the patch sheds some better light as to what's failing?

 The patch won't fix the problem, but it should give us an accurate error
 message so that we can learn what precisely is returning an error
 status.

 Thanks in advance.

>> I do notice that Devin's manually prefixing the error message with the
>> tool name, is partially redundancy when the tool does it it self, but we
>> can't always be sure it will do that.
>>
> The next patchset will fix that.
>
> I'm dropping the tool name from the msgbox contents and putting it in
> the title (e.g., '"Error: gpart") that way... even if the tool spits out its 
> own
> name (or not), we'll know what exactly what was going on by looking
> at the title.
>
>
>> the graid thing is rather hard to detect, especially when it is a
>> faulted array that doesn't even appear in graid status etc.
>>
> I believe the idea behind the script is that whatever you tell it to use will
> be destroyed.
>
> Allan, maybe perhaps we could add some code that attempts to dis-
> assemble a graid to make the disk usable?
>
> Johan, what would you be more apt to expect? That it killed your graid
> or that it gave an error? (/me thinks what the recourse to the error might
> entail -- going to partedit?)
Your recourse would be switching to the shell (control+alt+f4) and
destroying the graid.

I am a little hesitant to go destroying graids unprompted. If we had the
geom.confxml parsing, we might be able to detect it and ask the user
what to do

-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI

On Oct 21, 2013, at 8:50 AM, Allan Jude wrote:

> On 2013-10-21 11:45, Johan Broman wrote:
>> Hi!
>> 
>> Sorry for the delayed answer. I've patched zfsboot and rebuilt the
>> release. I now get an error message that ada2 can't be used, which is
>> correct. Good stuff! :)
>> 
>> ( I've recreated the test environment using a KVM guest with four SATA
>> drives instead of the server I was using. I makes it easier to test
>> stuff. )
>> 
>> Here's the screenshot:
>> 
>> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99
>> 
>> 
>> Maybe one should be unable to select drives that are part of a graid
>> in the first place? Or is that out-of-scope for bsdinstall at this
>> point? (As I guess that requires too many changes/new lines)
>> 
>> 
>> Cheers
>> Johan
>> 
>> 
>> On 19/10/13 22:20, Teske, Devin wrote:
>>> 
>>> On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:
>>> 
 I recreated the graid mirror on ada2 and ada3 and reran the
 installation. I'm unable to scroll the msgbox using PgDn or arrow
 keys. There is no indication that the action failed and I'm returned
 to the ZFS setup screen if I hit OK.

 I have screen shots (taken with my phone) of the msgbox and "ps
 auxwww" output. Let me know what kind of debug info you would like.
 I've put the screen shots here:

 https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1
>>> 
>>> I've added a patch to fix debugging in the zfsboot script...
>>> 
>>> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9
>>> 
>>> Feedback welcome.
>>> 
>>> Johan,...
>>> 
>>> Can you see if the patch sheds some better light as to what's failing?
>>> 
>>> The patch won't fix the problem, but it should give us an accurate error
>>> message so that we can learn what precisely is returning an error
>>> status.
>>> 
>>> Thanks in advance.
>>> 
> I do notice that Devin's manually prefixing the error message with the
> tool name, is partially redundancy when the tool does it it self, but we
> can't always be sure it will do that.
> 

The next patchset will fix that.

I'm dropping the tool name from the msgbox contents and putting it in
the title (e.g., '"Error: gpart") that way... even if the tool spits out its own
name (or not), we'll know what exactly what was going on by looking
at the title.

> the graid thing is rather hard to detect, especially when it is a
> faulted array that doesn't even appear in graid status etc.
> 

I believe the idea behind the script is that whatever you tell it to use will
be destroyed.

Allan, maybe perhaps we could add some code that attempts to dis-
assemble a graid to make the disk usable?

Johan, what would you be more apt to expect? That it killed your graid
or that it gave an error? (/me thinks what the recourse to the error might
entail -- going to partedit?)
-- 
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] Patch to bsdinstall to support root-on-ZFS and GELI

On 2013-10-21 11:45, Johan Broman wrote:
> Hi!
>
> Sorry for the delayed answer. I've patched zfsboot and rebuilt the
> release. I now get an error message that ada2 can't be used, which is
> correct. Good stuff! :)
>
> ( I've recreated the test environment using a KVM guest with four SATA
> drives instead of the server I was using. I makes it easier to test
> stuff. )
>
> Here's the screenshot:
>
> http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png
>
>
> Maybe one should be unable to select drives that are part of a graid
> in the first place? Or is that out-of-scope for bsdinstall at this
> point? (As I guess that requires too many changes/new lines)
>
>
> Cheers
> Johan
>
>
> On 19/10/13 22:20, Teske, Devin wrote:
>>
>> On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:
>>
>>> I recreated the graid mirror on ada2 and ada3 and reran the
>>> installation. I'm unable to scroll the msgbox using PgDn or arrow
>>> keys. There is no indication that the action failed and I'm returned
>>> to the ZFS setup screen if I hit OK.
>>>
>>> I have screen shots (taken with my phone) of the msgbox and "ps
>>> auxwww" output. Let me know what kind of debug info you would like.
>>> I've put the screen shots here:
>>>
>>> http://212.181.212.146/bsdinstall
>>
>> I've added a patch to fix debugging in the zfsboot script...
>>
>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>
>> Feedback welcome.
>>
>> Johan,...
>>
>> Can you see if the patch sheds some better light as to what's failing?
>>
>> The patch won't fix the problem, but it should give us an accurate error
>> message so that we can learn what precisely is returning an error
>> status.
>>
>> Thanks in advance.
>>
I do notice that Devin's manually prefixing the error message with the
tool name, is partially redundancy when the tool does it it self, but we
can't always be sure it will do that.

the graid thing is rather hard to detect, especially when it is a
faulted array that doesn't even appear in graid status etc.

-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-21 Thread Johan Broman


Hi!

Sorry for the delayed answer. I've patched zfsboot and rebuilt the 
release. I now get an error message that ada2 can't be used, which is 
correct. Good stuff! :)


( I've recreated the test environment using a KVM guest with four SATA 
drives instead of the server I was using. I makes it easier to test stuff. )


Here's the screenshot:

http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png


Maybe one should be unable to select drives that are part of a graid in 
the first place? Or is that out-of-scope for bsdinstall at this point? 
(As I guess that requires too many changes/new lines)



Cheers
Johan


On 19/10/13 22:20, Teske, Devin wrote:


On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:


I recreated the graid mirror on ada2 and ada3 and reran the installation. I'm 
unable to scroll the msgbox using PgDn or arrow keys. There is no indication 
that the action failed and I'm returned to the ZFS setup screen if I hit OK.

I have screen shots (taken with my phone) of the msgbox and "ps auxwww" output. 
Let me know what kind of debug info you would like. I've put the screen shots here:

http://212.181.212.146/bsdinstall


I've added a patch to fix debugging in the zfsboot script...

http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/

Feedback welcome.

Johan,...

Can you see if the patch sheds some better light as to what's failing?

The patch won't fix the problem, but it should give us an accurate error
message so that we can learn what precisely is returning an error status.

Thanks in advance.


___
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] Patch to bsdinstall to support root-on-ZFS and GELI




On 19/10/13 20:52, Teske, Devin wrote:


On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:




On 19/10/13 18:27, Allan Jude wrote:

On 2013-10-19 11:55, Teske, Devin wrote:

On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote:


On Oct 19, 2013, at 8:34 AM, Allan Jude wrote:


On 2013-10-19 11:31, Johan Broman wrote:


On 19/10/13 17:23, Allan Jude wrote:

On 2013-10-19 10:56, Johan Broman wrote:

Hi!

Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I
have 4 SATA drives in my server. I select all four of them in a RAIDZ1
setup. I hit enter to continue the installation and the zpool is
created, but I'm then returned to the zpool selection screen again. It
turned out that two of the drives had previously been used in a
(Linux) software mirror setup and because of this they got activated
in /dev/raid/r0. Because of this I ended up in an endless bsdinstall
loop.

Removing the raid device using the graid command resolved the
situation.

Now maybe this is working as designed, but there was no warning/alert
to the fact that the devices couldn't be used. Perhaps a warning
should be rasied in this situation?

Thanks for all the great work on the new installer, really looking
forward to FreeBSD 10!

Cheers
Johan
___
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"

Errors like that normally generate a msgbox dialog with the error output
from whichever command failed. I'll have to dig into it and see where
that problem is. I've seen other people have problems creating ZFS
arrays after graid, but in that case it was an incomplete graid label
causing a device to be locked but not appear in the graid status output.


Ah ok. A msgbox did appear but the drives that had the problem (ada2
and ada3) wasn't visible in the output. (not sure if the box itself
has a size limit or maybe I was just unable to scroll down and see the
errors?). The only visible output was that it was able to create
labels on ada0 and ada1.

/Johan
___
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"

Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to
add a scrollbar but turns out that is not possible.

The only indication that there is more message to read, is a small 'xx%'
in the bottom right. We might have to look at breaking that output up or
something.



The only reason for a msgbox widget to scroll is if it is displayed at
maximum height or width of the screen and it *still* has more data
to display than can be presented at-once.


I should clarify...

The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API.
That being said, msgbox widgets automatically scale their size to fit the
content being displayed. So whenever a msgbox is thrown up using this
API... the widget will never scroll unless the box can't be made big enough
to hold the entire content (either the screen resolution or terminal size is
too small; we maxed out the size of the widget; and there's still hidden
content).

But...

While all of bsdconfig uses this API, hardly any of bsdinstall uses this API.




If... however... the msgbox widget is *not* full-height or full-width
yet... it is requiring you to scroll -- then we've found a bug.

Can we get a screen shot?

So we really need to nail down precisely which error box this is so that
we can address whether the issue is in-fact an instance of using the old
error-box handling instead of the auto-sizing API.

So...

With this described API, you should never have to scroll a box unless it
can't fit all the data *and* you should be able to immediately identify when
that becomes the case...

1. The widget spans the entire width of the screen.

2. The widget spans the entire height of the screen.

3. Both 1 and 2.

It's in *those* cases that you should then *EXPECT* to find that the
region can scroll with cursor keys and page up/down (look for the
scroll percentage in the widget as Allan suggested.

I don't want to see the scroll percentage doohickey *unless* the widget
is auto-sized to full-width or full-height. Meaning, there's either a bug in
the API or someone fell into a trap (there are a couple).


the error output msgbox is huge, probably 100+ lines (the screen is
what, 24 lines high, and with the ok button, top and bottom reserved
space etc, can display maybe 18 lines at once)

It contains all the shell output from everything we do, creating the
gparts, setting up gnop, all of the redundant destroys etc.

I don't think the TINY little % in the bottom right is really enough of
an indicator to the user that they CAN scroll, let alone HOW to scroll
(IIRC the arrow keys do not work, must use page down)



I recreated the graid mirror on a

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:

> I recreated the graid mirror on ada2 and ada3 and reran the installation. I'm 
> unable to scroll the msgbox using PgDn or arrow keys. There is no indication 
> that the action failed and I'm returned to the ZFS setup screen if I hit OK.
> 
> I have screen shots (taken with my phone) of the msgbox and "ps auxwww" 
> output. Let me know what kind of debug info you would like. I've put the 
> screen shots here:
> 
> http://212.181.212.146/bsdinstall

I've added a patch to fix debugging in the zfsboot script...

http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/

Feedback welcome.

Johan,...

Can you see if the patch sheds some better light as to what's failing?

The patch won't fix the problem, but it should give us an accurate error
message so that we can learn what precisely is returning an error status.

Thanks in advance.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
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] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 19, 2013, at 10:07 AM, Johan Broman wrote:

> 
> 
> On 19/10/13 18:27, Allan Jude wrote:
>> On 2013-10-19 11:55, Teske, Devin wrote:
>>> On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote:
>>> 
 On Oct 19, 2013, at 8:34 AM, Allan Jude wrote:
 
> On 2013-10-19 11:31, Johan Broman wrote:
>> 
>> On 19/10/13 17:23, Allan Jude wrote:
>>> On 2013-10-19 10:56, Johan Broman wrote:
 Hi!
 
 Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I
 have 4 SATA drives in my server. I select all four of them in a RAIDZ1
 setup. I hit enter to continue the installation and the zpool is
 created, but I'm then returned to the zpool selection screen again. It
 turned out that two of the drives had previously been used in a
 (Linux) software mirror setup and because of this they got activated
 in /dev/raid/r0. Because of this I ended up in an endless bsdinstall
 loop.
 
 Removing the raid device using the graid command resolved the
 situation.
 
 Now maybe this is working as designed, but there was no warning/alert
 to the fact that the devices couldn't be used. Perhaps a warning
 should be rasied in this situation?
 
 Thanks for all the great work on the new installer, really looking
 forward to FreeBSD 10!
 
 Cheers
 Johan
 ___
 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"
>>> Errors like that normally generate a msgbox dialog with the error output
>>> from whichever command failed. I'll have to dig into it and see where
>>> that problem is. I've seen other people have problems creating ZFS
>>> arrays after graid, but in that case it was an incomplete graid label
>>> causing a device to be locked but not appear in the graid status output.
>>> 
>> Ah ok. A msgbox did appear but the drives that had the problem (ada2
>> and ada3) wasn't visible in the output. (not sure if the box itself
>> has a size limit or maybe I was just unable to scroll down and see the
>> errors?). The only visible output was that it was able to create
>> labels on ada0 and ada1.
>> 
>> /Johan
>> ___
>> 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"
> Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to
> add a scrollbar but turns out that is not possible.
> 
> The only indication that there is more message to read, is a small 'xx%'
> in the bottom right. We might have to look at breaking that output up or
> something.
> 
 
 The only reason for a msgbox widget to scroll is if it is displayed at
 maximum height or width of the screen and it *still* has more data
 to display than can be presented at-once.
 
>>> I should clarify...
>>> 
>>> The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig 
>>> API.
>>> That being said, msgbox widgets automatically scale their size to fit the
>>> content being displayed. So whenever a msgbox is thrown up using this
>>> API... the widget will never scroll unless the box can't be made big enough
>>> to hold the entire content (either the screen resolution or terminal size is
>>> too small; we maxed out the size of the widget; and there's still hidden
>>> content).
>>> 
>>> But...
>>> 
>>> While all of bsdconfig uses this API, hardly any of bsdinstall uses this 
>>> API.
>>> 
>>> 
>>> 
 If... however... the msgbox widget is *not* full-height or full-width
 yet... it is requiring you to scroll -- then we've found a bug.
 
 Can we get a screen shot?
>>> So we really need to nail down precisely which error box this is so that
>>> we can address whether the issue is in-fact an instance of using the old
>>> error-box handling instead of the auto-sizing API.
>>> 
>>> So...
>>> 
>>> With this described API, you should never have to scroll a box unless it
>>> can't fit all the data *and* you should be able to immediately identify when
>>> that becomes the case...
>>> 
>>> 1. The widget spans the entire width of the screen.
>>> 
>>> 2. The widget spans the entire height of the screen.
>>> 
>>> 3. Both 1 and 2.
>>> 
>>> It's in *those* cases that you should then *EXPECT* to find that the
>>> region can scroll with cursor keys and page up/down (look for the
>>> scroll percentage in the widget as Allan suggested.
>>> 
>>> I don't want to see the scroll percentage doohickey *unless* the widget
>>> is auto-sized to full-width or full-height. Meaning, th

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 19, 2013, at 9:27 AM, Allan Jude wrote:

> On 2013-10-19 11:55, Teske, Devin wrote:
>> On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote:
>> 
>>> On Oct 19, 2013, at 8:34 AM, Allan Jude wrote:
>>> 
 On 2013-10-19 11:31, Johan Broman wrote:
> 
> On 19/10/13 17:23, Allan Jude wrote:
>> On 2013-10-19 10:56, Johan Broman wrote:
>>> Hi!
>>> 
>>> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I
>>> have 4 SATA drives in my server. I select all four of them in a RAIDZ1
>>> setup. I hit enter to continue the installation and the zpool is
>>> created, but I'm then returned to the zpool selection screen again. It
>>> turned out that two of the drives had previously been used in a
>>> (Linux) software mirror setup and because of this they got activated
>>> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall
>>> loop.
>>> 
>>> Removing the raid device using the graid command resolved the
>>> situation.
>>> 
>>> Now maybe this is working as designed, but there was no warning/alert
>>> to the fact that the devices couldn't be used. Perhaps a warning
>>> should be rasied in this situation?
>>> 
>>> Thanks for all the great work on the new installer, really looking
>>> forward to FreeBSD 10!
>>> 
>>> Cheers
>>> Johan
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/mailman/listinfo/freebsd-current&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=AnourZYCpeybP9aMxTFH%2B4GBOf0xikQ2jpEi%2BPFWcKo%3D%0A&s=fec708d91fa0976a0e297ef3628851168f36e9cb34727dc7935e26ae190e90da
>>> To unsubscribe, send any mail to
>>> "freebsd-current-unsubscr...@freebsd.org"
>> Errors like that normally generate a msgbox dialog with the error output
>> from whichever command failed. I'll have to dig into it and see where
>> that problem is. I've seen other people have problems creating ZFS
>> arrays after graid, but in that case it was an incomplete graid label
>> causing a device to be locked but not appear in the graid status output.
>> 
> Ah ok. A msgbox did appear but the drives that had the problem (ada2
> and ada3) wasn't visible in the output. (not sure if the box itself
> has a size limit or maybe I was just unable to scroll down and see the
> errors?). The only visible output was that it was able to create
> labels on ada0 and ada1.
> 
> /Johan
> ___
> freebsd-current@freebsd.org mailing list
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/mailman/listinfo/freebsd-current&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=AnourZYCpeybP9aMxTFH%2B4GBOf0xikQ2jpEi%2BPFWcKo%3D%0A&s=fec708d91fa0976a0e297ef3628851168f36e9cb34727dc7935e26ae190e90da
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"
 Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to
 add a scrollbar but turns out that is not possible.
 
 The only indication that there is more message to read, is a small 'xx%'
 in the bottom right. We might have to look at breaking that output up or
 something.
 
>>> 
>>> The only reason for a msgbox widget to scroll is if it is displayed at
>>> maximum height or width of the screen and it *still* has more data
>>> to display than can be presented at-once.
>>> 
>> I should clarify...
>> 
>> The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API.
>> That being said, msgbox widgets automatically scale their size to fit the
>> content being displayed. So whenever a msgbox is thrown up using this
>> API... the widget will never scroll unless the box can't be made big enough
>> to hold the entire content (either the screen resolution or terminal size is
>> too small; we maxed out the size of the widget; and there's still hidden
>> content).
>> 
>> But...
>> 
>> While all of bsdconfig uses this API, hardly any of bsdinstall uses this API.
>> 
>> 
>> 
>>> If... however... the msgbox widget is *not* full-height or full-width
>>> yet... it is requiring you to scroll -- then we've found a bug.
>>> 
>>> Can we get a screen shot?
>> So we really need to nail down precisely which error box this is so that
>> we can address whether the issue is in-fact an instance of using the old
>> error-box handling instead of the auto-sizing API.
>> 
>> So...
>> 
>> With this described API, you should never have to scroll a box unless it
>> can't fit all the data *and* you should be able to immediately identify when
>> that becomes the case...
>> 
>> 1. The widget spans the entire width of the screen.
>> 
>> 2. The widget spans the entire height of the screen.
>> 
>> 3. Bo

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI




On 19/10/13 18:27, Allan Jude wrote:

On 2013-10-19 11:55, Teske, Devin wrote:

On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote:


On Oct 19, 2013, at 8:34 AM, Allan Jude wrote:


On 2013-10-19 11:31, Johan Broman wrote:


On 19/10/13 17:23, Allan Jude wrote:

On 2013-10-19 10:56, Johan Broman wrote:

Hi!

Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I
have 4 SATA drives in my server. I select all four of them in a RAIDZ1
setup. I hit enter to continue the installation and the zpool is
created, but I'm then returned to the zpool selection screen again. It
turned out that two of the drives had previously been used in a
(Linux) software mirror setup and because of this they got activated
in /dev/raid/r0. Because of this I ended up in an endless bsdinstall
loop.

Removing the raid device using the graid command resolved the
situation.

Now maybe this is working as designed, but there was no warning/alert
to the fact that the devices couldn't be used. Perhaps a warning
should be rasied in this situation?

Thanks for all the great work on the new installer, really looking
forward to FreeBSD 10!

Cheers
Johan
___
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"

Errors like that normally generate a msgbox dialog with the error output
from whichever command failed. I'll have to dig into it and see where
that problem is. I've seen other people have problems creating ZFS
arrays after graid, but in that case it was an incomplete graid label
causing a device to be locked but not appear in the graid status output.


Ah ok. A msgbox did appear but the drives that had the problem (ada2
and ada3) wasn't visible in the output. (not sure if the box itself
has a size limit or maybe I was just unable to scroll down and see the
errors?). The only visible output was that it was able to create
labels on ada0 and ada1.

/Johan
___
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"

Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to
add a scrollbar but turns out that is not possible.

The only indication that there is more message to read, is a small 'xx%'
in the bottom right. We might have to look at breaking that output up or
something.



The only reason for a msgbox widget to scroll is if it is displayed at
maximum height or width of the screen and it *still* has more data
to display than can be presented at-once.


I should clarify...

The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API.
That being said, msgbox widgets automatically scale their size to fit the
content being displayed. So whenever a msgbox is thrown up using this
API... the widget will never scroll unless the box can't be made big enough
to hold the entire content (either the screen resolution or terminal size is
too small; we maxed out the size of the widget; and there's still hidden
content).

But...

While all of bsdconfig uses this API, hardly any of bsdinstall uses this API.




If... however... the msgbox widget is *not* full-height or full-width
yet... it is requiring you to scroll -- then we've found a bug.

Can we get a screen shot?

So we really need to nail down precisely which error box this is so that
we can address whether the issue is in-fact an instance of using the old
error-box handling instead of the auto-sizing API.

So...

With this described API, you should never have to scroll a box unless it
can't fit all the data *and* you should be able to immediately identify when
that becomes the case...

1. The widget spans the entire width of the screen.

2. The widget spans the entire height of the screen.

3. Both 1 and 2.

It's in *those* cases that you should then *EXPECT* to find that the
region can scroll with cursor keys and page up/down (look for the
scroll percentage in the widget as Allan suggested.

I don't want to see the scroll percentage doohickey *unless* the widget
is auto-sized to full-width or full-height. Meaning, there's either a bug in
the API or someone fell into a trap (there are a couple).


the error output msgbox is huge, probably 100+ lines (the screen is
what, 24 lines high, and with the ok button, top and bottom reserved
space etc, can display maybe 18 lines at once)

It contains all the shell output from everything we do, creating the
gparts, setting up gnop, all of the redundant destroys etc.

I don't think the TINY little % in the bottom right is really enough of
an indicator to the user that they CAN scroll, let alone HOW to scroll
(IIRC the arrow keys do not work, must use page down)



I recreated the graid mirror on ada2 and ada3 and reran the 
installation. I'm unable to scroll the msgbox using PgDn or arrow k

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-19 Thread Allan Jude

On 2013-10-19 11:55, Teske, Devin wrote:
> On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote:
>
>> On Oct 19, 2013, at 8:34 AM, Allan Jude wrote:
>>
>>> On 2013-10-19 11:31, Johan Broman wrote:

 On 19/10/13 17:23, Allan Jude wrote:
> On 2013-10-19 10:56, Johan Broman wrote:
>> Hi!
>>
>> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I
>> have 4 SATA drives in my server. I select all four of them in a RAIDZ1
>> setup. I hit enter to continue the installation and the zpool is
>> created, but I'm then returned to the zpool selection screen again. It
>> turned out that two of the drives had previously been used in a
>> (Linux) software mirror setup and because of this they got activated
>> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall
>> loop.
>>
>> Removing the raid device using the graid command resolved the
>> situation.
>>
>> Now maybe this is working as designed, but there was no warning/alert
>> to the fact that the devices couldn't be used. Perhaps a warning
>> should be rasied in this situation?
>>
>> Thanks for all the great work on the new installer, really looking
>> forward to FreeBSD 10!
>>
>> Cheers
>> Johan
>> ___
>> 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"
> Errors like that normally generate a msgbox dialog with the error output
> from whichever command failed. I'll have to dig into it and see where
> that problem is. I've seen other people have problems creating ZFS
> arrays after graid, but in that case it was an incomplete graid label
> causing a device to be locked but not appear in the graid status output.
>
 Ah ok. A msgbox did appear but the drives that had the problem (ada2
 and ada3) wasn't visible in the output. (not sure if the box itself
 has a size limit or maybe I was just unable to scroll down and see the
 errors?). The only visible output was that it was able to create
 labels on ada0 and ada1.

 /Johan
 ___
 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"
>>> Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to
>>> add a scrollbar but turns out that is not possible.
>>>
>>> The only indication that there is more message to read, is a small 'xx%'
>>> in the bottom right. We might have to look at breaking that output up or
>>> something.
>>>
>>
>> The only reason for a msgbox widget to scroll is if it is displayed at
>> maximum height or width of the screen and it *still* has more data
>> to display than can be presented at-once.
>>
> I should clarify...
>
> The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API.
> That being said, msgbox widgets automatically scale their size to fit the
> content being displayed. So whenever a msgbox is thrown up using this
> API... the widget will never scroll unless the box can't be made big enough
> to hold the entire content (either the screen resolution or terminal size is
> too small; we maxed out the size of the widget; and there's still hidden
> content).
>
> But...
>
> While all of bsdconfig uses this API, hardly any of bsdinstall uses this API.
>
>
>
>> If... however... the msgbox widget is *not* full-height or full-width
>> yet... it is requiring you to scroll -- then we've found a bug.
>>
>> Can we get a screen shot?
> So we really need to nail down precisely which error box this is so that
> we can address whether the issue is in-fact an instance of using the old
> error-box handling instead of the auto-sizing API.
>
> So...
>
> With this described API, you should never have to scroll a box unless it
> can't fit all the data *and* you should be able to immediately identify when
> that becomes the case...
>
> 1. The widget spans the entire width of the screen.
>
> 2. The widget spans the entire height of the screen.
>
> 3. Both 1 and 2.
>
> It's in *those* cases that you should then *EXPECT* to find that the
> region can scroll with cursor keys and page up/down (look for the
> scroll percentage in the widget as Allan suggested.
>
> I don't want to see the scroll percentage doohickey *unless* the widget
> is auto-sized to full-width or full-height. Meaning, there's either a bug in
> the API or someone fell into a trap (there are a couple).

the error output msgbox is huge, probably 100+ lines (the screen is
what, 24 lines high, and with the ok button, top and bottom reserved
space etc, can display maybe 18 lines at once)

It contains all the shell output from everything we do, creating the
gparts, setting u

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote:

> 
> On Oct 19, 2013, at 8:34 AM, Allan Jude wrote:
> 
>> On 2013-10-19 11:31, Johan Broman wrote:
>>> 
>>> 
>>> On 19/10/13 17:23, Allan Jude wrote:
 On 2013-10-19 10:56, Johan Broman wrote:
> Hi!
> 
> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I
> have 4 SATA drives in my server. I select all four of them in a RAIDZ1
> setup. I hit enter to continue the installation and the zpool is
> created, but I'm then returned to the zpool selection screen again. It
> turned out that two of the drives had previously been used in a
> (Linux) software mirror setup and because of this they got activated
> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall
> loop.
> 
> Removing the raid device using the graid command resolved the
> situation.
> 
> Now maybe this is working as designed, but there was no warning/alert
> to the fact that the devices couldn't be used. Perhaps a warning
> should be rasied in this situation?
> 
> Thanks for all the great work on the new installer, really looking
> forward to FreeBSD 10!
> 
> Cheers
> Johan
> ___
> 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"
 Errors like that normally generate a msgbox dialog with the error output
 from whichever command failed. I'll have to dig into it and see where
 that problem is. I've seen other people have problems creating ZFS
 arrays after graid, but in that case it was an incomplete graid label
 causing a device to be locked but not appear in the graid status output.

>>> 
>>> Ah ok. A msgbox did appear but the drives that had the problem (ada2
>>> and ada3) wasn't visible in the output. (not sure if the box itself
>>> has a size limit or maybe I was just unable to scroll down and see the
>>> errors?). The only visible output was that it was able to create
>>> labels on ada0 and ada1.
>>> 
>>> /Johan
>>> ___
>>> 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"
>> Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to
>> add a scrollbar but turns out that is not possible.
>> 
>> The only indication that there is more message to read, is a small 'xx%'
>> in the bottom right. We might have to look at breaking that output up or
>> something.
>> 
> 
> 
> The only reason for a msgbox widget to scroll is if it is displayed at
> maximum height or width of the screen and it *still* has more data
> to display than can be presented at-once.
> 

I should clarify...

The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API.
That being said, msgbox widgets automatically scale their size to fit the
content being displayed. So whenever a msgbox is thrown up using this
API... the widget will never scroll unless the box can't be made big enough
to hold the entire content (either the screen resolution or terminal size is
too small; we maxed out the size of the widget; and there's still hidden
content).

But...

While all of bsdconfig uses this API, hardly any of bsdinstall uses this API.

> If... however... the msgbox widget is *not* full-height or full-width
> yet... it is requiring you to scroll -- then we've found a bug.
> 
> Can we get a screen shot?

So we really need to nail down precisely which error box this is so that
we can address whether the issue is in-fact an instance of using the old
error-box handling instead of the auto-sizing API.

So...

With this described API, you should never have to scroll a box unless it
can't fit all the data *and* you should be able to immediately identify when
that becomes the case...

1. The widget spans the entire width of the screen.

2. The widget spans the entire height of the screen.

3. Both 1 and 2.

It's in *those* cases that you should then *EXPECT* to find that the
region can scroll with cursor keys and page up/down (look for the
scroll percentage in the widget as Allan suggested.

I don't want to see the scroll percentage doohickey *unless* the widget
is auto-sized to full-width or full-height. Meaning, there's either a bug in
the API or someone fell into a trap (there are a couple).
-- 
Devin
-- 
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

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI




On 19/10/13 17:43, Teske, Devin wrote:


On Oct 19, 2013, at 8:34 AM, Allan Jude wrote:


On 2013-10-19 11:31, Johan Broman wrote:



On 19/10/13 17:23, Allan Jude wrote:

On 2013-10-19 10:56, Johan Broman wrote:

Hi!

Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I
have 4 SATA drives in my server. I select all four of them in a RAIDZ1
setup. I hit enter to continue the installation and the zpool is
created, but I'm then returned to the zpool selection screen again. It
turned out that two of the drives had previously been used in a
(Linux) software mirror setup and because of this they got activated
in /dev/raid/r0. Because of this I ended up in an endless bsdinstall
loop.

Removing the raid device using the graid command resolved the
situation.

Now maybe this is working as designed, but there was no warning/alert
to the fact that the devices couldn't be used. Perhaps a warning
should be rasied in this situation?

Thanks for all the great work on the new installer, really looking
forward to FreeBSD 10!

Cheers
Johan
___
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"

Errors like that normally generate a msgbox dialog with the error output
from whichever command failed. I'll have to dig into it and see where
that problem is. I've seen other people have problems creating ZFS
arrays after graid, but in that case it was an incomplete graid label
causing a device to be locked but not appear in the graid status output.



Ah ok. A msgbox did appear but the drives that had the problem (ada2
and ada3) wasn't visible in the output. (not sure if the box itself
has a size limit or maybe I was just unable to scroll down and see the
errors?). The only visible output was that it was able to create
labels on ada0 and ada1.

/Johan
___
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"

Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to
add a scrollbar but turns out that is not possible.

The only indication that there is more message to read, is a small 'xx%'
in the bottom right. We might have to look at breaking that output up or
something.




The only reason for a msgbox widget to scroll is if it is displayed at
maximum height or width of the screen and it *still* has more data
to display than can be presented at-once.

If... however... the msgbox widget is *not* full-height or full-width
yet... it is requiring you to scroll -- then we've found a bug.

Can we get a screen shot?



Hmmm. Can't believe I didn't do a PgDn. Then againit was pretty late 
last night when I tested it...tired brain. :)

I'll recreate the mirror and see if I can provide a screen shot!

/Johan
___
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] Patch to bsdinstall to support root-on-ZFS and GELI

On Oct 19, 2013, at 8:34 AM, Allan Jude wrote:

> On 2013-10-19 11:31, Johan Broman wrote:
>> 
>> 
>> On 19/10/13 17:23, Allan Jude wrote:
>>> On 2013-10-19 10:56, Johan Broman wrote:
 Hi!

 Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I
 have 4 SATA drives in my server. I select all four of them in a RAIDZ1
 setup. I hit enter to continue the installation and the zpool is
 created, but I'm then returned to the zpool selection screen again. It
 turned out that two of the drives had previously been used in a
 (Linux) software mirror setup and because of this they got activated
 in /dev/raid/r0. Because of this I ended up in an endless bsdinstall
 loop.

 Removing the raid device using the graid command resolved the
 situation.

 Now maybe this is working as designed, but there was no warning/alert
 to the fact that the devices couldn't be used. Perhaps a warning
 should be rasied in this situation?

 Thanks for all the great work on the new installer, really looking
 forward to FreeBSD 10!

 Cheers
 Johan
 ___
 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"
>>> Errors like that normally generate a msgbox dialog with the error output
>>> from whichever command failed. I'll have to dig into it and see where
>>> that problem is. I've seen other people have problems creating ZFS
>>> arrays after graid, but in that case it was an incomplete graid label
>>> causing a device to be locked but not appear in the graid status output.
>>> 
>> 
>> Ah ok. A msgbox did appear but the drives that had the problem (ada2
>> and ada3) wasn't visible in the output. (not sure if the box itself
>> has a size limit or maybe I was just unable to scroll down and see the
>> errors?). The only visible output was that it was able to create
>> labels on ada0 and ada1.
>> 
>> /Johan
>> ___
>> 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"
> Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to
> add a scrollbar but turns out that is not possible.
> 
> The only indication that there is more message to read, is a small 'xx%'
> in the bottom right. We might have to look at breaking that output up or
> something.
> 

The only reason for a msgbox widget to scroll is if it is displayed at
maximum height or width of the screen and it *still* has more data
to display than can be presented at-once.

If... however... the msgbox widget is *not* full-height or full-width
yet... it is requiring you to scroll -- then we've found a bug.

Can we get a screen shot?
-- 
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-19 Thread Allan Jude

On 2013-10-19 11:31, Johan Broman wrote:
>
>
> On 19/10/13 17:23, Allan Jude wrote:
>> On 2013-10-19 10:56, Johan Broman wrote:
>>> Hi!
>>>
>>> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I
>>> have 4 SATA drives in my server. I select all four of them in a RAIDZ1
>>> setup. I hit enter to continue the installation and the zpool is
>>> created, but I'm then returned to the zpool selection screen again. It
>>> turned out that two of the drives had previously been used in a
>>> (Linux) software mirror setup and because of this they got activated
>>> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall
>>> loop.
>>>
>>> Removing the raid device using the graid command resolved the
>>> situation.
>>>
>>> Now maybe this is working as designed, but there was no warning/alert
>>> to the fact that the devices couldn't be used. Perhaps a warning
>>> should be rasied in this situation?
>>>
>>> Thanks for all the great work on the new installer, really looking
>>> forward to FreeBSD 10!
>>>
>>> Cheers
>>> Johan
>>> ___
>>> 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"
>> Errors like that normally generate a msgbox dialog with the error output
>> from whichever command failed. I'll have to dig into it and see where
>> that problem is. I've seen other people have problems creating ZFS
>> arrays after graid, but in that case it was an incomplete graid label
>> causing a device to be locked but not appear in the graid status output.
>>
>
> Ah ok. A msgbox did appear but the drives that had the problem (ada2
> and ada3) wasn't visible in the output. (not sure if the box itself
> has a size limit or maybe I was just unable to scroll down and see the
> errors?). The only visible output was that it was able to create
> labels on ada0 and ada1.
>
> /Johan
> ___
> 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"
Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to
add a scrollbar but turns out that is not possible.

The only indication that there is more message to read, is a small 'xx%'
in the bottom right. We might have to look at breaking that output up or
something.

-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI




On 19/10/13 17:23, Allan Jude wrote:

On 2013-10-19 10:56, Johan Broman wrote:

Hi!

Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I
have 4 SATA drives in my server. I select all four of them in a RAIDZ1
setup. I hit enter to continue the installation and the zpool is
created, but I'm then returned to the zpool selection screen again. It
turned out that two of the drives had previously been used in a
(Linux) software mirror setup and because of this they got activated
in /dev/raid/r0. Because of this I ended up in an endless bsdinstall
loop.

Removing the raid device using the graid command resolved the situation.

Now maybe this is working as designed, but there was no warning/alert
to the fact that the devices couldn't be used. Perhaps a warning
should be rasied in this situation?

Thanks for all the great work on the new installer, really looking
forward to FreeBSD 10!

Cheers
Johan
___
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"

Errors like that normally generate a msgbox dialog with the error output
from whichever command failed. I'll have to dig into it and see where
that problem is. I've seen other people have problems creating ZFS
arrays after graid, but in that case it was an incomplete graid label
causing a device to be locked but not appear in the graid status output.



Ah ok. A msgbox did appear but the drives that had the problem (ada2 and 
ada3) wasn't visible in the output. (not sure if the box itself has a 
size limit or maybe I was just unable to scroll down and see the 
errors?). The only visible output was that it was able to create labels 
on ada0 and ada1.


/Johan
___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-19 Thread Allan Jude

On 2013-10-19 10:56, Johan Broman wrote:
> Hi!
>
> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I
> have 4 SATA drives in my server. I select all four of them in a RAIDZ1
> setup. I hit enter to continue the installation and the zpool is
> created, but I'm then returned to the zpool selection screen again. It
> turned out that two of the drives had previously been used in a
> (Linux) software mirror setup and because of this they got activated
> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall
> loop.
>
> Removing the raid device using the graid command resolved the situation.
>
> Now maybe this is working as designed, but there was no warning/alert
> to the fact that the devices couldn't be used. Perhaps a warning
> should be rasied in this situation?
>
> Thanks for all the great work on the new installer, really looking
> forward to FreeBSD 10!
>
> Cheers
> Johan
> ___
> 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"
Errors like that normally generate a msgbox dialog with the error output
from whichever command failed. I'll have to dig into it and see where
that problem is. I've seen other people have problems creating ZFS
arrays after graid, but in that case it was an incomplete graid label
causing a device to be locked but not appear in the graid status output.

-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI


Hi!

Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I 
have 4 SATA drives in my server. I select all four of them in a RAIDZ1 
setup. I hit enter to continue the installation and the zpool is 
created, but I'm then returned to the zpool selection screen again. It 
turned out that two of the drives had previously been used in a (Linux) 
software mirror setup and because of this they got activated in 
/dev/raid/r0. Because of this I ended up in an endless bsdinstall loop.


Removing the raid device using the graid command resolved the situation.

Now maybe this is working as designed, but there was no warning/alert to 
the fact that the devices couldn't be used. Perhaps a warning should be 
rasied in this situation?


Thanks for all the great work on the new installer, really looking 
forward to FreeBSD 10!


Cheers
Johan
___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-14 Thread Allan Jude

For those of you not aware, the latest version of the root-on-ZFS+GELI
in bsdinstall patch shipped as part of FreeBSD 10.0-BETA1 today. Please
test it and report any issues you have.

There is one known issue (already patched in our repo), where if you do
a GELI pool, the unencrypted /boot pool is not mounted properly once the
system is up (a case where the /boot/zfs/zpool.cache is still useful)

-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI

On Oct 10, 2013, at 10:54 AM, Allan Jude wrote:

> On 2013-10-10 13:21, Warren Block wrote:
>> [off-list reply]
>> 
>> I have not tested the new version yet.  Is there any chance it
>> supports setting up a gmirror?
>> 
>> Something I've been meaning to discuss with Devin is the concept of
>> presets.  The user would be able to choose from a list of presets:
>> 
>>  Filesystem Layout
>>  -
>>  Merged / filesystem
>>  Split /, /var, /tmp, /usr filesystems
>> 
>> then
>> 
>>  Filesystem Type
>>  ---
>>  UFS
>>  ZFS
>> 
>> then
>> 
>>  Disk Layout
>>  ---
>>  Plain disk
>>  Mirror
>>  RAID
>> 
>> Those choices might change depending on earlier ones, like if they had
>> chosen ZFS earlier they would get a choice of Mirror, RAID-Z1,
>> RAID-Z2, and so on.
>> 
>> All this would build up a configuration, and at the end the user can
>> edit it (filesystem sizes, for instance), then pick Go and walk away.
> 
> All of the UFS stuff is in C, so is read-only for me.
> 
> It is something I'd like to do, but it is really iffy if that can be
> done in time for 10.0
> 
> In general, gmirror support could be added to the ZFS section (renamed
> to something else). So in our current 'zfs' menu, would become the 'new
> partition manager' menu. Add an extra option for ZFS or UFS, and then
> the vdev menu would context switch between zfs vdevs and ufs options
> like gmirror and gstripe or something
> 
> Adding an extra option for / or / /var /tmp /usr is not a bad idea
> either, maybe even for ZFS, offering a simpler set of datasets that
> might be some people's preference (especially if I can't do the
> following in time:)
> 
> In a future revision of the zfsboot stuff, I'd like to offer a dialog
> where users can actually adjust the ZFS datasets. provide a menu listing
> the created dataset, with option to add more, and when you select a
> dataset, you can adjust its options or delete it (some really scary
> validation needs to happen here so you can't delete /usr if you have
> /usr/local)
> 
> If the UFS stuff took the form of the current ZFS stuff (give me the
> entire disk, and i'll run with it), it would be fairly easy to
> implement, and could probably be done between 10.0-BETA1 and 10.0-BETA2
> 
> The more powerful features of the current partedit code, where it
> actually shows what is on your disk already, and allows you to just
> adjust it, and in general manage dual booting etc, that is a lot more
> complicated.
> 

But the API exists (and we get a taste of the API in zfsboot). Specifically, a 
script
would mangle a disk and then call f_device_rescan to get the menus to populate
new entries.

That aside, one of my plans for diskmgmt was to essentially let the user perform
free-wheeling adhoc configurations.

Here's an extreme example of what I mean**:

1. Boot a box with naked disks
2. Create some gmultipath labels
3. Put a GPT scheme on the disk with one BSD partition
4. Put some UFS labels in the partition
5. Build a zpool out of a secondary label of each multipath'd disk

** Because afterall, FreeBSD shouldn't prevent you from doing something like 
that.

I think that if we try to tackle scenarios like that, then we'll really come up 
with a
winning diskmgmt module (because right now I can't go do some UFS setup and
then shove the products into a zpool).

_When_ the ZFS management stuff is all integrated (which I plan on integrating
bits from pjd's zfsconf too), I think it should be agnostic about what you give 
it as
a device *and* allow you to configure many types of things without being forced
into an "either-or" situation (because often it can be a "I want both" 
situation).

(tuppence)
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-10 Thread Allan Jude

On 2013-10-10 13:21, Warren Block wrote:
> [off-list reply]
>
> I have not tested the new version yet.  Is there any chance it
> supports setting up a gmirror?
>
> Something I've been meaning to discuss with Devin is the concept of
> presets.  The user would be able to choose from a list of presets:
>
>   Filesystem Layout
>   -
>   Merged / filesystem
>   Split /, /var, /tmp, /usr filesystems
>
> then
>
>   Filesystem Type
>   ---
>   UFS
>   ZFS
>
> then
>
>   Disk Layout
>   ---
>   Plain disk
>   Mirror
>   RAID
>
> Those choices might change depending on earlier ones, like if they had
> chosen ZFS earlier they would get a choice of Mirror, RAID-Z1,
> RAID-Z2, and so on.
>
> All this would build up a configuration, and at the end the user can
> edit it (filesystem sizes, for instance), then pick Go and walk away.

All of the UFS stuff is in C, so is read-only for me.

It is something I'd like to do, but it is really iffy if that can be
done in time for 10.0

In general, gmirror support could be added to the ZFS section (renamed
to something else). So in our current 'zfs' menu, would become the 'new
partition manager' menu. Add an extra option for ZFS or UFS, and then
the vdev menu would context switch between zfs vdevs and ufs options
like gmirror and gstripe or something

Adding an extra option for / or / /var /tmp /usr is not a bad idea
either, maybe even for ZFS, offering a simpler set of datasets that
might be some people's preference (especially if I can't do the
following in time:)

In a future revision of the zfsboot stuff, I'd like to offer a dialog
where users can actually adjust the ZFS datasets. provide a menu listing
the created dataset, with option to add more, and when you select a
dataset, you can adjust its options or delete it (some really scary
validation needs to happen here so you can't delete /usr if you have
/usr/local)

If the UFS stuff took the form of the current ZFS stuff (give me the
entire disk, and i'll run with it), it would be fairly easy to
implement, and could probably be done between 10.0-BETA1 and 10.0-BETA2

The more powerful features of the current partedit code, where it
actually shows what is on your disk already, and allows you to just
adjust it, and in general manage dual booting etc, that is a lot more
complicated.

-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 10, 2013, at 10:18 AM, Allan Jude wrote:

> On 2013-10-10 11:30, Teske, Devin wrote:
>> On Oct 10, 2013, at 4:55 AM, Nathan Whitehorn wrote:
>> 
>>> On 10/10/13 09:20, Allan Jude wrote:
 On 2013-10-10 03:00, Nathan Whitehorn wrote:
> On 10/09/13 18:55, Teske, Devin wrote:
>> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
>> 
>>> On 10/09/13 01:13, Allan Jude wrote:
 On 2013-10-08 16:17, Nathan Whitehorn wrote:
> On 10/07/13 21:59, Allan Jude wrote:
>> Devin Teske and I have been working on a big patch to bsdinstall to
>> implement installing on a ZFS pool. It supports both GPT and MBR, 
>> the 4k
>> sector gnop trick, and optional GELI encryption. We would like to 
>> commit
>> this in time for 10.0-BETA1 so it needs some testing to work out any
>> obvious bugs before we send it off to re@ to get it committed.
>> 
>> It includes a single configuration menu that allows you to select 
>> all of
>> the required details, including which drives to use (gets details 
>> from
>> camcontrol, also includes an inspection utility that presents the
>> detailed output of camcontrol inquiry/identify, and gpart show), what
>> ZFS RAID level to use (taking in to consideration the selected 
>> number of
>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>> 
>> 
>> Additional, it includes some other changes to bsdinstall:
>> 1. Change the default to the 'non-standard keyboard mapping' prompt 
>> to no
>> 2. Replace the 3 separate dialogs to configure an ipv4 address with 
>> just 1
>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>> feature has been combined into the regular 'services to enable' 
>> dialog
>> and enabled by default
>> 
>> 
>> You can browse the patches here:
>> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=ckXs2H5TEcKdiN%2F9l%2FClInsMys9LmTwEbElzzrBchMU%3D%0A&s=6361ad5ccc04a6d8401158a3ee1b3d8df9fcd2ef47ff6ad6365a57b907cceaec
>> 
>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>> available compressed (48 MB) or uncompressed (211 MB):
>> 
>> https://urldefense.proofpoint.com/v1/url?u=http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=ckXs2H5TEcKdiN%2F9l%2FClInsMys9LmTwEbElzzrBchMU%3D%0A&s=570daea25d9e629788c76c2b5a6eae19d32050363986a1004a6434c3466965c2
>> 
>> https://urldefense.proofpoint.com/v1/url?u=http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=ckXs2H5TEcKdiN%2F9l%2FClInsMys9LmTwEbElzzrBchMU%3D%0A&s=f52d604a2503a48b409f92f8376bb773de4dbc469d1e74b16d051a20ad894820
>> 
>> 
>> We look forward to your feedback
>> 
> Thanks for doing this! I had a few comments:
> 1. ZFS is not bootable on all architectures. Could you adjust that 
> menu
> item to only display for i386, amd64, and (I think?) sparc64. Use 
> uname
> -m, not -p, for this.
 I had not considered that, I'll make that change
 
> 1a. The script is broken on sparc64 in any case, which uses VTOC8
> instead of GPT.
 I'll disable sparc64 as well
 
> 2. Why are you using camcontrol? That is guaranteed not to work on
> non-CAM systems. You should use the GEOM ident string if you need an 
> ID.
 The GEOM ident string doesn't do enough to help the user identify which
 drive is which.
 More data is not exposed anywhere that I could find
 
 What we really need, is dev.ada.0.desc% like we have for network
 interfaces and a slew of other devices. GEOM data is great, but it is
 not exposed in a shell friendly way any place that I could find, other
 than the sysctl with DOT and XML data.
>>> This is one of the reasons the partition editor is written in C. There
>>> are a few other odd corner-cases where C is much more powerful than the
>>> command-line for the GEOM operations that partedit needs to do. I'm not
>>> sure how to usefully get it just from the shell. You can see how to do
>>> it in C in the boot_disk() routine of partedit/auto_part.c.
>>> 
> 3. Any plans to integrate this into the regular partition editor? ZFS
> support is important enough that I will definitely not get in the way,
> even as a bolt-on, but it would be a shame for it to stay t

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-10 Thread Allan Jude

On 2013-10-10 11:30, Teske, Devin wrote:
> On Oct 10, 2013, at 4:55 AM, Nathan Whitehorn wrote:
>
>> On 10/10/13 09:20, Allan Jude wrote:
>>> On 2013-10-10 03:00, Nathan Whitehorn wrote:
 On 10/09/13 18:55, Teske, Devin wrote:
> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
>
>> On 10/09/13 01:13, Allan Jude wrote:
>>> On 2013-10-08 16:17, Nathan Whitehorn wrote:
 On 10/07/13 21:59, Allan Jude wrote:
> Devin Teske and I have been working on a big patch to bsdinstall to
> implement installing on a ZFS pool. It supports both GPT and MBR, the 
> 4k
> sector gnop trick, and optional GELI encryption. We would like to 
> commit
> this in time for 10.0-BETA1 so it needs some testing to work out any
> obvious bugs before we send it off to re@ to get it committed.
>
> It includes a single configuration menu that allows you to select all 
> of
> the required details, including which drives to use (gets details from
> camcontrol, also includes an inspection utility that presents the
> detailed output of camcontrol inquiry/identify, and gpart show), what
> ZFS RAID level to use (taking in to consideration the selected number 
> of
> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>
>
> Additional, it includes some other changes to bsdinstall:
> 1. Change the default to the 'non-standard keyboard mapping' prompt 
> to no
> 2. Replace the 3 separate dialogs to configure an ipv4 address with 
> just 1
> 3. Remove the dialog asking if you wish to enable crash dumps, this
> feature has been combined into the regular 'services to enable' dialog
> and enabled by default
>
>
> You can browse the patches here:
> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>
> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
> available compressed (48 MB) or uncompressed (211 MB):
>
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>
>
> We look forward to your feedback
>
 Thanks for doing this! I had a few comments:
 1. ZFS is not bootable on all architectures. Could you adjust that menu
 item to only display for i386, amd64, and (I think?) sparc64. Use uname
 -m, not -p, for this.
>>> I had not considered that, I'll make that change
>>>
 1a. The script is broken on sparc64 in any case, which uses VTOC8
 instead of GPT.
>>> I'll disable sparc64 as well
>>>
 2. Why are you using camcontrol? That is guaranteed not to work on
 non-CAM systems. You should use the GEOM ident string if you need an 
 ID.
>>> The GEOM ident string doesn't do enough to help the user identify which
>>> drive is which.
>>> More data is not exposed anywhere that I could find
>>>
>>> What we really need, is dev.ada.0.desc% like we have for network
>>> interfaces and a slew of other devices. GEOM data is great, but it is
>>> not exposed in a shell friendly way any place that I could find, other
>>> than the sysctl with DOT and XML data.
>> This is one of the reasons the partition editor is written in C. There
>> are a few other odd corner-cases where C is much more powerful than the
>> command-line for the GEOM operations that partedit needs to do. I'm not
>> sure how to usefully get it just from the shell. You can see how to do
>> it in C in the boot_disk() routine of partedit/auto_part.c.
>>
 3. Any plans to integrate this into the regular partition editor? ZFS
 support is important enough that I will definitely not get in the way,
 even as a bolt-on, but it would be a shame for it to stay that way. The
 editor is also designed for ZFS to be added.
>>> I am a sysadmin, not a programmer. I can't write C. Most people
>>> deploying servers can't write C. I agree with Devin Teske, if everything
>>> was in shell it would be a lot more usable for non-developers, who
>>> probably make up the majority of people who deploy FreeBSD.
>> There are some cases the other way too. Devin is probably the most
>> shell-proficient FreeBSD committer.
> Well, there's jilles ;D (he writes/maintains the sh(1) implementation 
> itself).
>
>
>> I certainly can't write shell
>> scripts at that level, which means that for me bsdconfig, for example,
>> is effectively read-only (and quite hard to read as well).
> In the past few days of working on the bsdinstall_zfs patch-set with Allan
> Jude, I learned something new actually.
>
> It seems that sh(1) doesn't suffer so much from this "read only" c

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 10, 2013, at 4:55 AM, Nathan Whitehorn wrote:

> On 10/10/13 09:20, Allan Jude wrote:
>> On 2013-10-10 03:00, Nathan Whitehorn wrote:
>>> On 10/09/13 18:55, Teske, Devin wrote:
 On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
 
> On 10/09/13 01:13, Allan Jude wrote:
>> On 2013-10-08 16:17, Nathan Whitehorn wrote:
>>> On 10/07/13 21:59, Allan Jude wrote:
 Devin Teske and I have been working on a big patch to bsdinstall to
 implement installing on a ZFS pool. It supports both GPT and MBR, the 
 4k
 sector gnop trick, and optional GELI encryption. We would like to 
 commit
 this in time for 10.0-BETA1 so it needs some testing to work out any
 obvious bugs before we send it off to re@ to get it committed.
 
 It includes a single configuration menu that allows you to select all 
 of
 the required details, including which drives to use (gets details from
 camcontrol, also includes an inspection utility that presents the
 detailed output of camcontrol inquiry/identify, and gpart show), what
 ZFS RAID level to use (taking in to consideration the selected number 
 of
 drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
 
 
 Additional, it includes some other changes to bsdinstall:
 1. Change the default to the 'non-standard keyboard mapping' prompt to 
 no
 2. Replace the 3 separate dialogs to configure an ipv4 address with 
 just 1
 3. Remove the dialog asking if you wish to enable crash dumps, this
 feature has been combined into the regular 'services to enable' dialog
 and enabled by default
 
 
 You can browse the patches here:
 http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
 
 I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
 available compressed (48 MB) or uncompressed (211 MB):
 
 http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
 
 http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
 
 
 We look forward to your feedback
 
>>> Thanks for doing this! I had a few comments:
>>> 1. ZFS is not bootable on all architectures. Could you adjust that menu
>>> item to only display for i386, amd64, and (I think?) sparc64. Use uname
>>> -m, not -p, for this.
>> I had not considered that, I'll make that change
>> 
>>> 1a. The script is broken on sparc64 in any case, which uses VTOC8
>>> instead of GPT.
>> I'll disable sparc64 as well
>> 
>>> 2. Why are you using camcontrol? That is guaranteed not to work on
>>> non-CAM systems. You should use the GEOM ident string if you need an ID.
>> The GEOM ident string doesn't do enough to help the user identify which
>> drive is which.
>> More data is not exposed anywhere that I could find
>> 
>> What we really need, is dev.ada.0.desc% like we have for network
>> interfaces and a slew of other devices. GEOM data is great, but it is
>> not exposed in a shell friendly way any place that I could find, other
>> than the sysctl with DOT and XML data.
> This is one of the reasons the partition editor is written in C. There
> are a few other odd corner-cases where C is much more powerful than the
> command-line for the GEOM operations that partedit needs to do. I'm not
> sure how to usefully get it just from the shell. You can see how to do
> it in C in the boot_disk() routine of partedit/auto_part.c.
> 
>>> 3. Any plans to integrate this into the regular partition editor? ZFS
>>> support is important enough that I will definitely not get in the way,
>>> even as a bolt-on, but it would be a shame for it to stay that way. The
>>> editor is also designed for ZFS to be added.
>> I am a sysadmin, not a programmer. I can't write C. Most people
>> deploying servers can't write C. I agree with Devin Teske, if everything
>> was in shell it would be a lot more usable for non-developers, who
>> probably make up the majority of people who deploy FreeBSD.
> There are some cases the other way too. Devin is probably the most
> shell-proficient FreeBSD committer.
 Well, there's jilles ;D (he writes/maintains the sh(1) implementation 
 itself).
 
 
> I certainly can't write shell
> scripts at that level, which means that for me bsdconfig, for example,
> is effectively read-only (and quite hard to read as well).
 In the past few days of working on the bsdinstall_zfs patch-set with Allan
 Jude, I learned something new actually.
 
 It seems that sh(1) doesn't suffer so much from this "read only" concept.
 
 Imagine you're starting a new C project on an operating system that has
 all new syscalls and all new APIs

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-10 Thread Nathan Whitehorn

On 10/10/13 09:20, Allan Jude wrote:
> On 2013-10-10 03:00, Nathan Whitehorn wrote:
>> On 10/09/13 18:55, Teske, Devin wrote:
>>> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
>>>
 On 10/09/13 01:13, Allan Jude wrote:
> On 2013-10-08 16:17, Nathan Whitehorn wrote:
>> On 10/07/13 21:59, Allan Jude wrote:
>>> Devin Teske and I have been working on a big patch to bsdinstall to
>>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>>> sector gnop trick, and optional GELI encryption. We would like to commit
>>> this in time for 10.0-BETA1 so it needs some testing to work out any
>>> obvious bugs before we send it off to re@ to get it committed.
>>>
>>> It includes a single configuration menu that allows you to select all of
>>> the required details, including which drives to use (gets details from
>>> camcontrol, also includes an inspection utility that presents the
>>> detailed output of camcontrol inquiry/identify, and gpart show), what
>>> ZFS RAID level to use (taking in to consideration the selected number of
>>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>>>
>>>
>>> Additional, it includes some other changes to bsdinstall:
>>> 1. Change the default to the 'non-standard keyboard mapping' prompt to 
>>> no
>>> 2. Replace the 3 separate dialogs to configure an ipv4 address with 
>>> just 1
>>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>>> feature has been combined into the regular 'services to enable' dialog
>>> and enabled by default
>>>
>>>
>>> You can browse the patches here:
>>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>>
>>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>>> available compressed (48 MB) or uncompressed (211 MB):
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>>
>>>
>>> We look forward to your feedback
>>>
>> Thanks for doing this! I had a few comments:
>> 1. ZFS is not bootable on all architectures. Could you adjust that menu
>> item to only display for i386, amd64, and (I think?) sparc64. Use uname
>> -m, not -p, for this.
> I had not considered that, I'll make that change
>
>> 1a. The script is broken on sparc64 in any case, which uses VTOC8
>> instead of GPT.
> I'll disable sparc64 as well
>
>> 2. Why are you using camcontrol? That is guaranteed not to work on
>> non-CAM systems. You should use the GEOM ident string if you need an ID.
> The GEOM ident string doesn't do enough to help the user identify which
> drive is which.
> More data is not exposed anywhere that I could find
>
> What we really need, is dev.ada.0.desc% like we have for network
> interfaces and a slew of other devices. GEOM data is great, but it is
> not exposed in a shell friendly way any place that I could find, other
> than the sysctl with DOT and XML data.
 This is one of the reasons the partition editor is written in C. There
 are a few other odd corner-cases where C is much more powerful than the
 command-line for the GEOM operations that partedit needs to do. I'm not
 sure how to usefully get it just from the shell. You can see how to do
 it in C in the boot_disk() routine of partedit/auto_part.c.

>> 3. Any plans to integrate this into the regular partition editor? ZFS
>> support is important enough that I will definitely not get in the way,
>> even as a bolt-on, but it would be a shame for it to stay that way. The
>> editor is also designed for ZFS to be added.
> I am a sysadmin, not a programmer. I can't write C. Most people
> deploying servers can't write C. I agree with Devin Teske, if everything
> was in shell it would be a lot more usable for non-developers, who
> probably make up the majority of people who deploy FreeBSD.
 There are some cases the other way too. Devin is probably the most
 shell-proficient FreeBSD committer.
>>> Well, there's jilles ;D (he writes/maintains the sh(1) implementation 
>>> itself).
>>>
>>>
 I certainly can't write shell
 scripts at that level, which means that for me bsdconfig, for example,
 is effectively read-only (and quite hard to read as well).
>>> In the past few days of working on the bsdinstall_zfs patch-set with Allan
>>> Jude, I learned something new actually.
>>>
>>> It seems that sh(1) doesn't suffer so much from this "read only" concept.
>>>
>>> Imagine you're starting a new C project on an operating system that has
>>> all new syscalls and all new APIs that you've never seen. Would be pretty
>>> hard, no doubt. Now imagine that you're thrown a life-line called POSIX
>>> and hey, now you're slinging code in MinGW on Windows when you don't
>>> know a lick of M$

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-10 Thread Allan Jude

On 2013-10-10 03:00, Nathan Whitehorn wrote:
> On 10/09/13 18:55, Teske, Devin wrote:
>> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
>>
>>> On 10/09/13 01:13, Allan Jude wrote:
 On 2013-10-08 16:17, Nathan Whitehorn wrote:
> On 10/07/13 21:59, Allan Jude wrote:
>> Devin Teske and I have been working on a big patch to bsdinstall to
>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>> sector gnop trick, and optional GELI encryption. We would like to commit
>> this in time for 10.0-BETA1 so it needs some testing to work out any
>> obvious bugs before we send it off to re@ to get it committed.
>>
>> It includes a single configuration menu that allows you to select all of
>> the required details, including which drives to use (gets details from
>> camcontrol, also includes an inspection utility that presents the
>> detailed output of camcontrol inquiry/identify, and gpart show), what
>> ZFS RAID level to use (taking in to consideration the selected number of
>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>>
>>
>> Additional, it includes some other changes to bsdinstall:
>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 
>> 1
>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>> feature has been combined into the regular 'services to enable' dialog
>> and enabled by default
>>
>>
>> You can browse the patches here:
>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>
>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>> available compressed (48 MB) or uncompressed (211 MB):
>>
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>
>>
>> We look forward to your feedback
>>
> Thanks for doing this! I had a few comments:
> 1. ZFS is not bootable on all architectures. Could you adjust that menu
> item to only display for i386, amd64, and (I think?) sparc64. Use uname
> -m, not -p, for this.
 I had not considered that, I'll make that change

> 1a. The script is broken on sparc64 in any case, which uses VTOC8
> instead of GPT.
 I'll disable sparc64 as well

> 2. Why are you using camcontrol? That is guaranteed not to work on
> non-CAM systems. You should use the GEOM ident string if you need an ID.
 The GEOM ident string doesn't do enough to help the user identify which
 drive is which.
 More data is not exposed anywhere that I could find

 What we really need, is dev.ada.0.desc% like we have for network
 interfaces and a slew of other devices. GEOM data is great, but it is
 not exposed in a shell friendly way any place that I could find, other
 than the sysctl with DOT and XML data.
>>> This is one of the reasons the partition editor is written in C. There
>>> are a few other odd corner-cases where C is much more powerful than the
>>> command-line for the GEOM operations that partedit needs to do. I'm not
>>> sure how to usefully get it just from the shell. You can see how to do
>>> it in C in the boot_disk() routine of partedit/auto_part.c.
>>>
> 3. Any plans to integrate this into the regular partition editor? ZFS
> support is important enough that I will definitely not get in the way,
> even as a bolt-on, but it would be a shame for it to stay that way. The
> editor is also designed for ZFS to be added.
 I am a sysadmin, not a programmer. I can't write C. Most people
 deploying servers can't write C. I agree with Devin Teske, if everything
 was in shell it would be a lot more usable for non-developers, who
 probably make up the majority of people who deploy FreeBSD.
>>> There are some cases the other way too. Devin is probably the most
>>> shell-proficient FreeBSD committer.
>> Well, there's jilles ;D (he writes/maintains the sh(1) implementation 
>> itself).
>>
>>
>>> I certainly can't write shell
>>> scripts at that level, which means that for me bsdconfig, for example,
>>> is effectively read-only (and quite hard to read as well).
>> In the past few days of working on the bsdinstall_zfs patch-set with Allan
>> Jude, I learned something new actually.
>>
>> It seems that sh(1) doesn't suffer so much from this "read only" concept.
>>
>> Imagine you're starting a new C project on an operating system that has
>> all new syscalls and all new APIs that you've never seen. Would be pretty
>> hard, no doubt. Now imagine that you're thrown a life-line called POSIX
>> and hey, now you're slinging code in MinGW on Windows when you don't
>> know a lick of M$ syscalls or APIs.
>>
>> In a similar manner, I've witnessed functionality be added that is truly
>> functional *without* using any of the API c

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 10, 2013, at 12:00 AM, Nathan Whitehorn wrote:

> On 10/09/13 18:55, Teske, Devin wrote:
>> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
>> 
>>> On 10/09/13 01:13, Allan Jude wrote:
 On 2013-10-08 16:17, Nathan Whitehorn wrote:
> On 10/07/13 21:59, Allan Jude wrote:
>> Devin Teske and I have been working on a big patch to bsdinstall to
>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>> sector gnop trick, and optional GELI encryption. We would like to commit
>> this in time for 10.0-BETA1 so it needs some testing to work out any
>> obvious bugs before we send it off to re@ to get it committed.
>> 
>> It includes a single configuration menu that allows you to select all of
>> the required details, including which drives to use (gets details from
>> camcontrol, also includes an inspection utility that presents the
>> detailed output of camcontrol inquiry/identify, and gpart show), what
>> ZFS RAID level to use (taking in to consideration the selected number of
>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>> 
>> 
>> Additional, it includes some other changes to bsdinstall:
>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 
>> 1
>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>> feature has been combined into the regular 'services to enable' dialog
>> and enabled by default
>> 
>> 
>> You can browse the patches here:
>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>> 
>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>> available compressed (48 MB) or uncompressed (211 MB):
>> 
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>> 
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>> 
>> 
>> We look forward to your feedback
>> 
> Thanks for doing this! I had a few comments:
> 1. ZFS is not bootable on all architectures. Could you adjust that menu
> item to only display for i386, amd64, and (I think?) sparc64. Use uname
> -m, not -p, for this.
 I had not considered that, I'll make that change
 
> 1a. The script is broken on sparc64 in any case, which uses VTOC8
> instead of GPT.
 I'll disable sparc64 as well
 
> 2. Why are you using camcontrol? That is guaranteed not to work on
> non-CAM systems. You should use the GEOM ident string if you need an ID.
 The GEOM ident string doesn't do enough to help the user identify which
 drive is which.
 More data is not exposed anywhere that I could find
 
 What we really need, is dev.ada.0.desc% like we have for network
 interfaces and a slew of other devices. GEOM data is great, but it is
 not exposed in a shell friendly way any place that I could find, other
 than the sysctl with DOT and XML data.
>>> This is one of the reasons the partition editor is written in C. There
>>> are a few other odd corner-cases where C is much more powerful than the
>>> command-line for the GEOM operations that partedit needs to do. I'm not
>>> sure how to usefully get it just from the shell. You can see how to do
>>> it in C in the boot_disk() routine of partedit/auto_part.c.
>>> 
> 3. Any plans to integrate this into the regular partition editor? ZFS
> support is important enough that I will definitely not get in the way,
> even as a bolt-on, but it would be a shame for it to stay that way. The
> editor is also designed for ZFS to be added.
 I am a sysadmin, not a programmer. I can't write C. Most people
 deploying servers can't write C. I agree with Devin Teske, if everything
 was in shell it would be a lot more usable for non-developers, who
 probably make up the majority of people who deploy FreeBSD.
>>> There are some cases the other way too. Devin is probably the most
>>> shell-proficient FreeBSD committer.
>> Well, there's jilles ;D (he writes/maintains the sh(1) implementation 
>> itself).
>> 
>> 
>>> I certainly can't write shell
>>> scripts at that level, which means that for me bsdconfig, for example,
>>> is effectively read-only (and quite hard to read as well).
>> In the past few days of working on the bsdinstall_zfs patch-set with Allan
>> Jude, I learned something new actually.
>> 
>> It seems that sh(1) doesn't suffer so much from this "read only" concept.
>> 
>> Imagine you're starting a new C project on an operating system that has
>> all new syscalls and all new APIs that you've never seen. Would be pretty
>> hard, no doubt. Now imagine that you're thrown a life-line called POSIX
>> and hey, now you're slinging code in MinGW on Windows when you don't
>> know a lick of M$ syscalls or APIs.
>> 
>> In a similar manner, I've witnessed functionality be added that is truly
>> functional

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-10 Thread Nathan Whitehorn

On 10/09/13 18:55, Teske, Devin wrote:
> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
>
>> On 10/09/13 01:13, Allan Jude wrote:
>>> On 2013-10-08 16:17, Nathan Whitehorn wrote:
 On 10/07/13 21:59, Allan Jude wrote:
> Devin Teske and I have been working on a big patch to bsdinstall to
> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
> sector gnop trick, and optional GELI encryption. We would like to commit
> this in time for 10.0-BETA1 so it needs some testing to work out any
> obvious bugs before we send it off to re@ to get it committed.
>
> It includes a single configuration menu that allows you to select all of
> the required details, including which drives to use (gets details from
> camcontrol, also includes an inspection utility that presents the
> detailed output of camcontrol inquiry/identify, and gpart show), what
> ZFS RAID level to use (taking in to consideration the selected number of
> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>
>
> Additional, it includes some other changes to bsdinstall:
> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
> 3. Remove the dialog asking if you wish to enable crash dumps, this
> feature has been combined into the regular 'services to enable' dialog
> and enabled by default
>
>
> You can browse the patches here:
> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>
> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
> available compressed (48 MB) or uncompressed (211 MB):
>
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>
>
> We look forward to your feedback
>
 Thanks for doing this! I had a few comments:
 1. ZFS is not bootable on all architectures. Could you adjust that menu
 item to only display for i386, amd64, and (I think?) sparc64. Use uname
 -m, not -p, for this.
>>> I had not considered that, I'll make that change
>>>
 1a. The script is broken on sparc64 in any case, which uses VTOC8
 instead of GPT.
>>> I'll disable sparc64 as well
>>>
 2. Why are you using camcontrol? That is guaranteed not to work on
 non-CAM systems. You should use the GEOM ident string if you need an ID.
>>> The GEOM ident string doesn't do enough to help the user identify which
>>> drive is which.
>>> More data is not exposed anywhere that I could find
>>>
>>> What we really need, is dev.ada.0.desc% like we have for network
>>> interfaces and a slew of other devices. GEOM data is great, but it is
>>> not exposed in a shell friendly way any place that I could find, other
>>> than the sysctl with DOT and XML data.
>> This is one of the reasons the partition editor is written in C. There
>> are a few other odd corner-cases where C is much more powerful than the
>> command-line for the GEOM operations that partedit needs to do. I'm not
>> sure how to usefully get it just from the shell. You can see how to do
>> it in C in the boot_disk() routine of partedit/auto_part.c.
>>
 3. Any plans to integrate this into the regular partition editor? ZFS
 support is important enough that I will definitely not get in the way,
 even as a bolt-on, but it would be a shame for it to stay that way. The
 editor is also designed for ZFS to be added.
>>> I am a sysadmin, not a programmer. I can't write C. Most people
>>> deploying servers can't write C. I agree with Devin Teske, if everything
>>> was in shell it would be a lot more usable for non-developers, who
>>> probably make up the majority of people who deploy FreeBSD.
>> There are some cases the other way too. Devin is probably the most
>> shell-proficient FreeBSD committer.
> Well, there's jilles ;D (he writes/maintains the sh(1) implementation itself).
>
>
>> I certainly can't write shell
>> scripts at that level, which means that for me bsdconfig, for example,
>> is effectively read-only (and quite hard to read as well).
> In the past few days of working on the bsdinstall_zfs patch-set with Allan
> Jude, I learned something new actually.
>
> It seems that sh(1) doesn't suffer so much from this "read only" concept.
>
> Imagine you're starting a new C project on an operating system that has
> all new syscalls and all new APIs that you've never seen. Would be pretty
> hard, no doubt. Now imagine that you're thrown a life-line called POSIX
> and hey, now you're slinging code in MinGW on Windows when you don't
> know a lick of M$ syscalls or APIs.
>
> In a similar manner, I've witnessed functionality be added that is truly
> functional *without* using any of the API calls. Then I come in and do
> a round of optimizations to leverage the existing API.
>
> Shell is kinda like that...
>
> I'm noticing Allan Jude doesn't k

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 9, 2013, at 8:11 PM, Allan Jude wrote:

> On 2013-10-09 14:14, Teske, Devin wrote:
>> On Oct 9, 2013, at 10:47 AM, Allan Jude wrote:
>> 
>>> On 2013-10-09 13:21, Teske, Devin wrote:
 On Oct 8, 2013, at 8:49 PM, Allan Jude wrote:
 
> On 2013-10-07 15:59, Allan Jude wrote:
>> Devin Teske and I have been working on a big patch to bsdinstall to
>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>> sector gnop trick, and optional GELI encryption. We would like to commit
>> this in time for 10.0-BETA1 so it needs some testing to work out any
>> obvious bugs before we send it off to re@ to get it committed.
>> 
>> It includes a single configuration menu that allows you to select all of
>> the required details, including which drives to use (gets details from
>> camcontrol, also includes an inspection utility that presents the
>> detailed output of camcontrol inquiry/identify, and gpart show), what
>> ZFS RAID level to use (taking in to consideration the selected number of
>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>> 
>> 
>> Additional, it includes some other changes to bsdinstall:
>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 
>> 1
>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>> feature has been combined into the regular 'services to enable' dialog
>> and enabled by default
>> 
>> 
>> You can browse the patches here:
>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>> 
>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>> available compressed (48 MB) or uncompressed (211 MB):
>> 
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>> 
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>> 
>> 
>> We look forward to your feedback
>> 
> We've made more improvements, including corporating most all of the
> feedback we've gotten so far
> 
> 
> Outstanding items:
> 1. Apply the changes to ipv6 config the way we did ipv4
> 2. improve disk identification (model info and serial # instead of one
> or the other)
> 3. Include a helpful message before the GELI step where you have to
> enter your password many times, the user will be less confused if it is
> explained why they have to enter their password 3 * number of disks times
 I'm hopeful that we can script the application of a password that we
 first prompt for.
 
 What tool is prompting for a password? Can we not just provide an answer
 on stdin? (e.g., echo "$pass" | tool_that_needs_pass)
 
>>> It is 'geli create' and 'geli attach'. I am not sure if we want to have
>>> the password show up in the process list (obviously in the installer
>>> this is less of an issue, but)
>>> 
>> It won't.
>> 
>> echo is a shell built-in.
>> 
>> If we're uber paranoid... we prefix the word "builtin"; e.g.,...
>> 
>> builtin echo "$pass" | tool_that_needs_pass
>> 
>> You'll see the tool in ps, but you won't see the echo (that's part of the
>> shell invocation -- all you see in ps is an instance of sh).
>> 
> I have implemented this, 'geli init' takes the -J  flag, which can
> be set to - to mean stdin. 'geli attach' is the same except the flag is -j
> 
> I first prompt for the password with a dialog --passwordbox, so the user
> only has to enter it once
> 
> Do we think it makes sense to prompt the user twice, and confirm the two
> entered passphrases are the same?
> 

I think so. I'm afraid someone could make a typo and then not be able to
log into their system because the password that was actually used is
different than what the user thinks it is.




> 
>> 
> 4. Validate vdev type choice inside the vdev type menu, and warn the
> user if they have made an invalid selection, so they can add more disks
> or chance their selection, without having to try to start the
> installation first
 This will be done with fanciness ;D (read: ... --and-widget --infobox ... 
 and
 sundry smartness; retaining as much as possible the ability to do things
 out of order but never arise at a point of astonishment).
 
>>> I don't think we need --and-widget, just in the function where we apply
>>> the results of the menu selection,
>> The purpose of --and-widget with an --infobox is to let the user know that
>> validation is occurring each/every time they make a selection.
>> 
>> Seeing the infobox before being returned to the previous menu (in the case
>> of selecting a valid vdev_type) is to cement in the mind of the user that 
>> their
>> selection was validated. Of course, in the case of an invalid selection, they
>> get a message box. What the message box says depends on:
>> 
>> 1. Are they trying to select a vdev_type f

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-09 Thread Allan Jude

On 2013-10-09 14:14, Teske, Devin wrote:
> On Oct 9, 2013, at 10:47 AM, Allan Jude wrote:
>
>> On 2013-10-09 13:21, Teske, Devin wrote:
>>> On Oct 8, 2013, at 8:49 PM, Allan Jude wrote:
>>>
 On 2013-10-07 15:59, Allan Jude wrote:
> Devin Teske and I have been working on a big patch to bsdinstall to
> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
> sector gnop trick, and optional GELI encryption. We would like to commit
> this in time for 10.0-BETA1 so it needs some testing to work out any
> obvious bugs before we send it off to re@ to get it committed.
>
> It includes a single configuration menu that allows you to select all of
> the required details, including which drives to use (gets details from
> camcontrol, also includes an inspection utility that presents the
> detailed output of camcontrol inquiry/identify, and gpart show), what
> ZFS RAID level to use (taking in to consideration the selected number of
> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>
>
> Additional, it includes some other changes to bsdinstall:
> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
> 3. Remove the dialog asking if you wish to enable crash dumps, this
> feature has been combined into the regular 'services to enable' dialog
> and enabled by default
>
>
> You can browse the patches here:
> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=oPEdrpFUFqEutq%2B7DHGyBIA0gTt5%2BZ6FWvbN6q4bjm4%3D%0A&s=32f69a33d9c98c63ecf3962b89eea0af631f5a2fd6e82b55afb6ec139f3f803d
>
> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
> available compressed (48 MB) or uncompressed (211 MB):
>
> https://urldefense.proofpoint.com/v1/url?u=http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=oPEdrpFUFqEutq%2B7DHGyBIA0gTt5%2BZ6FWvbN6q4bjm4%3D%0A&s=fd0f3ed623f12c8cb5eee607cf82122523a0800ab9f5624cb3f77ae2646e1b1b
>
> https://urldefense.proofpoint.com/v1/url?u=http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=oPEdrpFUFqEutq%2B7DHGyBIA0gTt5%2BZ6FWvbN6q4bjm4%3D%0A&s=fa49aaa528513a591ac40a2f0c5666abae2d7269bd66ac70d7100475a9574300
>
>
> We look forward to your feedback
>
 We've made more improvements, including corporating most all of the
 feedback we've gotten so far


 Outstanding items:
 1. Apply the changes to ipv6 config the way we did ipv4
 2. improve disk identification (model info and serial # instead of one
 or the other)
 3. Include a helpful message before the GELI step where you have to
 enter your password many times, the user will be less confused if it is
 explained why they have to enter their password 3 * number of disks times
>>> I'm hopeful that we can script the application of a password that we
>>> first prompt for.
>>>
>>> What tool is prompting for a password? Can we not just provide an answer
>>> on stdin? (e.g., echo "$pass" | tool_that_needs_pass)
>>>
>> It is 'geli create' and 'geli attach'. I am not sure if we want to have
>> the password show up in the process list (obviously in the installer
>> this is less of an issue, but)
>>
> It won't.
>
> echo is a shell built-in.
>
> If we're uber paranoid... we prefix the word "builtin"; e.g.,...
>
> builtin echo "$pass" | tool_that_needs_pass
>
> You'll see the tool in ps, but you won't see the echo (that's part of the
> shell invocation -- all you see in ps is an instance of sh).
>
I have implemented this, 'geli init' takes the -J  flag, which can
be set to - to mean stdin. 'geli attach' is the same except the flag is -j

I first prompt for the password with a dialog --passwordbox, so the user
only has to enter it once

Do we think it makes sense to prompt the user twice, and confirm the two
entered passphrases are the same?


>
 4. Validate vdev type choice inside the vdev type menu, and warn the
 user if they have made an invalid selection, so they can add more disks
 or chance their selection, without having to try to start the
 installation first
>>> This will be done with fanciness ;D (read: ... --and-widget --infobox ... 
>>> and
>>> sundry smartness; retaining as much as possible the ability to do things
>>> out of order but never arise at a point of astonishment).
>>>
>> I don't think we need --and-widget, just in the function where we apply
>> the results of the menu selection,
> The purpose of --and-widget with an --infobox is to let the user know that
> validation is occurring each

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

On Oct 9, 2013, at 10:47 AM, Allan Jude wrote:

> On 2013-10-09 13:21, Teske, Devin wrote:
>> On Oct 8, 2013, at 8:49 PM, Allan Jude wrote:
>> 
>>> On 2013-10-07 15:59, Allan Jude wrote:
 Devin Teske and I have been working on a big patch to bsdinstall to
 implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
 sector gnop trick, and optional GELI encryption. We would like to commit
 this in time for 10.0-BETA1 so it needs some testing to work out any
 obvious bugs before we send it off to re@ to get it committed.

 It includes a single configuration menu that allows you to select all of
 the required details, including which drives to use (gets details from
 camcontrol, also includes an inspection utility that presents the
 detailed output of camcontrol inquiry/identify, and gpart show), what
 ZFS RAID level to use (taking in to consideration the selected number of
 drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.

 Additional, it includes some other changes to bsdinstall:
 1. Change the default to the 'non-standard keyboard mapping' prompt to no
 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
 3. Remove the dialog asking if you wish to enable crash dumps, this
 feature has been combined into the regular 'services to enable' dialog
 and enabled by default

 You can browse the patches here:
 https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=oPEdrpFUFqEutq%2B7DHGyBIA0gTt5%2BZ6FWvbN6q4bjm4%3D%0A&s=32f69a33d9c98c63ecf3962b89eea0af631f5a2fd6e82b55afb6ec139f3f803d

 I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
 available compressed (48 MB) or uncompressed (211 MB):

 https://urldefense.proofpoint.com/v1/url?u=http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=oPEdrpFUFqEutq%2B7DHGyBIA0gTt5%2BZ6FWvbN6q4bjm4%3D%0A&s=fd0f3ed623f12c8cb5eee607cf82122523a0800ab9f5624cb3f77ae2646e1b1b

 https://urldefense.proofpoint.com/v1/url?u=http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=oPEdrpFUFqEutq%2B7DHGyBIA0gTt5%2BZ6FWvbN6q4bjm4%3D%0A&s=fa49aaa528513a591ac40a2f0c5666abae2d7269bd66ac70d7100475a9574300

 We look forward to your feedback

>>> We've made more improvements, including corporating most all of the
>>> feedback we've gotten so far
>>> 
>>> 
>>> Outstanding items:
>>> 1. Apply the changes to ipv6 config the way we did ipv4
>>> 2. improve disk identification (model info and serial # instead of one
>>> or the other)
>>> 3. Include a helpful message before the GELI step where you have to
>>> enter your password many times, the user will be less confused if it is
>>> explained why they have to enter their password 3 * number of disks times
>> I'm hopeful that we can script the application of a password that we
>> first prompt for.
>> 
>> What tool is prompting for a password? Can we not just provide an answer
>> on stdin? (e.g., echo "$pass" | tool_that_needs_pass)
>> 
> It is 'geli create' and 'geli attach'. I am not sure if we want to have
> the password show up in the process list (obviously in the installer
> this is less of an issue, but)
> 

It won't.

echo is a shell built-in.

If we're uber paranoid... we prefix the word "builtin"; e.g.,...

builtin echo "$pass" | tool_that_needs_pass

You'll see the tool in ps, but you won't see the echo (that's part of the
shell invocation -- all you see in ps is an instance of sh).

>> 
>>> 4. Validate vdev type choice inside the vdev type menu, and warn the
>>> user if they have made an invalid selection, so they can add more disks
>>> or chance their selection, without having to try to start the
>>> installation first
>> This will be done with fanciness ;D (read: ... --and-widget --infobox ... and
>> sundry smartness; retaining as much as possible the ability to do things
>> out of order but never arise at a point of astonishment).
>> 
> 
> I don't think we need --and-widget, just in the function where we apply
> the results of the menu selection,

The purpose of --and-widget with an --infobox is to let the user know that
validation is occurring each/every time they make a selection.

Seeing the infobox before being returned to the previous menu (in the case
of selecting a valid vdev_type) is to cement in the mind of the user that their
selection was validated. Of course, in the case of an invalid selection, they
get a message box. What the message box says depends on:

1. Are they trying to select a vdev_type for which they don't have enough
devices? Tell them that they don't have enough devices, and bri

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-09 Thread Allan Jude

On 2013-10-09 13:21, Teske, Devin wrote:
> On Oct 8, 2013, at 8:49 PM, Allan Jude wrote:
>
>> On 2013-10-07 15:59, Allan Jude wrote:
>>> Devin Teske and I have been working on a big patch to bsdinstall to
>>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>>> sector gnop trick, and optional GELI encryption. We would like to commit
>>> this in time for 10.0-BETA1 so it needs some testing to work out any
>>> obvious bugs before we send it off to re@ to get it committed.
>>>
>>> It includes a single configuration menu that allows you to select all of
>>> the required details, including which drives to use (gets details from
>>> camcontrol, also includes an inspection utility that presents the
>>> detailed output of camcontrol inquiry/identify, and gpart show), what
>>> ZFS RAID level to use (taking in to consideration the selected number of
>>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>>>
>>>
>>> Additional, it includes some other changes to bsdinstall:
>>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
>>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>>> feature has been combined into the regular 'services to enable' dialog
>>> and enabled by default
>>>
>>>
>>> You can browse the patches here:
>>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>>
>>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>>> available compressed (48 MB) or uncompressed (211 MB):
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>>
>>>
>>> We look forward to your feedback
>>>
>> We've made more improvements, including corporating most all of the
>> feedback we've gotten so far
>>
>>
>> Outstanding items:
>> 1. Apply the changes to ipv6 config the way we did ipv4
>> 2. improve disk identification (model info and serial # instead of one
>> or the other)
>> 3. Include a helpful message before the GELI step where you have to
>> enter your password many times, the user will be less confused if it is
>> explained why they have to enter their password 3 * number of disks times
> I'm hopeful that we can script the application of a password that we
> first prompt for.
>
> What tool is prompting for a password? Can we not just provide an answer
> on stdin? (e.g., echo "$pass" | tool_that_needs_pass)
>
It is 'geli create' and 'geli attach'. I am not sure if we want to have
the password show up in the process list (obviously in the installer
this is less of an issue, but)

>
>> 4. Validate vdev type choice inside the vdev type menu, and warn the
>> user if they have made an invalid selection, so they can add more disks
>> or chance their selection, without having to try to start the
>> installation first
> This will be done with fanciness ;D (read: ... --and-widget --infobox ... and
> sundry smartness; retaining as much as possible the ability to do things
> out of order but never arise at a point of astonishment).
>

I don't think we need --and-widget, just in the function where we apply
the results of the menu selection, we can add a regular --msgbox telling
them that their config won't work, and they need to either select more
drives or a different vdev type

>> 5. Whatever else you guys find wrong tonight
>>
>> I generated new test images, and attached the patch (which got REALLY
>> big when Devin Teske decided to fix "all of the things":
>>
> And then I merged "all of the things" into HEAD, so the patch-set shrunk
> back to its normal size. Now we have global exit codes which will make
> merging of code that is based off of Thomas Dickey's samples easier.

I am glad to see all of the good ideas, and plans to make everything
wonderful, but my biggest concern is getting this over to re@ so it can
get in to 10.0-BETA1, the deadline for which is looming (like, tomorrow
I think).

As such, I have rolled back the patches to netconfig and netconfig_ipv4
(my stuff to reduce the number of dialogs to configure ipv4, it posed
some problems with the possible usage of xdialog, and didn't actually
offer an option to 'cancel'). I kept Warren's netconfig wireless patch

This leaves the only real outstanding problem the keymap thing. I
propose changing it from a yes/no/other to a --menu, and hopefully we
can find the bug with the display name, or just make it show the keymap
name instead.



-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 8, 2013, at 8:49 PM, Allan Jude wrote:

> On 2013-10-07 15:59, Allan Jude wrote:
>> Devin Teske and I have been working on a big patch to bsdinstall to
>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>> sector gnop trick, and optional GELI encryption. We would like to commit
>> this in time for 10.0-BETA1 so it needs some testing to work out any
>> obvious bugs before we send it off to re@ to get it committed.
>> 
>> It includes a single configuration menu that allows you to select all of
>> the required details, including which drives to use (gets details from
>> camcontrol, also includes an inspection utility that presents the
>> detailed output of camcontrol inquiry/identify, and gpart show), what
>> ZFS RAID level to use (taking in to consideration the selected number of
>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>> 
>> 
>> Additional, it includes some other changes to bsdinstall:
>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>> feature has been combined into the regular 'services to enable' dialog
>> and enabled by default
>> 
>> 
>> You can browse the patches here:
>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>> 
>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>> available compressed (48 MB) or uncompressed (211 MB):
>> 
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>> 
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>> 
>> 
>> We look forward to your feedback
>> 
> 
> We've made more improvements, including corporating most all of the
> feedback we've gotten so far
> 
> 
> Outstanding items:
> 1. Apply the changes to ipv6 config the way we did ipv4
> 2. improve disk identification (model info and serial # instead of one
> or the other)
> 3. Include a helpful message before the GELI step where you have to
> enter your password many times, the user will be less confused if it is
> explained why they have to enter their password 3 * number of disks times

I'm hopeful that we can script the application of a password that we
first prompt for.

What tool is prompting for a password? Can we not just provide an answer
on stdin? (e.g., echo "$pass" | tool_that_needs_pass)



> 4. Validate vdev type choice inside the vdev type menu, and warn the
> user if they have made an invalid selection, so they can add more disks
> or chance their selection, without having to try to start the
> installation first

This will be done with fanciness ;D (read: ... --and-widget --infobox ... and
sundry smartness; retaining as much as possible the ability to do things
out of order but never arise at a point of astonishment).


> 5. Whatever else you guys find wrong tonight
> 
> I generated new test images, and attached the patch (which got REALLY
> big when Devin Teske decided to fix "all of the things":
> 

And then I merged "all of the things" into HEAD, so the patch-set shrunk
back to its normal size. Now we have global exit codes which will make
merging of code that is based off of Thomas Dickey's samples easier.
-- 
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] Patch to bsdinstall to support root-on-ZFS and GELI

On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:

> On 10/09/13 01:13, Allan Jude wrote:
>> On 2013-10-08 16:17, Nathan Whitehorn wrote:
>>> On 10/07/13 21:59, Allan Jude wrote:
 Devin Teske and I have been working on a big patch to bsdinstall to
 implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
 sector gnop trick, and optional GELI encryption. We would like to commit
 this in time for 10.0-BETA1 so it needs some testing to work out any
 obvious bugs before we send it off to re@ to get it committed.

 It includes a single configuration menu that allows you to select all of
 the required details, including which drives to use (gets details from
 camcontrol, also includes an inspection utility that presents the
 detailed output of camcontrol inquiry/identify, and gpart show), what
 ZFS RAID level to use (taking in to consideration the selected number of
 drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.

 Additional, it includes some other changes to bsdinstall:
 1. Change the default to the 'non-standard keyboard mapping' prompt to no
 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
 3. Remove the dialog asking if you wish to enable crash dumps, this
 feature has been combined into the regular 'services to enable' dialog
 and enabled by default

 You can browse the patches here:
 http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/

 I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
 available compressed (48 MB) or uncompressed (211 MB):

 http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz

 http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso

 We look forward to your feedback

>>> Thanks for doing this! I had a few comments:
>>> 1. ZFS is not bootable on all architectures. Could you adjust that menu
>>> item to only display for i386, amd64, and (I think?) sparc64. Use uname
>>> -m, not -p, for this.
>> I had not considered that, I'll make that change
>> 
>>> 1a. The script is broken on sparc64 in any case, which uses VTOC8
>>> instead of GPT.
>> I'll disable sparc64 as well
>> 
>>> 2. Why are you using camcontrol? That is guaranteed not to work on
>>> non-CAM systems. You should use the GEOM ident string if you need an ID.
>> The GEOM ident string doesn't do enough to help the user identify which
>> drive is which.
>> More data is not exposed anywhere that I could find
>> 
>> What we really need, is dev.ada.0.desc% like we have for network
>> interfaces and a slew of other devices. GEOM data is great, but it is
>> not exposed in a shell friendly way any place that I could find, other
>> than the sysctl with DOT and XML data.
> 
> This is one of the reasons the partition editor is written in C. There
> are a few other odd corner-cases where C is much more powerful than the
> command-line for the GEOM operations that partedit needs to do. I'm not
> sure how to usefully get it just from the shell. You can see how to do
> it in C in the boot_disk() routine of partedit/auto_part.c.
> 
>>> 3. Any plans to integrate this into the regular partition editor? ZFS
>>> support is important enough that I will definitely not get in the way,
>>> even as a bolt-on, but it would be a shame for it to stay that way. The
>>> editor is also designed for ZFS to be added.
>> I am a sysadmin, not a programmer. I can't write C. Most people
>> deploying servers can't write C. I agree with Devin Teske, if everything
>> was in shell it would be a lot more usable for non-developers, who
>> probably make up the majority of people who deploy FreeBSD.
> 
> There are some cases the other way too. Devin is probably the most
> shell-proficient FreeBSD committer.

Well, there's jilles ;D (he writes/maintains the sh(1) implementation itself).

> I certainly can't write shell
> scripts at that level, which means that for me bsdconfig, for example,
> is effectively read-only (and quite hard to read as well).

In the past few days of working on the bsdinstall_zfs patch-set with Allan
Jude, I learned something new actually.

It seems that sh(1) doesn't suffer so much from this "read only" concept.

Imagine you're starting a new C project on an operating system that has
all new syscalls and all new APIs that you've never seen. Would be pretty
hard, no doubt. Now imagine that you're thrown a life-line called POSIX
and hey, now you're slinging code in MinGW on Windows when you don't
know a lick of M$ syscalls or APIs.

In a similar manner, I've witnessed functionality be added that is truly
functional *without* using any of the API calls. Then I come in and do
a round of optimizations to leverage the existing API.

Shell is kinda like that...

I'm noticing Allan Jude doesn't know all the API calls yet (who could? other
than me of course -- and even I have trouble remembering them _all_) yet
this doesn't

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 9, 2013, at 9:05 AM, Allan Jude wrote:

> On 2013-10-09 03:22, Matthias Gamsjager wrote:
>> Hi,
>> 
>> tried 10-8 iso in Virtualbox but after reboot I was looking at a
>> bootloader with a nice '-' but nothing more. 
>> post setup 'gpart list' showed no entries at all.
>> 
>> 
>> 
>> 
>> On Wed, Oct 9, 2013 at 5:49 AM, Allan Jude > > wrote:
>> 
>>On 2013-10-07 15:59, Allan Jude wrote:
>>> Devin Teske and I have been working on a big patch to bsdinstall to
>>> implement installing on a ZFS pool. It supports both GPT and
>>MBR, the 4k
>>> sector gnop trick, and optional GELI encryption. We would like
>>to commit
>>> this in time for 10.0-BETA1 so it needs some testing to work out any
>>> obvious bugs before we send it off to re@ to get it committed.
>>> 
>>> It includes a single configuration menu that allows you to
>>select all of
>>> the required details, including which drives to use (gets
>>details from
>>> camcontrol, also includes an inspection utility that presents the
>>> detailed output of camcontrol inquiry/identify, and gpart show),
>>what
>>> ZFS RAID level to use (taking in to consideration the selected
>>number of
>>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>>> 
>>> 
>>> Additional, it includes some other changes to bsdinstall:
>>> 1. Change the default to the 'non-standard keyboard mapping'
>>prompt to no
>>> 2. Replace the 3 separate dialogs to configure an ipv4 address
>>with just 1
>>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>>> feature has been combined into the regular 'services to enable'
>>dialog
>>> and enabled by default
>>> 
>>> 
>>> You can browse the patches here:
>>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>> 
>>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>>> available compressed (48 MB) or uncompressed (211 MB):
>>> 
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>> 
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>> 
>>> 
>>> We look forward to your feedback
>>> 
>> 
>>We've made more improvements, including corporating most all of the
>>feedback we've gotten so far
>> 
>> 
>>Outstanding items:
>>1. Apply the changes to ipv6 config the way we did ipv4
>>2. improve disk identification (model info and serial # instead of one
>>or the other)
>>3. Include a helpful message before the GELI step where you have to
>>enter your password many times, the user will be less confused if
>>it is
>>explained why they have to enter their password 3 * number of
>>disks times
>>4. Validate vdev type choice inside the vdev type menu, and warn the
>>user if they have made an invalid selection, so they can add more
>>disks
>>or chance their selection, without having to try to start the
>>installation first
>>5. Whatever else you guys find wrong tonight
>> 
>>I generated new test images, and attached the patch (which got REALLY
>>big when Devin Teske decided to fix "all of the things":
>> 
>>http://www.allanjude.com/bsd/zfsbootonly.2013-10-08.iso.xz
>> 
>>http://www.allanjude.com/bsd/zfsbootonly.2013-10-08.iso
>> 
>> 
>>--
>>Allan Jude
>> 
>> 
>>___
>>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
>>"
>> 
>> 
> This was a variable scoping error made by Devin when he refactored some
> of the code into a subroutine. I have fixed it
> 

Ouch and apologies.

It was too hard to see at 2AM after starting-in on a deeper pathos to the keymap
patches (which I'm still working on). Allan alerted me to the issue but when I 
started
digging-in, I realized much deeper changes were required. And then I passed out
around 2:30AM (keyboard-faceplant).
-- 
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] Patch to bsdinstall to support root-on-ZFS and GELI

On Oct 9, 2013, at 8:29 AM, Warren Block wrote:

> On Tue, 8 Oct 2013, Teske, Devin wrote:
> 
>> "But shell is nasty; slow; and not as powerful as C" (it depends in what
>> context; the first is rhetoric, the second is only true for poor implement-
>> ations, and the third may be true in some contexts, but I consider the
>> answer to "how maintainable is it" to be a factor in the "power" of a
>> language, so don't necessarily consider C to be more powerful than
>> shell as the latter is as-or-more maintainable with fewer LoC and a
>> higher return on investment; see previous [above] arguments).
> 
> My question would be: why are sh and C the only choices?  If the answer is 
> "because that's all we have in base", is that a valid concern?
> 
> As far as sh, it lacks many high- or even mid-level constructs and has real 
> problems with quoting,

Enter helper functions...

dte...@scribe9.vicor.com bsdconfig $ grep '^# f_' 
/usr/share/bsdconfig/strings.subr 
# f_substr "$string" $start [ $length ]
# f_snprintf $var_to_set $size $format ...
# f_vsnprintf $var_to_set $size $format $format_args
# f_longest_line_length
# f_number_of_lines
# f_isinteger $arg
# f_uriencode [$text]
# f_uridecode [$text]
# f_replaceall $string $find $replace [$var_to_set]
# f_str2varname $string [$var_to_set]
# f_shell_escape $string [$var_to_set]
# f_shell_unescape $string [$var_to_set]
# f_expand_number $string [$var_to_set]

The ones dealing specifically with quoting are f_shell_escape() and 
f_shell_unescape().
With those two helper functions, I consider quoting in sh(1) to be complete and 
maleable
to handle all situations.

> parsing,

Surely, a strength. It can take a while to engrain or impart all the expansions 
and at-
what stage (and in what context) they are performed, but when you understand the
mechanics of (for example) in what order each element (escaped-sequences, 
params,
newlines, and sub-shells) is expanded... the parsing becomes an asset, not a
hindrance (imho). Not to mention the flexibility afforded by "compound strings".

Take for example, the following syntax (leveraging ordered expansion and 
compound
strings):

f_dialog_input bar \
'Enter *any* text; including globs [*] and shell special chars 
[$`#'"']..."
f_dialog_input baz \
"Enter some *more* non-conforming text please..."
f_shell_escape "$bar" bar
f_shell_escape "$baz" baz
items="'$bar' '$baz'"
show="You entered:\n1=%s\n2=%s\n"
eval printf \"\$show\" $items

I'd be surprised if you could get anything out but the values you enter.

> and output (2>&1 >&3, for example).

I think it helps to highlight a technique for solving the general-purpose issue 
of
how you launch a program and have it talk to a parent's maintained 
file-descriptor.

In C, you'd have to pass special args to posix_spawn(3) to get this 
functionality.
Talking about succinctness of syntax... that sequence is likely much shorter 
than
any syntax I've ever seen in C for setting up file descriptors. I've interfaced 
with
dialog(1) from within C and getting the data back from it is non-trivial.

ASIDE: You may be asking yourself... why on Earth would you fork-exec an
instance of dialog(1) from within C instead of using dialog(3)? There are some
rare cases when this is advantageous. Usually when you want to support a drop-
in replacement (like Xdialog(1)) for a long-running stateful widget (e.g. 
gauge).
Usually (>=99% of the time) a C program _should_ use dialog(3) but in those
rare cases ( see http://druidbsd.cvs.sf.net/viewvc/druidbsd/fdpv/ ) thank 
goodness
I haven't had to mangle the file descriptors to get back any data (I call out 
to gauge
and just pump it massive amounts of data via stdin through a pipe passed to the
posix_spawn(3) call -- no data to read back.

So I don't see the above syntax as anything to point out -- C programs have more
complicated setup for doing the same thing (they just have to do it less often).

Oh... and in bsdconfig, you'll notice I don't do that. Upon initialization I 
clone the
*real* terminal fd's _once_ and then use variables to reference the dup'd fd.

> These make it harder to do things (aka, more code to accomplish a task, more 
> code to be maintained, more difficult to modify) than the higher level 
> Perubython languages.
> 

Only because those languages have APIs that handle those things.

Which I might add that those APIs have to be maintained. In that spirit,
bsdconfig(8) provides the API for shell -- and similarly, said API (like most
APIs) will be need much less maintenance than the programs using said
API (how often do we make changes to posix_spawn(3)? or how often
does Perubython change an API call?).

It's in that light that the bsdconfig(8) shell API is also treated just like any
other API with respect to changes (I treat all the "*.subr" includes as though
they are an ABI -- changes to function arguments must be well thought out).

> In any case, thanks for working on this.  A functioning program in any 
> langu

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-09 Thread Allan Jude

On 2013-10-09 03:22, Matthias Gamsjager wrote:
> Hi,
>
> tried 10-8 iso in Virtualbox but after reboot I was looking at a
> bootloader with a nice '-' but nothing more. 
> post setup 'gpart list' showed no entries at all.
>
>
>
>
> On Wed, Oct 9, 2013 at 5:49 AM, Allan Jude  > wrote:
>
> On 2013-10-07 15:59, Allan Jude wrote:
> > Devin Teske and I have been working on a big patch to bsdinstall to
> > implement installing on a ZFS pool. It supports both GPT and
> MBR, the 4k
> > sector gnop trick, and optional GELI encryption. We would like
> to commit
> > this in time for 10.0-BETA1 so it needs some testing to work out any
> > obvious bugs before we send it off to re@ to get it committed.
> >
> > It includes a single configuration menu that allows you to
> select all of
> > the required details, including which drives to use (gets
> details from
> > camcontrol, also includes an inspection utility that presents the
> > detailed output of camcontrol inquiry/identify, and gpart show),
> what
> > ZFS RAID level to use (taking in to consideration the selected
> number of
> > drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
> >
> >
> > Additional, it includes some other changes to bsdinstall:
> > 1. Change the default to the 'non-standard keyboard mapping'
> prompt to no
> > 2. Replace the 3 separate dialogs to configure an ipv4 address
> with just 1
> > 3. Remove the dialog asking if you wish to enable crash dumps, this
> > feature has been combined into the regular 'services to enable'
> dialog
> > and enabled by default
> >
> >
> > You can browse the patches here:
> > http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
> >
> > I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
> > available compressed (48 MB) or uncompressed (211 MB):
> >
> > http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
> >
> > http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
> >
> >
> > We look forward to your feedback
> >
>
> We've made more improvements, including corporating most all of the
> feedback we've gotten so far
>
>
> Outstanding items:
> 1. Apply the changes to ipv6 config the way we did ipv4
> 2. improve disk identification (model info and serial # instead of one
> or the other)
> 3. Include a helpful message before the GELI step where you have to
> enter your password many times, the user will be less confused if
> it is
> explained why they have to enter their password 3 * number of
> disks times
> 4. Validate vdev type choice inside the vdev type menu, and warn the
> user if they have made an invalid selection, so they can add more
> disks
> or chance their selection, without having to try to start the
> installation first
> 5. Whatever else you guys find wrong tonight
>
> I generated new test images, and attached the patch (which got REALLY
> big when Devin Teske decided to fix "all of the things":
>
> http://www.allanjude.com/bsd/zfsbootonly.2013-10-08.iso.xz
>
> http://www.allanjude.com/bsd/zfsbootonly.2013-10-08.iso
>
>
> --
> Allan Jude
>
>
> ___
> 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
> "
>
>
This was a variable scoping error made by Devin when he refactored some
of the code into a subroutine. I have fixed it

-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-09 Thread Warren Block


On Tue, 8 Oct 2013, Teske, Devin wrote:


"But shell is nasty; slow; and not as powerful as C" (it depends in what
context; the first is rhetoric, the second is only true for poor implement-
ations, and the third may be true in some contexts, but I consider the
answer to "how maintainable is it" to be a factor in the "power" of a
language, so don't necessarily consider C to be more powerful than
shell as the latter is as-or-more maintainable with fewer LoC and a
higher return on investment; see previous [above] arguments).


My question would be: why are sh and C the only choices?  If the answer 
is "because that's all we have in base", is that a valid concern?


As far as sh, it lacks many high- or even mid-level constructs and has 
real problems with quoting, parsing, and output (2>&1 >&3, for example). 
These make it harder to do things (aka, more code to accomplish a task, 
more code to be maintained, more difficult to modify) than the higher 
level Perubython languages.


In any case, thanks for working on this.  A functioning program in any 
language is better than a non-existent "better" one.

___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-09 Thread Warren Block


On Tue, 8 Oct 2013, Freddie Cash wrote:


On Tue, Oct 8, 2013 at 1:17 PM, Nathan Whitehorn wrote:


4. What is this gnop stuff for?



Can't comment on the rest, but gnop is required to create 4K-aligned vdevs
where the minimum block size is 4K (aka ashift=12).


Right, but to emphasize: the gnop hack forces ZFS to 4K blocks.  It does 
not, by itself, guarantee alignment with 4K native blocks on the drive, 
that has to be done by making the partitions aligned.

___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-09 Thread Matthias Gamsjager

Hi,

tried 10-8 iso in Virtualbox but after reboot I was looking at a bootloader
with a nice '-' but nothing more.
post setup 'gpart list' showed no entries at all.




On Wed, Oct 9, 2013 at 5:49 AM, Allan Jude  wrote:

> On 2013-10-07 15:59, Allan Jude wrote:
> > Devin Teske and I have been working on a big patch to bsdinstall to
> > implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
> > sector gnop trick, and optional GELI encryption. We would like to commit
> > this in time for 10.0-BETA1 so it needs some testing to work out any
> > obvious bugs before we send it off to re@ to get it committed.
> >
> > It includes a single configuration menu that allows you to select all of
> > the required details, including which drives to use (gets details from
> > camcontrol, also includes an inspection utility that presents the
> > detailed output of camcontrol inquiry/identify, and gpart show), what
> > ZFS RAID level to use (taking in to consideration the selected number of
> > drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
> >
> >
> > Additional, it includes some other changes to bsdinstall:
> > 1. Change the default to the 'non-standard keyboard mapping' prompt to no
> > 2. Replace the 3 separate dialogs to configure an ipv4 address with just
> 1
> > 3. Remove the dialog asking if you wish to enable crash dumps, this
> > feature has been combined into the regular 'services to enable' dialog
> > and enabled by default
> >
> >
> > You can browse the patches here:
> > http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
> >
> > I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
> > available compressed (48 MB) or uncompressed (211 MB):
> >
> > http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
> >
> > http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
> >
> >
> > We look forward to your feedback
> >
>
> We've made more improvements, including corporating most all of the
> feedback we've gotten so far
>
>
> Outstanding items:
> 1. Apply the changes to ipv6 config the way we did ipv4
> 2. improve disk identification (model info and serial # instead of one
> or the other)
> 3. Include a helpful message before the GELI step where you have to
> enter your password many times, the user will be less confused if it is
> explained why they have to enter their password 3 * number of disks times
> 4. Validate vdev type choice inside the vdev type menu, and warn the
> user if they have made an invalid selection, so they can add more disks
> or chance their selection, without having to try to start the
> installation first
> 5. Whatever else you guys find wrong tonight
>
> I generated new test images, and attached the patch (which got REALLY
> big when Devin Teske decided to fix "all of the things":
>
> http://www.allanjude.com/bsd/zfsbootonly.2013-10-08.iso.xz
>
> http://www.allanjude.com/bsd/zfsbootonly.2013-10-08.iso
>
>
> --
> Allan Jude
>
>
> ___
> 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-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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-09 Thread Nathan Whitehorn

On 10/09/13 01:13, Allan Jude wrote:
> On 2013-10-08 16:17, Nathan Whitehorn wrote:
>> On 10/07/13 21:59, Allan Jude wrote:
>>> Devin Teske and I have been working on a big patch to bsdinstall to
>>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>>> sector gnop trick, and optional GELI encryption. We would like to commit
>>> this in time for 10.0-BETA1 so it needs some testing to work out any
>>> obvious bugs before we send it off to re@ to get it committed.
>>>
>>> It includes a single configuration menu that allows you to select all of
>>> the required details, including which drives to use (gets details from
>>> camcontrol, also includes an inspection utility that presents the
>>> detailed output of camcontrol inquiry/identify, and gpart show), what
>>> ZFS RAID level to use (taking in to consideration the selected number of
>>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>>>
>>>
>>> Additional, it includes some other changes to bsdinstall:
>>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
>>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>>> feature has been combined into the regular 'services to enable' dialog
>>> and enabled by default
>>>
>>>
>>> You can browse the patches here:
>>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>>
>>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>>> available compressed (48 MB) or uncompressed (211 MB):
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>>
>>>
>>> We look forward to your feedback
>>>
>> Thanks for doing this! I had a few comments:
>> 1. ZFS is not bootable on all architectures. Could you adjust that menu
>> item to only display for i386, amd64, and (I think?) sparc64. Use uname
>> -m, not -p, for this.
> I had not considered that, I'll make that change
>
>> 1a. The script is broken on sparc64 in any case, which uses VTOC8
>> instead of GPT.
> I'll disable sparc64 as well
>
>> 2. Why are you using camcontrol? That is guaranteed not to work on
>> non-CAM systems. You should use the GEOM ident string if you need an ID.
> The GEOM ident string doesn't do enough to help the user identify which
> drive is which.
> More data is not exposed anywhere that I could find
>
> What we really need, is dev.ada.0.desc% like we have for network
> interfaces and a slew of other devices. GEOM data is great, but it is
> not exposed in a shell friendly way any place that I could find, other
> than the sysctl with DOT and XML data.

This is one of the reasons the partition editor is written in C. There
are a few other odd corner-cases where C is much more powerful than the
command-line for the GEOM operations that partedit needs to do. I'm not
sure how to usefully get it just from the shell. You can see how to do
it in C in the boot_disk() routine of partedit/auto_part.c.

>> 3. Any plans to integrate this into the regular partition editor? ZFS
>> support is important enough that I will definitely not get in the way,
>> even as a bolt-on, but it would be a shame for it to stay that way. The
>> editor is also designed for ZFS to be added.
> I am a sysadmin, not a programmer. I can't write C. Most people
> deploying servers can't write C. I agree with Devin Teske, if everything
> was in shell it would be a lot more usable for non-developers, who
> probably make up the majority of people who deploy FreeBSD.

There are some cases the other way too. Devin is probably the most
shell-proficient FreeBSD committer. I certainly can't write shell
scripts at that level, which means that for me bsdconfig, for example,
is effectively read-only (and quite hard to read as well). I suspect the
same is true for many other developers. Without any prejudice about the
relative merits of the languages, this can cause some significant
internal maintenance issues. Something similar happened to sysinstall
(which was in C): due to its complexity and high amounts of magic, it
had become read-only for basically all committers and as a result fell
years and years behind the rest of the project. Hopefully this is
paranoia, but I can easily see complex shell scripts engendering the
same problem.

In any case, this particular comment was just related to the benefits of
having one tool, and one UI, rather than duplicating partitioning logic
in multiple places. None of this is actually complicated, so the
duplication isn't that bad, but doing everything in one place long-term
is almost certainly better for the user, no matter what programming
language that tool is written in.
-Nathan
___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-08 Thread Outback Dingo

On Tue, Oct 8, 2013 at 10:30 PM, Outback Dingo wrote:

>
>
>
> On Tue, Oct 8, 2013 at 7:13 PM, Allan Jude  wrote:
>
>> On 2013-10-08 16:17, Nathan Whitehorn wrote:
>> > On 10/07/13 21:59, Allan Jude wrote:
>> >> Devin Teske and I have been working on a big patch to bsdinstall to
>> >> implement installing on a ZFS pool. It supports both GPT and MBR, the
>> 4k
>> >> sector gnop trick, and optional GELI encryption. We would like to
>> commit
>> >> this in time for 10.0-BETA1 so it needs some testing to work out any
>> >> obvious bugs before we send it off to re@ to get it committed.
>> >>
>> >> It includes a single configuration menu that allows you to select all
>> of
>> >> the required details, including which drives to use (gets details from
>> >> camcontrol, also includes an inspection utility that presents the
>> >> detailed output of camcontrol inquiry/identify, and gpart show), what
>> >> ZFS RAID level to use (taking in to consideration the selected number
>> of
>> >> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>> >>
>> >>
>> >> Additional, it includes some other changes to bsdinstall:
>> >> 1. Change the default to the 'non-standard keyboard mapping' prompt to
>> no
>> >> 2. Replace the 3 separate dialogs to configure an ipv4 address with
>> just 1
>> >> 3. Remove the dialog asking if you wish to enable crash dumps, this
>> >> feature has been combined into the regular 'services to enable' dialog
>> >> and enabled by default
>> >>
>> >>
>> >> You can browse the patches here:
>> >> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>> >>
>> >> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>> >> available compressed (48 MB) or uncompressed (211 MB):
>> >>
>> >> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>> >>
>> >> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>> >>
>> >>
>> >> We look forward to your feedback
>> >>
>> > Thanks for doing this! I had a few comments:
>> > 1. ZFS is not bootable on all architectures. Could you adjust that menu
>> > item to only display for i386, amd64, and (I think?) sparc64. Use uname
>> > -m, not -p, for this.
>> I had not considered that, I'll make that change
>>
>> > 1a. The script is broken on sparc64 in any case, which uses VTOC8
>> > instead of GPT.
>> I'll disable sparc64 as well
>>
>> > 2. Why are you using camcontrol? That is guaranteed not to work on
>> > non-CAM systems. You should use the GEOM ident string if you need an ID.
>> The GEOM ident string doesn't do enough to help the user identify which
>> drive is which.
>> More data is not exposed anywhere that I could find
>>
>> What we really need, is dev.ada.0.desc% like we have for network
>> interfaces and a slew of other devices. GEOM data is great, but it is
>> not exposed in a shell friendly way any place that I could find, other
>> than the sysctl with DOT and XML data.
>>
>> > 3. Any plans to integrate this into the regular partition editor? ZFS
>> > support is important enough that I will definitely not get in the way,
>> > even as a bolt-on, but it would be a shame for it to stay that way. The
>> > editor is also designed for ZFS to be added.
>> I am a sysadmin, not a programmer. I can't write C. Most people
>> deploying servers can't write C. I agree with Devin Teske, if everything
>> was in shell it would be a lot more usable for non-developers, who
>> probably make up the majority of people who deploy FreeBSD.
>>
>> > 4. What is this gnop stuff for?
>> yeah, we align the partitions and the blocks to ensure optimal
>> performance on 'advanced format' drives, there is no real downside for
>> older drives, and it saves you from headaches in the future.
>>
>> > 5. I think some substantial part of the MBR code will blow up if you are
>> > reinitalizing a previously formatted disk (the bsdlabel will be retasted
>> > and come back from the dead).
>> We try to do what we can here, including creating a fresh GPT and MBR
>> and blowing them away to ensure that anything left over is really dead.
>> We also use zpool labelclear, which doesn't check if there ever was a
>> ZFS label, it just blindly overwrites the spots where the label would go.
>> I'll add some additional napalm to ensure there are no zombie partitions.
>>
>> > -Nathan
>>
>
> I can now confirm with the latest patches from 1.5 hours ago applied i can
> now install and boot
> into a zfs-on-root system under XEN.. now you seriously ROCK! great
> work ... and thanks
>
> dmesg
> Copyright (c) 1992-2013 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 10.0-ALPHA5 #1 r256169M: Wed Oct  9 01:03:43 EDT 2013
> di...@current.optimcloud.com:/usr/obj/usr/src/sys/GENERIC amd64
> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
> XEN: Hypervisor version 4.3 detected.
> CP

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-08 Thread Outback Dingo

On Tue, Oct 8, 2013 at 7:13 PM, Allan Jude  wrote:

> On 2013-10-08 16:17, Nathan Whitehorn wrote:
> > On 10/07/13 21:59, Allan Jude wrote:
> >> Devin Teske and I have been working on a big patch to bsdinstall to
> >> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
> >> sector gnop trick, and optional GELI encryption. We would like to commit
> >> this in time for 10.0-BETA1 so it needs some testing to work out any
> >> obvious bugs before we send it off to re@ to get it committed.
> >>
> >> It includes a single configuration menu that allows you to select all of
> >> the required details, including which drives to use (gets details from
> >> camcontrol, also includes an inspection utility that presents the
> >> detailed output of camcontrol inquiry/identify, and gpart show), what
> >> ZFS RAID level to use (taking in to consideration the selected number of
> >> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
> >>
> >>
> >> Additional, it includes some other changes to bsdinstall:
> >> 1. Change the default to the 'non-standard keyboard mapping' prompt to
> no
> >> 2. Replace the 3 separate dialogs to configure an ipv4 address with
> just 1
> >> 3. Remove the dialog asking if you wish to enable crash dumps, this
> >> feature has been combined into the regular 'services to enable' dialog
> >> and enabled by default
> >>
> >>
> >> You can browse the patches here:
> >> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
> >>
> >> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
> >> available compressed (48 MB) or uncompressed (211 MB):
> >>
> >> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
> >>
> >> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
> >>
> >>
> >> We look forward to your feedback
> >>
> > Thanks for doing this! I had a few comments:
> > 1. ZFS is not bootable on all architectures. Could you adjust that menu
> > item to only display for i386, amd64, and (I think?) sparc64. Use uname
> > -m, not -p, for this.
> I had not considered that, I'll make that change
>
> > 1a. The script is broken on sparc64 in any case, which uses VTOC8
> > instead of GPT.
> I'll disable sparc64 as well
>
> > 2. Why are you using camcontrol? That is guaranteed not to work on
> > non-CAM systems. You should use the GEOM ident string if you need an ID.
> The GEOM ident string doesn't do enough to help the user identify which
> drive is which.
> More data is not exposed anywhere that I could find
>
> What we really need, is dev.ada.0.desc% like we have for network
> interfaces and a slew of other devices. GEOM data is great, but it is
> not exposed in a shell friendly way any place that I could find, other
> than the sysctl with DOT and XML data.
>
> > 3. Any plans to integrate this into the regular partition editor? ZFS
> > support is important enough that I will definitely not get in the way,
> > even as a bolt-on, but it would be a shame for it to stay that way. The
> > editor is also designed for ZFS to be added.
> I am a sysadmin, not a programmer. I can't write C. Most people
> deploying servers can't write C. I agree with Devin Teske, if everything
> was in shell it would be a lot more usable for non-developers, who
> probably make up the majority of people who deploy FreeBSD.
>
> > 4. What is this gnop stuff for?
> yeah, we align the partitions and the blocks to ensure optimal
> performance on 'advanced format' drives, there is no real downside for
> older drives, and it saves you from headaches in the future.
>
> > 5. I think some substantial part of the MBR code will blow up if you are
> > reinitalizing a previously formatted disk (the bsdlabel will be retasted
> > and come back from the dead).
> We try to do what we can here, including creating a fresh GPT and MBR
> and blowing them away to ensure that anything left over is really dead.
> We also use zpool labelclear, which doesn't check if there ever was a
> ZFS label, it just blindly overwrites the spots where the label would go.
> I'll add some additional napalm to ensure there are no zombie partitions.
>
> > -Nathan
>

I can now confirm with the latest patches from 1.5 hours ago applied i can
now install and boot
into a zfs-on-root system under XEN.. now you seriously ROCK! great
work ... and thanks

dmesg
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-ALPHA5 #1 r256169M: Wed Oct  9 01:03:43 EDT 2013
di...@current.optimcloud.com:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
XEN: Hypervisor version 4.3 detected.
CPU: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (2494.38-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x306a9  Family = 0x6  Model = 0x3a
 Stepping = 9

Features=0x1783fbff

Features2=0xffb8

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-08 Thread Allan Jude

On 2013-10-08 16:17, Nathan Whitehorn wrote:
> On 10/07/13 21:59, Allan Jude wrote:
>> Devin Teske and I have been working on a big patch to bsdinstall to
>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>> sector gnop trick, and optional GELI encryption. We would like to commit
>> this in time for 10.0-BETA1 so it needs some testing to work out any
>> obvious bugs before we send it off to re@ to get it committed.
>>
>> It includes a single configuration menu that allows you to select all of
>> the required details, including which drives to use (gets details from
>> camcontrol, also includes an inspection utility that presents the
>> detailed output of camcontrol inquiry/identify, and gpart show), what
>> ZFS RAID level to use (taking in to consideration the selected number of
>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>>
>>
>> Additional, it includes some other changes to bsdinstall:
>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>> feature has been combined into the regular 'services to enable' dialog
>> and enabled by default
>>
>>
>> You can browse the patches here:
>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>
>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>> available compressed (48 MB) or uncompressed (211 MB):
>>
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>
>>
>> We look forward to your feedback
>>
> Thanks for doing this! I had a few comments:
> 1. ZFS is not bootable on all architectures. Could you adjust that menu
> item to only display for i386, amd64, and (I think?) sparc64. Use uname
> -m, not -p, for this.
I had not considered that, I'll make that change

> 1a. The script is broken on sparc64 in any case, which uses VTOC8
> instead of GPT.
I'll disable sparc64 as well

> 2. Why are you using camcontrol? That is guaranteed not to work on
> non-CAM systems. You should use the GEOM ident string if you need an ID.
The GEOM ident string doesn't do enough to help the user identify which
drive is which.
More data is not exposed anywhere that I could find

What we really need, is dev.ada.0.desc% like we have for network
interfaces and a slew of other devices. GEOM data is great, but it is
not exposed in a shell friendly way any place that I could find, other
than the sysctl with DOT and XML data.

> 3. Any plans to integrate this into the regular partition editor? ZFS
> support is important enough that I will definitely not get in the way,
> even as a bolt-on, but it would be a shame for it to stay that way. The
> editor is also designed for ZFS to be added.
I am a sysadmin, not a programmer. I can't write C. Most people
deploying servers can't write C. I agree with Devin Teske, if everything
was in shell it would be a lot more usable for non-developers, who
probably make up the majority of people who deploy FreeBSD.

> 4. What is this gnop stuff for?
yeah, we align the partitions and the blocks to ensure optimal
performance on 'advanced format' drives, there is no real downside for
older drives, and it saves you from headaches in the future.

> 5. I think some substantial part of the MBR code will blow up if you are
> reinitalizing a previously formatted disk (the bsdlabel will be retasted
> and come back from the dead).
We try to do what we can here, including creating a fresh GPT and MBR
and blowing them away to ensure that anything left over is really dead.
We also use zpool labelclear, which doesn't check if there ever was a
ZFS label, it just blindly overwrites the spots where the label would go.
I'll add some additional napalm to ensure there are no zombie partitions.

> -Nathan
> ___
> 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"


-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-08 Thread Teske, Devin

On Oct 8, 2013, at 2:28 PM, Nathan Whitehorn wrote:

> On 10/08/13 23:21, Kurt Lidl wrote:
>> 
>> On 10/8/2013, Nathan Whitehorn wrote:
>>> On 10/07/13 21:59, Allan Jude wrote:
 Devin Teske and I have been working on a big patch to bsdinstall to
 implement installing on a ZFS pool. It supports both GPT and MBR,
 the 4k
 sector gnop trick, and optional GELI encryption. We would like to
 commit
 this in time for 10.0-BETA1 so it needs some testing to work out any
 obvious bugs before we send it off to re@ to get it committed.

 It includes a single configuration menu that allows you to select
 all of
 the required details, including which drives to use (gets details from
 camcontrol, also includes an inspection utility that presents the
 detailed output of camcontrol inquiry/identify, and gpart show), what
 ZFS RAID level to use (taking in to consideration the selected
 number of
 drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.

 Additional, it includes some other changes to bsdinstall:
 1. Change the default to the 'non-standard keyboard mapping' prompt
 to no
 2. Replace the 3 separate dialogs to configure an ipv4 address with
 just 1
 3. Remove the dialog asking if you wish to enable crash dumps, this
 feature has been combined into the regular 'services to enable' dialog
 and enabled by default

 You can browse the patches here:
 http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/

 I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
 available compressed (48 MB) or uncompressed (211 MB):

 http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz

 http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso

 We look forward to your feedback

>>> 
>>> Thanks for doing this! I had a few comments:
>>> 1. ZFS is not bootable on all architectures. Could you adjust that menu
>>> item to only display for i386, amd64, and (I think?) sparc64. Use uname
>>> -m, not -p, for this.
>>> 1a. The script is broken on sparc64 in any case, which uses VTOC8
>>> instead of GPT.
>>> 2. Why are you using camcontrol? That is guaranteed not to work on
>>> non-CAM systems. You should use the GEOM ident string if you need an ID.
>>> 3. Any plans to integrate this into the regular partition editor? ZFS
>>> support is important enough that I will definitely not get in the way,
>>> even as a bolt-on, but it would be a shame for it to stay that way. The
>>> editor is also designed for ZFS to be added.
>>> 4. What is this gnop stuff for?
>>> 5. I think some substantial part of the MBR code will blow up if you are
>>> reinitalizing a previously formatted disk (the bsdlabel will be retasted
>>> and come back from the dead).
>>> -Nathan
>> 
>> I wrote some support for adding ZFS to the partition editor a couple of
>> months ago, around the time that 9.2 was branched.  One of the biggest
>> things that I have not done is integrate setting up a zfs mirror between
>> any disks before creating the zpool.  Nor did I do the gnop hack to
>> create 4K disk blocks before creating the pool.
>> 
>> I more or less changed the partedit program to take an argument when
>> invoked with "ufs" (same as current behavior) or "zfs", which knows
>> about zfs setup stuff.  The hookup to the actual scripts was, shall
>> we say, much less intrusive than what has been published here.
>> 
>> I guess it's time to dig out the patches and make them available to
>> others.
> 
> That would be great! The original idea was to have a "zfs_ops.c" to go
> with "gpart_ops.c" and have some fields in the disk item struct that
> said which to use. Not sure if that's ultimately workable, though. I can
> hack on it once the patches are there in any case.

One of the options presented was to integrate ZFS knowledge into the
partedit module.

However, another approach that is not being spoken about is in the
other direction: rewriting partedit to be in sh(1).

What I'd like to see is the --treeview widget of dialog(1) "fixed" before
such a transition is made, so the former option may be the best bet for
now. For anyone that hasn't run the treeview or treeview2 samples in
head/contrib/dialog/samples ... it's not anything we'd want to use to
replace dialog(3) with. I've seen much nicer treeview implementations
than what is in [c]dialog (currently we're using dialog-1.2-20130925 and
the treeview for some reason incorporates a radio-button column which
we do _not_ want for a disk partition layout menu).

Of course, right now you're all looking at me like I'm crazy.

Like a fox.

There are real tangible benefits to rewriting the C code of partedit into
shell syntax. The value-add is not just perceived. Some of the values
obtained are:

+ Conflated namespace with singular API rather than having to learn
how to script each individual blocking-utility which implements a unique
method fo

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-08 Thread Outback Dingo

On Tue, Oct 8, 2013 at 5:21 AM, Teske, Devin wrote:

>
> On Oct 7, 2013, at 10:48 PM, Allan Jude wrote:
>
> > On 2013-10-08 01:11, Teske, Devin wrote:
> >> On Oct 7, 2013, at 10:07 PM, Allan Jude wrote:
> >>
> >>> On 2013-10-07 15:59, Allan Jude wrote:
>  Devin Teske and I have been working on a big patch to bsdinstall to
>  implement installing on a ZFS pool. It supports both GPT and MBR, the
> 4k
>  sector gnop trick, and optional GELI encryption. We would like to
> commit
>  this in time for 10.0-BETA1 so it needs some testing to work out any
>  obvious bugs before we send it off to re@ to get it committed.
> 
>  It includes a single configuration menu that allows you to select all
> of
>  the required details, including which drives to use (gets details from
>  camcontrol, also includes an inspection utility that presents the
>  detailed output of camcontrol inquiry/identify, and gpart show), what
>  ZFS RAID level to use (taking in to consideration the selected number
> of
>  drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
> 
> 
>  Additional, it includes some other changes to bsdinstall:
>  1. Change the default to the 'non-standard keyboard mapping' prompt
> to no
>  2. Replace the 3 separate dialogs to configure an ipv4 address with
> just 1
>  3. Remove the dialog asking if you wish to enable crash dumps, this
>  feature has been combined into the regular 'services to enable' dialog
>  and enabled by default
> 
> 
>  You can browse the patches here:
>  http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
> 
>  I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>  available compressed (48 MB) or uncompressed (211 MB):
> 
>  http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
> 
>  http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
> 
> 
>  We look forward to your feedback
> 
> >>> I've generated a new version of the ISO incorporating all of todays
> >>> changes and moving up to 10.0-ALPHA5
> >>> It includes 2 patches from Warren Block, improving the keymap menu and
> >>> indicating which network interfaces are wireless
> >>>
> >> Excellent.
> >>
> >> However, I have to say... you opened a can of worms by touching keymap.
> >>
> >> Eventually I plan to rewrite all of the scripts to the same format that
> zfsboot
> >> is using. I've already started rewriting keymap to the new format. Of
> course,
> >> this opened up another can of worms... the simple things like:
> >>
> >> DIALOG_OK
> >> DIALOG_CANCEL
> >> DIALOG_ESC
> >
> > Yeah, after having them, I felt a bit naked not having all of those
> > 'constants' defined.
> >
>
> The constants are now where they belong... `dialog.subr'
> I also went through bsdconfig(8) with a fine-tooth comb and made use of the
> new "constants" everywhere.
>
> I think it's a definite improvement.
>
>
>
> > Originally, all I had done was add --defaultno to the dialog command,
> > but Warren's patch makes a lot of sense, allow the user to 'try' the new
> > keymap before trying to do the rest of the install based on it.
> >
>
> I rewrote warren's code into the stateful design and cleaned it up.
>
>
>
> >> I feel would be much better off in the `dialog.subr' module. So,...
> I've started
> >> peppering their usage everywhere in bsdconfig to make them "proper".
> >>
> >> That means they will just be transparent from including `dialog.subr'.
> >>
> >
> > This is definately something that I think is a good idea, but my focus
> > is on improving the usability and functionality of the installer in time
> > for 10.0. Unifying everything to the bsdconfig style is slightly lower
> > priority. Admittedly, the `bsdconfig networking` stuff is quite nice
> >
>
> *nods*
>
> I took a look at the bsdinstall networking stuff, and I wanted to run away.
>
> Let's push that into the future.
>
> It wasn't too hard to get those global exit codes deployed, so I did that,
> but like you say... I agree we should minimize "extra work" that will be
> eventually slated for a future release.
> --
> Devin
>
>
>
Just noticed that when trying to install root-on-zfs under xen it doesn't
recognize the xbd0 virtual block device attached as ada0 so it skips the
install screen and goes to configure networking



>
> >>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
> >>>
> >>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
> >>>
> >> Excellent, thanks!
> >
> >
> > --
> > Allan Jude
> >
> > ___
> > 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)

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

On 10/08/13 23:21, Kurt Lidl wrote:
>
> On 10/8/2013, Nathan Whitehorn wrote:
>> On 10/07/13 21:59, Allan Jude wrote:
>>> Devin Teske and I have been working on a big patch to bsdinstall to
>>> implement installing on a ZFS pool. It supports both GPT and MBR,
>>> the 4k
>>> sector gnop trick, and optional GELI encryption. We would like to
>>> commit
>>> this in time for 10.0-BETA1 so it needs some testing to work out any
>>> obvious bugs before we send it off to re@ to get it committed.
>>>
>>> It includes a single configuration menu that allows you to select
>>> all of
>>> the required details, including which drives to use (gets details from
>>> camcontrol, also includes an inspection utility that presents the
>>> detailed output of camcontrol inquiry/identify, and gpart show), what
>>> ZFS RAID level to use (taking in to consideration the selected
>>> number of
>>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>>>
>>>
>>> Additional, it includes some other changes to bsdinstall:
>>> 1. Change the default to the 'non-standard keyboard mapping' prompt
>>> to no
>>> 2. Replace the 3 separate dialogs to configure an ipv4 address with
>>> just 1
>>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>>> feature has been combined into the regular 'services to enable' dialog
>>> and enabled by default
>>>
>>>
>>> You can browse the patches here:
>>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>>
>>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>>> available compressed (48 MB) or uncompressed (211 MB):
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>>
>>>
>>> We look forward to your feedback
>>>
>>
>> Thanks for doing this! I had a few comments:
>> 1. ZFS is not bootable on all architectures. Could you adjust that menu
>> item to only display for i386, amd64, and (I think?) sparc64. Use uname
>> -m, not -p, for this.
>> 1a. The script is broken on sparc64 in any case, which uses VTOC8
>> instead of GPT.
>> 2. Why are you using camcontrol? That is guaranteed not to work on
>> non-CAM systems. You should use the GEOM ident string if you need an ID.
>> 3. Any plans to integrate this into the regular partition editor? ZFS
>> support is important enough that I will definitely not get in the way,
>> even as a bolt-on, but it would be a shame for it to stay that way. The
>> editor is also designed for ZFS to be added.
>> 4. What is this gnop stuff for?
>> 5. I think some substantial part of the MBR code will blow up if you are
>> reinitalizing a previously formatted disk (the bsdlabel will be retasted
>> and come back from the dead).
>> -Nathan
>
> I wrote some support for adding ZFS to the partition editor a couple of
> months ago, around the time that 9.2 was branched.  One of the biggest
> things that I have not done is integrate setting up a zfs mirror between
> any disks before creating the zpool.  Nor did I do the gnop hack to
> create 4K disk blocks before creating the pool.
>
> I more or less changed the partedit program to take an argument when
> invoked with "ufs" (same as current behavior) or "zfs", which knows
> about zfs setup stuff.  The hookup to the actual scripts was, shall
> we say, much less intrusive than what has been published here.
>
> I guess it's time to dig out the patches and make them available to
> others.

That would be great! The original idea was to have a "zfs_ops.c" to go
with "gpart_ops.c" and have some fields in the disk item struct that
said which to use. Not sure if that's ultimately workable, though. I can
hack on it once the patches are there in any case.
-Nathan
___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-08 Thread John-Mark Gurney

Devin Teske wrote this message on Tue, Oct 08, 2013 at 20:50 +:
> > 2. Why are you using camcontrol? That is guaranteed not to work on
> > non-CAM systems. You should use the GEOM ident string if you need an ID.
> 
> I imagine we could get the info from many places, and to be honest, I never
> knew about "diskinfo" until last week (but apparently it's been around since
> 5.x days).
> 
> The one place where I suspect camcontrol(8) usage is appropriate is the
> mini "disk inspector" dialog. The camcontrol inquiry output is specifically
> helpful if/when you're doing multipathing (and you need to identify which
> da# devices are duplicates of the same device -- given Serial#).
> 
> But I gather you mean for "disk description" in the device menu (for picking
> text to go along with the device name).
> 
> I'm open to using a different tool... or multiple tools. Do you think it 
> would be
> better to just stick to one tool? or to query a few? (which ones win-out?)

diskinfo -v dumps the serial number for you under disk ident..  diskinfo
gets it from geom and most geoms properly present that info now...  or
at least probably anyones support by cam will do it automatically...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-08 Thread Kurt Lidl



On 10/8/2013, Nathan Whitehorn wrote:

On 10/07/13 21:59, Allan Jude wrote:

Devin Teske and I have been working on a big patch to bsdinstall to
implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
sector gnop trick, and optional GELI encryption. We would like to commit
this in time for 10.0-BETA1 so it needs some testing to work out any
obvious bugs before we send it off to re@ to get it committed.

It includes a single configuration menu that allows you to select all of
the required details, including which drives to use (gets details from
camcontrol, also includes an inspection utility that presents the
detailed output of camcontrol inquiry/identify, and gpart show), what
ZFS RAID level to use (taking in to consideration the selected number of
drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.


Additional, it includes some other changes to bsdinstall:
1. Change the default to the 'non-standard keyboard mapping' prompt to no
2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
3. Remove the dialog asking if you wish to enable crash dumps, this
feature has been combined into the regular 'services to enable' dialog
and enabled by default


You can browse the patches here:
http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/

I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
available compressed (48 MB) or uncompressed (211 MB):

http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz

http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso


We look forward to your feedback



Thanks for doing this! I had a few comments:
1. ZFS is not bootable on all architectures. Could you adjust that menu
item to only display for i386, amd64, and (I think?) sparc64. Use uname
-m, not -p, for this.
1a. The script is broken on sparc64 in any case, which uses VTOC8
instead of GPT.
2. Why are you using camcontrol? That is guaranteed not to work on
non-CAM systems. You should use the GEOM ident string if you need an ID.
3. Any plans to integrate this into the regular partition editor? ZFS
support is important enough that I will definitely not get in the way,
even as a bolt-on, but it would be a shame for it to stay that way. The
editor is also designed for ZFS to be added.
4. What is this gnop stuff for?
5. I think some substantial part of the MBR code will blow up if you are
reinitalizing a previously formatted disk (the bsdlabel will be retasted
and come back from the dead).
-Nathan


I wrote some support for adding ZFS to the partition editor a couple of
months ago, around the time that 9.2 was branched.  One of the biggest
things that I have not done is integrate setting up a zfs mirror between
any disks before creating the zpool.  Nor did I do the gnop hack to
create 4K disk blocks before creating the pool.

I more or less changed the partedit program to take an argument when
invoked with "ufs" (same as current behavior) or "zfs", which knows
about zfs setup stuff.  The hookup to the actual scripts was, shall
we say, much less intrusive than what has been published here.

I guess it's time to dig out the patches and make them available to
others.

-Kurt




___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-08 Thread Kurt Lidl




5. I think some substantial part of the MBR code will blow up if you are
reinitalizing a previously formatted disk (the bsdlabel will be retasted
and come back from the dead).

Will not some combination of "gpart destroy -F" and (insert suggestion) work?


Yes, that will work just fine.


Actually, it will appear to work, and then viciously hurt (substitute
more graphic verb for "hurt") you later, if you happen to repartition,
and are using a geom-mirror for your swap space.  At least if you manage
to get your old geom and new geom on the same physical location of the
disk.

To be safe, you really need to either zero out the space used by geom
before destroying the gpart label when it isn't in use, or run:

gmirror deactivate NAME provider1
gmirror deactivate NAME provider2

-Kurt

___
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] Patch to bsdinstall to support root-on-ZFS and GELI

On 10/08/13 22:50, Teske, Devin wrote:
> On Oct 8, 2013, at 1:17 PM, Nathan Whitehorn wrote:
>
>> On 10/07/13 21:59, Allan Jude wrote:
>>> Devin Teske and I have been working on a big patch to bsdinstall to
>>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>>> sector gnop trick, and optional GELI encryption. We would like to commit
>>> this in time for 10.0-BETA1 so it needs some testing to work out any
>>> obvious bugs before we send it off to re@ to get it committed.
>>>
>>> It includes a single configuration menu that allows you to select all of
>>> the required details, including which drives to use (gets details from
>>> camcontrol, also includes an inspection utility that presents the
>>> detailed output of camcontrol inquiry/identify, and gpart show), what
>>> ZFS RAID level to use (taking in to consideration the selected number of
>>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>>>
>>>
>>> Additional, it includes some other changes to bsdinstall:
>>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
>>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>>> feature has been combined into the regular 'services to enable' dialog
>>> and enabled by default
>>>
>>>
>>> You can browse the patches here:
>>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>>
>>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>>> available compressed (48 MB) or uncompressed (211 MB):
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>>
>>>
>>> We look forward to your feedback
>>>
>> Thanks for doing this! I had a few comments:
>> 1. ZFS is not bootable on all architectures. Could you adjust that menu
>> item to only display for i386, amd64, and (I think?) sparc64. Use uname
>> -m, not -p, for this.
> I think we can do that no problem.
>
>
>> 1a. The script is broken on sparc64 in any case, which uses VTOC8
>> instead of GPT.
> *nods* we'll have to purloin your VTOC8 code before we offer it to
> sparc64.
>
>
>
>> 2. Why are you using camcontrol? That is guaranteed not to work on
>> non-CAM systems. You should use the GEOM ident string if you need an ID.
> I imagine we could get the info from many places, and to be honest, I never
> knew about "diskinfo" until last week (but apparently it's been around since
> 5.x days).
>
> The one place where I suspect camcontrol(8) usage is appropriate is the
> mini "disk inspector" dialog. The camcontrol inquiry output is specifically
> helpful if/when you're doing multipathing (and you need to identify which
> da# devices are duplicates of the same device -- given Serial#).
>
> But I gather you mean for "disk description" in the device menu (for picking
> text to go along with the device name).
>
> I'm open to using a different tool... or multiple tools. Do you think it 
> would be
> better to just stick to one tool? or to query a few? (which ones win-out?)

Absolutely all information you could possibly want is inside GEOM,
including disk serial numbers. It the Correct Place (tm) for whatever
information you want to get.

>
>> 3. Any plans to integrate this into the regular partition editor? ZFS
>> support is important enough that I will definitely not get in the way,
>> even as a bolt-on, but it would be a shame for it to stay that way. The
>> editor is also designed for ZFS to be added.
> Yes and yes. (and didn't know the editor was designed for ZFS too)

Great!
>> 4. What is this gnop stuff for?
> Thanks goes to Freddie Cash for his excellent explanation (I had to
> admit, I didn't understand it at that level)
>
>
>> 5. I think some substantial part of the MBR code will blow up if you are
>> reinitalizing a previously formatted disk (the bsdlabel will be retasted
>> and come back from the dead).
> Will not some combination of "gpart destroy -F" and (insert suggestion) work?

Yes, that will work just fine.
-Nathan
___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-08 Thread Teske, Devin

On Oct 8, 2013, at 1:17 PM, Nathan Whitehorn wrote:

> On 10/07/13 21:59, Allan Jude wrote:
>> Devin Teske and I have been working on a big patch to bsdinstall to
>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>> sector gnop trick, and optional GELI encryption. We would like to commit
>> this in time for 10.0-BETA1 so it needs some testing to work out any
>> obvious bugs before we send it off to re@ to get it committed.
>> 
>> It includes a single configuration menu that allows you to select all of
>> the required details, including which drives to use (gets details from
>> camcontrol, also includes an inspection utility that presents the
>> detailed output of camcontrol inquiry/identify, and gpart show), what
>> ZFS RAID level to use (taking in to consideration the selected number of
>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>> 
>> 
>> Additional, it includes some other changes to bsdinstall:
>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>> feature has been combined into the regular 'services to enable' dialog
>> and enabled by default
>> 
>> 
>> You can browse the patches here:
>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>> 
>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>> available compressed (48 MB) or uncompressed (211 MB):
>> 
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>> 
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>> 
>> 
>> We look forward to your feedback
>> 
> 
> Thanks for doing this! I had a few comments:
> 1. ZFS is not bootable on all architectures. Could you adjust that menu
> item to only display for i386, amd64, and (I think?) sparc64. Use uname
> -m, not -p, for this.

I think we can do that no problem.

> 1a. The script is broken on sparc64 in any case, which uses VTOC8
> instead of GPT.

*nods* we'll have to purloin your VTOC8 code before we offer it to
sparc64.

> 2. Why are you using camcontrol? That is guaranteed not to work on
> non-CAM systems. You should use the GEOM ident string if you need an ID.

I imagine we could get the info from many places, and to be honest, I never
knew about "diskinfo" until last week (but apparently it's been around since
5.x days).

The one place where I suspect camcontrol(8) usage is appropriate is the
mini "disk inspector" dialog. The camcontrol inquiry output is specifically
helpful if/when you're doing multipathing (and you need to identify which
da# devices are duplicates of the same device -- given Serial#).

But I gather you mean for "disk description" in the device menu (for picking
text to go along with the device name).

I'm open to using a different tool... or multiple tools. Do you think it would 
be
better to just stick to one tool? or to query a few? (which ones win-out?)

> 3. Any plans to integrate this into the regular partition editor? ZFS
> support is important enough that I will definitely not get in the way,
> even as a bolt-on, but it would be a shame for it to stay that way. The
> editor is also designed for ZFS to be added.

Yes and yes. (and didn't know the editor was designed for ZFS too)

> 4. What is this gnop stuff for?

Thanks goes to Freddie Cash for his excellent explanation (I had to
admit, I didn't understand it at that level)

> 5. I think some substantial part of the MBR code will blow up if you are
> reinitalizing a previously formatted disk (the bsdlabel will be retasted
> and come back from the dead).

Will not some combination of "gpart destroy -F" and (insert suggestion) work?
-- 
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] Patch to bsdinstall to support root-on-ZFS and GELI

On 10/08/13 22:25, Freddie Cash wrote:
> On Tue, Oct 8, 2013 at 1:17 PM, Nathan Whitehorn
> mailto:nwhiteh...@freebsd.org>>wrote:
>
> 4. What is this gnop stuff for?
>
>
> Can't comment on the rest, but gnop is required to create 4K-aligned
> vdevs where the minimum block size is 4K (aka ashift=12).  Without
> this, ZFS relies on the underlying disk driver providing the correct
> information, and most don't.  Also, if you don't do this, and create a
> vdev using 512B sectors, the ashift will be set to 9, and replacing
> the drive down the line with 4K Advanced Format drive will drop your
> drive performance in the toilet.
>
> Thus, to future-proof your pool, you need to:
>   - set the ashift of the pool to 12 (4 KB)
>   - align the disk/partition on 4 KB boundaries (starting partition at
> 1 MB works well)
>
> Until our ZFS gains the ability to set a minimum ashift for the pool,
> or to set the ashift at vdev creation, or all drive manufacturers
> write perfect firmware, than we need to fake it with gnop.
>

Well, that's a disgusting hack, but I see why it's there. Thanks for the
explanation!
-Nathan
___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-08 Thread Freddie Cash

On Tue, Oct 8, 2013 at 1:17 PM, Nathan Whitehorn wrote:

> 4. What is this gnop stuff for?
>

Can't comment on the rest, but gnop is required to create 4K-aligned vdevs
where the minimum block size is 4K (aka ashift=12).  Without this, ZFS
relies on the underlying disk driver providing the correct information, and
most don't.  Also, if you don't do this, and create a vdev using 512B
sectors, the ashift will be set to 9, and replacing the drive down the line
with 4K Advanced Format drive will drop your drive performance in the
toilet.

Thus, to future-proof your pool, you need to:
  - set the ashift of the pool to 12 (4 KB)
  - align the disk/partition on 4 KB boundaries (starting partition at 1 MB
works well)

Until our ZFS gains the ability to set a minimum ashift for the pool, or to
set the ashift at vdev creation, or all drive manufacturers write perfect
firmware, than we need to fake it with gnop.

-- 
Freddie Cash
fjwc...@gmail.com
___
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] Patch to bsdinstall to support root-on-ZFS and GELI

On 10/07/13 21:59, Allan Jude wrote:
> Devin Teske and I have been working on a big patch to bsdinstall to
> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
> sector gnop trick, and optional GELI encryption. We would like to commit
> this in time for 10.0-BETA1 so it needs some testing to work out any
> obvious bugs before we send it off to re@ to get it committed.
>
> It includes a single configuration menu that allows you to select all of
> the required details, including which drives to use (gets details from
> camcontrol, also includes an inspection utility that presents the
> detailed output of camcontrol inquiry/identify, and gpart show), what
> ZFS RAID level to use (taking in to consideration the selected number of
> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>
>
> Additional, it includes some other changes to bsdinstall:
> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
> 3. Remove the dialog asking if you wish to enable crash dumps, this
> feature has been combined into the regular 'services to enable' dialog
> and enabled by default
>
>
> You can browse the patches here:
> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>
> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
> available compressed (48 MB) or uncompressed (211 MB):
>
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>
>
> We look forward to your feedback
>

Thanks for doing this! I had a few comments:
1. ZFS is not bootable on all architectures. Could you adjust that menu
item to only display for i386, amd64, and (I think?) sparc64. Use uname
-m, not -p, for this.
1a. The script is broken on sparc64 in any case, which uses VTOC8
instead of GPT.
2. Why are you using camcontrol? That is guaranteed not to work on
non-CAM systems. You should use the GEOM ident string if you need an ID.
3. Any plans to integrate this into the regular partition editor? ZFS
support is important enough that I will definitely not get in the way,
even as a bolt-on, but it would be a shame for it to stay that way. The
editor is also designed for ZFS to be added.
4. What is this gnop stuff for?
5. I think some substantial part of the MBR code will blow up if you are
reinitalizing a previously formatted disk (the bsdlabel will be retasted
and come back from the dead).
-Nathan
___
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-08 Thread Teske, Devin

On Oct 7, 2013, at 10:48 PM, Allan Jude wrote:

> On 2013-10-08 01:11, Teske, Devin wrote:
>> On Oct 7, 2013, at 10:07 PM, Allan Jude wrote:
>> 
>>> On 2013-10-07 15:59, Allan Jude wrote:
 Devin Teske and I have been working on a big patch to bsdinstall to
 implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
 sector gnop trick, and optional GELI encryption. We would like to commit
 this in time for 10.0-BETA1 so it needs some testing to work out any
 obvious bugs before we send it off to re@ to get it committed.

 It includes a single configuration menu that allows you to select all of
 the required details, including which drives to use (gets details from
 camcontrol, also includes an inspection utility that presents the
 detailed output of camcontrol inquiry/identify, and gpart show), what
 ZFS RAID level to use (taking in to consideration the selected number of
 drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.

 Additional, it includes some other changes to bsdinstall:
 1. Change the default to the 'non-standard keyboard mapping' prompt to no
 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
 3. Remove the dialog asking if you wish to enable crash dumps, this
 feature has been combined into the regular 'services to enable' dialog
 and enabled by default

 You can browse the patches here:
 http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/

 I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
 available compressed (48 MB) or uncompressed (211 MB):

 http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz

 http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso

 We look forward to your feedback

>>> I've generated a new version of the ISO incorporating all of todays
>>> changes and moving up to 10.0-ALPHA5
>>> It includes 2 patches from Warren Block, improving the keymap menu and
>>> indicating which network interfaces are wireless
>>> 
>> Excellent.
>> 
>> However, I have to say... you opened a can of worms by touching keymap.
>> 
>> Eventually I plan to rewrite all of the scripts to the same format that 
>> zfsboot
>> is using. I've already started rewriting keymap to the new format. Of course,
>> this opened up another can of worms... the simple things like:
>> 
>> DIALOG_OK
>> DIALOG_CANCEL
>> DIALOG_ESC
> 
> Yeah, after having them, I felt a bit naked not having all of those
> 'constants' defined.
> 

The constants are now where they belong... `dialog.subr'
I also went through bsdconfig(8) with a fine-tooth comb and made use of the
new "constants" everywhere.

I think it's a definite improvement.

> Originally, all I had done was add --defaultno to the dialog command,
> but Warren's patch makes a lot of sense, allow the user to 'try' the new
> keymap before trying to do the rest of the install based on it.
> 

I rewrote warren's code into the stateful design and cleaned it up.

>> I feel would be much better off in the `dialog.subr' module. So,... I've 
>> started
>> peppering their usage everywhere in bsdconfig to make them "proper".
>> 
>> That means they will just be transparent from including `dialog.subr'.
>> 
> 
> This is definately something that I think is a good idea, but my focus
> is on improving the usability and functionality of the installer in time
> for 10.0. Unifying everything to the bsdconfig style is slightly lower
> priority. Admittedly, the `bsdconfig networking` stuff is quite nice
> 

*nods*

I took a look at the bsdinstall networking stuff, and I wanted to run away.

Let's push that into the future.

It wasn't too hard to get those global exit codes deployed, so I did that,
but like you say... I agree we should minimize "extra work" that will be
eventually slated for a future release.
-- 
Devin

>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>> 
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>> 
>> Excellent, thanks!
> 
> 
> -- 
> Allan Jude
> 
> ___
> 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

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

On 2013-10-08 01:11, Teske, Devin wrote:
> On Oct 7, 2013, at 10:07 PM, Allan Jude wrote:
>
>> On 2013-10-07 15:59, Allan Jude wrote:
>>> Devin Teske and I have been working on a big patch to bsdinstall to
>>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>>> sector gnop trick, and optional GELI encryption. We would like to commit
>>> this in time for 10.0-BETA1 so it needs some testing to work out any
>>> obvious bugs before we send it off to re@ to get it committed.
>>>
>>> It includes a single configuration menu that allows you to select all of
>>> the required details, including which drives to use (gets details from
>>> camcontrol, also includes an inspection utility that presents the
>>> detailed output of camcontrol inquiry/identify, and gpart show), what
>>> ZFS RAID level to use (taking in to consideration the selected number of
>>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>>>
>>>
>>> Additional, it includes some other changes to bsdinstall:
>>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
>>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>>> feature has been combined into the regular 'services to enable' dialog
>>> and enabled by default
>>>
>>>
>>> You can browse the patches here:
>>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>>
>>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>>> available compressed (48 MB) or uncompressed (211 MB):
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>>
>>>
>>> We look forward to your feedback
>>>
>> I've generated a new version of the ISO incorporating all of todays
>> changes and moving up to 10.0-ALPHA5
>> It includes 2 patches from Warren Block, improving the keymap menu and
>> indicating which network interfaces are wireless
>>
> Excellent.
>
> However, I have to say... you opened a can of worms by touching keymap.
>
> Eventually I plan to rewrite all of the scripts to the same format that 
> zfsboot
> is using. I've already started rewriting keymap to the new format. Of course,
> this opened up another can of worms... the simple things like:
>
> DIALOG_OK
> DIALOG_CANCEL
> DIALOG_ESC

Yeah, after having them, I felt a bit naked not having all of those
'constants' defined.

Originally, all I had done was add --defaultno to the dialog command,
but Warren's patch makes a lot of sense, allow the user to 'try' the new
keymap before trying to do the rest of the install based on it.

> I feel would be much better off in the `dialog.subr' module. So,... I've 
> started
> peppering their usage everywhere in bsdconfig to make them "proper".
>
> That means they will just be transparent from including `dialog.subr'.
>

This is definately something that I think is a good idea, but my focus
is on improving the usability and functionality of the installer in time
for 10.0. Unifying everything to the bsdconfig style is slightly lower
priority. Admittedly, the `bsdconfig networking` stuff is quite nice

>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>
> Excellent, thanks!


-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI

On Oct 7, 2013, at 10:07 PM, Allan Jude wrote:

> On 2013-10-07 15:59, Allan Jude wrote:
>> Devin Teske and I have been working on a big patch to bsdinstall to
>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>> sector gnop trick, and optional GELI encryption. We would like to commit
>> this in time for 10.0-BETA1 so it needs some testing to work out any
>> obvious bugs before we send it off to re@ to get it committed.
>> 
>> It includes a single configuration menu that allows you to select all of
>> the required details, including which drives to use (gets details from
>> camcontrol, also includes an inspection utility that presents the
>> detailed output of camcontrol inquiry/identify, and gpart show), what
>> ZFS RAID level to use (taking in to consideration the selected number of
>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>> 
>> 
>> Additional, it includes some other changes to bsdinstall:
>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>> feature has been combined into the regular 'services to enable' dialog
>> and enabled by default
>> 
>> 
>> You can browse the patches here:
>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>> 
>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>> available compressed (48 MB) or uncompressed (211 MB):
>> 
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>> 
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>> 
>> 
>> We look forward to your feedback
>> 
> 
> I've generated a new version of the ISO incorporating all of todays
> changes and moving up to 10.0-ALPHA5
> It includes 2 patches from Warren Block, improving the keymap menu and
> indicating which network interfaces are wireless
> 

Excellent.

However, I have to say... you opened a can of worms by touching keymap.

Eventually I plan to rewrite all of the scripts to the same format that zfsboot
is using. I've already started rewriting keymap to the new format. Of course,
this opened up another can of worms... the simple things like:

DIALOG_OK
DIALOG_CANCEL
DIALOG_ESC

I feel would be much better off in the `dialog.subr' module. So,... I've started
peppering their usage everywhere in bsdconfig to make them "proper".

That means they will just be transparent from including `dialog.subr'.

> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
> 
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
> 

Excellent, thanks!
-- 
Devin

P.S. I have to get apache installed on one of my jails to server you the video 
;)
I'll have a URL for you tomorrow morning. Trying to work through all the changes
in keymap to get it upgraded.

_
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] Patch to bsdinstall to support root-on-ZFS and GELI

On 2013-10-07 15:59, Allan Jude wrote:
> Devin Teske and I have been working on a big patch to bsdinstall to
> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
> sector gnop trick, and optional GELI encryption. We would like to commit
> this in time for 10.0-BETA1 so it needs some testing to work out any
> obvious bugs before we send it off to re@ to get it committed.
>
> It includes a single configuration menu that allows you to select all of
> the required details, including which drives to use (gets details from
> camcontrol, also includes an inspection utility that presents the
> detailed output of camcontrol inquiry/identify, and gpart show), what
> ZFS RAID level to use (taking in to consideration the selected number of
> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>
>
> Additional, it includes some other changes to bsdinstall:
> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
> 3. Remove the dialog asking if you wish to enable crash dumps, this
> feature has been combined into the regular 'services to enable' dialog
> and enabled by default
>
>
> You can browse the patches here:
> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>
> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
> available compressed (48 MB) or uncompressed (211 MB):
>
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>
>
> We look forward to your feedback
>

I've generated a new version of the ISO incorporating all of todays
changes and moving up to 10.0-ALPHA5
It includes 2 patches from Warren Block, improving the keymap menu and
indicating which network interfaces are wireless

http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz

http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso



-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI

On Oct 7, 2013, at 5:31 PM, Allan Jude wrote:

> On 2013-10-07 20:21, Teske, Devin wrote:
>> On Oct 7, 2013, at 5:18 PM, Warren Block wrote:
>> 
>>> On Mon, 7 Oct 2013, Allan Jude wrote:
>>> 
 On 2013-10-07 16:43, Warren Block wrote:
> On Mon, 7 Oct 2013, Allan Jude wrote:
> 
>> Additional, it includes some other changes to bsdinstall:
>> 1. Change the default to the 'non-standard keyboard mapping' prompt
>> to no
> Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .
 That is a good idea, I'll add that

 I've also hit this:
 http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html
 and plan to throw in a fix for that.
 Which makes more sense, blindly 'killall dhclient' before we try to
 acquire a new lease, or detect that dhclient is running and try to use
 the IP that has already been assigned?
>>> killall seems all right.  In fact, internally, it's going to do that check. 
>>>  If nothing named dhclient is running, it will return immediately.
>>> 
>>> Although on 10.0, dhclient does not want to die sometimes.
>>> 
>>> Here's another PR for usability:
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/161547
>> Hope you guys aren't rewriting bsdconfig's network.subr
> 
> These changes are in usr.sbin/bsdinstall/scripts/network and
> usr.sbin/bsdinstall/scripts/network_ipv4
> 

Correct, but I meant "reinvent" actually.

There's an enormous API for dealing with the network.

/usr/share/bsdconfig/media/tcpip.subr

Is for acquiring/maintaining active TCP connections
Meanwhile,...

/usr/share/bsdconfig/network/*.subr

Is for configuring permanent network settings that stick after a reboot.

> I've not touched bsdconfig's network stuff
> 

Probably worth a look. It can probably replace bsdinstall's netconfig.
-- 
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] Patch to bsdinstall to support root-on-ZFS and GELI

On 2013-10-07 20:21, Teske, Devin wrote:
> On Oct 7, 2013, at 5:18 PM, Warren Block wrote:
>
>> On Mon, 7 Oct 2013, Allan Jude wrote:
>>
>>> On 2013-10-07 16:43, Warren Block wrote:
 On Mon, 7 Oct 2013, Allan Jude wrote:

> Additional, it includes some other changes to bsdinstall:
> 1. Change the default to the 'non-standard keyboard mapping' prompt
> to no
 Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .
>>> That is a good idea, I'll add that
>>>
>>> I've also hit this:
>>> http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html
>>> and plan to throw in a fix for that.
>>> Which makes more sense, blindly 'killall dhclient' before we try to
>>> acquire a new lease, or detect that dhclient is running and try to use
>>> the IP that has already been assigned?
>> killall seems all right.  In fact, internally, it's going to do that check.  
>> If nothing named dhclient is running, it will return immediately.
>>
>> Although on 10.0, dhclient does not want to die sometimes.
>>
>> Here's another PR for usability:
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/161547
> Hope you guys aren't rewriting bsdconfig's network.subr

These changes are in usr.sbin/bsdinstall/scripts/network and
usr.sbin/bsdinstall/scripts/network_ipv4

I've not touched bsdconfig's network stuff

-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI

On Oct 7, 2013, at 5:18 PM, Warren Block wrote:

> On Mon, 7 Oct 2013, Allan Jude wrote:
> 
>> On 2013-10-07 16:43, Warren Block wrote:
>>> On Mon, 7 Oct 2013, Allan Jude wrote:
>>> 
 Additional, it includes some other changes to bsdinstall:
 1. Change the default to the 'non-standard keyboard mapping' prompt
 to no
>>> 
>>> Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .
> 
>> That is a good idea, I'll add that
>> 
>> I've also hit this:
>> http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html
>> and plan to throw in a fix for that.
>> Which makes more sense, blindly 'killall dhclient' before we try to
>> acquire a new lease, or detect that dhclient is running and try to use
>> the IP that has already been assigned?
> 
> killall seems all right.  In fact, internally, it's going to do that check.  
> If nothing named dhclient is running, it will return immediately.
> 
> Although on 10.0, dhclient does not want to die sometimes.
> 
> Here's another PR for usability:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/161547

Hope you guys aren't rewriting bsdconfig's network.subr
-- 
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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-07 Thread Warren Block


On Mon, 7 Oct 2013, Allan Jude wrote:


On 2013-10-07 16:43, Warren Block wrote:

On Mon, 7 Oct 2013, Allan Jude wrote:


Additional, it includes some other changes to bsdinstall:
1. Change the default to the 'non-standard keyboard mapping' prompt
to no


Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .



That is a good idea, I'll add that

I've also hit this:
http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html
and plan to throw in a fix for that.
Which makes more sense, blindly 'killall dhclient' before we try to
acquire a new lease, or detect that dhclient is running and try to use
the IP that has already been assigned?


killall seems all right.  In fact, internally, it's going to do that 
check.  If nothing named dhclient is running, it will return 
immediately.


Although on 10.0, dhclient does not want to die sometimes.

Here's another PR for usability:
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/161547
___
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] Patch to bsdinstall to support root-on-ZFS and GELI

On 2013-10-07 18:25, Teske, Devin wrote:
> On Oct 7, 2013, at 3:21 PM, Outback Dingo wrote:
>
>>
>>
>> On Mon, Oct 7, 2013 at 5:49 PM, Teske, Devin  
>> wrote:
>>
>> On Oct 7, 2013, at 2:47 PM, Allan Jude wrote:
>>
>>> On 2013-10-07 17:00, Outback Dingo wrote:
 On Mon, Oct 7, 2013 at 4:54 PM, Allan Jude  wrote:

> On 2013-10-07 16:43, Warren Block wrote:
>> On Mon, 7 Oct 2013, Allan Jude wrote:
>>
>>> Additional, it includes some other changes to bsdinstall:
>>> 1. Change the default to the 'non-standard keyboard mapping' prompt
>>> to no
>> Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .
>> ___
>> 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"
> That is a good idea, I'll add that
>
> I've also hit this:
>
> http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html
> and plan to throw in a fix for that.
> Which makes more sense, blindly 'killall dhclient' before we try to
> acquire a new lease, or detect that dhclient is running and try to use
> the IP that has already been assigned?
>
>
>
 jeez after i just updated and patched my source tree to do a build, you
 go and fix things :P
 anyway you can just generate a master diff against the tree that we can
 apply, seems not ive to
 revert the patches and reapply all the newest ones.


> --
> Allan Jude
>
> ___
> 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-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>> Attached find the patch from last night against a fresh HEAD
>>>
>>> I am working on incorporating Warren's patch now
>>>
>> ... and I'm working to review and validate what Allan is writing ;D
>>
>> A couple of big patches to incorporate within the hour (next 15 minutes).
>>
>> okies dokies guess ill revert it all and wait till you guys give the green 
>> light to try again
>>  
> Thanks... you know... Allan is giving me a work-out. He's running like the 
> wind and
> I'm trying to catch my breath as he I trail behind him.
>
> Go Allan Go!
>
> ;D
I make it work, Devin makes it pretty. Then he makes it so it is useful
to other people. Then he makes an API out of it, with C style structs in
SH. Then he does some other wizardry. It is quite impressive.

-- 
Allan Jude

___
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] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 7, 2013, at 3:21 PM, Outback Dingo wrote:

> 
> 
> 
> On Mon, Oct 7, 2013 at 5:49 PM, Teske, Devin  
> wrote:
> 
> On Oct 7, 2013, at 2:47 PM, Allan Jude wrote:
> 
> > On 2013-10-07 17:00, Outback Dingo wrote:
> >> On Mon, Oct 7, 2013 at 4:54 PM, Allan Jude  wrote:
> >>
> >>> On 2013-10-07 16:43, Warren Block wrote:
>  On Mon, 7 Oct 2013, Allan Jude wrote:
> 
> > Additional, it includes some other changes to bsdinstall:
> > 1. Change the default to the 'non-standard keyboard mapping' prompt
> > to no
>  Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .
>  ___
>  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"
> >>> That is a good idea, I'll add that
> >>>
> >>> I've also hit this:
> >>>
> >>> http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html
> >>> and plan to throw in a fix for that.
> >>> Which makes more sense, blindly 'killall dhclient' before we try to
> >>> acquire a new lease, or detect that dhclient is running and try to use
> >>> the IP that has already been assigned?
> >>>
> >>>
> >>>
> >> jeez after i just updated and patched my source tree to do a build, you
> >> go and fix things :P
> >> anyway you can just generate a master diff against the tree that we can
> >> apply, seems not ive to
> >> revert the patches and reapply all the newest ones.
> >>
> >>
> >>> --
> >>> Allan Jude
> >>>
> >>> ___
> >>> 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-current@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> >
> > Attached find the patch from last night against a fresh HEAD
> >
> > I am working on incorporating Warren's patch now
> >
> 
> ... and I'm working to review and validate what Allan is writing ;D
> 
> A couple of big patches to incorporate within the hour (next 15 minutes).
> 
> okies dokies guess ill revert it all and wait till you guys give the green 
> light to try again
>  

Thanks... you know... Allan is giving me a work-out. He's running like the wind 
and
I'm trying to catch my breath as he I trail behind him.

Go Allan Go!

;D
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; 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] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-07 Thread Outback Dingo

On Mon, Oct 7, 2013 at 5:49 PM, Teske, Devin wrote:

>
> On Oct 7, 2013, at 2:47 PM, Allan Jude wrote:
>
> > On 2013-10-07 17:00, Outback Dingo wrote:
> >> On Mon, Oct 7, 2013 at 4:54 PM, Allan Jude 
> wrote:
> >>
> >>> On 2013-10-07 16:43, Warren Block wrote:
>  On Mon, 7 Oct 2013, Allan Jude wrote:
> 
> > Additional, it includes some other changes to bsdinstall:
> > 1. Change the default to the 'non-standard keyboard mapping' prompt
> > to no
>  Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .
>  ___
>  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"
> >>> That is a good idea, I'll add that
> >>>
> >>> I've also hit this:
> >>>
> >>>
> http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html
> >>> and plan to throw in a fix for that.
> >>> Which makes more sense, blindly 'killall dhclient' before we try to
> >>> acquire a new lease, or detect that dhclient is running and try to use
> >>> the IP that has already been assigned?
> >>>
> >>>
> >>>
> >> jeez after i just updated and patched my source tree to do a build,
> you
> >> go and fix things :P
> >> anyway you can just generate a master diff against the tree that we can
> >> apply, seems not ive to
> >> revert the patches and reapply all the newest ones.
> >>
> >>
> >>> --
> >>> Allan Jude
> >>>
> >>> ___
> >>> 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-current@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
> >
> > Attached find the patch from last night against a fresh HEAD
> >
> > I am working on incorporating Warren's patch now
> >
>
> ... and I'm working to review and validate what Allan is writing ;D
>
> A couple of big patches to incorporate within the hour (next 15 minutes).
>

okies dokies guess ill revert it all and wait till you guys give the green
light to try again


> --
> 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"
>
___
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] Patch to bsdinstall to support root-on-ZFS and GELI


On Oct 7, 2013, at 2:47 PM, Allan Jude wrote:

> On 2013-10-07 17:00, Outback Dingo wrote:
>> On Mon, Oct 7, 2013 at 4:54 PM, Allan Jude  wrote:
>> 
>>> On 2013-10-07 16:43, Warren Block wrote:
 On Mon, 7 Oct 2013, Allan Jude wrote:
 
> Additional, it includes some other changes to bsdinstall:
> 1. Change the default to the 'non-standard keyboard mapping' prompt
> to no
 Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .
 ___
 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"
>>> That is a good idea, I'll add that
>>> 
>>> I've also hit this:
>>> 
>>> http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html
>>> and plan to throw in a fix for that.
>>> Which makes more sense, blindly 'killall dhclient' before we try to
>>> acquire a new lease, or detect that dhclient is running and try to use
>>> the IP that has already been assigned?
>>> 
>>> 
>>> 
>> jeez after i just updated and patched my source tree to do a build, you
>> go and fix things :P
>> anyway you can just generate a master diff against the tree that we can
>> apply, seems not ive to
>> revert the patches and reapply all the newest ones.
>> 
>> 
>>> --
>>> Allan Jude
>>> 
>>> ___
>>> 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-current@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> Attached find the patch from last night against a fresh HEAD
> 
> I am working on incorporating Warren's patch now
> 

... and I'm working to review and validate what Allan is writing ;D

A couple of big patches to incorporate within the hour (next 15 minutes).
-- 
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] Patch to bsdinstall to support root-on-ZFS and GELI

On 2013-10-07 17:00, Outback Dingo wrote:
> On Mon, Oct 7, 2013 at 4:54 PM, Allan Jude  wrote:
>
>> On 2013-10-07 16:43, Warren Block wrote:
>>> On Mon, 7 Oct 2013, Allan Jude wrote:
>>>
 Additional, it includes some other changes to bsdinstall:
 1. Change the default to the 'non-standard keyboard mapping' prompt
 to no
>>> Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .
>>> ___
>>> 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"
>> That is a good idea, I'll add that
>>
>> I've also hit this:
>>
>> http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html
>> and plan to throw in a fix for that.
>> Which makes more sense, blindly 'killall dhclient' before we try to
>> acquire a new lease, or detect that dhclient is running and try to use
>> the IP that has already been assigned?
>>
>>
>>
> jeez after i just updated and patched my source tree to do a build, you
> go and fix things :P
> anyway you can just generate a master diff against the tree that we can
> apply, seems not ive to
> revert the patches and reapply all the newest ones.
>
>
>> --
>> Allan Jude
>>
>> ___
>> 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-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Attached find the patch from last night against a fresh HEAD

I am working on incorporating Warren's patch now

-- 
Allan Jude

Index: usr.sbin/bsdconfig/share/device.subr
===
--- usr.sbin/bsdconfig/share/device.subr(revision 256125)
+++ usr.sbin/bsdconfig/share/device.subr(working copy)
@@ -208,6 +208,10 @@ f_device_get_all()
n=$(( $n + 1 ))
# Get the desc, type, and max (with debugging disabled)
# NOTE: Bypassing f_device_name_get() for efficiency
+   # ASIDE: This would be equivalent to the following:
+   #   debug= f_device_name_get $dev desc
+   #   debug= f_device_name_get $dev type
+   #   debug= f_device_name_get $dev max
debug= f_getvar _device_desc$n desc
debug= f_getvar _device_type$n type
debug= f_getvar _device_max$n max
@@ -313,7 +317,10 @@ f_device_get_all()
continue
fi
 
-   f_device_register "$diskname" "" \
+   # Try and find its description
+   f_device_desc "$diskname" $DEVICE_TYPE_DISK desc
+
+   f_device_register "$diskname" "$desc" \
  "/dev/$diskname" $DEVICE_TYPE_DISK 0
f_dprintf "Found a disk device named %s" "$diskname"
 
@@ -379,10 +386,27 @@ f_device_name_get()
case "$__prop" in type|desc|max) : good ;;
*) return $FAILURE; esac
 
+   #
+   # Attempt to create an alternate-form of $__name that contains the
+   # first contiguous string of numbers replaced with `%d' for comparison
+   # against stored pattern names (see MAIN).
+   #
+   local __left="${__name%%[0-9]*}" __right="${__name#*[0-9]}" __dname=
+   if [ "$__left" != "$__name" ]; then
+   # Chop leading digits from right 'til we hit first non-digit
+   while :; do
+   case "$__right" in
+   [0-9]*) __right="${__right#[0-9]}" ;;
+*) break
+   esac
+   done
+   __dname="${__left}%d$__right"
+   fi
+
[ "$__type" = "$DEVICE_TYPE_ANY" ] && __type=
for __dev in $DEVICE_NAMES; do
__n=$(( $__n + 1 ))
-   [ "$__dev" = "$__name" ] || continue
+   [ "$__dev" = "$__name" -o "$__dev" = "$__dname" ] || continue
f_getvar _device_type$__n __devtype
[ "${__type:-$__devtype}" = "$__devtype" ] || continue
f_getvar _device_$__prop$__n $__var_to_set
@@ -463,6 +487,39 @@ f_device_desc()
fi
fi
 
+   #
+   # For disks, attempt to return camcontrol(8) descriptions.
+   # Otherwise fall through to below static list.
+   #
+   f_have camcontrol &&
+   [ "${__type:-$DEVICE_TYPE_DISK}" = "$DEVICE_TYPE_DISK" ] &&
+   __cp=$( camcontrol devlist 2> /dev/null | awk -v disk="$__name" '
+   $0~"(\\(|,)"disk"(,|\\))" {
+   if (!match($0, "<[^>]+>")) next
+

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

2013-10-07 Thread Outback Dingo

On Mon, Oct 7, 2013 at 4:54 PM, Allan Jude  wrote:

> On 2013-10-07 16:43, Warren Block wrote:
> > On Mon, 7 Oct 2013, Allan Jude wrote:
> >
> >> Additional, it includes some other changes to bsdinstall:
> >> 1. Change the default to the 'non-standard keyboard mapping' prompt
> >> to no
> >
> > Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .
> > ___
> > 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"
> That is a good idea, I'll add that
>
> I've also hit this:
>
> http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html
> and plan to throw in a fix for that.
> Which makes more sense, blindly 'killall dhclient' before we try to
> acquire a new lease, or detect that dhclient is running and try to use
> the IP that has already been assigned?
>
>
>
jeez after i just updated and patched my source tree to do a build, you
go and fix things :P
anyway you can just generate a master diff against the tree that we can
apply, seems not ive to
revert the patches and reapply all the newest ones.


>
> --
> Allan Jude
>
> ___
> 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-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] Patch to bsdinstall to support root-on-ZFS and GELI