Alpine Linux on a laptop

Ossola 2023

Introduction

In “Review of Alpine Linux” we tried the distribution Alpine Linux on a virtual machine in VirtualBox. The positive experience motivated me to try on two different laptops:

an Acer Swift 3, with Slackware Linux as my main OS
a Lenovo Thinkpad with Secure Boot enabled and a running Fedora Linux

The first one can be considered a generic laptop, the second one is a more challenging case since, in general, it requires extra steps.

Install Alpine Linux

My experience so far is that the official installation process[2] only works on VMs, but you can give it a try. I have described my tests in the section “The official way”. If you are only interested in a working method you can skip it and go directly to section “The way that works”.

The official way

Let’s start by downloading the Alpine Linux installer image. We have a good choice of ISO images from the download page [1]. My Acer Swift 3 is a traditional AMD64 architecture so I need to choose an x86_64 image. From the list of the available options we exclude the “Raspberry Pi” and “Generic U-Boot” because they support different architectures. We also exclude “Xen”, “Virtual” and “Mini root filesystem” because they are meant for specific use cases different from ours.

You are free to choose anyone between “Standard”, “Extended” and “Netboot”. The choice is more about your personal taste. Everyone should work. Since I like minimalism, I always opt for the “Netboot” when it’s available. Be aware that it contains the bare minimum to bootstrap the OS and then you have to connect to the internet to proceed with the installation. This can be an easy step if you know how to do it, but can be challenging if the firmware of your Wi-Fi card is not in the netboot image or if you don’t know what to do when you try to use dhcpcd or dhclient and you find out that an unknown udhcp is the only command you have.

With my surprise the “Netboot” image is bigger than the “Standard”. This is because they do not follow the same naming convention of the other distros, where “netboot” is synonym of “minimum content, just the required to boot, connect to the network and run the installation from it”. In Alpine’s case it means “standard image plus extra modules for comprehensive network support”.

I started from the “Standard” image and eventually I tried also the other two with the same unfortunate result: it doesn’t boot.

The official documentation[2] says to disable Secure Boot and mine is disabled since I don’t like it, however they say to burn the ISO image on a pen drive and boot from it. I usually find quicker to load the kernel and the initrd from a folder where I previously extracted the content of the ISO image (see Quest for the Live distro continues for details) or use the new Grub 2 feature that allow to load them directly from the ISO image. Now, since my problem was a black screen after the bootloader, I suspected a kernel panic. I got this behavior consistently with all the three images. If my guess is correct, booting from the pen drive will not work as well, but just to say “I did everything according to the documentation”, I tried and failed also this way.

Is this the end of our experiment? Does it mean Alpine is great in containers and VMs, but not on the bare metal?

I was not in the mood of giving up and also I had another tool in my arsenal that proved to be far more useful than I thought.

If you are an affectionate reader of this blog, you know what I am talking about: using the kernel from another distro ;)

The way that works

If my assumption is correct and it is a kernel issue, I need a quick test to prove it. I have a running Slackware 15, so let’s try to combine the “huge” kernel with the Alpine installer.

When I say “huge” I am referring to a specific kernel that Slackware folks have built trying to integrate the most common drivers to be sure they are able to boot on the most common machines[3].

To run my test:

I have extracted /boot/initramfs from the “Standard” ISO image of Alpine.
I have found the kernel /boot/vmlinuz-huge-5.15.19 on my local filesystem (you can download and extract it from the package kernel-huge-5.15.19-x86_64-2.txz that you can find on a Slackware mirror like slackware.uk or slackware.nl).
I created a folder on my filesystem where I have put both the extracted initramfs and the kernel vmlinuz-huge-5.15.19
I have added a new entry in Grub to boot Slackware “huge” kernel with Alpine’s installer initramfs.

After the reboot, I was glad to see a shell prompt and this prove my assumption to be correct.

A few comments before proceeding:

my test was good to check if my solution works, but I cannot proceed with the installation without fixing more stuff (for example the installer expects a folder with local copy of packages or we might need additional modules and firmware to connect to the network).
The idea of using a different kernel works both with and without Secure Boot active. On my Acer Swift 3 (Secure Boot disabled) I ended up using the Slackware kernel, on the Lenovo Thinkpad (Secure Boot active) I had to use Fedora’s kernel which works out of the box (see this article for details).

There are three ways to proceed at this point:

fixing the installer using a different kernel and adding some of its modules to the initramfs - it might require more hacking.
extracting in a folder the content of the initramfs from a running Linux (use a live edition if you don’t have one already installed - use Fedora or Ubuntu if Secure Boot is enabled). Then chroot in the folder and execute the install scripts - be careful that the installer does not try to mess with your bootloader without asking.
mounting the hard drive partition where we want to install Alpine and run an installation using apk to create a chroot environment.

