Due to parallel probing of the linux kernel `/dev/sd*` can't be used to
reliably address a hard disk. This can be seen by the many spurious
failures of the dracut CI, where `mdadm` failed with error 524 or tests
failed due to the success marker message written to the wrong disk.
* don't rely on `/dev/sd*` but use disk ids and `/dev/disk/by-id/ata-disk_<name>`
* specify the exact qemu machine architecture `-M q35` needed for the
disk ids. A later patch will move this to `run-qemu`, when all tests are converted
* due to `-M q35` the interface names have changed from
`ens2` -> `enp0s1` and `ens3` -> `enp0s2`
On Fedora 30 the paritition sizes turn out to be too small again:
+ mkdir -p /sysroot
+ mount /dev/dracut/root /sysroot
+ cp -a -t /sysroot /source/bin /source/dev /source/etc /source/lib /source/lib64 /source/proc /source/root /source/sbin /source/sys /source/tmp /source/usr /source/var
cp: error writing '/sysroot/usr/lib64/libkrb5.so.3.3': No space left on device
cp: error writing '/sysroot/usr/lib64/libkrb5support.so.0.1': No space left on device
It turns out that there has been quite some size increase in some libraries,
notably glibc, though not all -- some even shrunk, ruling out a toolchain
problem. Here's are files over 1M we install on Fedora 30:
f29 f30
2.7M => 6.4M /usr/lib64/{libc-2.28.so => libc-2.29.so}
3.1M => 6.0M /usr/lib64/libcrypto.so.1.1.1c
2.0M => 3.5M /usr/lib64/{libm-2.28.so => libm-2.29.so}
2.9M => 2.8M /usr/lib/systemd/{libsystemd-shared-239.so => libsystemd-shared-241.so}
1.7M => 2.5M /usr/lib64/libunistring.so.2.1.0
2.3M => 2.4M /usr/lib64/bind9-export/libdns-export.so.1105.0.0
1.2M => 2.1M /usr/bin/bash
1.1M => 1.4M /usr/lib64/libkrb5.so.3.3
1.2M => 1.4M /usr/lib64/libgcrypt.so.20.2.4
612K => 1.1M /usr/lib64/libssl.so.1.1.1c
This increases the image sizes to accomodate for this. There's probably
little else we can do.
Harald Hoyer