Description of problem: I was using the GUI to build a new virtual machine using Fedora19 x86_64 netinst ISO, a pair of local repositories, and a kickstart file. This is the first time I have tried this combination. I tried using the GUI because text mode was spinning on "Starting automated install...................................................". I was hoping to get more information. Version-Release number of selected component: anaconda-19.30.13-1 The following was filed automatically by anaconda: anaconda 19.30.13-1 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1231, in _selectYumGroup raise NoSuchGroup(groupid) File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1336, in _applyYumSelections self._selectYumGroup("core") File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1410, in checkSoftwareSelection self._applyYumSelections() File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1497, in preInstall self.checkSoftwareSelection() File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 159, in doInstall payload.preInstall(packages=packages, groups=payload.languageGroups()) File "/usr/lib64/python2.7/threading.py", line 764, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run threading.Thread.run(self, *args, **kwargs) NoSuchGroup: core Additional info: cmdline: /usr/bin/python /sbin/anaconda cmdline_file: method=http://host.hunter.org/repos/fedora19/iso ks=http://host.hunter.org/repos/Test-ks.cfg executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.9.5-301.fc19.x86_64 product: Fedora release: Cannot get release name. type: anaconda version: 19
Created attachment 769766 [details] File: anaconda-tb
Created attachment 769767 [details] File: anaconda.log
Created attachment 769768 [details] File: environ
Created attachment 769769 [details] File: ks.cfg
Created attachment 769770 [details] File: lsblk_output
Created attachment 769771 [details] File: nmcli_dev_list
Created attachment 769772 [details] File: os_info
Created attachment 769773 [details] File: program.log
Created attachment 769774 [details] File: storage.log
Created attachment 769775 [details] File: syslog
Created attachment 769776 [details] File: ifcfg.log
Created attachment 769777 [details] File: packaging.log
The problem continues even after I found the correction to bug # 981847. The problem may be resolved by using the DVD ISO file instead of the netinst ISO file in virt-install or virt-manager: virt-install \ --autostart \ --channel unix,path=/var/lib/libvirt/qemu/guest.agent,mode=bind,target_type=virtio,name=org.qemu.guest_agent.0 \ --connect qemu:///system \ --disk vol=Guests/$domain \ --extra-args "inst.ks=file:/$(basename $kickstart)" \ --graphics spice \ --initrd-inject $kickstart \ --location /srv/nfs/ISO/Fedora-$releasever-x86_64-DVD.iso \ --name $domain \ --network network=$vmNetwork \ --os-type "linux" \ --os-variant $osVariant \ --ram 2048 \ --vcpus 2 The first difference I can find between the DVD and netinst ISO files is that the DVD file includes these two files in the root and the netinst file does not: .discinfo .treeinfo And just in case it helps any, the Anaconda packaged with the Fedora 18 netinst file does not have this problem.
You need the group data from comps.xml in your local repos. The full DVD works since the DVD contains a yum repository containing the comps data. http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups has more information on the data and how it is used.
If the group data from comps.xml is required in the local repository then anaconda should say so naming the file that is missing, not fail with a stack trace that only developers can understand. Please fix this to be more useful to the rest of us.
This is a problem to be fixed in the repository, not anaconda. You are using your own repos instead of the Fedora repos, so this is already an exceptional case. A NoSuchGroup error should be enough to tell you that your groups are broken.