BSDInstall ISO images

[Nathan Whitehorn]

On 01/23/11 13:55, Garrett Cooper wrote:
> On Sun, Jan 23, 2011 at 11:23 AM, Nathan Whitehorn
> <nwhitehorn at freebsd.org>  wrote:
>> On 01/23/11 12:59, Garrett Cooper wrote:
>>> On Sat, Jan 8, 2011 at 2:54 PM, Nathan Whitehorn<nwhitehorn at freebsd.org>
>>>   wrote:
>>>> I've spent some time integrating bsdinstall into startup of install CDs,
>>>> mostly related to building useful live-CD-based installers. An i386 image
>>>> can be found here (other architectures may follow, as my very slow DSL
>>>> line
>>>> permits):
>>>>
>>>> http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110108.iso.bz2
>>>>
>>>> The source for this can be found at:
>>>>
>>>> svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall
>>>>
>>>> The bits related to live CD usage are the testsystem.sh and rc.local
>>>> files.
>>>> Instead of running sysinstall as an init replacement, I have written a
>>>> small
>>>> rc.local script that gives the user the option to either start the
>>>> installer, open a single-user-mode style shell, or to continue to boot to
>>>> a
>>>> multi-user live CD. Also, instead of the md root used by sysinstall, this
>>>> just boots from the CD directly. This prevents the need for sysinstall's
>>>> media selection, since the distribution files are in the mounted root
>>>> file
>>>> system.
>>>>
>>>> I would appreciate any comments or test results.
>>> Not sure if it matters anymore, but here are my comments:
>>> NOTE: this was using
>>> http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110118.iso.bz2
>>> .
>>>
>>> 1. The i386 image (apparently) isn't compiled with ATACAM, etc support
>>> so opening /dev/cd0 always fails with ENODEV.
>> Yes. But it will fall back to acd0. This is for people with SCSI or USB CD
>> drives. The real problem is if the CD ends up in [a]cd1, so cdboot needs a
>> more robust mechanism here.
> I'm not so much worried about the failure as I am about the noise
> visible to the end user. A lot of stuff fails today silently, that
> should fail silently, and that's ok as long as it makes sense in the
> overall design of things.
>
> So again, printing that stuff is fine in verbose mode but doesn't make
> sense in a more polished / quiet mode that will be packaged as an
> install distribution to lots of users.

Right. I'm just pointing out that it needs to be fixed for other 
reasons, too -- it's potentially broken in addition to being ugly.

>
>>> Partition Editor (I used Manual for the first try):
>>> 1. It would be helpful if the cursor was at the end of the textbox so
>>> that I didn't have to position the cursor at the end or press the
>>> delete key.
>> I'll see if there's a way to change this.
> Much appreciated :). If anything this should be done in libdialog, not
> in bsdinstall as it's more intuitive behavior that belongs there.

Yes, I think so.

>
>>> 3. Having a mountpoint for a bsdlabel partition doesn't make sense and
>>> is confusing.
>> That is true. Since the same form with the mountpoint also has the partition
>> type, I could not find a clean way to make the last line go away. The same
>> issue applies to swap. Ideas for this part of the UI would be very much
>> appreciated.
> Maybe graying out some fields would be helpful in the meantime? Not
> sure if that's possible with the new libdialog in an easy manner.

It is possible to gray out fields, but you'd have to have hooks to check 
at each keystroke what the contents of the partition-type field are. I 
guess one option would be to not support mountpoints for partitions on 
MBR disks, but that would break setting the mount point of your linux 
partition, or adding FAT partitions, etc.

>>> 4. Backing out of the Partition Manager and going back to the previous
>>> dialogs is impossible.
>> Which previous dialogs do you mean? Do you want to back out of the partition
>> manager to use the auto paritioner? If you press "Abort", you can restart
>> the installation, which isn't so far off from that. There wasn't a whole lot
>> of room at the bottom of the partitioner screen for a sysinstall-like "Auto
>> Defaults" button.
> If I do into the manual partitioner and use the standard buttons
> (don't hit ^c, etc), then I couldn't get back to setting the hostname,
> going back and choosing the guided partitioner, etc.

Ah, I see. You can do this by pressing "Finished", then "Abort". There 
should be a nicer way to do this.

>>> 5. Noting that the values (freebsd-ufs, etc) map back to gpart driven
>>> values would be helpful.
>> There's a help line at the bottom of the screen with this information. Do
>> you have a suggestion for making it more intuitive? Dialog doesn't support
>> drop-down menus, which is what I would ordinarily use on this field.
> I'll look at that again in my next run-through. Before what was nice
> about sysinstall is that it placed the help diags further up on the
> screen, so visually I had to parse the text at the top first before I
> proceeded downward. [Most?] humans do top-down reading so I think that
> that concern should be pushed back to libdialog upstream.

As a human, I think I agree. This uses libdialog's help line 
functionality. I'm not sure if where that goes is a config option.

>
>>> Chose restart, walked through the process again and chose manual, made
>>> sure the slice was properly configured for / and swap was setup, then
>>> continued. This time the install went through properly.
>>>
>>> Progress bar:
>>> I think you're on the right track by simplifying the install, but it
>>> could be polished to say:
>>>
>>> kernel
>>> world
>>> distribution (in what context is distribution? Is it configuration
>>> files, etc from `make distribution' ?)
>> That is exactly what "distribution" is. What goes in which files, and how
>> many parts there are, is an interesting question. I think sysinstall splits
>> up the base system a little too much.
> Agreed. But saying "Configuration files", etc is a bit easier for
> end-users to understand.

Yes. Adding human-readable aliases is probably a good idea.
>>> Configuring Network (etc)
>>>
>>> Seems like this could have been done earlier on to shrink the CD size
>>> down a bit.
>> Why would that shrink the CD size? It is done earlier if you need it to
>> download the distfiles. I had placed it towards the end because it's part of
>> a series of optional system configuration steps.
> Today I can download a bootonly ISO and pull down the package chunks I
> want instead of downloading a fat CD/DVD to do that. Network installs
> are nice.

Yes, they are. The installer supports them already -- the ISOs I have 
sent out just come with the installation files, so that logic is never 
triggered.
-Nathan