Saved searches
Use saved searches to filter your results more quickly
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Building and Testing
Clone this wiki locally
Below are a set of quick instructions to build your own ISO.
The best thing you can do, is follow the official documentation for archiso on Arch Linux Wiki.
But the gist is this:
# mkdir -p ./archiso # cd ./archiso # cp -r /usr/share/archiso/configs/releng/* ./ Step 2: Add packages to packages.x86_64
git python python-setuptools While standing in the archiso folder, clone using:
# git clone https://github.com/Torxed/archinstall airootfs/root/archinstall-git Step 4: Create a skel .zprofile for autolaunch
While standing in the archiso folder, create and add the following:
# cat <<\EOF >> ./airootfs/root/.zprofile [[ -z $DISPLAY && $XDG_VTNR -eq 1 ]] && sh -c "cd /root/archinstall-git; git config --global pull.rebase false; git pull; cp examples/guided.py ./; python guided.py" EOF This will auto-run when the ISO boots.
It will perform four simple tasks every login on tty1:
- Enter the archinstall-git folder
- git config and git pull each time
- copy guided.py into the root git folder due to how the import works in Python
- Finally it will run the latest version of guided.py
This makes it easy to test the latest version, by simply logging out and back in — and the four steps will get repeated.
No need to reboot or re-build.
Archiso has great information and the latest info. But in general, all you need to do (standing in the arciso folder), is to run:
And that should produce your ISO.
For a simple script that builds, boots and does all this automatically.
The following convenience script is provided. Simply run ./test.sh .
#!/bin/bash if [ -z "$1" ] then echo "Need to define a output folder for the archiso:" echo "Example (build and run):" echo " ./test.sh ./archiso true" echo "Example (skip building and run ISO as given path):" echo " ./test.sh ./archiso" exit 1 fi REPO="https://github.com/Torxed/archinstall.git" ARCHISO_FOLDER=$1 REBUILD=$2 BRANCH="master" if [ $REBUILD ] then echo "Making a clean build!" `rm -rf "$ " 2>/dev/null` || ( echo "Could not delete protected folder:"; echo "-> $ "; echo "Running as sudo."; sudo rm -rf "$ " ) mkdir -p "$ " cp -r /usr/share/archiso/configs/releng/* "$ /" git clone "$ " "$ /airootfs/root/archinstall-git" (cd "$ /airootfs/root/archinstall-git"; git checkout "$ " ) echo "git" >> "$ /packages.x86_64" echo "python" >> "$ /packages.x86_64" echo "python-setuptools" >> "$ /packages.x86_64" cat \EOF >> "$ /airootfs/root/.zprofile" [[ -z $DISPLAY && $XDG_VTNR -eq 1 ]] && sh -c "cd /root/archinstall-git; git config --global pull.rebase false; git pull; cp examples/guided.py ./; python guided.py" EOF ( cd "$ /"; sudo mkarchiso -v -w work/ -o out/ ./; ) fi if [ ! -f "./test.qcow2" ]; then qemu-img create -f qcow2 ./test.qcow2 15G fi sudo qemu-system-x86_64 \ -cpu host \ -enable-kvm \ -machine q35,accel=kvm \ -device intel-iommu \ -m 8192 \ -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd \ -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_VARS.fd \ -device virtio-scsi-pci,bus=pcie.0,id=scsi0 \ -device scsi-hd,drive=hdd0,bus=scsi0.0,id=scsi0.0,bootindex=2 \ -drive file=./test.qcow2,if=none,format=qcow2,discard=unmap,aio=native,cache=none,id=hdd0 \ -device virtio-scsi-pci,bus=pcie.0,id=scsi1 \ -device scsi-cd,drive=cdrom0,bus=scsi1.0,bootindex=1 \ -drive file=$(ls -t $ARCHISO_FOLDER/out/*.iso | head -n 1),media=cdrom,if=none,format=raw,cache=none,id=cdrom0
Modify BRANCH to suit your needs.
Tests for the Arch Linux infrastructure
The Arch Linux DevOps team uses a combination of Ansible and Terraform to manage their hosts. If you want to have a look on their infrastructure repository, you can do so via this link: https://git.archlinux.org/infrastructure.git/tree/
The combination of Ansible and Terraform works quite well for Arch Linux, the only subject we are missing is proper testing. I want to present a small proof of concept on how we could do tests in the future. My approach uses molecule for testing. Molecule utilizes Vagrant and Docker for running the Ansible Playbooks.
Arch Linux provides images for both of them, since quite a while now. These projects are called Arch-Boxes and Archlinux-Docker. Therefore it makes sense to reuse them infrastructure tests.
The actual tests are written in Python with support of the library testinfra.
First of all we need to install the dependencies. You can find most of our needed tools in our repositories:
- ansible
- python-pip
- python
- flake8
- ansible-lint
- docker
- vagrant
What we are missing right now is molecule. We can install molecule with the vagrant dependencies via pip install molecule[vagrant] —user . Pip will install all needed packages to our $HOME.
So let us pick a first role we want to test:
❯ ls -la drwxr-xr-x - chris 15 Dec 2019 handlers drwxr-xr-x - chris 15 Dec 2019 tasks drwxr-xr-x - chris 15 Dec 2019 templates We can initialize a molecule test scenario on an already existing Ansible role via molecule init scenario —role-name sshd —driver-name vagrant . The command is going to create a molecule directory for us. The created directory will have this structure:
❯ tree molecule molecule └── default ├── INSTALL.rst ├── molecule.yml ├── playbook.yml ├── prepare.yml └── tests ├── __pycache__ │ ├── test_default.cpython-38-pytest-5.3.5.pyc │ └── test_default.cpython-38.pyc └── test_default.py The interesting files we will have a look at are molecule.yml , prepare.yml and test_default.py . In molecule.yml we configure basic molecule behavior. In prepare.yml we can do first preparations with Ansible (we need to do this, because Arch Linux is slightly different to distributions the molecule team normally uses). test_default.py stores our tests as testinfra functions.
The molecule.yml shouldn’t be so different for Arch Linux to the one that is usually generated by molecule, but let me highlight the changes:
--- galaxy vagrant virtualbox yamllint - instance archlinux/archlinux ansible ansible-lint testinfra flake8 prepare.yml includes some magic, regarding mirror setup, installing python and a fresh restart. We need this mirror setup tasks, because we are just enabling all mirrors in our Arch Linux Vagrant box right now. This leads to slow mirrors. I am going to fix this in a new Arch-Boxes release. For now I just set static mirrors from which I know that they are fast for my location. In the second prepare.yml task we need to install python for Ansible. Consider that I use pacman -Syu here, because I want a full system upgrade, everything else will lead us into trouble when playing around with kernel modules (Arch Linux provides still no nice way to use kernel modules when you’ve installed a new kernel). Due to the full system upgrade, we need to reboot for making sure that we boot into the new kernel. --- > /etc/pacman.d/mirrorlist - Install python for Ansible test -e /usr/bin/python || (pacman -Syu --noconfirm python) - Reboot for kernel updates The last important file is test_default.py . test_default.py stores our unit tests for the Ansible roles. Right now I am just checking for an installed openssh package and a running and enabled sshd daemon. The usage of testinfra should be self-explanatory, however I didn’t make experience with more complex tasks like comparing templates yet. I can imagine that this will become very tedious for us. The future will show if the usage of testinfra suits our demands. If not we either use a different library or we need to stay with Ansible and YAML linting + tests on clean VMs or Docker containers. Both of them would be already far better than the current situation with no tests at all. For running our tests we can trigger molecule test from inside of our sshd role directory. I haven’t played around with molecule converge yet, but I guess this is the command you would use for local Ansible development. molecule test will trigger a clean environment on every test (destroying the VM snapshot etc). This is pretty cost intensive and takes time.
If you are interested in this work, you can follow my branch on github: