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

From: Teske, Devin <Devin.Teske_at_fisglobal.com>
Date: Sat, 19 Oct 2013 15:55:06 +0000
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_at_freebsd.org mailing list
>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>> To unsubscribe, send any mail to
>>>>> "freebsd-current-unsubscribe_at_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_at_freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to
>>> "freebsd-current-unsubscribe_at_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 by persons other than the intended recipient. Thank you.
Received on Sat Oct 19 2013 - 13:55:11 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:43 UTC