We no longer require any user intervention when testing dracut on
a local block device in qemu, assuming everything passes. If things fail,
we still might need to manually kill things.
First, add a check script to 99base to ensure that it will load its
prerequisites.
Second, disable the udev magic dracut normally uses when generating
test images -- it was causing random failures when creating the test
root filesystem, presumably due to race conditions between the
rootfs creation scripts and udev.
Third, consolidate the rootfs creation scripts into one script.
There is no point loading every driver available when we are not testing
network functionality and qemu does not even support the stuff we were
loading. It just wastes time and space.
If we install copy-root as a mount hook, it will be run after the root fs
is mounted and it will make hte proc directory, allowing root filesystem
creation to finish without error.
If the host supports kvm, use is. If this is not the case but the kqemu
module is loaded, run qemu with kqemu optimization. Otherwise fall-back to
pure usermode qemu.
If we purport to test booting to an md raid, we may as well test it.
We do not need the plymouth module and the normal crypt module to include
duplicate functionality.
Also create the root filesystem from within the virtual env, this way there
will be no nasty suprises w.r.t interactions with the host machine. This
is important when we test booting to LVM, LUKS, and mdraid.
This creates a basic root filesystem, creates an initramfs, and tries
to boot to the basic filesystem.
The init code on the test filesystem prints how much memory is used vs. free
and then drops to a shell. Exiting the shell will power off the VM.
Harald Hoyer