Bug 1292928

related to some net device manipulation we may be doing?

Based on https://access.redhat.com/solutions/1195453 I am guessing that the VM has eth0 configured to use static IP, but no static IP was provided.

Can you provide VM details via the cloud-init dialog, instead of the first boot?

Hello Dan,

cloud-init is working perfect in this case.

"systemctl enable initial-setup-graphical.target" also works until we create template out of it.

I'm not sure I understand. What happens if you set cloud-init data (particularly, static ip information) for your VM prior to its first boot?

When I set cloud-init for a vm, all the changes(IP,Hostname,Timezone,etc) appear on the vm as desired.

But unfortunately, Customer is not willing to use "could-init" instead of "initial-setup-graphical.target"

And "initial-setup-graphical.target" is not working with RHEL 7.2 when created from template in RHEVM.

Did the steps listed in https://access.redhat.com/solutions/198693 work with a former guest version?

Can you share the content of /etc/sysconfig/network-scripts/ifcfg-* in the template?

I am not familiar with initial-setup-graphical and its network requirement. Would you be kind to test if complete removal of ifcfg-* makes initial-setup happier? If it doesn't, can you share more of its logs?

Martin, do you happen to know initial-setup?

I started the project and wrote and maintained the first version. But I haven't been involved for a long time now.

The code now lives at https://github.com/rhinstaller/initial-setup

There is no explicit network requirement, but it is possible that network is required by systemd's graphical.target.

The unit in question is here:

https://github.com/rhinstaller/initial-setup/blob/rhel7-branch/systemd/initial-setup-graphical.service

1) Did the steps listed in https://access.redhat.com/solutions/198693 work with a former guest version?
>> Yes. It did worked for RHEL 6.7

2) Can you share the content of /etc/sysconfig/network-scripts/ifcfg-* in the template?
>>[root@dhcp8-113 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
Device=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet

3) Would you be kind to test if complete removal of ifcfg-* makes initial-setup happier? If it doesn't, can you share more of its logs?
>> After complete removal of ifcfg-* also no luck.

Below is what I observed:
--------------------------------------------
Last login: Tue Jan 19 11:36:22 IST 2016 on pts/0
ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1453183582
[root@dhcp8-113 ~]# abrt-cli list --since 1453183582
id 80d3dc1d207bd200666e58f66822aa4a61069ff7
reason:         nm.py:760:nm_device_setting_value:SettingsNotFoundError: SettingsNotFoundError('eth0',)
time:           Tue 19 Jan 2016 09:04:47 AM IST
cmdline:        python -m initial_setup
package:        initial-setup-0.3.9.30-1.el7
uid:            0 (root)
count:          2
Directory:      /var/spool/abrt/Python-2016-01-19-09:04:47-2785
Run 'abrt-cli report /var/spool/abrt/Python-2016-01-19-09:04:47-2785' for creating a case in Red Hat Customer Portal
------------------------------------------

From messages:
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  Loaded device plugin: NMBondFactory (internal)
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  Loaded device plugin: NMAtmManager (/usr/lib64/NetworkManager/libnm-device-plugin-adsl.so)
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  Loaded device plugin: NMWifiFactory (/usr/lib64/NetworkManager/libnm-device-plugin-wifi.so)
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  Loaded device plugin: NMTeamFactory (/usr/lib64/NetworkManager/libnm-device-plugin-team.so)
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  WiFi enabled by radio killswitch; enabled by state file
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  WWAN enabled by radio killswitch; enabled by state file
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  WiMAX enabled by radio killswitch; enabled by state file
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  Networking is enabled by state file
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  (eth0): new Ethernet device (carrier: OFF, driver: 'virtio_net', ifindex: 2)
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  (eth0): link connected
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  (lo): link connected
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  (lo): new Generic device (carrier: ON, driver: 'unknown', ifindex: 1)
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com dbus[650]: [system] Activating via systemd: service name='fi.w1.wpa_supplicant1' unit='wpa_supplicant.service'
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com systemd[1]: Configuration file /usr/lib/systemd/system/wpa_supplicant.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com dbus-daemon[650]: dbus[650]: [system] Activating via systemd: service name='fi.w1.wpa_supplicant1' unit='wpa_supplicant.service'
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com NetworkManager[796]: <info>  (eth0): device state change: unavailable -> disconnected (reason 'none') [20 30 0]
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com systemd[1]: Starting WPA Supplicant daemon...
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com dbus[650]: [system] Successfully activated service 'fi.w1.wpa_supplicant1'
Jan 19 11:53:01 dhcp8-113.gsslab.pnq.redhat.com dbus-daemon[650]: dbus[650]: [system] Successfully activated service 'fi.w1.wpa_supplicant1'
--
Jan 19 11:53:10 dhcp8-113.gsslab.pnq.redhat.com xinit[697]: uuid = nm.nm_device_setting_value(device.get_iface(), "connection", "uuid")
Jan 19 11:53:10 dhcp8-113.gsslab.pnq.redhat.com xinit[697]: File "/usr/lib64/python2.7/site-packages/pyanaconda/nm.py", line 760, in nm_device_setting_value
Jan 19 11:53:10 dhcp8-113.gsslab.pnq.redhat.com xinit[697]: raise SettingsNotFoundError(name)
Jan 19 11:53:10 dhcp8-113.gsslab.pnq.redhat.com xinit[697]: pyanaconda.nm.SettingsNotFoundError: SettingsNotFoundError('eth0',)
Jan 19 11:53:10 dhcp8-113.gsslab.pnq.redhat.com postfix/pickup[1688]: EE7892DA7A6: uid=0 from=<user@localhost>
Jan 19 11:53:10 dhcp8-113.gsslab.pnq.redhat.com xinit[697]: Exception AttributeError: "'NoneType' object has no attribute 'udev_unref'" in <bound method Context.__del__ of <pyudev.core.Context object at 0x2be8890>> ignored
-----------------------------------------------

