From nobody Fri Jul 16 20:28:20 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 F3AB512A48C2 for ; Fri, 16 Jul 2021 20:28:30 +0000 (UTC) (envelope-from yzhong@freebsdfoundation.org) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 4GRN9V0xP4z4p9m for ; Fri, 16 Jul 2021 20:28:29 +0000 (UTC) (envelope-from yzhong@freebsdfoundation.org) Received: by mail-lf1-x131.google.com with SMTP id y42so18029631lfa.3 for ; Fri, 16 Jul 2021 13:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsdfoundation.org; s=gfnp-20170908; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=/HdI7kVDzAWI9Itx1d+tz4thOEvlGBdecI3mF8LEnng=; b=gKVAQYzrbDXa1M7N6VknxHdNkBgnScaWhIFw6dzin1PIWJRQglw7EtJ8fYgYpEhk8z ed4sa3U8wILWEb9d/TOzBCd3C7Pa1yZjLhPd6FT1h1XFCKui7PE6u+FcbH/vYPwDD5J8 F+piRy6WqMzlzXNmbw0mwN2v5skmLaKmJdH7S0Yfd/WLhd5fXgMxIR9Xl8LhcEJzkfjQ tMb9fu8dYSpVDe9l9Jlxs/OO1uK/WjjhEszZjmTYaXVM43R3fnKEsAlhbATK85XyOS6z 60nu/cl59rBxW63LENNyVzEUUSYIsPYO+ib6qTiozaSyvJdEB84sEBwGygjlw+oDzDmH rNsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=/HdI7kVDzAWI9Itx1d+tz4thOEvlGBdecI3mF8LEnng=; b=Q8Ny9JxPuAYXGB+iBmOuiJJkNXDEnpn0FQ5k4eNqgrQwr+Xk0dDGF6L5lNOOaO+7dB 8BtiBJMAP7xaRni8Vs8UIv4ve5ar83pP4pHOw5FBlKVPWluHU6BEYCKwcHMHAIgF2Z8U I1YgItwCKiJiMArBZp8BcUIwDyNk86pp2x7j0UNFZVS6Ft/vhR4diMr9aZeqJVxweT5o Iz/UrzCtK4PlWFxIN4ih+9sKjAZCWM8oE1Tma6EdL7q46GdjbnWk2JhdVo9As113j2ZJ GtPUCr0mh2jbfjCLhinFO/CqnuXewtHU7sdQsYnLZ9ExzZn88TMGQlZy4ipwgAkKYrAG w5gw== X-Gm-Message-State: AOAM530wczQH7luaPE3einqJMe0iIfdOQrPE6WL0q9QTCWN3ycCRuY4D GquHNQo/sLNFj60qAefzvP/ie5hmRdRfMQN09vk6hFvtmBh6RQd3q00= X-Google-Smtp-Source: ABdhPJwxZdIaHwmsTQVC6HJkx3PA37m0Z5ewwSTNj1fkGMar21e9+djm+dOhhHQvIC7/Rrwe+PtvJBhGVBEvlZD35IA= X-Received: by 2002:a05:6512:4004:: with SMTP id br4mr9017519lfb.2.1626467308166; Fri, 16 Jul 2021 13:28:28 -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 Date: Fri, 16 Jul 2021 13:28:20 -0700 Message-ID: Subject: Experimental FreeBSD installer work To: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4GRN9V0xP4z4p9m X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=freebsdfoundation.org header.s=gfnp-20170908 header.b=gKVAQYzr; dmarc=pass (policy=quarantine) header.from=freebsdfoundation.org; spf=pass (mx1.freebsd.org: domain of yzhong@freebsdfoundation.org designates 2a00:1450:4864:20::131 as permitted sender) smtp.mailfrom=yzhong@freebsdfoundation.org X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[freebsdfoundation.org:s=gfnp-20170908]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::131:from:127.0.2.255]; DKIM_TRACE(0.00)[freebsdfoundation.org:+]; DMARC_POLICY_ALLOW(-0.50)[freebsdfoundation.org,quarantine]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::131:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::131:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] Reply-To: yzhong@freebsdfoundation.org From: Yang Zhong via freebsd-arch X-Original-From: Yang Zhong X-ThisMailContainsUnwantedMimeParts: N 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 bu= t 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.