The difference between the last two options is that the former try to emulate the environment that the system is in when the laptop is bootstrapped from the installer ISO image, the latter would be the exact same process used to create the filesystem for a base docker image or a chroot environment that is supposed to live in a folder.

For all the three options, at the end of the installation remember to remove the Alpine kernel, if present, and manually copy the one from the current OS (plus its modules and firmware).

For options 2 and 3, don’t forget to configure the bootloader after the installation.

The following commands are a hint for whoever decide to try the Option 1:

# find where the installer expect to find the local packages
cat /etc/apk/repositories

# in my case apk packages are in /media/usb/apks/x86_64/

# read the install script and the invoked ones
less /usr/sbin/setup-alpine

I find solution 3 to be the more elegant. I also like that I have full control and I rely less on “cross-your-finger-and-hope” method.

The procedure at a high level is the same that we followed for Slackware here, but in this case we are luckier because the chroot installation for Alpine is documented in its Wiki [5]. Therefore, this is the script I came out with:

#!/bin/bash

# Assume the target partition is formatted with ext4 and mounted in
# the folder ./fed2

chroot_dir=fed2

wget https://dl-cdn.alpinelinux.org/alpine/v3.21/main/x86_64/apk-tools-static-2.14.6-r3.apk
cat apk-tools-static-2.14.6-r3.apk | tar zx sbin/apk.static
mv sbin/apk.static .

./apk.static -X https://dl-cdn.alpinelinux.org/alpine/v3.21/main \
    -U --allow-untrusted -p ./${chroot_dir} --initdb \
    add alpine-base

mknod -m 666 ${chroot_dir}/dev/full c 1 7
mknod -m 666 ${chroot_dir}/dev/ptmx c 5 2
mknod -m 644 ${chroot_dir}/dev/random c 1 8
mknod -m 644 ${chroot_dir}/dev/urandom c 1 9
mknod -m 666 ${chroot_dir}/dev/zero c 1 5
mknod -m 666 ${chroot_dir}/dev/tty c 5 0

echo https://dl-cdn.alpinelinux.org/alpine/v3.21/main      >  ${chroot_dir}/etc/apk/repositories
echo https://dl-cdn.alpinelinux.org/alpine/v3.21/community >  ${chroot_dir}/etc/apk/repositories

echo 'LABEL=fed2      /               ext4    rw,relatime     0 1' > ${chroot_dir}/etc/fstab

mkdir -p ${chroot_dir}/boot
cp /boot/vmlinuz ${chroot_dir}/boot
cp -r /lib/modules /lib/firmware/ ${chroot_dir}/lib/
lsmod | awk '{print $1}'|tail -n +2 >> ${chroot_dir}/etc/modules

touch ${chroot_dir}/root/firstconfig.sh
chmod a+x ${chroot_dir}/root/firstconfig.sh
cat <<"EOF" > ${chroot_dir}/root/firstconfig.sh
#!/bin/sh

export PATH=/bin:/sbin:/usr/bin:/usr/sbin:$PATH

rc-update add devfs sysinit
rc-update add dmesg sysinit
rc-update add mdev sysinit
rc-update add hwclock boot
rc-update add modules boot
rc-update add sysctl boot
rc-update add hostname boot
rc-update add bootmisc boot
rc-update add syslog boot
rc-update add mount-ro shutdown
rc-update add killprocs shutdown
rc-update add savecache shutdown

apk update
apk add mkinitfs wpa_supplicant
mkinitfs
EOF

mount -o bind /dev ${chroot_dir}/dev
mount -t proc none ${chroot_dir}/proc
mount -o bind /sys ${chroot_dir}/sys

# chroot ${chroot_dir} /bin/ash -l
chroot ${chroot_dir} /root/firstconfig.sh

umount ${chroot_dir}/dev ${chroot_dir}/proc ${chroot_dir}/sys

echo "Please configure the bootloader and restart the system"

Check this article to configure the bootloader.

Funny enough the same issue with the audio card found when we tested the combination Slackware Linux + Fedora kernel on the same laptop is present also here. After a while I had some time to investigate on the issue and I eventually found a solution. Check “Fixes for mixing the kernel and userland from different distributions” for details.

Conclusions

It was not straightforward, but eventually we were able to install successfully Alpine Linux on two laptops: one traditionally configured without the hassle that comes with Secure Boot, the other with Secure Boot active.

In “Install Slackware in a chroot from any distro” we successfully tested for the first time the idea of running a Linux distribution with the kernel (and associated resources) from another one. We saw how this idea can be very useful also in this article.