Bug 1273167
Summary: | static kickstart file created DHCP-based ifcfg profile | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stephen Gallagher <sgallagh> | ||||
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 23 | CC: | anaconda-maint-list, anilsson, awilliam, dcbw, g.kaviyarasu, jklimes, jonathan, lkundrak, lrintel, mvollmer, ngompa13, psimerda, robatino, rvykydal, stefw, vanmeeuwen+fedora | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2015-10-22 15:46:32 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Stephen Gallagher
2015-10-19 19:58:58 UTC
Transferring blocker nomination from #1273145, as this is really the more significant bug here. joining a realm via kickstart will fail in the case that you need to override the nameserver via 'nameserver=' parameter and you don't also configure an entire static IP setup (so no DNS server is configured via DHCP). We *think* things should still work OK if the DHCP-provided DNS server supports realm discovery, though. Right, while this bug makes testing a real pain in the neck, it is unlikely to be an issue in the majority of production environments, so I'm -1 to blocking on it. Addendum: If we can figure out what is causing this to happen in a timely manner, I'm also +1 FE. One more note: I just also performed an installation against the F23 Server Final TC11 media using this kickstart: https://sgallagh.fedorapeople.org/kickstarts/f23/static.ks The resulting system had: [root@ipaksclient ~]# nmcli c show ens3 connection.id: ens3 connection.uuid: 7ee1db3b-54c4-45c7-bcde-4d39ec8a77a9 connection.interface-name: ens3 connection.type: 802-3-ethernet connection.autoconnect: yes connection.autoconnect-priority: 0 connection.timestamp: 1445281872 connection.read-only: no connection.permissions: connection.zone: -- connection.master: -- connection.slave-type: -- connection.autoconnect-slaves: -1 (default) connection.secondaries: connection.gateway-ping-timeout: 0 connection.metered: unknown 802-3-ethernet.port: -- 802-3-ethernet.speed: 0 802-3-ethernet.duplex: -- 802-3-ethernet.auto-negotiate: yes 802-3-ethernet.mac-address: -- 802-3-ethernet.cloned-mac-address: -- 802-3-ethernet.mac-address-blacklist: 802-3-ethernet.mtu: auto 802-3-ethernet.s390-subchannels: 802-3-ethernet.s390-nettype: -- 802-3-ethernet.s390-options: 802-3-ethernet.wake-on-lan: default 802-3-ethernet.wake-on-lan-password: -- ipv4.method: auto ipv4.dns: 192.168.124.79 ipv4.dns-search: ipv4.addresses: ipv4.gateway: -- ipv4.routes: ipv4.route-metric: -1 ipv4.ignore-auto-routes: no ipv4.ignore-auto-dns: no ipv4.dhcp-client-id: -- ipv4.dhcp-send-hostname: yes ipv4.dhcp-hostname: -- ipv4.never-default: no ipv4.may-fail: yes ipv6.method: auto ipv6.dns: ipv6.dns-search: ipv6.addresses: ipv6.gateway: -- ipv6.routes: ipv6.route-metric: -1 ipv6.ignore-auto-routes: no ipv6.ignore-auto-dns: no ipv6.never-default: no ipv6.may-fail: yes ipv6.ip6-privacy: -1 (unknown) ipv6.dhcp-send-hostname: yes ipv6.dhcp-hostname: -- GENERAL.NAME: ens3 GENERAL.UUID: 7ee1db3b-54c4-45c7-bcde-4d39ec8a77a9 GENERAL.DEVICES: ens3 GENERAL.STATE: activated GENERAL.DEFAULT: yes GENERAL.DEFAULT6: no GENERAL.VPN: no GENERAL.ZONE: -- GENERAL.DBUS-PATH: /org/freedesktop/NetworkManager/ActiveConnection/0 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/Settings/0 GENERAL.SPEC-OBJECT: / GENERAL.MASTER-PATH: -- IP4.ADDRESS[1]: 192.168.124.102/24 IP4.GATEWAY: 192.168.124.1 IP4.DNS[1]: 192.168.124.1 IP4.DNS[2]: 192.168.124.79 DHCP4.OPTION[1]: requested_classless_static_routes = 1 DHCP4.OPTION[2]: requested_rfc3442_classless_static_routes = 1 DHCP4.OPTION[3]: subnet_mask = 255.255.255.0 DHCP4.OPTION[4]: requested_subnet_mask = 1 DHCP4.OPTION[5]: domain_name_servers = 192.168.124.1 DHCP4.OPTION[6]: ip_address = 192.168.124.102 DHCP4.OPTION[7]: requested_static_routes = 1 DHCP4.OPTION[8]: dhcp_server_identifier = 192.168.124.1 DHCP4.OPTION[9]: requested_nis_servers = 1 DHCP4.OPTION[10]: requested_time_offset = 1 DHCP4.OPTION[11]: broadcast_address = 192.168.124.255 DHCP4.OPTION[12]: requested_interface_mtu = 1 DHCP4.OPTION[13]: dhcp_rebinding_time = 3150 DHCP4.OPTION[14]: requested_domain_name_servers = 1 DHCP4.OPTION[15]: dhcp_message_type = 5 DHCP4.OPTION[16]: requested_broadcast_address = 1 DHCP4.OPTION[17]: routers = 192.168.124.1 DHCP4.OPTION[18]: dhcp_renewal_time = 1800 DHCP4.OPTION[19]: requested_domain_name = 1 DHCP4.OPTION[20]: requested_routers = 1 DHCP4.OPTION[21]: expiry = 1445285472 DHCP4.OPTION[22]: requested_wpad = 1 DHCP4.OPTION[23]: host_name = ipaksclient DHCP4.OPTION[24]: requested_nis_domain = 1 DHCP4.OPTION[25]: requested_ms_classless_static_routes = 1 DHCP4.OPTION[26]: network_number = 192.168.124.0 DHCP4.OPTION[27]: requested_domain_search = 1 DHCP4.OPTION[28]: next_server = 192.168.124.1 DHCP4.OPTION[29]: requested_ntp_servers = 1 DHCP4.OPTION[30]: requested_host_name = 1 DHCP4.OPTION[31]: dhcp_lease_time = 3600 IP6.ADDRESS[1]: fe80::5054:ff:fee2:19ed/64 IP6.GATEWAY: Note particularly that, despite the kickstart settings of static IP address and DNS servers, the installed system had ipv4.method: auto ipv4.ignore-auto-dns: no This certainly doesn't match the intent, so something went wrong somewhere. I can reproduce this with Cockpit 0.80 and F23. Toggling the 'DNS Automatic' toggle seems to have no effect on the 'ipv4.ignore-auto-dns' setting. Performing the same action in gnome-control-center *does* have an effect. (In reply to Stephen Gallagher from comment #0) > Further information: when attempting to set these values in the Cockpit > admin interface, the user is unable to modify the "Automatic" setting of the > DNS field. (It displays "off" but setting it in either direction has no > effect on the DNS server list). This part is a Cockput bug. Cockpit regression fixed here: https://github.com/cockpit-project/cockpit/pull/2984 (In reply to Stephen Gallagher from comment #4) > One more note: I just also performed an installation against the F23 Server > Final TC11 media using this kickstart: > https://sgallagh.fedorapeople.org/kickstarts/f23/static.ks > > Note particularly that, despite the kickstart settings of static IP address > and DNS servers, the installed system had > ipv4.method: auto > ipv4.ignore-auto-dns: no > > > This certainly doesn't match the intent, so something went wrong somewhere. NetworkManager works correctly. I have tested with "ipv4.ignore-auto-dns: yes" and that works as expected (only using manually configured DNS server). So the question is who created the ens3 profile and if it is correct according to the kickstart file. Re-assigning for anaconda for thoughts. Looking at the kickstart from comment #8 network --device=eth0 --bootproto=static --ip=192.168.124.73 --netmask=255.255.255.0 --gateway=192.168.124.1 --nameserver=192.168.124.79 --hostname=ipaksclient.tc11.final.f23 shouldn't there be --device=ens3 ? AFAIK only virtio VM network devices didn't use predictable names (as ens3). Maybe you are not using virtio? Or perhaps virtio started to use predictable names? @Radek: virtio net interfaces don't use predictable names unless you are using systemd 226 or newer. Since Fedora 23 uses systemd 222, it should still be designated as "unstable". (In reply to Neal Gompa from comment #10) > @Radek: virtio net interfaces don't use predictable names unless you are > using systemd 226 or newer. Since Fedora 23 uses systemd 222, it should > still be designated as "unstable". Can someone then explain to me how setting a static IP and such in a kickstart is supposed to be possible? If you can never predict what name an interface will have, how can you ever set that? (Alternately, if the answer is "don't use --device and the first detected device will get the rest of the settings", that should be in the documentation...) You can use --device=link. https://github.com/rhinstaller/pykickstart/blob/master/docs/kickstart-docs.rst#network Actually no --device which should default to --device=link might be broken currently. We've just been fixing it in RHEL and are going to backport the patches to master. (In reply to Radek Vykydal from comment #12) > Actually no --device which should default to --device=link might be broken > currently. We've just been fixing it in RHEL and are going to backport the > patches to master. https://github.com/rhinstaller/anaconda/pull/412 I can confirm that leaving out --device does not fix the problem. When I specify --device=ens3 (which is different from what the virtio device comes up as in F23 Beta, which was eth0), the installation appears to go properly. (So on that note, I'm firmly -1 blocker) Would you mind adding some documentation on what exactly "--device=link" means? The word "link" appears on that page exactly once: when it's used in that example. Does it mean "the first detected device"? The first interface that has a detected "cable"? (In reply to Stephen Gallagher from comment #14) > Would you mind adding some documentation on what exactly "--device=link" > means? The word "link" appears on that page exactly once: when it's used in > that example. Does it mean "the first detected device"? The first interface > that has a detected "cable"? You couldn't find it because the --device network option on the page links to other doc: https://rhinstaller.github.io/anaconda/boot-options.html#ksdevice Hmmm, "no --device is broken" actually sounds like a *more* serious bug, if anything. Does that mean that any kickstart with a network line that doesn't specify a particular device will be broken? If so I'd say that's at least an FE. (In reply to awilliam from comment #16) > Hmmm, "no --device is broken" actually sounds like a *more* serious bug, if > anything. Does that mean that any kickstart with a network line that doesn't > specify a particular device will be broken? If so I'd say that's at least an > FE. The kickstart command will just be ignored. But to be clear, it didn't break recently, I think f22 and f21 have the same behavior. Hmm, OK - I would've guessed it would be more common. I've just checked that f22 behaves the same. But I'm not opposed to get the patch into f23. It will definitely go to rawhide. I'm gonna call this one NOTABUG, there isn't really anything sensible to track here. We *could* open a Fedora bug for the 'omitting --device doesn't work as intended' issue and throw an FE/CommonBugs at it if we want, not sure if it's worth the trouble, but using this bug for that would just be confusing, I think. |