Mail archive

Re: [alpine-devel] PXE boot of Alpine Linux

From: Hugo Landau <>
Date: Thu, 25 Apr 2013 17:09:51 +0100

Alpine does not support root=/dev/nfs or nfsroot.

However, I recently submitted a patch to enable Alpine to PXE boot and
run from RAM. You can find this patch here:, but
it should eventually go into Alpine itself. The patch is for the init
script placed into the initrd by mkinitfs.

You must configure mkinitfs to include appropriate files in the initrd.
Create the following files:

/etc/mkinitfs/modules.d/nfs, containing:

/etc/mkinitfs/modules.d/ethernet, containing:
     (you can make this more specific if you know what NICs you'll
      be using)
     (required for udhcpc to work)

/etc/mkinitfs/files.d/dhcp, containing:

Finally add nfs, ethernet and dhcp to the list of features in
/etc/mkinitfs/mkinitfs.conf and run mkinitfs to regenerate the initrd.
This new init script is compatible with ordinary "sys" booting, so you
can use it for both PXE and MBR boot. Just copy /boot/initramfs-grsec to
whereever you need it for PXE.

You will want to boot with something like
   alpine_dev=nfs: ip=dhcp

However, do note that this does not result in an NFS *root*. The
alpine_dev parameter is used to provide a filesystem to the run-from-RAM
init script code path, similar to a LiveCD boot. Currently this is used
to locate a squashfs file containing extra kernel modules and a
repository of apks. Copying from an Alpine CD would be a good start
here. You need the ".boot_repository" indicator file and so on in order
for it to autodetect the repository. Alternatively, specify the
alpine_repo argument (e.g.
alpine_repo= Whatever you
specify will be placed in /etc/apk/repositories.

This patch only modifies the init script. There are still some things
that need to be cleaned up, e.g. with post-initrd init scripts such as
modloop. I'm fairly sure that modloop should correctly detect a squashfs
image located on an alpine_dev nfs share just like it would on a LiveCD,
though I haven't tested this. (Eventually I'll patch it to support
kernel modules simply sitting on an NFS share.) You might need to
specify modules=loop,squashfs. At any rate, you should be able to boot
to a login prompt.

ovl_dev has also been modified to accept an HTTP URL. As a convenience,
{MAC} and {UUID} will be substituted with the MAC address of the boot
interface and the machine's SMBIOS UUID automatically. e.g.
You can use this to generate an apkovl dynamically, if you wish. The
quotes are essential.

(If you wanted to discriminate by machine earlier in the boot process,
you might be interested to know that gpxe, which can be used instead of
PXE linux, is also capable of doing this MAC and UUID substitution, and
can load and boot kernels from an HTTP server, too. If you have any
inexplicable network issues with gpxe, you may want to try selecting the
"undionly" driver, especially if using the online binary generator,
which is possibly buggy.)

If you're new to Alpine, an apkovl is basically a "overlay" tar.gz file
containing all system files which have been changed from the package
default. You can create one using "lbu". The list of packages installed
on a system is canonically represented in /etc/apk/world, and any
packages specified in /etc/apk/world in an apkovl will be installed
automatically by the init script.

Keep in mind that the contents of /etc/fstab in an apkovl provided via
ovl_dev should be honoured, if you want to mount any extra NFS shares.

This PXE boot support is completely new, so I'd be very interested to
hear how you get on. In some ways a run-from-RAM arrangement might be
superior to a NFS root since this reduces network reliance. Currently
alpine_dev is still needed, and required to be a filesystem, for
purposes of loading kernel modules (which, due to hotplugging, can
potentially happen at any time). At some point I will probably work on a
way to cache a squashfs image locally to remove this NFS requirement. If
having an NFS -root- is absolutely vital, I'd be interested to hear your
use case and reasoning. Appropriate further changes to the init script
could probably be made to enable such functionality if it were needed.

Hugo Landau

On 20130424 1550, Richard Johnson wrote:
> Hi,
> I want to setup a PXE boot server offering customized alpine linux
> images. Initially I used 'setup-alpine' to configure alpine linux to
> boot from my external hard drive. Now I have copied the contents of the
> external hard drive on a debian server which acts as a PXE server. I am
> using syslinux to boot alpine using the following boot description:
> KERNEL linux/alpine/boot/mboot.c32
> APPEND linux/alpine/boot/xen.gz dom0_mem=256M ---
> linux/alpine/boot/vmlinuz-3.6.11-grsec --- linux/alpine/boot/grsec.gz
> root=/dev/nfs rw rootfstype=nfs nfsroot=
> Where "linux/alpine/" is the relative folder where I have copied alpine
> on the debian server and "" is the IP of the debian server.
> Now, the PXE starts with booting xen.gz, vmlinuz-3.6.11-grsec and grsec
> successfully, however it then complains with the error:
> cp: can't stat '/media//.alpine-release': No such file or directory
> /sbin/init not found in new root. Launching emergency recovery shell
> Type exit to continue boot.
> sh: can't access tty; job control turned off
> I have attached a photo of the boot logs. Sorry for the bad image
> quality, I could not take a snapshot. I suspect that the boot parameters
> might not be completely correct. Does anyone have a working solution for
> booting alpine linux using PXE?
> Regards

Received on Thu Apr 25 2013 - 17:09:51 UTC