RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1292928 - "systemctl enable initial-setup-graphical.target" is not working when VM is created from template
Summary: "systemctl enable initial-setup-graphical.target" is not working when VM is c...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: pre-dev-freeze
: ---
Assignee: Radek Vykydal
QA Contact: Release Test Team
URL:
Whiteboard: network
: 1304536 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-18 19:00 UTC by Kumar Mashalkar
Modified: 2020-03-20 09:00 UTC (History)
18 users (show)

Fixed In Version: anaconda-21.48.22.71-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 23:21:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
journalctl_-a (158.43 KB, text/plain)
2016-06-01 13:17 UTC, Kumar Mashalkar 		no flags Details
tmp_anaconda.log (4.64 KB, text/plain)
2016-06-01 13:17 UTC, Kumar Mashalkar 		no flags Details
tmp_ifcfg.log (2.67 KB, text/plain)
2016-06-01 13:18 UTC, Kumar Mashalkar 		no flags Details
anaconda.log grabbed from nfs server (17.50 KB, text/plain)
2016-06-02 08:29 UTC, Radek Vykydal 		no flags Details
ifcfg.log grabbed from the nfs server (1.27 KB, text/plain)
2016-06-02 08:30 UTC, Radek Vykydal 		no flags Details
syslog grabbed from the nfs server (71.90 KB, text/plain)
2016-06-02 08:30 UTC, Radek Vykydal 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1265593 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHEA-2016:2158 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2016-11-03 13:13:55 UTC

Internal Links: 1265593

Description Kumar Mashalkar 2015-12-18 19:00:49 UTC 
Description of problem:
"systemctl enable initial-setup-graphical.target" is not working when VM is created from template.

Version-Release number of selected component (if applicable):
RHEVM 3.4

How reproducible:
After following this article "https://access.redhat.com/solutions/198693"
create a vm from the template.


Steps to Reproduce:
1. Clean the vm
2. Create template out of it.
3. Create new vm from it. 


Actual results:
After first root login we can see:

ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1450449887 
------------------
Below is the output of ABRT:
SettingsNotFoundError: SettingsNotFoundError('eth0')
reason:         nm.py:760:nm_device_setting_value:SettingsNotFoundError: SettingsNotFoundError('eth0',)
time:           Fri 18 Dec 2015 07:11:53 PM IST
cmdline:        python -m initial_setup
package:        initial-setup-0.3.9.30-1.el7
uid:            0 (root)
count:          8
Directory:      /var/spool/abrt/Python-2015-12-18-19:11:53-809
-------------------

Expected results:
It should ask for root password, Timezone, Hostname, etc at first boot.

Additional info:
When we follow above article and reboot the vm we are getting expected screen where we can input root password,etc. But when we redo above steps create template and again create vm from it, It is not working.
Comment 2 Michal Skrivanek 2016-01-08 17:37:28 UTC 
related to some net device manipulation we may be doing?
Comment 3 Dan Kenigsberg 2016-01-10 14:52:40 UTC 
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?
Comment 4 Kumar Mashalkar 2016-01-11 05:39:32 UTC 
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.
Comment 5 Dan Kenigsberg 2016-01-12 14:51:11 UTC 
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?
Comment 6 Kumar Mashalkar 2016-01-18 02:11:58 UTC 
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.
Comment 7 Dan Kenigsberg 2016-01-18 09:52:34 UTC 
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?
Comment 8 Martin Sivák 2016-01-18 10:33:19 UTC 
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
Comment 9 Kumar Mashalkar 2016-01-19 07:28:24 UTC 
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?
Comment 13 Dan Kenigsberg 2016-01-31 15:50:41 UTC 
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)
Comment 14 Martin Kolman 2016-02-02 09:03:25 UTC 
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.
Comment 19 Brian Lane 2016-05-26 20:59:08 UTC 
*** Bug 1304536 has been marked as a duplicate of this bug. ***
Comment 20 Radek Vykydal 2016-05-30 11:28:37 UTC 
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.
Comment 21 Kumar Mashalkar 2016-06-01 13:17:20 UTC 
Created attachment 1163648 [details]
journalctl_-a
Comment 22 Kumar Mashalkar 2016-06-01 13:17:58 UTC 
Created attachment 1163649 [details]
tmp_anaconda.log
Comment 23 Kumar Mashalkar 2016-06-01 13:18:22 UTC 
Created attachment 1163650 [details]
tmp_ifcfg.log
Comment 25 Radek Vykydal 2016-06-01 15:27:08 UTC 
I've grabbed the files from the nfs server.
Comment 26 Radek Vykydal 2016-06-02 08:29:16 UTC 
Created attachment 1163968 [details]
anaconda.log grabbed from nfs server
Comment 27 Radek Vykydal 2016-06-02 08:30:01 UTC 
Created attachment 1163969 [details]
ifcfg.log grabbed from the nfs server
Comment 28 Radek Vykydal 2016-06-02 08:30:36 UTC 
Created attachment 1163970 [details]
syslog grabbed from the nfs server
Comment 29 Radek Vykydal 2016-06-02 08:32:04 UTC 
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.
Comment 30 Jan Stodola 2016-06-02 11:21:49 UTC 
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)
Comment 31 Radek Vykydal 2016-06-02 14:05:20 UTC 
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.
Comment 34 Nanda Kishore Chinnaram 2016-07-17 17:11:37 UTC 
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?
Comment 35 Martin Kolman 2016-07-20 13:02:45 UTC 
(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.
Comment 36 Nanda Kishore Chinnaram 2016-07-20 13:53:46 UTC 
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 ?
Comment 38 errata-xmlrpc 2016-11-03 23:21:00 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.