Hi,
For compatibility with RHEL 6, and kickstarts out there, we always
activate the device of the first network command in installer
environment (we are assuming --activate option). The problem is that
there is no way to turn this default off.
There are BZs appearing that hit this limitation [2]. The use case is:
- configure a device for installation in dracut stage (to fetch
kickstart, or perhaps even the payload) - via boot options
- use another configuration of the device for target system - via kickstart
Activating the target system configuration in installer (after
switchroot) can result for example in unreachable source,
disconnected/stalled nfs mount of installer image, ...
I can see three options to support such use cases:
1) A workaround: use dummy first network command with non-existing
device. Anaconda will just ignore it:
network --device=NONE
network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4
Or in case hostname is configured, use this as first network command
network --device=NONE
network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4
... well, it is just an ugly workaround
2) Change the behaviour - treat the first network command same as other
network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4
... I am afraid we can't afford such a change with respect to users
already relying on current behaviour.IIRC
3) New network kickstart command option --donotactivate with lower
priority than --activate. Which means it would effectively apply only to
the first network command, for other commands it is the default.
network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4
--donotactivate
... does not seem very elegant
In my opinion, for RHEL 7 (and maybe even for master) we should go with 3)
What do you think?
Radek
[1] or reactivate it with kickstart configuration in case it has been
already activated in dracut
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1338631
https://bugzilla.redhat.com/show_bug.cgi?id=1277975
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
