As with other netroot boot arguments ip= lines should be parsed and
checked. Having this has the advantage that other cmdline scripts
can tell the ip= parser if dhcp or ip=:srv:... is needed, like
parse-root.sh (renamed dhcp-fallback) or parse-nfsroot do.
The nfs test-suite has one check which uses static ip lines, but
the autoconf param is wrong. Fixed this as well.
This introduces detailed cmdline parsing, warning or aborting if the
cmdline does not contain arguments according to the spec.
Makeing sure the parsers don't just call getarg for netroot et al,
allows their reuse inside netroot to analyse dhcp root-path as well.
Hence we can get rid of the current netroot hooks. The hook itself stays
in order to add further modules which should run before netroot handlers
are called.
This has one drawback: nfsroot needs some more logic to handle nfs
specific data inside dhcp root-path.
The parsers have been writting according to current discussions about
cmdline arguments. This lead to the "discovery" that some test-cases
violate the spec. These tests have not been removed, but change to
"must fail".
Debian based distros use dhcpd3 instead of just dhcpd. Accordingly
paths to lease files etc are different as well. This patch ensures
that the test-suite can run with either dhcpd or dhcpd3.
This patch enhances nfsroot and the nfs test-suite with compatibility
for debian based distros. This is mainly the difference of using
portmap instead of rpcbind and the missing file /etc/netconfig
With this change, we can now use LUKS and LVM over NBD. There are
some decisions to be made regarding where we should get the fstype
and fsoptions from (DHCP root vs rootfstype= etc), but the basic
functionality is there.
This adds support for a command line option netroot=, which is currently
equivalent to root=. This will allow us to break out handling in NBD and
iSCSI to support constructs such as "root=LABEL=/ netroot=dhcp" to make
use of our block device handling with network attached devices.
iSCSI has not been changed in this patch as I don't currently have a way
to test it.
This implements a default path of /tftpboot/%s if no path is provided,
and adds host name substitution for %s, with a fall back to the IP address,
as provided by the kernel's nfsroot handling.
The test suite is updated to test this functionality.
The full tests take over 6 minutes to run, and commenting out unneeded
ones is time consuming -- this change lets me comment out one line to
temporarily avoid an entire class of tests.
Test additional combinations of command line and DHCP option formats. This
is by no means the complete list, but gets us started with some common ones.
When debugging, this is still needed as we won't be redirecting out
output to /dev/null or a file. However, we need to guard against not
having a terminal.
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