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/1b01d22596708a59275b7a... [2] https://wiki.archlinux.org/title/Archinstall [3] e.g. https://gitlab.archlinux.org/archlinux/infrastructure/-/tree/master/roles/in... [4] https://gitlab.archlinux.org/archlinux/archiso/-/blob/1b01d22596708a59275b7a... [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