Description of problem: During the HDD preparation Anaconda unexpectedly crashed. It seems the reason is that disk is damaged/corrupted and application was not able to handle this type of error properly. Version-Release number of selected component: anaconda-20.25.15-1.fc20.i686 The following was filed automatically by anaconda: anaconda 20.25.15-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/formats/disklabel.py", line 292, in commit raise DiskLabelCommitError(msg) File "/usr/lib/python2.7/site-packages/blivet/formats/disklabel.py", line 269, in create self.commit() File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 473, in execute options=self.device.formatArgs) File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 244, in processActions action.execute() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 308, in doIt self.devicetree.processActions() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 167, in turnOnFilesystems storage.doIt() File "/usr/lib/python2.7/site-packages/pyanaconda/install.py", line 142, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall) File "/usr/lib/python2.7/threading.py", line 764, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib/python2.7/site-packages/pyanaconda/threads.py", line 192, in run threading.Thread.run(self, *args, **kwargs) DiskLabelCommitError: Could not commit to disk /dev/sda, (py_ped_disk_commit) Additional info: cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat rw rd.live.image rd.live.overlay=LABEL=LIVE quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 rd.live.check BOOT_IMAGE=vmlinuz0 executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.11.10-301.fc20.i686 other involved packages: python-blivet-0.23.9-1.fc20.noarch, python-libs-2.7.5-9.fc20.i686 product: Fedora release: Fedora release 20 (Heisenbug) type: anaconda version: 20
Created attachment 857326 [details] File: anaconda-tb
Created attachment 857327 [details] File: anaconda.log
Created attachment 857328 [details] File: environ
Created attachment 857329 [details] File: journalctl
Created attachment 857330 [details] File: lsblk_output
Created attachment 857331 [details] File: nmcli_dev_list
Created attachment 857332 [details] File: os_info
Created attachment 857333 [details] File: program.log
Created attachment 857334 [details] File: storage.log
Created attachment 857335 [details] File: ifcfg.log
You have bad cdrom or drive: Jan 30 07:11:36 localhost.localdomain kernel: ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen Jan 30 07:11:36 localhost.localdomain kernel: ata1.00: failed command: READ FPDMA QUEUED Jan 30 07:12:13 localhost.localdomain kernel: sr0: CDROM (ioctl) error, command: Read TOC/PMA/ATIP 43 00 00 00 00 00 00 00 0c 00 Run the media check from the boot menu to check the cd.
Could you please consider reopening the issue, as those messages are from the guest. There is no indication that the F21 host's (real) drive is failing or has any issues. I used the default virt-manager setup. I used the same approach, as I used to run F20 guest on F20 host, which worked fine. This F21 was upgraded from the F20 using fedup. Could it be host/guest's kernel, VM, virt-manager issue? Anaconda might not be the culprit. I am not an linux expert, just a user for 10+ years. Could you please have a look and reassign to a better component as needed? I have just tried to install Fedora-Live-KDE-x86_64-20-1.iso in VM on my F21 (host) using the same steps, I ran into a similar bug. When I reported the bug, it was marked as a duplicate of #1059512. It seems, I am not able to install any VM using using F20/F22 Live/Netinst ISOs on my F21. All ISOs pass the sha256sum -c ..-CHECKSUM test.
(In reply to Tomas Toth from comment #12) > Could you please consider reopening the issue, as those messages are from > the guest. There is no indication that the F21 host's (real) drive is > failing or has any issues. Open a bug against the kernel and include the output of dmesg from the guest. Based on the logs you posted, the cdrom is inaccessible at a (virtual) hardware level, and there's nothing anaconda can do about that.