This changes the s390 support on several stages:
1) On s390 the boot process is based on zipl which boots into an
initrd from which a userspace grub process is started to support
the grub capabilities. The implementation of this concept is
provided via the grub2-s390x-emu package. Once installed the
setup of the bootloader is done via the grub2-mkconfig and
grub2-install commands and therefore from a caller perspective
the same as with any other grub2 setup process. For kiwi this
means no extra zipl bootloader target code is needed. Therefore
this commit deletes the zipl setup from kiwi and puts on
the standard grub2 process. This Fixes bsc#1170863
2) To support different targettypes the grub2-s390x-emu provided
zipl template must be adapted. Parts of the former zipl bootloader
setup therefore now applies to an update of the zipl2grub
template file
3) Support for CDL/LDL DASD targets has been disabled in the schema
When testing 4k devices and a respective zipl2grub template
setup for CDL/LDL targettype it has turned out that grub2-install
is not able to run on such a device. My assumption is that
the device code in grub2-install does not work for 4k devices
with an fdasd created partition table. As this needs further
investigations and most probably adaptions on the grub toolchain
for s390, we disabled the setup of these modes for now.
emulated DASD (FBA) and SCSI targets stays supported.
A vmx image is the same disk as an oem just without the dracut
repart/resize feature. This difference is better handled with
an oemconfig parameter <oem-resize> which allows to switch resize
on or off. The extra image type vmx will be dropped and an XSLT
stylesheet automatically transforms a vmx description to be a
oem image with the resize feature switched off.
This Fixes#1425
In an OEM deployment that requested the creation of a swap
partition via <oem-swap> that swap partition was created
at first boot and was always the last partition on the disk.
This was required because it could not be placed before
any other partition without destroying those partition
contents. This process leaves the system in an inflexible
condition if the storage device can change its geometry
dynamicly as it's the case for SAN systems. The typical
deployment target for OEM images are SAN storage clusters
and it's cumbersome to resize the root partition if swap
is last.
This commit Fixes#1231 and changes the handling of swap if
requested via <oem-swap> as follows:
1. The swap space is created as part of the image build process
and no longer on first boot of the image via dracut code.
This increases the size of the non compressed .raw disk image
by the configured swap space size or the default. The
compressed versions are not affected since zero initialized
swap space compresses to almost no space. Deployment of
the image however also deploys the swap partition which
increases deployment time. For big swap configurations
it's advisable to switch off image verification via
oem-skip-verify. For very big swap configurations it's
also recommended to prevent kiwi from adding them as part
of the image and let them be created on first boot via
a systemd service that e.g places a swap file, or creates
a swap volume when possible such that the fexibility to
resize the rootfs is still available.
2. The setup of the swap space is now explicit. It's no longer
calculated by twice times RAM size because on newer machines
this could lead to huge numbers. Either the kiwi encoded
default swap size applies or the user configured value.
3. LVM based oem disks creates the swap space as logical volume.
The volume is created as part of the image build process
and no longer on first boot. The swap volume at build time
of the image is of a minimal size and gets resized on first
boot.
4. The move of the swap creation into the builder code also
handles swap per configured device persistency schema like
any other devices. This means by default swap is mounted
via by-uuid name and thus also Fixes#1259
