Hey, all. One of the things that I feel limits Arch Linux is the lack of an ability to kick off an unattended install. Sure, you can boot via PXE or the like, but the actual install does not take place. 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. 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)? 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). 2.) b.) If not, would the amount of maintenance overhead required for mastering a separate ISO be worth the feature-add? Thank you in advance for your feedback. [0] In Golang so it could be easy to package, contained to a relatively localized install, and still relatively accessible to outside contributors. A couple years ago I had an implementation written in Python but this was discouraged as it would be far too complex to maintain, both from a codebase and a RelEng perspective (which, fair point). Golang also would allow for some cleaner parallel operations as well, though one may argue this is more of a nice-to-have in an install context. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info