Jack Schwartz wrote:
> Hi everyone.
>
> Some of us had an impromptu meeting around the text-installer and
> text-mode Device Driver Utility (DDU) invocation and interaction.
> After the meeting I followed up with Frank, our resident UI expert.
> Here's a summary of what I discussed with Frank, along with enough
> background for those who didn't attend.
>
> 1)The text mode comes up with a menu of four options: Run DDU, run
> installer, shell and reboot. We discussed just dropping to the shell
> automatically if the installer exits after a successful installation,
> and rebooting when the user quit that shell. Frank thought that
> automatically dropping to a shell after the text installer finished
> successfully was not worth the effort. He felt that displaying a menu
> with four choices was fine. (I didn't solicit this particular
> response either :) )
>
> 2) We discussed what the DDU should do about configuring network
> access so it can go to repos, etc. We discussed the idea of having a
> library for displaying the network screens and doing the network
> setup; this library would be linked by both the DDU and the
> installer. We discussed what to do in the installer if the DDU has
> already set up the network.
>
> There were three choices in the first network screen, per Frank's
> original mock up: auto, manual, none. One option discussed was to
> offer a fourth choice alongside the existing three: to keep the
> network as set up by the DDU (with the settings displayed, of course).
>
> Frank's preference for what to do in the installer regarding network
> setup, after the DDU has configured the network, is to still offer
> only three choices in the first network screen. If DHCP wasn't used
> to set up the network, display the manual screen with all fields
> filled in when chosen. The user could then change or tweak
> accordingly. The choice for keeping three choices boils down to
> having a less cluttered/confusing screen at the expense of having the
> user hit an extra screen.
>
> On a related note, it would be better not to pass configuration from
> the DDU to the text installer, but to have the text installer pick it
> up using ifconfig and other commands (vs passing a file). Not only is
> this kludge-free, but it allows the user to tweak the network settings
> post-DDU and pre-Installer and have those new network settings be
> properly reflected in the Installer network screens.
>
> 3) Frank and I agreed that there should be a common library of network
> setup / screens to be shared by the DDU and installer. Not only does
> this provide a more consistent user interface. It prevents
> reinventing the wheel, and will be easier for the DDU team to just
> link with the library when it is ready.
>
> 4) I also ran by Frank that the DDU will possibly need to configure
> the network (if it is given the command to automatically install
> missing drivers (which requires a repo), or if it otherwise needs to
> go to a repository or a URL on the net). We agreed that if the DDU
> requires the net, it will try to bring up the network automatically
> first (a la DHCP / NWAM).
I don't follow "a la DHCP/NWAM. It was my understanding that profile
applied to the microroot would disable network/physical:nwam and the
"default" instance of the service would be enabled. Do you plan to
enable the nwam instance of the service ? Note that while NWAM uses
DHCP, the reverse is not true.
> If it can't for some reason (maybe the net doesn't have a DHCP
> server), then the user will be asked if the network should be set up,
> and then presented with the network setup screen. (Screen would
> likely have different text but the same choices as the installer's
> "manual" network setup screen.)
>
> Questions/comments/corrections invited.
>
> Thanks,
> Jack
>
