[RFC] Dracut and complicated netboot cases

[Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html