This is probably not necessary, but paranoia dictates that the actual
netroot handlers should check if all three required arguments (netif,
root, NEWROOT) are there and useable.
rpc.statd is only needed for NFSv4, because it's required for
locking. We don't support locking for NFSv2/3, so start it only
if we are mount from NFSv4.
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
This kernel module is dangerous to load here. It is meant only to allow direct
access to SCSI disks, which can destroy data. The i2o_block driver gives you
access to the defined hardware RAID arrays.
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.
Philippe Seewer