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

# 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:

```bash 
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 page[^1] and grab the
latest virtual image.

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

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

```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`, 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 alpine[^3], 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` 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 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 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 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  ;).

[^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/