Description of problem: Happens in post-install phase with current Rawhide Atomic installer nightly images, see e.g. https://openqa.stg.fedoraproject.org/tests/15371 . I believe this is caused by the setup method of the Timezone class in pyanaconda/kickstart.py, which assumes it can just add chrony to the list of packages to install and then add chronyd to the list of the services to enable, without considering the install methods (Atomic and live) where packages are not used. I believe this would also break on a live image that happened not to include chrony. Version-Release number of selected component: anaconda-25.9-1 The following was filed automatically by anaconda: anaconda 25.9-1 exception report Traceback (most recent call first): File "/usr/lib64/python3.5/site-packages/pyanaconda/iutil.py", line 789, in enable_service raise ValueError("Error enabling service %s: %s" % (service, ret)) File "/usr/lib64/python3.5/site-packages/pyanaconda/kickstart.py", line 1665, in execute iutil.enable_service(svc) File "/usr/lib64/python3.5/site-packages/pyanaconda/install.py", line 79, in doConfiguration ksdata.services.execute(storage, ksdata, instClass) File "/usr/lib64/python3.5/threading.py", line 862, in run self._target(*self._args, **self._kwargs) File "/usr/lib64/python3.5/site-packages/pyanaconda/threads.py", line 253, in run threading.Thread.run(self, *args, **kwargs) ValueError: Error enabling service chronyd: 1 Additional info: addons: com_redhat_kdump, com_redhat_docker cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-Rawhide-x86_64 quiet executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.6.0-0.rc5.git1.1.fc25.x86_64 product: Fedora release: Cannot get release name. reproducible: Not sure how to reproduce the problem type: anaconda version: rawhide
Created attachment 1152403 [details] File: anaconda-tb
Created attachment 1152404 [details] File: anaconda.log
Created attachment 1152405 [details] File: environ
Created attachment 1152406 [details] File: lsblk_output
Created attachment 1152407 [details] File: lvm.log
Created attachment 1152408 [details] File: nmcli_dev_list
Created attachment 1152409 [details] File: os_info
Created attachment 1152410 [details] File: program.log
Created attachment 1152411 [details] File: storage.log
Created attachment 1152412 [details] File: syslog
Created attachment 1152413 [details] File: ifcfg.log
So interestingly the setup method logic here is quite old; https://github.com/rhinstaller/anaconda/commit/db800dc1bcb62cb8f811adae09a5b07c4f71ea5f doesn't seem like its changes to kickstart.py would have triggered this. *But* I'm wondering if the move of where the setup method is actually called - from pyanaconda/ui/gui/spokes/datetime_spoke.py to pyanaconda/install.py - might be the culprit. Maybe when it was in the spoke it didn't get run on Atomic installs, but when it's in install.py it does?
Still happening - https://openqa.fedoraproject.org/tests/18178 is the failure for 20160519.n.0.
is anyone planning on fixing this any time soon? Install from the Atomic installer image has been broken in Rawhide for a month and a half now...
I hit this as well. I noticed that something along the way added a %packages section with chronyd in it, which of course isn't going to work on an atomic install.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
Still broken, more than three months now. Does anyone actually care about this image?
Similar problem has been detected: Tried to install Fedora Atomic from Fedora-25-20160815.n.2, this showed during installation in "configuring installed system" phase. addons: com_redhat_docker, com_redhat_kdump cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-25-x86_64 quiet hashmarkername: anaconda kernel: 4.8.0-0.rc1.git0.1.fc25.x86_64 package: anaconda-25.20-1 packaging.log: product: Fedora reason: ValueError: Error enabling service chronyd: 1 release: Cannot get release name. version: 25
Atomic Host specifically uses systemd-timesyncd since https://pagure.io/fedora-atomic/c/56d268f30c6f479141802f7ad3cfc9806dd47625?branch=master See also https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YZBPJWXYG2RGSVJS5GMCIZFW6RW4QYKL/
So anaconda supports both models of: - Kickstart explicitly specifying NTP servers - Propagating DHCP-specified servers The former makes sense, but I don't think Anaconda should be in the business of the latter. It is actively a bad idea when doing server-side image generation (e.g. Fedora cloud images, consumed downstream) - we don't want every user of those images to try to reach the (possibly/likely) internal servers, and also doesn't work for mobile clients. Oh, actually it looks like what's breaking here is the Anaconda code explicitly parses the chrony defaults that came in the installer, then ends up trying to write them back, which seems unnecessary at best. Basically, I think there are two paths: - Admin explicitly specified servers in kickstart or UI; we should suppor this probably, though we'd have to grow some abstraction over timesyncd/chrony/ntpd - For everything else, once NM grows support for propagating DHCP ( https://bugzilla.gnome.org/show_bug.cgi?id=746911 ), we don't need to do this in Anaconda, and it automatically works for mobile clients. In the short term...if we patched Anaconda to keep track internally of when it used the defaults, then we wouldn't try to write the config file or start chrony, which I think is simplest.
I spent a while reading the code, convinced that it was datetime.py configuring ksdata.ntpservers, but what's actually going wrong is a lot simpler: ntp.py just assumes that unless `--nontp` is passed, we should install and enable chrony. So...given Server uses ntpd, Workstation already has chrony installed an enabled, and Atomic Host uses timesyncd, it seems we could just remove the "install and enable" logic and have it be a per-product decision.
https://github.com/rhinstaller/anaconda/pull/761
for some reason install has worked on 25 since Fedora-25-20160902.n.0...not sure why, no obviously related package changed that day. Did someone work around it in a kickstart? But this bug still occurs on Rawhide.
The above PR links to https://pagure.io/fedora-atomic/pull-request/11
why's rawhide still hitting this, then?
*** Bug 1379173 has been marked as a duplicate of this bug. ***
This seems to be fixed.
Similar problem has been detected: This crash happened during the final stage of an F25 kickstart install addons: com_redhat_kdump, com_redhat_docker cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img ks=http://mirror.ini.cmu.edu/ks/F25/kvmsrv25.ks nomodeset ip=eno1:dhcp hashmarkername: anaconda kernel: 4.8.6-300.fc25.x86_64 package: anaconda-25.20.8-1 product: Fedora reason: ValueError: Error enabling service libvirt-guests: 1 release: Cannot get release name. version: 25
Similar problem has been detected: This happens at the very end of an F25 kickstart install. Apologies if this is a dupe! addons: com_redhat_kdump, com_redhat_docker cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img ks=http://mirror.ini.cmu.edu/ks/F25/kvmsrv25.ks nomodeset ip=eno1:dhcp hashmarkername: anaconda kernel: 4.8.6-300.fc25.x86_64 package: anaconda-25.20.8-1 product: Fedora reason: ValueError: Error enabling service libvirt-guests: 1 release: Cannot get release name. version: 25
*** Bug 1442856 has been marked as a duplicate of this bug. ***