We would like to make an automated installer for Alpine Linux for running our own application on an embedded x86 pc. Our application setup requires packages not present on the downloadable media and we need it to run self-contained and offline. I have implemented the functionality we need, but that requires "main" and "community" repositories present on the USB-stick.

I have solved this so far by burning the ISO-image to the USB-stick using Rufus in ISO mode (making it writable) and then essentially rsync'ing a mirror to the USB-stick (to /media/usb/alpine) and manually adding this directory to /etc/apk/repositories as needed. This works well.

Unfortunaly this is an almost 20 GB download meaning that the manual step to copy to the USB-stick takes a very long time on the USB-sticks I have available right now (2 hours at the moment). A SSD USB-disk takes about 20 minutes.

I have therefore been looking at setup-apkcache and found that we only need less than 100 MB of packages, but that it appears from my experiments that setup-disk installing to the local harddisk in "sys"-mode (which runs lbu package - under the covers) does not use the packages in the cache, but expects all packages to be found from one of the repositories listed in /etc/apk/repositories.

Is using a apk cache the way to go? Or am I barking up the wrong tree?

1 Answer 1


For future reference I ended up in a situation where we had to recompile Qt5 without SSE and with TSLIB so I forked the Alpine Linux aports repository and made our local branch off the 3.14-stable branch to rebuild the packages in a docker image.

It turned out that this docker image was well suited for building an ISO as well. By creating a new profile as scripts/mkimg.XXX.sh adapting profile_extended and adding additional packages to $apks as needed we could have Gitlab build a new ISO in a few minutes with our revised packages using a frozen internal mirror of an official package repository, and store it as an artifact. That resulted in a 620 MB ISO which could be burned fast enough for our purposes.

Had we had more time, I would have created our custom payload as an Alpine Linux package depending on the packages we needed so we only needed that package added in the build script and the dependencies transparently pulled in. Also we could have benefitted from having a PXE netboot version as well during development. Next time...

EDIT: The Alpine Technical Steering Committee decided in January 2022 to "continue with i586 as a best effort, specify that a platform must actually implement i586 correctly to be supported (e.g. no Vortex86), and some packages may require i686 if upstreams only support i686 (e.g. those with JITs).". For our particular usage that meant that we needed to continue using a separate compilation tree.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .