Date: Sat, 17 Jul 2021 01:25:57 +0300 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: yzhong@freebsdfoundation.org Cc: FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: Experimental FreeBSD installer work Message-ID: <CAOgwaMvYBdwi7OJuiLd93jLLk-enR34UHNu9gG4u6WSRs_CkUA@mail.gmail.com> In-Reply-To: <CABKYNzZmTRpocizdUeDyCLsLEGWRscAaHBkPbtwGV0QBMeAsxg@mail.gmail.com> References: <CABKYNzZmTRpocizdUeDyCLsLEGWRscAaHBkPbtwGV0QBMeAsxg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000093408905c745141f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 16, 2021 at 11:29 PM Yang Zhong via freebsd-arch < freebsd-arch@freebsd.org> 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=E2=80=99t done much work or research on this idea, so I don=E2=80= =99t 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=E2=80=99ve 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 --00000000000093408905c745141f--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMvYBdwi7OJuiLd93jLLk-enR34UHNu9gG4u6WSRs_CkUA>