Hide Forgot
Description of problem: When installing on iBFT (with just one network interface), anaconda requires FQDN for installation source. With dhcp network configuration url like: http://local-source/install-tree/ works without issue, though if iBFT configuration is used full name of server has to be used in url: http://local-source.in.my.domain/install-tree/ This is probably due to missing line in resolv.conf: domain in.my.domain This looks like an anaconda issue, other tools works without problem with same configuration, for example: wget http://local-source/install-tree/ passes where anaconda fails. I can't say if it is regression, however it is incosistent behaviour, what couldn't meet customer's expectation. Fix or release note (due to simple workaround) seems to be necessary for ongoing release.
Created attachment 494150 [details] log files
Is your ibft configured to use dhcp? From the syslog it doesn't seem so. Therefore NetworkManager is not getting domains from dhcp for /etc/resolv.conf.
(In reply to comment #2) > Is your ibft configured to use dhcp? From the syslog it doesn't seem so. > Therefore NetworkManager is not getting domains from dhcp for /etc/resolv.conf. It is configured by dhcp. Btw hostname is set to 'system-name.in.my.domain' (I'm using same naming scheme like in initial report, hostname and domain are actually little bit different in real test env), it is enough for other tools (wget) to identify correct domain and to perform correct name lookup, just the anaconda can't do lookups in local domain (what is quite strange to me).
Jirka, do you have any hint? ibft is configured to use dhcp but NM seems to use static configuration using ibft values, shouldn't it do dhcp too?. Marian says in description that without ibft, using dhcp (that is BOOTPROTO=dhcp) name resolution works as expected. From logs in comment #1: /etc/sysconfig/network-scripts/ifcfg-eth0: DEVICE=eth0 HWADDR=52:54:00:12:34:56 ONBOOT=yes TYPE=Ethernet BOOTPROTO=ibft from syslog: 07:37:36,160 NOTICE NetworkManager: ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-eth0 07:37:36,163 NOTICE NetworkManager: ifcfg-rh: Managing connection 'System eth0' and its device because NM_CONTROLLED was true. 07:37:36,167 INFO NetworkManager: <info> (eth0): now managed 07:37:36,167 INFO NetworkManager: <info> (eth0): device state change: 1 -> 2 (reason 2) 07:37:36,167 INFO NetworkManager: <info> (eth0): preparing device. 07:37:36,167 INFO NetworkManager: <info> (eth0): deactivating device (reason: 2). 07:37:36,167 INFO NetworkManager: <info> (eth0): device state change: 2 -> 3 (reason 0) 07:37:36,167 INFO NetworkManager: <info> Activation (eth0) starting connection 'System eth0' 07:37:36,167 INFO NetworkManager: <info> (eth0): device state change: 3 -> 4 (reason 0) 07:37:36,167 INFO NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... 07:37:36,168 INFO NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started... 07:37:36,168 INFO NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... 07:37:36,168 INFO NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete. 07:37:36,168 INFO NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting... 07:37:36,168 INFO NetworkManager: <info> (eth0): device state change: 4 -> 5 (reason 0) 07:37:36,168 INFO NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful. 07:37:36,168 INFO NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled. 07:37:36,168 INFO NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete. 07:37:36,168 INFO NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started... 07:37:36,168 INFO NetworkManager: <info> (eth0): device state change: 5 -> 7 (reason 0) 07:37:36,168 INFO NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) scheduled... 07:37:36,169 INFO NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete. 07:37:36,169 INFO NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) started... 07:37:36,169 INFO NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled... 07:37:36,169 INFO NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) complete. 07:37:36,169 INFO NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) started... 07:37:37,170 INFO NetworkManager: <info> (eth0): device state change: 7 -> 8 (reason 0) 07:37:37,171 INFO NetworkManager: <info> Policy set 'System eth0' (eth0) as default for IPv4 routing and DNS. 07:37:37,171 INFO NetworkManager: <info> Activation (eth0) successful, device activated. 07:37:37,173 INFO NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete. 07:37:37,181 INFO NetworkManager: <info> Setting system hostname to 'system1.virt' (from address lookup) 07:37:37,190 WARNING nm-dispatcher.action: nm_dispatcher_action: Invalid connection: '(null)' / 'connection setting not found' invalid: 1 07:37:38,190 NOTICE NetworkManager: ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/resolv.conf: # Generated by NetworkManager domain brq.redhat.com search brq.redhat.com englab.brq.redhat.com lab.eng.brq.redhat.com redhat.com nameserver 10.34.255.7 nameserver 10.34.255.6
(In reply to comment #5) > /etc/resolv.conf: > > # Generated by NetworkManager > domain brq.redhat.com > search brq.redhat.com englab.brq.redhat.com lab.eng.brq.redhat.com redhat.com > nameserver 10.34.255.7 > nameserver 10.34.255.6 Marian, can you also attach /etc/resolv.conf generated using just dhcp (no ibft)? (The one above is from logs you attached in comment #1). Also syslog and anaconda.log might be handy.
Created attachment 494899 [details] log file for dhcp
Based on irc conversation with Marian, it seems that NM isn't getting information that ibft is configured to use dhcp. NM is parsing output of "iscsiadm -m -fw" command, Marian, can you attach it? So the bug seems as testing environment (seems more likely to me) or NetworkManager issue.
(In reply to comment #8 > NM is parsing output of "iscsiadm -m -fw" command, Marian, can you attach it? # BEGIN RECORD 2.0-872 iface.initiatorname = iqn.2000-01.org.etherboot:system1 iface.hwaddress = 52:54:00:12:34:56 iface.bootproto = STATIC iface.ipaddress = 10.0.0.11 iface.subnet_mask = 255.255.255.0 iface.gateway = 10.0.0.1 iface.primary_dns = 10.0.0.1 iface.vlan = 0 iface.net_ifacename = eth0 node.name = iqn.2010-04.virt.nap:default node.conn[0].address = 10.0.0.1 node.conn[0].port = 3260 node.boot_lun = 00000000 # END RECORD > So the bug seems as testing environment (seems more likely to me) or > NetworkManager issue. Or bugreport shown strange behavior of anaconda (or libcurl) when it is not able to resolve dns names in situation when other tools are resolving without issue (due to correct hostname set, what should be also acceptable configuration for proper name resolving in local domain)
(In reply to comment #9) > (In reply to comment #8 > > NM is parsing output of "iscsiadm -m -fw" command, Marian, can you attach it? > > # BEGIN RECORD 2.0-872 > iface.initiatorname = iqn.2000-01.org.etherboot:system1 > iface.hwaddress = 52:54:00:12:34:56 > iface.bootproto = STATIC Because ibft is indicating so, NM and therefore anaconda is using static configuration. > > Or bugreport shown strange behavior of anaconda (or libcurl) when it is not > able to resolve dns names in situation when other tools are resolving without > issue (due to correct hostname set, what should be also acceptable > configuration for proper name resolving in local domain) Alright, but then I think it would be better to factor out using ibft, I believe the behaviour will be the same for normal static configuration.
(In reply to comment #5) > Jirka, do you have any hint? ibft is configured to use dhcp but NM seems to use > static configuration using ibft values, shouldn't it do dhcp too?. Marian says > in description that without ibft, using dhcp (that is BOOTPROTO=dhcp) name > resolution works as expected. > As you have written, NM parses "iscsiadm -m -fw" output and uses its values when BOOTPROTO=ibft. > # BEGIN RECORD 2.0-872 > iface.initiatorname = iqn.2000-01.org.etherboot:system1 > iface.hwaddress = 52:54:00:12:34:56 > iface.bootproto = STATIC and there is static configuration. That's why static IPs are used instead of dhcp. As far as DNS domains are concerned, I'm not sure how to handle that. It appears there's no configuration in ibft for that. So nothing is added to "search" directive in resolv.conf at the moment. Maybe, NM could parse standard DOMAIN directive? DEVICE=eth0 HWADDR=52:54:00:12:34:56 ONBOOT=yes TYPE=Ethernet BOOTPROTO=ibft DOMAIN="mysearch.domain.com"
Please open a new bug and specify clearly expected behaviour to prevent misunderstandings when evaluating and handling this bug. The description and bug summary are misleading. E.g. it is not clear to me if you expect iBFT static configuration to behave differently than normal static configuration (because now it does not) or you want a change of static configuration behaviour (wrt of domain setting) in general.
Understood, closing this one. New bug coming soon