Bug 721210

Perhaps asknetwork boot option could be the solution. I guess you are fetching kickstart over network and default network configuration (dhcp) is used to set up networking for getting the kickstart in this case. Asknetwork option should make anaconda ask instead of using the default (before fetching kickstart). Once the network is up, it can be reconfigured only non-interactively using kickstart network commands.

If network is neither needed to fetch kickstart nor configured (and activated) in kickstart with network commands, user is asked to configure network if/when the installer needs to access network.

Mark,

Does the 'asknetwork' boot option as described in comment #2 work for you?  If so, we'll get the documentation updated.

Hi David and Radek,

Yep, using the 'asknetwork' command seems to do the trick in my testing.  Haven't heard back from the customer yet to see if it does what they are looking for, but at least having 'addnetwork' in the documentation would certainly help customers.  And Radek's second paragraph added to the existing documention about exactly under what conditions users will be prompted for network information (not related to 'asknetwork').

Thanks,
Mark

You can see also https://bugzilla.redhat.com/show_bug.cgi?id=723449#c3 for details.

(In reply to comment #4)
> ...  And Radek's second paragraph added to the existing
> documention about exactly under what conditions users will be prompted for
> network information (not related to 'asknetwork').
> 

Yes, it can be difficult to deduce how this all works just from information scattered among description of boot options, kickstart options and some other places (which I reviewed for 6.1). We need to find place for this information. It should be based on facts I collected here: https://fedoraproject.org/wiki/Anaconda/Network.

Just letting you know the customer tried the 'asknetwork' boot option and whilst it did allow them to set the network information manually during boot, it didn't however allow them to set the hostname.  So when the host was registered to their satellite, its profile name was 'unknown'.  So they have decided to not use 'asknetwork' and instead use 'system-config-network-tui' in a %post section.

Thanks for the information, I wasn't thinking about hostname setting. The idea of hostname screen not being skipped if there is asknetwork boot option seems reasonable. As the boot option would result in UI interaction anyway, adding this shouldn't break any existing fully non-interactive configurations. Nevertheless, I am glad that your customer found acceptable solution using the %post section as it could be difficult to include the new feature into rhel 6.2.

Basic update of documentation is done in scope of bug 727612 and bug 723449. I'll keep this bug open to track eventual update of Installation guide with information summarizing network enablement options (e.g. 2nd paragraph of comment #2 and comment #5)

Thanks for great update. I noticed some minor things (most of them possibly not related directly to this bz/update, or something I omitted before):

1)
--nodefroute - "Prevents setting the interface as default route."
(instead of "Do not use the default route.")

2)
--netmask - "network mask of the device"

3)
--nameserver - "Multiple nameservers must be comma separated." should be appended

4)
--ip= — "IP address of the device"
instead of "IP address for the machine to be installed."

5)
--ipv6= - "IPv6 address of the device"
instead of "IPv6 address for the machine to be installed"