Bill Nottingham wrote:
Hans de Goede (j.w.r.degoede@xxxxxx) 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
