[arch-releng] RFC: Automated Install

[David Runge]

Hi Brent,

On 2021-07-09 02:24:03 (-0400), brent s. via arch-releng wrote:
> I'm in the middle of writing a tool that will do just this[0]. Much
> like RedHat's Kickstart or Debian's preseed, it uses kernel
> commandline options/parameters to fetch a configuration, parses that
> configuration, and then installs Arch according to that specified
> configuration.  (Everything from partitioning disks to installing
> certain packages, etc.) Note that it isn't intended to make the
> install process "easier", per se; it intends to do it with *minimal to
> no user interaction*. One would need a very clear understanding and
> familiarity with the manual Arch install process to make use of this.

There are already a few ways of doing this (in theory):

- the script= kernel command line parameter [1]
- archinstall [2]
- ansible [3]

Additionally, we have support for cloud-init on the installation medium
since archiso >= 51.

> The reason I'm even writing to this list instead of say, just having a
> package on the AUR as it makes little to no sense to run this software
> on anything but the install medium.
> 
> 
> In order to perform things like disk partitioning and the like, I'm
> thinking of using the udisks2 API via DBUS.
> Unfortunately, this means that it (udisks2) would need to be included in
> the live ISO image (or an alternate one would be spun up).
> 
> Alternatively I could do it via libblockdev and gobject-introspection,
> but that is... significantly more complicated.
> 
> As such, a couple questions:
> 
> 
> 1.) Is the RelEng team interested in adding such an unattended install
> ability to Arch Linux (especially one developed externally)?

I don't see much of a benefit to add another way of installation
automation, especially given that we have the above capabilities.

> 2.) a.) Would udisks2 (and perhaps other libraries) be able to be added
> to the standard installer ISO?
>         As of udisks2-2.9.2-1, for instance, this would add 14086.78 KiB
> (~14 MiB) to the squashed root (before squashing).

The udisks2 package is currently not required for any installation or
rescue system specific task (to my knowledge), so there would be no
reason to add it. Sorry.

> 2.) b.) If not, would the amount of maintenance overhead required for
> mastering a separate ISO be worth the feature-add?

With the archiso profiles [4] I hope it has become much simpler to
create a custom ISO (even with custom repostories containing custom
packages).
Currently I don't see us in the position to add another custom ISO
plainly for the purpose of (semi?) unattended installation (given that
we have this functionality already).
At this point in time, more important milestones to reach are the full
automation of release artifact creation [5], more specifically also the
consolidation of how/where we release [6] and the full reproducibility
of our installation medium [7].

I invite you to look into the existing solutions and contribute there,
if possible.

Best,
David

[1] https://gitlab.archlinux.org/archlinux/archiso/-/blob/1b01d22596708a59275b7af5aa3e7ad4d1a3edb7/docs/README.bootparams#L145-149
[2] https://wiki.archlinux.org/title/Archinstall
[3] e.g. https://gitlab.archlinux.org/archlinux/infrastructure/-/tree/master/roles/install_arch
[4] https://gitlab.archlinux.org/archlinux/archiso/-/blob/1b01d22596708a59275b7af5aa3e7ad4d1a3edb7/docs/README.profile.rst
[5] https://gitlab.archlinux.org/archlinux/releng
[6] https://gitlab.archlinux.org/archlinux/releng/-/issues/11
[7] https://gitlab.archlinux.org/archlinux/archiso/-/issues/68

-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-releng/attachments/20210710/894cd4a2/attachment.sig>