Features/S390xNetworkBoot: Difference between revisions

Revision as of 13:11, 12 September 2017

This is a short overview about using network boot for s390x.

Overview

The network boot feature enhances the s390x ipl device and the s390-ccw bios with support for booting via a virtio-net boot device. A new address is added to the ccw ipl block providing the address of a s390-netboot.img which performs the actual load over the network. This code has been included into QEMU since 2.9.

Starting with 2.10 QEMU includes a pre-built s390-netboot.img based on the SLOF firmware, enabling network booting from a DHCP/TFTP server. As s390 network bootable images are not very common, this document gives a brief overview on how to build one.

Booting from a network interface

The network boot can't be triggered using the traditional -boot n command line option, but requires to specify the bootindex attribute on the network device. E.g.,

  qemu-system-s390x ... -device virtio-net-ccw,netdev=hostnet0,id=net0,mac=52:54:00:2d:b5:b5,devno=fe.0.0001,bootindex=1

or, with libvirt

  ...
  <interface type='network'>
    <mac address='52:54:00:2d:b5:b5'/>
    <source network='default'/>
    <model type='virtio'/>
    <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
    <boot order='1'>
  </interface>
  ...

Building a s390 network bootable binary

A s390 network bootable image can be built by bundling some shell scripts, busybox and the kexec binary bundled into an initial ramdisk and append that to a kernel image. An existing s390 system can be used as source.

One way to do that is to take a kernel and an installer initial ramdisk from a distribution's DVD/ISO and concatenate them. Some fixups are necessary int the new binary, which can be done by using the script in [1]. Booting this image would then start the installation process as if booted from the DVD.

Another possible way is to build a binary that behaves similar to the PXELINUX boot loader. In this case an initial ramdisk with an init process triggering the PXELINUX-like processing has to be built as described in [2]. The site also contains a script assisting in the creation of such an initial ramdisk.

@@ Line 5: / Line 5: @@
 The network boot feature enhances the s390x ipl device and the s390-ccw bios with support for booting via a virtio-net boot device. A new address is added to the ccw ipl block providing the address of a s390-netboot.img which performs the actual load over the network. This code has been included into QEMU since 2.9.
-Starting with 2.10 QEMU includes a pre-built s390-netboot.img based on the SLOF firmware, enabling network booting from a DHCP/TFTP server
+Starting with 2.10 QEMU includes a pre-built s390-netboot.img based on the SLOF firmware, enabling network booting from a DHCP/TFTP server. As s390 network bootable images are not very common, this document gives a brief overview on how to build one.
-== Building s390-netboot.img ==
+== Booting from a network interface ==
-A s390-netboot.img can be built by bundling some shell scripts, busybox and the kexec binary bundled into an initial ramdisk and append that to a kernel image. An existing s390 system can be used as source.
+The network boot can't be triggered using the traditional ''-boot n'' command line option, but requires to specify the ''bootindex'' attribute on the network device. E.g.,
-The init process can be a simple shell script that mounts a few essential filesystems, like /dev, /proc, /sys, ..., starts a DHCP client (busybox udchpc) and then invokes another script to do the actual network boot.
+<code>
+   qemu-system-s390x ... -device virtio-net-ccw,netdev=hostnet0,id=net0,mac=52:54:00:2d:b5:b5,devno=fe.0.0001,bootindex=1
+</code>
-udchpc will invoke the script /usr/share/udhcpc/default.script in response to DHCP server messages to configure interfaces. The sample busybox default.script can be used for that, but needs to also extract the DHCP options like the tftp server address and pass that on to the boot script.
+or, with libvirt
-The boot script itself has to retrieve the PXELINUX configuration from the tftp server as in [http://www.syslinux.org/wiki/index.php?title=PXELINUX#Configuration_filename], then retrieve the remote kernel and initial ramdisk and finally use kexec to boot the network kernel.
+<code>
+   ...
+   <interface type='network'>
+     <mac address='52:54:00:2d:b5:b5'/>
+     <source network='default'/>
+     <model type='virtio'/>
+     <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
+     <boot order='1'>
+   </interface>
+   ...
+</code>
-In a nutshell:
+== Building a s390 network bootable binary ==
-# Create a skeleton initramfs directory structure
+A s390 network bootable image can be built by bundling some shell scripts, busybox and the kexec binary bundled into an initial ramdisk and append that to a kernel image. An existing s390 system can be used as source.
-# Create the init script, the PXE boot scripts and the DHCP default script
-# Copy kexec and its dependencies from the source system into the initramfs
+One way to do that is to take a kernel and an installer initial ramdisk from a distribution's DVD/ISO and concatenate them. Some fixups are necessary int the new binary, which can be done by using the script in [https://github.com/ibm-s390-tools/s390-tools/blob/master/netboot/mk-s390image]. Booting this image would then start the installation process as if booted from the DVD.
-# Copy virtio network and block modules from the source system into the initramfs
-# Copy the busybox binaries into the initramfs
+Another possible way is to build a binary that behaves similar to the PXELINUX boot loader. In this case an initial ramdisk with an init process triggering the PXELINUX-like processing has to be built as described in [https://github.com/ibm-s390-tools/s390-tools/tree/master/netboot]. The site also contains a script assisting in the creation of such an initial ramdisk.
-# Build the ramdisk (in compressed CPIO format)
-# Concatenate the kernel image and the initial ramdisk
-# Update the 8 bytes at location 66568 with the offset value of the ramdisk in the new binary, and the 8 bytes at location 66576 with the size of the ramdisk. Both values need to be updated in binary, big endian format.