Version-Release number of selected component: anaconda-20.21-1.fc20.x86_64 The following was filed automatically by anaconda: anaconda 20.21-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/formats/__init__.py", line 327, in destroy raise FormatDestroyError(msg) File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 527, in execute self.format.destroy() File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 237, in processActions action.execute() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 310, in doIt self.devicetree.processActions() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 169, in turnOnFilesystems storage.doIt() File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 142, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall) 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) FormatDestroyError: error wiping old signatures from /dev/vda2: 1 Additional info: cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8 cmdline_file: initrd=initrd0.img root=live:CDLABEL=testday-2013-10-10 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.11.2-301.fc20.x86_64 other involved packages: python-blivet-0.22-1.fc20.noarch, python-libs-2.7.5-7.fc20.x86_64 product: Fedora release: Fedora release 20 (Heisenbug) type: anaconda version: 20 Potential duplicate: bug 950593
Created attachment 810804 [details] File: anaconda-tb
Created attachment 810805 [details] File: anaconda.log
Created attachment 810806 [details] File: environ
Created attachment 810807 [details] File: lsblk_output
Created attachment 810808 [details] File: nmcli_dev_list
Created attachment 810809 [details] File: os_info
Created attachment 810810 [details] File: program.log
Created attachment 810811 [details] File: storage.log
Created attachment 810812 [details] File: ifcfg.log
Proposing as a beta blocker: "The installer must be able to remove existing storage volumes; reject or disallow invalid disk and volume configurations without crashing." Is this reproducible? Or did you try again and did it work? It doesn't look like the wipefs worked on vda2 which is reported to be ext4, but I'm uncertain why it failed.
I tried multiple times on the same virtual machine after rebooting.
Can you tell us anything specific about the configuration of the VM that would enable us to reproduce the bug step by step? If so can you run wipefs /dev/vda2 and report the results?
It seems that I have deleted that virtual machine probably because I wasn't able to install Fedora 20 on it. In case it matters, I used testday-2013-10-10.x86_64.iso.
17:38:19,638 INFO program: Running... wipefs -f -a /dev/vda2 17:38:19,650 INFO program: wipefs: error: /dev/vda2: probing initialization failed: No such file or directory Did you somehow do something to cause vda2 to disappear 'behind the installer's back' - fiddle with the disk layout from a terminal during the install process and then not use the 're-scan disks' option in custom partitioning, for instance? The subsequent lsblk output does seem to show vda2 was really not there any more when anaconda tried to write it. The other possibility is some kind of logical fail in anaconda that causes it to delete a partition and later try to format it, I guess. Did you go through multiple partitioning paths (guided, custom)?
I might have run fdisk, gdisk or Disks the first or the second time, but I don't think I've done it afterwards. Yes, I tried both automatic and custom partitioning sometimes even in the same install session.
OK I'd put this in the category of unique configuration, unless there are some really clear and reasonably sane "how to" reproduce steps published. If the anaconda team thinks better behavior is needed since the installer did crash, I'd support a beta freeze exception for a fix. Otherwise -1 blocker when it comes down to it.
Discussed at 2013-10-16 blocker review meetings. As things stand, this seems to be a messy and un-reproducible test scenario, so it is rejected as a blocker for now. If the OP or anyone else can provide a clearly repeatable reproducer for the bug, please re-propose it as a blocker (by re-setting the Blocks: field and clearing 'RejectedBlocker' from the whiteboard field) and it will be re-considered. Thanks.
Docking laptop while resizing HDD cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base --lang en_US.UTF-8 cmdline_file: initrd=initrd0.img root=live:UUID=b167fd7b-0e02-41e8-a2fa-f4b7a119663f rootfstype=ext2 ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 hashmarkername: anaconda kernel: 3.11.6-301.fc20.x86_64 other involved packages: python-libs-2.7.5-8.fc20.x86_64, python-blivet-0.23.2-1.fc20.noarch package: anaconda-20.25.4-1.fc20.x86_64 packaging.log: product: Fedora reason: FormatDestroyError: error wiping old signatures from /dev/dm-4: 1 release: Fedora release 20 (Heisenbug) version: 20
reproducible for me with: Hard install from live media Custom partitionning with: - one empty SSD set as /, swap and boot - one HDD containing an old default F19 install (fedora-root and fedora-home VG) I removed the fedora-root VG on the HDD, then used the actual fedora-home VG with it's /home. This HDD is using LUKS. And I set an other passphrase while Anaconda asked me.
Kevin thanks for the report. Can you reproduce this, and upon getting the crash go to console and find in /tmp the anaconda-tb-xxxxxxx, program.log, and storage.log and post those as separate plain-text attachments? That would be useful.
Sorry, I haven't thought about those logs. In fact, I was in hurry while installing. Couldn't we add in Anaconda where to get logs when it crashes? Or before, as a reminder when we read that it is a prerelease software (It won't be nice to display it for GOLD releases). I'll try to setup a virtual machine to reproduce this.
I can't reproduce this, there are too many possibilities. What was the exact layout from F19? Did you use custom partitioning or guided? Did you encrypt the whole HDD, a partition, or individual LVs? In c18 you say you were resizing the HDD, but I don't see how that fits into the sequence for c19. After removing fedora-root did you try to grow fedora-home?
and I were not able yet to produce a working VM. The F19 layout was one HDD (320 GB) installed from Live F18 and did a fedup to F19. One LV for /, one LV for /home, and other for swap. Last partition was /boot. Only /home was encrypted. I used ext4. In c18 I probably mean while anaconda started the process to write the partition table. But it has nothing to do with docking the laptop. No I didn't tryied to grow fedora-home. In fact, I had hard time understand how to create group volume and manage LV. I just deleted the fedora-root LV, set the fedora-home as home on the HDD and created custom partitioning on the SDD for /, /boot and swap. I thought to increase the fedora-home LV after the install complete. I am going once more to create a F19 VM
I started Fedora KDE 20 installation on Sony Vaio VPCF11Z1E. Custom partitions. Error appeared when I finished root password setup. cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: initrd=initrd0.img root=live:CDLABEL=Fedora-Live-KDE-x86_64-20-1 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 hashmarkername: anaconda kernel: 3.11.10-301.fc20.x86_64 other involved packages: python-blivet-0.23.9-1.fc20.noarch, python-libs-2.7.5-9.fc20.x86_64 package: anaconda-20.25.15-1.fc20.x86_64 packaging.log: product: Fedora reason: FormatDestroyError: error wiping old signatures from /dev/sda7: 1 release: Fedora release 20 (Heisenbug) version: 20
*** Bug 1046944 has been marked as a duplicate of this bug. ***
*** Bug 986094 has been marked as a duplicate of this bug. ***
Is this issue reproduceable with F21?
I have used "dnf system upgrade" for the latest Fedora releases, but before that I haven't encountered this bug any more.