* SYNTAX
bridge=<bridgename>:<ethname>
If bridge without parameters, assume bridge=br0:eth0
* When <ethname> would be configured by network scripts, instead create a bridge named <bridgename> then add <ethname> to that bridge.
* Then $netif becomes <bridgename> instead of <ethname> and all existing scripts process netroot mount via this new $netif instead of <ethname>.
* Include a few test cases in NFS and NBD
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.
Multiline conditionals ( && { ... } ) should use if, function
declarations go to the top of the file, add/update comments and remove
some unnecessary clutter.
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.
/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.
This changes the network config to run dhclient from within udev, and
allows multiple dhclients to run at once. It also sets the hostname and
adds a kernel command line option 'netdebug' to help debug network issues.
All modules now live in a subdirectory /modules.d. Each module is
self-contained -- it should contain everything that it will install
on the initrd. All modules must include a script named install, which
will be sourced by dracut. This script should do the actual file installation
using inst methods. The moddir variable will point to the full path to the
module dracut is currently working on.
As usual, this patch series applies on top of my previous patch series,
and is available as normalize-modules from http://git.fnordovax.org/dracut.
Static interfaces are still configured on the fly as we add them, but
discussions on the mailing list have suggested that we need to have finer
control over bringing up dhcp interfaces.
The default hook just runs all the requested dhclients in parallel and waits
for them to all return. If you need something more complicated than this, or
need to have more control over bringing interfaces up, you will probably need
to override some stuff in the 40network hook.
Provided that you are configuring them via DHCP. RARP, BOOTP, and static
configuration are not written yet.
Also, adding nic drivers really bloats the initrd.
I am looking for feedback on these patches from people who actually implement
booting over the network. This patch series does not include support for that
yet -- you will not find nfsroot= handling, or booting to a fs supplied by
dhcp yet. I do want to make it as easy as possible to add support for booting
over the network, as well as making it easy for people to customize things to
meet their site requirements.
This patch series is also available as the network-configurability branch at
http://git.fnordovax.org/dracut. It may be rebased without warning to keep
it in sync with the rest of dracut.
Warren Togami