From nobody Fri Jul 16 22:25:57 2021 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0FA2812764A1 for ; Fri, 16 Jul 2021 22:26:37 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GRQnm62HFz3h7d for ; Fri, 16 Jul 2021 22:26:36 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id f9so13677597wrq.11 for ; Fri, 16 Jul 2021 15:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o/dsRx1GVuJwDH2kiczy9j1zykiv36zKV5wMHP1U+ss=; b=WnXANx4Cjzfsq8BIXW6RM1ig1J1Y/Zoe+xuOCg1dyUeb73hM8X9b1RzcK/uqTzVbMW uoJAdplzz05rT3rEsQhypYl3qEabAju1kcV8W6uhbLifTWa3+KjwzOuyvdw9ND1tsoUO FCpdKJ6nqj0BrXBfORIbpLmtZh+Zq+q9qV/ayLgs+McaV+xBdMpCrvDheTc9pT8Ji895 Ebh4/sL67Tqlk1iLFaZmrBQyQJ863pmU27obs09USoWpa7Snm8NYQxF4oxnjMoSyH3yj o1gkaE4TCMvUvla/6RiLqalSrC7WPAY3UTypTDHO7C92xqb6yde1sQTArF0ac3qrbKod ISFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o/dsRx1GVuJwDH2kiczy9j1zykiv36zKV5wMHP1U+ss=; b=cT15/4Xl3kzAsDACj7xfwc47OF1g3ySQc5PjurR56BH2fHzKIVYvMzd6siBB6gY82s cNpOFdNXjpS3GFeMWm90gYDU1oIG8miD/ht861G60qFcZi8gDOSDCRHNheSCO0lbH4YG /horNIrPrNdWmNOE6fCPJ/ctWartjBqBoG0SzONoMFcE7DEkd/+rYF2pak7I01URSEIn gWxjLHAVkKGbA5ae8VTt3VQ9XO6BYkeXUFY/xHKn67sCYdrlFOsuCEi1gAcitW+tBacn g/uHJdDUpw3qEVdt1dIMT6d/6VTF8TfS1hkNCd85Me+nAewNUCAxc5tNb4P26uoj23Dx G1mg== X-Gm-Message-State: AOAM532TF3MdfN4wfODiaa1Exn+1d588Cl9a6dyOun4+gwpQ76tAyTvR Ngps1hehEihHC7Sogt/e3fHaqf1aSaDHtI2CiLM= X-Google-Smtp-Source: ABdhPJx870d8stzm4rdk+RLoHUZJGZf+3kq43EExSF2pXh9tF1U+LwHd0vUxrcx0Fx4YmmMFgf4nlI+LxXuSKnVZDzE= X-Received: by 2002:adf:a1c2:: with SMTP id v2mr15068322wrv.155.1626474395417; Fri, 16 Jul 2021 15:26:35 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Sat, 17 Jul 2021 01:25:57 +0300 Message-ID: Subject: Re: Experimental FreeBSD installer work To: yzhong@freebsdfoundation.org Cc: FreeBSD Arch Content-Type: multipart/alternative; boundary="00000000000093408905c745141f" X-Rspamd-Queue-Id: 4GRQnm62HFz3h7d X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --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--