Boot Methods

Ubuntu on S390X architecture always executes in some sort of virtualisation mode. This thus poses unusual requirements for exercising all the possible ways the install media may be booted.

Overall one can assume that S390X is always booted approximately like a network boot or a direct kernel boot.

LPAR FTP load

LPAR should be able to do remote network FTP load of the exported server ISO.

• Download and verify ISO checksums
• Loop-mount or extract the ISO and expose the contents over FTP protocol
• Using HMC web console perform Load from FTP using appropriate or anonymous credentials and path to the:
  • top level of the ISO image
  • ./boot sub directory
  • ./boot-hwe sub directory (LTS.2+)
• After a successful discovery of the FTP export it should be offered to load respectively:
  • ubuntu.ins and ubuntu-hwe.ins (LTS.2+) files
  • ubuntu.ins only
  • ubuntu.ins only
• Loading selected .ins file should result in a successful completion of the task
• One then should continue to use Operating System Messages console to configure network access
• After completing network access configuration, one should be able to ssh to complete installation
• The LPAR should reboot into installed system at the end of the installation

The .ins and related files on the ISO boot/boot-hwe subdirectories are identical to the matching d-i build exposed on the mirrors, thus one can also use just the d-i components off a mirror.

LPAR CDROM load

Requires remote hands?! Untested, should be identical to .ins file loading

LPAR PXE boot

Currently not available.

z/VM boot methods

z/VM using a CMS environment should be able to load kernel, initrd, paramfile (empty by default) and any other custom files from minidisk into spool files and IPL from there. One can download files and execute commands manually to do this if one is a sufficiently advanced user of CMS. One can also logout the z/VM user and ftp upload all the d-i files (respecting text and binary modes for text files and kernel/initrd). Once all files are in place one should be able to issue exec ubuntu via c3270 console to load the installer & configure networking. After this instalation can be finished via ssh.

The z/VM guest should reboot into installed system at the end of the installation

QEMU boot methods

Please note this applies to Ubuntu KVM and the z/KVM distributions for testing Ubuntu as a guest.

Direct kernel boot

Supplying d-i kernel and initrd for direct kernel boot should just work like on any other architecture.

The QEMU guest will not reboot into installed system at the end of the installation, and the boot device must be adjusted manually.

El-Torito image

Attaching ISO as a virtio hard drive, one should be able to boot of it excercising the El-Torito boot image.

The QEMU guest will not reboot into installed system at the end of the installation, and the boot device must be adjusted manually.

Cloud Image

Similar to other architectures, cloud image should boot as a hard drive.

Network types

qeth

Is the most common network type and is used most of the time in LPARs and z/VM. It is one of the first things that are configured when the installer launches. One needs to select appropriate bus_ids to configure the qeth device before it is used.

RDMA over Converged Ethernet (RoCE)

RoCE cards do not need any specific configuration, and they simply are available as potential NICs in netcfg.

VIRTIO

On QEMU only, virtio is the only network type available and they do not require any additional configuration.

Disk Drive Types

dasd

Installation should be tested onto the DASD drives. If any are available, a screen is presented allowing one to online these, format (wipe clean, if needed) and later used for partitioning by partman.

zfcp

There are also zfcp devices that one can online and they should be automatically discovered. Multipath is common with zfcp devices, and one should enable all paths to desired devices. The installer will detect multipath devices automatically and one should complete installation onto the multipath devices.

virtio

Qemu only has virtio disk types, however it does make a difference whether or not the virtio disk is backed by a normal linux file or by the DASD device file. There were bugs during xenial development cycle that prevented either file or dasd based drives fail to work (partitioned using wrong labels).

Atypical Installation Procedure

Offline installation against ISO mirror

The ISO has sufficient content to complete the installation without access to a full ubuntu mirror. Thus when contents of the ISO is exported over HTTP, it must be possible to specify that location as the Ubuntu mirror during installer and complete the install.