Re: Experimental FreeBSD installer work

On Fri, Jul 16, 2021 at 11:29 PM Yang Zhong via freebsd-arch <
[email protected]> wrote:

> For the past several weeks as part of my internship at the FreeBSD
> Foundation, I've been working on an experimental FreeBSD installer.
> It's intended to test out several different ideas. Here is a
> repository for the installer itself, with screenshots:
> https://github.com/yangzhong-freebsd/lua-httpd, and a repository for a
> live ISO containing the installer: https://yangzhong-freebsd/ISO.
> Right now, the installer is very rough, but can handle installs with
> basic configuration options. It would be very helpful for me if you
> try using the installer and give feedback on the process.
>
> The most prominent feature of this installer is that it uses a
> graphical, web interface. It works by running a server from the
> installation medium; you configure and execute the install through a
> browser on localhost. This work was started by Ryan Moeller:
> https://gitlab.com/freqlabs/lua-httpd/-/tree/freebsd-install, and my
> installer work adds on to it.
>
> Another possible benefit of this interface is that it could support a
> 'remote install' option where the server runs on the target machine,
> but you configure the install over a network from some other computer.
> I haven’t done much work or research on this idea, so I don’t have
> many concrete things to say here. The remote-install version of the
> installer would be different in several ways: for instance, the keymap
> configuration would no longer be changing the keymap in the actual
> install interface. There are some other problems that I’ve noted but
> not explored, such as the problem of sending passwords over the
> internet.
>
> An installation in this installer proceeds as follows: The user
> completes a configuration form in the browser and the backend writes
> the configuration to a text file. When the user clicks the final
> install button, the installer runs a program that converts that config
> file into one that bsdinstall accepts, and then runs bsdinstall with
> that script.
>
> I'm also thinking about improvements that can be made to the
> user-friendliness of the installer. From what I've read and discussed
> with others about, more automatic configuration would make a big
> improvement to the installation process. There are several ways this
> could be achieved: Ed Maste suggested a choice of 'pre-set'
> configurations, designed for different use cases. This page explores
> this idea, calling them 'profiles':
> www.wonkity.com/~wblock/docs/html/installers.html.
>
> As for future work, here are some problems I have with this
> installer's current design:
>
> 1. bsdinstall offers many different ways to configure partitions, one
> way being to open a terminal and manually do it. This works because
> bsdinstall does the partitioning immediately after partitions have
> been configured. In the experimental installer, the partitioning
> options get written to the configuration file, and everything is done
> at the end, all at once. It doesn't seem possible to offer the manual
> partitioning option while keeping this property of the experimental
> installer.
>
> 2. Because the keymap configurator in the installer sets keymap on
> demand, it sets the X keymap but not the console one. I intend to add
> the option to install a graphical environment in the installer, but
> haven't done that work yet. So, if you change the layout, it'll be set
> for the rest of the installation process, but not in the final
> installed system which boots to the console. There does not seem to be
> a straightforward way to map X keymap/variant options to console
> keymap layouts. While this is not an enormous problem, I'd like to
> come up with a good way to configure both layouts at the same time,
> especially because I use a non-standard layout myself.
>
> 3. This is less of a concrete issue, but I feel is a problem with
> operating system installers in general. I'm a fairly new FreeBSD user,
> and I've experienced this situation several times: I would want to
> configure some setting on my machine and I'd recall that this setting
> was an option in bsdinstall, so it must be possible, but I don't know
> how bsdinstall does it. It feels like the installer does a lot of
> convenient things that then have to be 're-discovered' once you start
> using the operating system post-install.
>
> To help with this, I'd like the installer to have a 'teaching'
> component to it, where each option has some text describing how the
> installer actually does the configuration. I think something like that
> would help new users understand that the installer isn't magic, it's
> just running simple commands for most configuration options. Something
> like that would certainly have helped me.
>
> 4. Things like setting the date and time could also benefit from a
> more automatic process. Selecting a timezone is one of the more
> convoluted parts of the current installer, as it first asks you the
> cryptic "Is your hardware clock set to UTC?" question, and then makes
> you go down some deeply nested menus. There are several web-based
> timezone selection interfaces where you simply pick your location on a
> world map, though the ones I've tried have not been very good. The
> installer could also geolocate your timezone using your IP address.
>
> ---
>
> As you can see, the installer is nowhere near ready for serious use,
> and is currently more of a testing ground for a bunch of interesting
> ideas. I said this earlier, but I'd appreciate any testing of the
> installer as it is, as I have not tested it myself very
> comprehensively. I'd also like to hear any of your thoughts on the
> direction of this work, or any ideas on installer
> design/implementation in general.
>
> Finally, the installer doesn't yet have a name, so let me know if you
> can think of a fitting name for it.
>
>

Many years ago I started to write an installer based on the "Expert System"
methodology.
Then I abandoned it .


Presently I am using Fedora exclusively . In Fedora installs , only
necessary information is supplied .
Installation is very fairly simple . Despite this , forgetting marking the
boot requirement is generation an
unbootable system which is not very appealing .

Before Fedora I was using Mandriva . In Mandriva , there were  options :
() Load install options from a diskette
() Store install options into a diskette

These options were making repeated installs very easy .



My opinion is that , in a similar manner , an XML file may be designed to
define FreeBSD installation options .
During install , this XML options file may be supplied in a USB stick ,
etc. to carry out the install .
Personally I do not like JSON files , and I never use such an option .



Such an install requires to load a FULLY usable initial loader able to use
computer peripherals without fancy mount nightmare
statements , etc. , just as in Mandriva simplicity .


This will allow repeatable install on the same and/or similar computers .

It will be easy to modify the XML file by copying it as a new file and
using it for a new install  .


Personally I would prefer such an approach , because it will be much
simpler than re-enter the same install parameters for
the same or similar installs every time .


Around 1990 , I was developing a set of statistical analysis programs ,
from previous parameter card driven programs , to
interactive parameter entering programs . Later on , I have deleted all of
the interactive parameter entering parts by converting
all of the parameter entering statements to NAMELIST (  in Fortran ) data
entry statements . This approach was much and much
easier than interactive parameter entries . It was possible to copy and
modify for a different set of data .  It was possible rerun the
same data data after corrections on some parts of data , etc.



Mehmet Erol Sanliturk