Adding s390x support to DIB
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
diskimage-builder |
Fix Released
|
Undecided
|
Andreas Scheuring |
Bug Description
This is a feature request to add the ability to build s390x images with diskimage-builder.
Use Cases
---------
* Allow users to create qcow2 image that can be used on a s390x nova libvirt/kvm node
* Enable nodepool image build for third party CI
Supported Distros
-----------------
The following Distros are officially supported on s390x architecture.
* RHEL - will not be supported by DIB, as rhel is not supported as a kvm guest on s390x and therefore there's no s390x cloud image like it is for other arches (this is required by the rhel7 DIB element)
* SLES - no support for SLES in DIB
* Ubuntu - full support in DIB
Testing
-------
There are limitation with building s390x images on other architectures. Therfore the plan is to provide a Third Party CI job that builds the s390x images and provides the logfiles. A similar CI already exists for nova [1]
Technical Details
-----------------
s390x does not support the grub2 bootloader. Instead of grub "zipl" [2] must be used.
new zipl element vs. existing bootloader element
+++++++
The challenge is, that the bootloader element (which contains the grub setup) is dependency of the vm element [3]. It will be called implicitly everytime the element "vm" is specified. Now 2 options exist
#1 extend the bootloader element to support zipl
#2 Implement a new element that "element-provides" bootloader. When explicitly specified as element in the commandline, the zipl element will override the "bootloader" element that is pulled in as dependency. For example:
diskimage-
The second approach has been chosen (not sure about the exact reason - the patch has a long history)
zipl configuration
++++++++++++++++++
Zipl requires a zipl.conf file being present at "/etc/zipl.conf". More details about this file see [4]. Basically it contains the location of the kernel and initramfs as well as the parmline.
* The location of the kernel and the initramfs is hardcoded to /boot/*.
* A default cmdline will be implemented, with the option for an overrride
zipl advanced block/sector settings
+++++++
The patch has some history [5] (outdated) [6] (current). Some versions of the patch where using a zipl helper file (see [7][8] for more information on zipl helper files) which did some magic to the block/sector settings. BTW, all those settings can also be done via zipl command options [9].
Let's understand it:
Disk image builder uses the following defaults
* Disk logical sector = physical sector size: 512B [10]
* Alignment: 1MiB [11] (configurable via [14])
(* File system block size: 4096B [12])
Alignment means, that a partition starts at the 1 MiB boundary.
The following parameters can be specified to zipl [8]
* targetbase -> The device that holds the boot volume
* targetblocksize -> the blocksize of the target device (in DIB always 512B) [10]
* targetoffset -> the block at which the boot partition starts
* targettype -> always "scsi" for s390x KVM VMs
We need to distinguish between a partitioned setup and a non partitioned setup [15].
Partitioned setup
~~~~~~~~~~~~~~~~~
Only MBR is supported (no GPT partitioning) [13].
* MBR supports up to 4 primary partitions.
* One of the primary partitions can become a extended partition.
* In an extended partition many logical partitions can be created.
MBR consumes 512 Byte. Due to the alignment the next (1MiB -512 Bytes) are unused. The first partition starts at 1 MiB which is block 2048 ((1024 * 1024)B / 512 Bytes per Block).
-> zipls targetoffset should be set to 2048 when the first partition is the boot partition.
Luckily zipl is able to calculate the starting block for primary and logical partitions as well as for an lvm setup and all the other parameters correctly. It uses the zipl_helper.
Building a partitioned image:
export DIB_DEV_
export DIB_DEV_
export DIB_DEV_
export DIB_BLOCK_
- local_loop:
name: image0
size: 3GB
- partitioning:
base: image0
label: mbr
partitions:
- name: root
flags: [ primary ]
size: 50%
- name: boot
flags: [boot, primary]
size: 50%
- mkfs:
name: root_fs
base: root
label: cloudimage-root
type: ext4
mount:
fstab:
options: "defaults"
- mkfs:
name: boot_fs
base: boot
label: cloudimage-boot
type: ext4
mount:
fstab:
options: "defaults"
'
disk-image-create -x -x ubuntu-minimal vm zipl devuser &> build.log
root@ubuntu:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 2.8G 0 disk
├─vda1 253:1 0 1.4G 0 part /
└─vda2 253:2 0 714.5M 0 part /boot
root@ubuntu:~# zipl -V
Using config file '/etc/zipl.conf'
Target device information
Device.
Partition.
Device name...
Device driver name..............: virtblk
Type.
Disk layout.
Geometry - start..
File system block size..........: 4096
Physical block size.............: 512
Device size in physical blocks..: 1463319
Building bootmap in '/boot'
Adding IPL section 'ubuntu' (default)
initial ramdisk...: /boot/initrd.img
kernel image......: /boot/vmlinuz
kernel parmline...: 'root=LABEL=
component address:
kernel image....: 0x00010000-
parmline.
initial ramdisk.: 0x00390000-
internal loader.: 0x0000a000-
Preparing boot device: vda (0000).
Detected SCSI PCBIOS disk layout.
Writing SCSI master boot record.
Syncing disks...
Done.
-> Geometry - start (targetoffset) is calculated automatically to the (right) first block of the boot partition.
Non-partitioned setup
~~~~~~~
In this setup no partitioning (also no MBR) is being created. The
filesystem directly starts at block 0. This can be done by not specifying the "vm" element during image build, e.g.
diskimage-
zipl fails during image build if no partition is defined
2017-11-07 13:08:25.013 | + zipl -V
2017-11-07 13:08:25.014 | Error: Could not get disk geometry
The reason is, that the unpartitioned disk is not detected by the device mapper?? At least the existing zipl_helper (/lib/s390-
A new zipl_helper script that can handle plain loop devices is required during image build with the following parameters
* targetbase: /dev/loopX (the base device)
* targetblocksize: 512B (more details see above)
* targetoffset: 0
* targettype: scsi (more details see above)
This helper file is only required during image build and can therefore be removed again after zipl has been called. When zipl is run inside a unpartitioned running vm, the disk is detected as device mapper device.
Building a non partitioned image:
export DIB_DEV_
export DIB_DEV_
export DIB_DEV_
disk-image-create -x -x ubuntu-minimal zipl devuser &> build_no_part.log
When zipl is run inside a VM, the output looks like this:
# zipl -V
Using config file '/etc/zipl.conf'
Target device information
Device.
Device name...
Device driver name..............: virtblk
Type.
Disk layout.
Geometry - start..
File system block size..........: 4096
Physical block size.............: 512
Device size in physical blocks..: 2302208
Building bootmap in '/boot'
Adding IPL section 'ubuntu' (default)
initial ramdisk...: /boot/initrd.img
kernel image......: /boot/vmlinuz
kernel parmline...: 'root=LABEL=
component address:
kernel image....: 0x00010000-
parmline.
initial ramdisk.: 0x00390000-
internal loader.: 0x0000a000-
Preparing boot device: vda (0000).
Detected plain SCSI partition.
Writing SCSI master boot record.
Syncing disks...
Done.
[1] https:/
[2] https:/
[3] https:/
[4] https:/
[5] https:/
[6] https:/
[7] https:/
[8] https:/
[9] https:/
[10] https:/
[11] https:/
[12] ?
[13] https:/
[14] https:/
[15] https:/
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Changed in diskimage-builder: | |
assignee: | nobody → Andreas Scheuring (andreas-scheuring) |
status: | New → In Progress |
Current patch: https:/ /review. openstack. org/#/c/ 504588/