NetworkworkManger and network based filesystem /usr

Hans de Goede j.w.r.degoede at hhs.nl
Fri Sep 12 18:43:05 UTC 2008


Bill Nottingham wrote:
> Hans de Goede (j.w.r.degoede at hhs.nl) said: 
>> What you see here is that the old network service started at priority 10, 
>> with low priorities starting first, then at 13 iscsi got started and at 
>> 25 network filesystems (nfs, iscsi, etc) get fsck-ed (where applicable) 
>> and then mounten.
>>
>> Then at 26 hal gets started and at 27 NetworkManager.
>>
>> Now here we have a problem as in the brave new world without the old 
>> network service, when iscsi gets started and when netfs tries to mount 
>> nfs shares, the network is not configured yet as NetworkManager hasn't 
>> been started yet.
> 
> netfs does not start if neither of network or NM has started yet, and
> is separately started by NM if needed.
> 

Thats a cool trick, can we teach NM to start iscsi too and do that (and let it 
complete) before it starts netfs?

That would be nicer then my current dbus-send get NM status and sleep while not 
connected loop in bash.

Although I wonder if this (delaying netfs start until NM is done) is a good 
solution, what if some later service which needs one of the dirs mounted by 
netfs gets started before NM is done configuring the interfaces?

>> But there is a catch, hal and NetworkManager are currently under /usr 
>> which could be on a network based fs itself. So hal and NetworkManager 
>> will need to be moved to /bin and /lib[64], or alternatively we could 
>> declare that installations where /usr is on a different fs then / are not 
>> supported (which might be a good thing todo for F-10 and then move hal + 
>> NM for F-11).
> 
> Having network /usr and non-network  / isn't really practical long term.
> I'm all for not supporting it.

What about having both network based, but not the same fs, so say 2 separate 
nfs exports one for / and one for /usr, that situation will run into similar 
problems, initrd will do some hackish setup of the network to get the rootfs, 
but won't mount other network based fs and netfs will not run untill NM is 
done, so we once more have a catch 22.

Regards,

Hans




More information about the fedora-devel-list mailing list