fwcd / archlinuxarm-images Goto Github PK

To prevent the artifacts from expiring.

The service should grow the partition, use resize2fs and finally disable itself from within the script.

The fstab in the Pi 4 images still seem to contain mmc0...

To make the analog audio device available to ALSA on Raspberry Pis, the following line has to be added to the top of /boot/config.txt (the order matters!):

dtparam=audio=on

See https://forums.raspberrypi.com/viewtopic.php?t=316709

Perhaps create a commit that pins the date?

There still seem to be some issues with the mainline kernel + U-Boot, therefore it would be nice to have ready-to-use images that use the Pi Foundation's kernel and bootloader.

See https://forum.endeavouros.com/t/custom-kernels-on-raspi-4/39059/3, we'd need to do something along these lines in a script:

pacman -R --noconfirm linux-aarch64 uboot-raspberrypi
pacman -Syu --noconfirm --needed linux-rpi raspberrypi-bootloader raspberrypi-firmware
cp /boot/config.txt /boot/config.txt.orig
cp /home/alarm/configs/rpi4-config.txt /boot/config.txt

With slight modifications for booting and a conversion to qcow2, we might be able to generate QEMU/UTM images directly: https://gist.github.com/thalamus/561d028ff5b66310fac1224f3d023c12

mixxx-pi-gen is a cool project that uses a modified Raspbian image for Mixxx. It would be interesting to see, if we could build something similar on top of Arch Linux using the existing setup script infrastructure in this repo.

Similar to how this script does it: https://github.com/Drewsif/PiShrink/blob/master/pishrink.sh

This will produce both smaller and more compressible images.

If the date changes during a CI build (e.g. because the workflow starts before midnight and ends after), it will fail as evidenced e.g. by https://github.com/fwcd/archlinuxarm-images/actions/runs/6017874327/job/16324990053.

To fix this, we should output the date once in a stage and then reference it instead of recomputing it on-the-fly.

This would allow us to properly perform package installations etc. from GitHub's x86_64 runners within a chroot jail.

We should probably be able to reuse large parts of the existing workflows. The images could be deployed via GHCR.