Hello list
With the frantic activity during the last few weeks Dracut is in a very
usable state. Sure, there's still a way to go, but we have an
infrastructure able to boot different configurations very well. Adding a
simple module to handle netboots isn't great magic anymore. What I'm
worrying about is some difficult cases, hence this plea for RFC.
Short introduction to netbooting: Network based boots aren't that
different from host based boots. Instead of a local root file system,
the root is delivered from a network server. The big difference is that
not only network interfaces need to be discovered and their drivers
loaded, these interfaces need to be configured as well. Usually with
dhcp or an ip option passed to the kernel. While this may be easy most
of the time, in some cases there's added logic needed to discover which
network interface is to be used. You could compare this to the state
booting was before we had label- or uuid-based mounting: Without
actually knowing which specific device to boot from, initrd's had to do
some real magic trying to discover the correct device.
Of course, there's no netboot module yet, but as mentioned that's simple
to do. But with the current state and a netboot module, the following
cases should work:
- Systems with only one network interface, configured statically (ip
boot option) or a successful dhcp
- Systems with multiple interfaces, but only one is connected, dhcp
succeeds and the network server is reachable via that configuration.
- Systems with multiple connected interfaces, dhcp succeeds, only one
default route is offered and the server is reachable via that configuration.
- Handling of Systems with no network interfaces or missing drivers if
netboot is required. This just makes boot fail.
What will work with a bit of added logic:
- Systems with multiple interfaces and a passed boot option specifying
which interface to use (interface=... or mac=...). Would work with both
static and dynamic configuration
- Only configure network devices if necessary: If we're not booting from
a network server, network interfaces should not be configured.
What I'm worried about are the following cases:
- No static configuration and dhcp fails: This can usually mean there is
no network. But with some network configurations, the initial setup-time
can take a while. Dracut currently has no means to restart the
configuration process.
- System with multiple interface, static configuration and no mac=...
option: The static configuration (ip=...) usually contains only the
configuration required to see the network server. But if we have several
interfaces we just don't know which interface this data has to be
applied to.
- System with multiple interfaces and dynamic configuration (dhcp): If
the network server is directly reachable without needing a default route
that is not a problem. But if we have more complicated network setups
(which is usually the case), the system needs a default route. But what
if the dhcp answer for interface A and interface B wants to set
different default routes? Problem one is that we can have only one
default route, Problem two is we don't know through wich route the
network server can be reached.
To solve these cases, I've had the following (pseudo-code) in our
production environment for the last 5 years:
while (not OK) do
for all known interfaces
configure interface or FAIL
ping server or FAIL
mount root-filesystem or FAIL
if not FAIL: set ok and break
if FAIL: deconfigure interface
endfor
if not OK:
print “please check cabling and hit enter to retry”
wait for user
endif
endwhile
(The ping part is an optimization since mounting can have a very long
timeout)
Now what I'm asking is: 1) Does Dracut need to be able to handle these
complicated cases? And if so 2) Is my solution really the 'Right Thing'
to do or is there be a better solution?
Thanks,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
