Description of problem: Tried to install Fedora-Live-KDE-x86_64-22_Beta-3.iso as VM into F21. Filled in the basincs in anaconda, pressed Begin installation. Version-Release number of selected component: anaconda-core-22.20.9-1.fc22.x86_64 The following was filed automatically by anaconda: anaconda 22.20.9-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 370, in processActions if dep.exists and dep.dependsOn(action.device.disk): File "/usr/lib/python2.7/site-packages/blivet/blivet.py", line 162, in doIt self.devicetree.processActions(callbacks) File "/usr/lib/python2.7/site-packages/blivet/osinstall.py", line 1058, in turnOnFilesystems storage.doIt(callbacks) File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 196, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall, callbacks=callbacks_reg) File "/usr/lib64/python2.7/threading.py", line 766, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 244, in run threading.Thread.run(self, *args, **kwargs) AttributeError: 'DiskDevice' object has no attribute 'disk' Additional info: cmdline: /usr/bin/python2 /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-KDE-x86_64-22_B-3 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.0.0-0.rc5.git4.1.fc22.x86_64 other involved packages: python-blivet-1.0.7-1.fc22.noarch, python-libs-2.7.9-5.fc22.x86_64 product: Fedora release: Fedora release 22 (Twenty Two) type: anaconda version: 22
Created attachment 1022796 [details] File: anaconda-tb
Created attachment 1022797 [details] File: anaconda.log
Created attachment 1022798 [details] File: environ
Created attachment 1022799 [details] File: journalctl
Created attachment 1022800 [details] File: lsblk_output
Created attachment 1022801 [details] File: nmcli_dev_list
Created attachment 1022802 [details] File: os_info
Created attachment 1022803 [details] File: program.log
Created attachment 1022804 [details] File: storage.log
Created attachment 1022805 [details] File: ifcfg.log
The journal/log is contains many of theses messages: May 06 16:38:12 localhost kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 May 06 16:38:12 localhost kernel: ata1.00: BMDMA stat 0x4 May 06 16:38:12 localhost kernel: ata1.00: failed command: WRITE DMA May 06 16:38:12 localhost kernel: ata1.00: cmd ca/00:18:00:00:00/00:00:00:00:00/e0 tag 0 dma 12288 out res 41/04:18:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error) May 06 16:38:12 localhost kernel: ata1.00: status: { DRDY ERR } May 06 16:38:12 localhost kernel: ata1.00: error: { ABRT } May 06 16:38:12 localhost kernel: ata1.00: configured for MWDMA2 May 06 16:38:12 localhost kernel: ata1.01: configured for MWDMA2 May 06 16:38:12 localhost kernel: ata1: EH complete May 06 16:38:12 localhost kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 May 06 16:38:12 localhost kernel: ata1.00: BMDMA stat 0x4 May 06 16:38:12 localhost kernel: ata1.00: failed command: WRITE DMA May 06 16:38:12 localhost kernel: ata1.00: cmd ca/00:18:00:00:00/00:00:00:00:00/e0 tag 0 dma 12288 out res 41/04:18:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error) May 06 16:38:12 localhost kernel: ata1.00: status: { DRDY ERR } May 06 16:38:12 localhost kernel: ata1.00: error: { ABRT } May 06 16:38:12 localhost kernel: ata1.00: configured for MWDMA2 May 06 16:38:12 localhost kernel: ata1.01: configured for MWDMA2 May 06 16:38:12 localhost kernel: ata1: EH complete Please note that my disk on the F21 host is OK. The issue could be in virtualization / (host) kernel. Could you please advice what other logs would help to narrow this down and how to generate them? I used virt-manager to setup the VM. I did not found how to export the VM's configuration from it. I get similar issues when trying to setup any CentOS, F21, F22 VM on my F21 host. Thanks.
Another user experienced a similar problem: Another try to install Fedora-Live-KDE-x86_64-22_Beta-3.iso as VM into F21 host using virt-manager. cmdline: /usr/bin/python2 /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-KDE-x86_64-22_B-3 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 hashmarkername: anaconda kernel: 4.0.0-0.rc5.git4.1.fc22.x86_64 other involved packages: python-blivet-1.0.7-1.fc22.noarch, python-libs-2.7.9-5.fc22.x86_64 package: anaconda-core-22.20.9-1.fc22.x86_64 packaging.log: product: Fedora reason: AttributeError: 'DiskDevice' object has no attribute 'disk' release: Fedora release 22 (Twenty Two) version: 22
Created attachment 1023274 [details] journalctl log from the F21 host (commented) Comments in the journalctl log show: - When the virt-manager was started - beginning of the log. - When New Virtual Machine was (started to be) created. The anaconda in the F22 guest crashes right after Begin Installation is pressed. It was at 23:13:20 of the host's time. There are no messages in the host's log after 07 23:08:23.
Reassigning to kernel based on comment 11
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.