At this point, I am doing a minimal installation, rebooting, installing packages, using pacopts, and 66-cmds. I am probably fifty percent complete with my i3 build. I am inspired by obarun-install and use of themes and wondering if I can leverage a custom theme to deploy. The idea being to deploy to multiple systems and a method that would be reasonably future-proof for future Obarun releases.

What are your recommendations on how to create a repeatable custom install using obarun-install or obarun-install-theme? References?

I don't mind digging and testing, but looking for a starting point.

Thank you!
I think your friend is pacman -Ql {obarun-install ,obarun-install-themes}
In /var/lib/obarun/obarun-install/config/xxxx you can add your own theme, but you can customize other scripts too.
If you notice once you pick choices from the front page and do one installation, the next time you start the installer your choices are saved. The place for this is /etc/obarun/install.conf. The only time an upgrade of the script that will touch this is when you run the git upgrade the first time, when it finishes it replaces the two fields yes yes with no no. Otherwise it is yours to keep. I wouldn't advise to skip the manual trigger of the script and let it run wild on its own, keep at least one part that for each loop you need to press enter, or y to continue.

Yes, it can be fun to some people once figuring it out, even with minimal script knowledge it can be fun. To relax sometimes instead of playing games I'd mess with vm installations and boot them. Eventually making my own minimal script (relevant to the wiki entry install from arch). The design of the installer in general is to provide interactive configuration, not do parallel network installations.

% sudo arch-chroot /mnt 66-tree -nE -S root2 test-tree
% sudo arch-chroot /mnt 66-enable -t test-tree ntpclient

this creates in the target a new Enabled tree named test-tree, which will only start after root2 tree has started, and then enables ntpclient in that tree. So your installation is ready to go to work at, after the install script runs.

With reference to 66, the diagnostic tools such as 66-intree 66-inservice when run into a chroot will give you confusing results, because they are looking really at what is running on the host not the target. If run from a system running systemd or runit or sinit, some common services may show an active pid, their log service will show 0 down, and other services will seem dead.
On a host running 66 with 100% identical trees and services it will show you a false positive picture, of everything being fine, when in fact it may not be.
You may see udevd in boot tree because most likely udevd is running on the host, the rest will seem down. Those tools are only useful for the system booting with s6/66 not a chroot.
All this hoopla about calamares being so great and pretty, all calamares does is copy the live/host system into a target partition, then use chroot scripts to rename user, set hostname, locale, tz, passwords, and once booted you are in the same old system.

Very safe for a distro to make sure everything is functional and boots well, because it is a very fixed model. So you download this month old 3GB fancy desktop image from their site, start calamares up, do an installation and then log into a month old system needing 1.5GB of upgrades, and in the meantime due to upgrades (like if qt or sddm did an upgrade) your system fails to reboot.

But calamares worked great, didin't it. The "warranty" is still valid, it booted once! Then it is all your fault.

Make a 3GB partition, and go to obarun jwm or base, and mount the target to /mnt, then run as root 
# cp -ax / /mnt
Get the oldest obarun iso you will find in archive, to do this. All you need to do is rerun syslinux afterwards on the target or grub.
Boot it, root pw toor oblive pw toor ...

That is all calamares does. Maybe Eric can add a console based video player and show rabbits chasing each other in the field while the installation is taking place, and that would make it a graphic installer.

Read the review by DW on archcraft today, then read the review by the same dodo-bird on Obarun, tell me how pissed off one should be.

OOhhh well!! Pay and play, don't pay and sit on the fence looking in. Who is free, those inside the fence or those out?
Awesome! Thank you, @ fungal_net. (<-- I keep wanting to drop the "_net." I am a lazy typist.)

I am sure that I will have further questions, but you have given me enough to move forward. I have been reviewing obarun-install file structure, package lists, etc. I had not started digging around Eric's shell code--not my area of expertise. It's neat!

Seeing how this if for my personal use not professional, I was looking for an alternative to authoring an Ansible playbook. I've used Ansible to apply technical standard implementation guides at work. It takes a surprising amount of time to author one from scratch. Time better spent documenting and goofing off. :)

and, thank you for warning me on the nuances of S6 and 66. I am sure that I would have gone down that rabbit hole at some point.
Copy a valid config from e.g. /var/lib/obarun/obarun-install/config/jwm to e.g. /var/lib/obarun/obarun-install/config/my_template.
So, now when you launch obarun-install your my_template will appear at number 3 of the main menu.

Details of the structure:
  • package_list directory: contents package to install. The file named base must exist and must be named base. But you can edit it and change whatever you want inside it. Each file contain one package per line. Comment with '# ' is allowed. All files except base can be deleted, changed or named as you want. You can obviously add your own file named as you want with the package to install that you want. Package can come from official repo or AUR. The installer will make the necessary in case of AUR package.
  • customizeChroot script: this script is launched at the end of the installation to configure your fresh installation. This means all package are installed, user has created, bootloader installed and so on. This is the very last instructions given to the installer. This is a bash script. You can edit as you want below the line marked 
    # ############################# only modify this script after this line # ###########################
    . Take the jwm (or other) customizeChroot script as example.
  • pacman.conf: this is the pacman.conf used by the installer. The installer do not take the one coming from the host but this one. So, you can add supplementary repo if you want or modify it as you want.
  • rootfs directory: This directory is copied as it on the fresh installation. Meaning any files/directory/.. (so elements) found with the same name on the fresh installation will be overwritten by the one found on this directory. For example the file rootfs/etc/sudoers will overwrite the file /etc/sudoers on your fresh installation. So, you can e.g configure the skeleton of the user used by the useradd command by editing the rootfs/etc/skel/ directory.
This is very simple but very efficient.
Thank you, Eric.

I will give that a try as soon as I work through the install challenges.

Where is the best forum section to post for guidance on packages citing systemd as a dependency? I strongly suspect it just needs an init script.

Powered by Obarun