---
title: "Running alpine in memory with data mode"
date: 2023-04-30
tags: ['alpine', 'linux']
---

# Local testing

To facilitate iteration and testing of this setup, we can use `qemu` and for the
whole 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,
follow these steps:

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

Those images have arbitrary sizes and probably won't even required that much for
this setup so feel free to choose another size. 

Once you have created the images go to alpine download page[^1] and grab the
latest virtual image.

We all of that we can now start the virtual machine 

```bash
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` documentation[^2].
Just pay attention to the `-boot d` option which will force cdrom to boot first
(more on that later as well).

# Setting up environment

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

Run `setup-interfaces` to configure interfaces. The default values will do.
After that start the networking service `rc-service networking start`. Now we
have internet we can setup a repository. You could edit `/etc/apk/repositories`
directly but there is handy command for 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:

```bash
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.:

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

Now let's format and mount `vdb` on `/media`.

```bash
# 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`, it shows 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 up to the
point where it asks to choose the device. It may repeat some of the step we
already did but it is be fine.

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

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

The cache folder is 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. Take a careful read of the
`lbu` documentation[^4], 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 you changes as saved and you are good to reboot.

The live ISO will look for `apkvol` files and try to restore it. That is why it
is required the ISO to be the first to boot. There is no boot info store
anywhere else since the one device is used to store `lbu` and the other one is
mount on `/var` so we use live ISO to boot and restore the state.

You can check here[^5] 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 now 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.

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 is a directory in Linux that is used to store variable data
files as the contents of this folder can change by the OS. This 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 allowing us to use a database on
data mode 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  ;).

[^1]: https://alpinelinux.org/downloads/
[^2]: https://www.qemu.org/docs/master/system/invocation.html
[^3]: https://wiki.alpinelinux.org/wiki/Installation
[^4]: https://wiki.alpinelinux.org/wiki/Alpine_local_backup
[^5]: https://bitfehler.srht.site/posts/2022-11-28_messing-with-your-initramfs---alpine-edition.html
[^6]: https://www.apalrd.net/posts/2022/alpine_pxe/