Do you need any specific logs apart from this?

IIUC, the same exception is thrown if initial-setup is run on a physical host that has no ifcfg-* files.

If so, and since the same environment works fine with el6 guests, I suggest to ask initial-setup current maintainers for assistance for surviving ifcfg files with no HWADDR (which is the el7 recommendation due to http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ and hotpluggin)

The networking code that you see crashing is provided by Anaconda (Initial setup is mainly a thin wrapper around Anaconda screens & modules), so any fix will need to go there. Therefore reassigning.

*** Bug 1304536 has been marked as a duplicate of this bug. ***

Please attach installation logs and initial-setup logs which can be found on the installed system at this locations:

/var/log/anaconda/anaconda.log
/var/log/anaconda/syslog
/var/log/anaconda/ifcfg.log

/tmp/ifcfg.log
/tmp/anaconda.log

Also output of
journalctl -a -u

There could be also traceback log found as
/tmp/anaconda-tb* I am not sure, may depend on exact time the traceback occurs.

Created attachment 1163648 [details]
journalctl_-a

Created attachment 1163649 [details]
tmp_anaconda.log

Created attachment 1163650 [details]
tmp_ifcfg.log

I've grabbed the files from the nfs server.

Created attachment 1163968 [details]
anaconda.log grabbed from nfs server

Created attachment 1163969 [details]
ifcfg.log grabbed from the nfs server

Created attachment 1163970 [details]
syslog grabbed from the nfs server

I am not able to reproduce the issue.
I am clueless looking at the logs.
It is well possible the issue is fixed by fix for #1265593.

Steps to reproduce with RHEL-7.2 GA:

1. create a new virtual machine with a virtio network device
2. install with the "Server with GUI" package set or similar (containing initial-setup)
3. reboot when the installation is finished, go through initial-setup and gnome firstboot
4. remove HWADDR= and UUID= from /etc/sysconfig/network-scripts/ifcfg-eth0
5. rm -rf /etc/ssh/ssh_host_*
6. systemctl enable initial-setup-graphical
7. shutdown the guest
8. copy the VM disk image, create a new VM using the copy of the disk image
9. boot the new VM, log in as root and see:

$ ssh root.122.212
Warning: Permanently added '192.168.122.212' (ECDSA) to the list of known hosts.
root.122.212's password: 
Last login: Thu Jun  2 12:57:13 2016 from 192.168.122.1
ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1464865033
[root@localhost ~]# abrt-cli list --since 1464865033
id f8168b605bbd655f9fcbd3726057a692471ce652
reason:         nm.py:760:nm_device_setting_value:SettingsNotFoundError: SettingsNotFoundError('eth0',)
time:           Thu 02 Jun 2016 01:04:52 PM CEST
cmdline:        python -m initial_setup
package:        initial-setup-0.3.9.30-1.el7
uid:            0 (root)
count:          1
Directory:      /var/spool/abrt/Python-2016-06-02-13:04:52-753
Run 'abrt-cli report /var/spool/abrt/Python-2016-06-02-13:04:52-753' for creating a case in Red Hat Customer Portal

The Autoreporting feature is disabled. Please consider enabling it by issuing
'abrt-auto-reporting enabled' as a user with root privileges
[root@localhost ~]#


journalctl contains the traceback (see attachment in comment 21)

Thank you Jan, I reproduced the bug, applied changes for bug #1265593 locally, rebooted and the problem seems to be fixed - I was able to edit eth0 configuration and finish initial setup.

Will this fix be released in RHEL 7.3 ?
I am planning to raise defect for same issue for tracking purpose. If it is confirmed that it will be released in RHEL 7.3 i will not raise issue. Does this sound good ?

Since i am unable to access BZ#1265593 and BZ#1298444, could someone please explain the exact technical cause behind the issue?

(In reply to Nanda Kishore Chinnaram from comment #34)
> Will this fix be released in RHEL 7.3 ?
Yes, it should be part of 7.3.
> I am planning to raise defect for same issue for tracking purpose. If it is
> confirmed that it will be released in RHEL 7.3 i will not raise issue. Does
> this sound good ?
> 
> Since i am unable to access BZ#1265593 and BZ#1298444, could someone please
> explain the exact technical cause behind the issue?
This was caused by a device that does only show on the installed system. We changed the code to handle this case.

Below patch at says that initial setup should not handle the devices that are created by libvirt,
https://github.com/rhinstaller/anaconda/commit/3a58747d870562642f62f00d4897f58a3a05f20b 

So, for similar issue where it shows "nm.py:760:nm_device_setting_value:SettingsNotFoundError: SettingsNotFoundError('virbr0',)", the above patch fixes the issue right ?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-2158.html