Running alpine in memory with data mode

Local testing

To make testing easier, we can use qemu, which will allow us to test the configuration before going for the real machine. For this setup we will be using two disks: one for mounting the /var folder and another for storing lbu files (more on that later). To create the two images with qemu run:

qemu-img create -f qcow2 var.cow2 10G
qemu-img create -f qcow2 media.cow2 5G

Those images have arbitrary sizes and probably we won’t even required that much for this setup so feel free to choose pick whatever size you want.

Once we have created the images, go to alpine download page1 and grab the latest virtual image.

We all of that we can now start the virtual machine, run:

qemu-system-x86_64 \
    -machine accel=kvm \
    -display gtk \
    -m 2048 \
    -boot d \
    -cdrom alpine-virt-3.17.3-x86_64.iso \
    -drive file=var.cow2,if=virtio \
    -drive file=media.cow2,if=virtio

For more info about what are those parameters head to qemu documentation2. Just make sure to add -boot d option which will force cdrom to boot first (more on that later).

Setting up environment

Before we can run setup-alpine we need to mount a persistent media folder so it can be used by lbu to store backup files. To do so we need to install some extra package that are not available in the live ISO.

First we need to connect to internet. Run setup-interfaces to configure interfaces, default values will do. After that start the networking service rc-service networking start. Now we should have internet. After that we need to setup a repository. You could edit /etc/apk/repositories directly but there is handy command that does that already setup-apkrepos. Run it and pick any option you see fit. I’d go for f but 1 also works.

Now we can install some packages required for the remaining of the setup:

apk add lsbkl e2fsprogs

lsblk is useful to identify devices and e2fsprogs will provide ext4 support.

Run lsblk and will display the device we attached, e.g.:

vda     253:0   0   10G     0   disk
vdb     253:0   0    5G     0   disk

Now let’s format and mount vdb on /media.

# formatting using ext4
mkfs.ext4 /dev/vdb

# creating target folder for mouting
# the name is arbitrary, feel free to choose another one
mkdir /media/vdb

# mouting 
mount -t ext4 /dev/vdb /media/vdb

To confirm if device is mounted you can run df -h /media/vdb, and it should show the size and which device is mounted on that folder.

Setting up alpine on data mode

Now we can run setup-alpine. Choose whatever options fits your need until up to the point where it asks to choose a device.

When it asks to choose a disks to use enter the name of the data disk, which, in this particularly setup, is vda. Then it will ask to choose how you would like to run alpine3, pick data.

Now it will prompt to choose which media device we want to use for storing lbu files. By default it should the media folder we mounted in the previous step, if not just enter vdb. Then select place for cache, default is fine.

The cache folder is also used to store the apk files we come to add. Since it does not have internet access when booting it needs to store those extra package in folder so later it can be restored.

Warning, do not reboot now. We need to use lbu to make a backup of all changes we did, otherwise everything will be lost on reboot. Take a careful read on the lbu documentation4, it will provide the necessary information to understand how lbu works.

Run lbu commit to backup it. You can check the apkvol file stored in the /media/vdb/. Now that we have saved our changes, we are good to reboot.

The initramfs of the live ISO will look for apkvol files and try to restore it and that is why cdroom is required to be the first thing to boot.

We can also notice that there is no boot info stored anywhere else. One device is used to store the lbu files and the other one is used ,later after boot, to mount /var, so the live iso is required.

You can check here5 how that is possible and here 6 how we can expand that idea and netboot using the apkvol to boot any machine to specific state.

Making changes

After rebooting your system, you can log into your fresh installation. You can then install a new package, such as vim, using the command apk add vim. However, if you reboot the system again, the vim package will be lost and you will need to reinstall it again after boot.

If you run lbu status will show what was changed and in this case /etc/apk/world. The world file store all the package you have installed and since you have added a new packaged it has been modified. lbu commit to persist it.

You can check the /media/vdb/cache folder to see that it has stored the vim package and its dependencies.

Why /var?

The /var folder contains files that are not critical to the basic operation of the system, but are instead used for tasks such as logging, spooling, and caching. For example postgresql store all its data on the var folder, and by mouting the var folder into a persistent file system it allows us to use a database os running on a tmpfs and still have its data persistent between boots.

In conclusion

We can take advantage of speed boost provided by tmpfs, and we can still restore the system state even if the computer is rebooted. The only thing to keep in mind is to commit any changes made before rebooting ;).