This patch adds STP timeout error handling with arping. It's rather
simple since it only cares about the primary interface and blindly
assumes that if no gateway is available the root server is on the
same subnet.
This introduces a new cmdline argument bootdev, to support the case
where multiple nics need to be up before the netroot handler is called.
Cases involved might be bonding, iscsi multipathing, bonding, ...
This argument is required to decide which interface is the primary to
use for dhcp root-path, default gw, etc.
When multiple ip= items are present on the cmdline, the ip= parser
now enforces the presence of <dev> further demands that the new argument
bootdev contains the name of the primary interface. Configurtion if of
course still delegated to netroot but in is enhance to ensure that netroot
"waits" for all required interfaces to be up.
Example: root=dhcp ip=eth0:dhcp ip=client-ip:::netmask::eth1:off bootdev=eth0
First, the ip= cmdline parser ensures that all ip items contain a <dev> then
checks the ip items and checks as well that an ip= item for the given bootdev
was found.
When the first netroot starts, probably for eth1, it checks wheter interface
configuration for all interfaces is available. If not it exits. The second
start of netroot (eth0, which was a bit delayed because of dhcp) sees that
all interfaces are present, configures them and continues.
Instead of configuring devices when they are ready, ifup and
dhclient-script write script files which are then sourced by
netroot.
This solves the problem of having multiple interfaces and not knowing
which one to use for dhcp or default route. This way, netroot (which
is serialized anyway) configures the interface before calling the root
handler and deconfigures it if the handler failed.
Example: root=nfs:server:path and ip=dhcp with eth0 and eth1 receiving
a dhcp reply, but eth0 is the correct one to use.
Assuming eth1 is the first to receive the dhcp-reply, netroot starts
and configures eth1. nfsroot is run but fails, so eth1 is deconfigured. If
eth0 has received a dhcp-reply (or not, then we wait) the other locked
netroot process starts and tries with eth0 and succeeds.
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".
Multiline conditionals ( && { ... } ) should use if, function
declarations go to the top of the file, add/update comments and remove
some unnecessary clutter.
This is mostly about style: Doing stuff after a successful mount
should go into pre-pivot.
In addition this corrects the case where the used netif is not eth0
base/init uses [ -d "$NEWROOT/proc" ] to check if root is mounted
or not. Netroot should do the same. In addition this gets rid of
another file in /tmp, since /tmp/netroot.done isn't needed anymore.
Having two files which are used more or less at the same time isn't
that easy to handle and read. Instead, move the contents of netroot.info
to root.info and only use root.info. This is cleaner and makes debugging
easier.
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.
/sbin/netroot is a jumping off point to allow various network
root devices to share infrastructure. It will loop over scriptlets
in the netroot handler, looking for a handler to run for this type
of netroot. Handlers can do choose to act based on command line
options to the kernel, or via DHCP options received on this interface.
They should massage root= into a form suitable for their handler.
Harald Hoyer