There appears to be an issue with newer QEMU versions (spotted with Arch
Linux and C9S containers) which causes the respective GH Action to hang
when booting a QEMU VM in combination with the `-cpu max` parameter.
During (a particularly painful) debugging session I once managed to get
some output from such "frozen" machine (using `earlycon` and
`earlyprintk` kernel cmdline options), and in that particular case the
VM died with a trap caused by an invalid opcode.
I couldn't reproduce this locally, only in GH Actions environment with
Arch Linux and C9S containers. Also, so far I haven't found out which
specific CPUID flag causes this, but using the `IvyBridge-v2` feature
set seems to mitigate the issue.
Add OpenSuse and Arch Linux to limited tests.
Only run the full tests against the latest stable Fedora version
to reduce the workload.
Also remove the `hung_task_panic=1` on the kernel command line, as qemu
tends to be really slow in non-kvm mode.
Removing sourcing of network link files from the udev-rules module.
What always should be included should be placed in the systemd-network
module and other modules that provide/require spesific link files
should add them, themselves via their relevant include section.
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`
* Correct the systemd generated sysroot.mount unit with the options
received by the DHCP request and do a `daemon-reload`.
* Inject the `nbd-client -check /dev/nbd0` in the finished initqueue.
* Reactivate the NBD tests and prepare them for NetworkManager tests.
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`
`qemu_add_drive_args` can be used to generate arguments to specify disks
for a qemu machine (`-M q35`).
This is mostly useful to address those raw disks via `/dev/disk/by-id`,
because due to parallel probing in the kernel `/dev/sd*` can point to
anything.
While creating the striped md raid0 sometimes this error occures:
```
mdadm: Defaulting to version 1.2 metadata
mdadm: RUN_ARRAY failed: Unknown error 524
Failed to clear hint file.
Device /dev/md0 not found.
Powering off.
```
Add debug output with the size of the disks.
Also create disks with multiple of 4096.
David Disseldorp