Diskless Mode

In Diskless mode the entire operating system with all applications are first loaded into RAM and then only run from there. This is the method already used to boot the Alpine Linux iso installation images. Alpine Linux can be installed and configured so that the system continue to boot like this if "disk=none" is specified while running the setup-alpine script.

The mode is extremely fast and can save on unnecessary disk spin-ups, power, and wear. It is similar to what other linux distributions may call a "frugal" install or boot into with a "toram" option.

Custom configurations may be preserved or "persist" across reboots by using the Alpine local backup tool lbu. It enables committing and reverting local configuration system state by using .apkovl files that are saved to a "local backup" location and loaded when booting.

• If a writable partition is available, setup-alpine can be told to store the configs on that writable partition using lbu and the initial (and possibly read-only) installation media can remain the only boot device for the "diskless" system.

• If additional or updated packages have been added to the system, these may also be made available for automatic (re)installation during the boot phase without any (re)downloading, by enabling a local package cache on the writable storage.

• Using the setup-bootable script, it is also possible to create a customizable boot device i.e a writable filesystem by copying the boot system i.e read-only installation media to a writable partition (e.g. /dev/sdXY).

Installation

Following the Installation steps to complete the base configuration completes the pre-setup of "diskless" Alpine Linux system.

If a writable partition is available, setup-alpine can be told to store the configs and the package cache on that writable partition. Use the setup-lbu script to configure a "local backup" location for the diskless system, and lbu commit to then save the local configuration state. Later, another directory on that same partition or another available partition may also be mounted as /home, or for example, for selected important applications to keep their run-time and user data on it. Refer Saving and loading ISO image customizations related to loading an .apkovl volume from system partitions.

As per Bug: #10473 Storing local configs and the package cache on internal disks requires manual steps to have the partition listed, i.e. making a /etc/fstab entry, mountpoint, and mount, *before* running setup-alpine. The linked workaround also still requires to commit these configurations to disk manually before rebooting.

As per Bug: #11589. The APKOVL loading of diskless setups doesn't work on btrfs and xfs filesystems, or nvme-based devices => So, for the moment, use only ext4 filesystem partitions on classic drives to store diskless mode states.

Note: mkfs.ext4 creates ext4 fs with 64bit feature enabled by default, but extlinux may not be able to boot with that, see Issue #14895. You may need to add "-O ^has_journal,^64bit" to mkfs.ext4 to circumvent this.

• The following creates an ext4 partition with disabled journaling, to reduce write operations and allow the disk to spin down after the .apkovl and the packages have been read from the partition during the boot.

# mkfs.ext4 -O ^has_journal /dev/sdXY   # the "-O ^has_journal" DISABLES journaling ("^" means "not")

In the above case, the initial read-only installation media may remain the boot device of the newly configured local "diskless" system. It is also possible to copy the boot system to a partition (e.g. /dev/sdXY) with setup-bootable script and create a customizable boot device.

Saving and loading ISO image customizations

Besides supporting a boot parameter to load customizations from a web server, Alpine's "diskless mode" ISO images try to load an .apkovl volume from system partitions. It is therefore possible to save customized running states to a .apkovl file on a writable partition, and have these automatically loaded when booting the ISO image.

Note: When the machine reboots, the remote repositories will not be available until after networking has started. That means packages newer than on your local boot media would not be available after a reboot, unless they were made to persistent, by having a local package cache available on a local, writable, storage device.

The local package cache, which enables additional and updated packages to automatically be copied into RAM during boot, may be stored on the same partition as the .apkovl file.

To use partitions on internal disks, however, you need to prepare a specific /etc/fstab entry manually, and save the configuration, as follows (setup-alpine does not list them for saving configs or package cache):

1. Boot the diskless system from ISO (as shown at Installation)
2. If necessary, create and format a partition as explained in "Setting up disks manually, for diskless and data disk mode installs". For the examples we will use /dev/sdXY

• Bug: Initramfs-init does not respect apkovl device fstab entry, so the partition can not be mounted to /boot. The workaround given there does not seem to work (e.g. mkdir -p /boot/ovl_dev/cache ; touch /boot/ovl_dev/cache/.boot_repository)
  

=> Alternative: Configure the /etc/fstab to mount the writable partition to /media/sdXY instead of /boot (i.e. conforming to the hot/cold-plug mountpoints):
3. mkdir /media/sdXY
4. echo "/dev/sdXY /media/sdXY ext4 noatime,ro 0 0" >> /etc/fstab
(Mounting read-only is possible, because the tools temporarily remount it writable for their operation.)
5. Use mount -a to load the partitions listed in /etc/fstab. Look at the output of mount to verify that the /etc/fstab changes have been applied correctly.
6. If setup-alpine has not run before, it may be used and should now enable you to choose the partition for saving the local configs and package cache. (If asked, there is no need to first unmount the partition, that would only be needed to allow installing on its parent disk.)
If setup-alpine has already been used to configure the diskless system, the storage settings may be modified directly with setup-lbu sdXY and mkdir /media/sdXY/cache ; setup-apkcache /media/sdXY/cache
7. If the partition is large enough, it can be useful to edit lbu.conf to uncomment and set BACKUP_LIMIT=3. For example, to allow reverting to a previous, working state if needed.

# apk add nano # nano /etc/lbu/lbu.conf

8. Finally, generate the first .apkovl file containing all the previous changes by executing lbu commit, so the customizations that were just made will persist a reboot.

From then on, whenever packages are installed or newly configured, and the changes should be kept, execute lbu commit again.

Notes:

• For a virtual machine, the QEMU example shows how an ISO image can automatically boot with .apkovl customizations.
• The Include special files section explains how to include custom files outside of /etc in the .apkovl file.
• Alpine Linux package management#Local Cache covers managing a local package cache.
  • The packages get listed in /etc/apk/world which gets saved with the lbu, for them to be automatically installed when the live system boots.
• It's possible to load an APKOVL file from a webserver, by supplying a custom url with the APKOVL kernel boot parameter.
  • If you don't have a web server you can run busybox's httpd temporarily to serve an .apkovl - busybox httpd -p 127.0.0.1:80.
• To customize the boot sequence further, one may refer to PXE boot#Specifying an apkovl and How to make a custom ISO image with mkimage.