1

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

Hugo Landau
Details
Message ID
<5179554F.3040804@devever.net>
Sender timestamp
1366906191
DKIM signature
missing
Download raw message
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: http://sprunge.us/TYHc, 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:
   kernel/fs/nfs/*
   kernel/fs/lockd/*
   kernel/net/sunrpc/*

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

/etc/mkinitfs/files.d/dhcp, containing:
   usr/share/udhcpc/default.script

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:192.168.0.52:/tftpboot/linux/alpine 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=http://nl.alpinelinux.org/alpine/v2.5/). 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.
   ovl_dev="http://.../generate-apkovl.cgi?mac={MAC}&uuid={UUID}"
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=192.168.0.52:/tftpboot/linux/alpine/
>
> Where "linux/alpine/" is the relative folder where I have copied alpine
> on the debian server and "192.168.0.52" 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



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Natanael Copa
Details
Message ID
<20130502120136.6c1be108@ncopa-desktop.alpinelinux.org>
In-Reply-To
<5179554F.3040804@devever.net> (view parent)
Sender timestamp
1367488896
DKIM signature
missing
Download raw message
On Thu, 25 Apr 2013 17:09:51 +0100
Hugo Landau <hlandau@devever.net> wrote:

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

Hugo, and all,

I have done a closer review of the patch now and I have some thoughts.

* I wonder if we could drop the ovl_dev boot option and use the format:

  apkovl=<device>[:<fstype>]:<path-to-apkovlfile>

where :<fstype> is optional. If no fstype is specified let kernel autodetect.

For PXE the boot option could be: apkovl=http://<server>/path/host.apkovl.tar.gz

I could not find anything documented on wiki.alpinelinux.org about ovl_dev. If nobody is using it, we could simply remove the ovl_dev option.

Otherwise we could keep it for compat but let a new apkvol option take preference.

-nc




---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---