Ignore the removal of nonexistent $image file. This removes the
following error message:
$ mk-s390image /var/lib/libvirt/images/hades/vmlinux-s390x out.img
...
rm: cannot remove 'out.img': No such file or directory
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
If an input file is not readable return a proper error message indicating
this.
Before:
$ mk-s390image /var/lib/libvirt/images/hades/vmlinux-s390x out.img
mk-s390image: Unrecognized file format for /var/lib/libvirt/images/hades/vmlinux-s390x
After:
$ mk-s390image /var/lib/libvirt/images/hades/vmlinux-s390x out.img
mk-s390image: File /var/lib/libvirt/images/hades/vmlinux-s390x cannot be read, no read permission
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Since Linux commit 5ecb2da660ab ("s390: support command lines longer
than 896 bytes") the s390x kernel supports longer command lines than 896
bytes. The indication of the maximum size is stored in a new field at
address 0x10430, older kernels without the support store a value of 0
there so in that case fallback to the old maximum length of 896.
In addition, use the checked size as limit to copy in the 'dd' call.
This prevents Linux kernel corruption in case the parmline has changed
in between.
Fixes: https://github.com/ibm-s390-linux/s390-tools/issues/194
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Most of the fixes were auto-generated using the following command:
$ shellcheck --format=diff mk-s390image | git apply -
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add the -v short option for version information to the mk-s390image and
mk-pxelinux-ramfs. Adjust the Makefile accordingly to set the correct
s390-tools version during installation.
Acked-by: Viktor Mihajlovski <mihajlov@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
A set of scripts and a short documentation describing how to build
a network boot image simulating a PXELINUX-style boot process.
Starting with QEMU 2.10 it is possible to boot a KVM guest over a
network interface using DHCP/BOOTP. The boot process is triggered by
the network boot firmware that is part of QEMU and follows the usual
network boot pattern: a DHCP request is issued by the client and
answered by a DHCP/BOOTP server. The DHCP reply will contain a
TFPT server identification and a bootfile name. The client will
retrieve the bootfile from the TFTP server, load it into memory
and IPL it.
A very common way of setting up a boot server has been defined
by PXELINUX, an open source implementation of PXE. With PXELINUX
the bootfile is a small network boot loader that will retrieve
a potentially client-specific configuration file containing
further instructions for the final boot process (kernel, ramdisk,...).
The set of sample scripts contained in the netboot directory provide
directions for a Linux distributor or a boot server administrator
on how to build a network boot image usable for a simplified
PXELINUX-style network boot setup for s390.
Note that the sample scripts are implementing only a subset of PXELINUX
functionality, specifically the config file parsing. In order to
get full functionality, a more specialized boot loader program
like petitboot or pxe-kexec must be used in the ramdisk.
Further, a sample Dockerfile is provided along with instructions on how
to build the network boot image in a Docker container.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
