Red Hat Bugzilla – Full Text Bug Listing
|Summary:||FormatDestroyError: error wiping old signatures from /dev/tmp: 1|
|Product:||[Fedora] Fedora||Reporter:||Clyde E. Kunkel <clydekunkel7734>|
|Component:||anaconda||Assignee:||David Lehman <dlehman>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||anaconda-maint-list, awilliam, cyberrider, david.filiatrault, jonathan, kparal, pschindl, vanmeeuwen+fedora|
|Fixed In Version:||anaconda-16.22-1.fc16||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-09-24 00:36:35 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Clyde E. Kunkel 2011-07-18 11:27:11 EDT
The following was filed automatically by anaconda: anaconda 16.12 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/__init__.py", line 314, in destroy raise FormatDestroyError(msg) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/deviceaction.py", line 483, in execute self.format.destroy() File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 316, in processActions action.execute(intf=self.intf) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 383, in doIt self.devicetree.processActions() File "/usr/lib64/python2.7/site-packages/pyanaconda/packages.py", line 122, in turnOnFilesystems anaconda.storage.doIt() File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 338, in dispatch self.dir = self.steps[self.step].target(self.anaconda) File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 235, in go_forward self.dispatch() File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1200, in nextClicked self.anaconda.dispatch.go_forward() FormatDestroyError: error wiping old signatures from /dev/tmp: 1
Comment 1 Clyde E. Kunkel 2011-07-18 11:27:18 EDT
Created attachment 513637 [details] Attached traceback automatically from anaconda.
Comment 2 David Lehman 2011-07-18 13:13:38 EDT
Clyde, have you tried again to see if you can reproduce this at will? If you can, I'd like you to do so with an updates.img so I can collect some more information.
Comment 3 Clyde E. Kunkel 2011-07-18 13:40:15 EDT
I have tried, but no luck so far. Other errors occur, however, and am trying to get info together to report them. They did not throw an exception like this, just an error msg box with an ok button. Will try again (and again). preview bzs: selecting preexisting home lv fails with error. an error occuring during bootloader installation (after fixing bootloader) grub2-install fails to populate kernel cmd line with rd_MD_UUID=... and rd_LVM_LV=root lv. These will be in later today and, hopefully, retests for this bz.
Comment 4 Clyde E. Kunkel 2011-07-19 11:23:29 EDT
Cannot reproduce this after 5 ties. Closing.
Comment 5 David Filiatrault 2011-09-05 17:52:40 EDT
Have reproduced this twice using following options: 1. Select "Use All Space" 2. Install Target Device, select a USB stick which is brand new (no prior writes), and select the "Boot Loader" option.
Comment 6 Kamil Páral 2011-09-15 07:27:22 EDT
Reopening. I reproduced this problem with my custom layout. The important part is that the disk partitions must already exist, anaconda then crashes. First I created a new custom layout: vda1 - bios boot vda2 - /boot ext4 vda3 - encrypted LVM vg_opt vda4 - LVM vg_main vg_opt: lv_opt - /opt ext4 vg_main: lv_root - / encrypted ext4 lv_swap - swap First installation went fine. After that I repeated the installation re-using the existing partitions. Then anaconda crashed. Appending logs. anaconda 16.17
Comment 7 Kamil Páral 2011-09-15 07:30:30 EDT
Created attachment 523350 [details] existing_layout.png
Comment 10 Kamil Páral 2011-09-15 07:32:08 EDT
Created attachment 523353 [details] anaconda-tb-Ddv7Ye
Comment 14 Kamil Páral 2011-09-15 07:33:26 EDT
Proposing as Final blocker, since: The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria
Comment 15 David Lehman 2011-09-15 16:41:07 EDT
An updates image is available for those who would like to test/verify a fix. Add the following to the boot command line if interested: updates=http://dlehman.fedorapeople.org/updates-lvm.img
Comment 16 Adam Williamson 2011-09-15 18:16:20 EDT
we are also interested in general testing of RC1 with the updates image, not just specific testing to see if it resolves this bug, but also to see if it causes any other problems.
Comment 17 Kamil Páral 2011-09-16 05:01:22 EDT
I can confirm that the update.img from comment 15 fixes this particular issue.
Comment 18 David Lehman 2011-09-23 10:07:34 EDT
This will be in anaconda-16.19-1.
Comment 19 Fedora Update System 2011-09-23 17:49:04 EDT
anaconda-16.19-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/anaconda-16.19-1.fc16
Comment 20 Fedora Update System 2011-09-24 00:35:41 EDT
anaconda-16.19-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Comment 21 Scott Marshall 2011-10-18 06:14:46 EDT
I've just downloaded the x86_64 Fedora 16 Beta from the fedora project site. It's running Anaconda 16.20. Using a custom layout, I get the results indicated previously. In other words, it still crashes.
Comment 22 Scott Marshall 2011-10-18 06:23:24 EDT
Created attachment 528776 [details] Anaconda 16.20 traceback
Comment 23 Scott Marshall 2011-10-18 06:29:41 EDT
Created attachment 528779 [details] BZIP2 tarball of /tmp/anaconda.log and anaconda traceback NB: The crash *did* occur inside a virtual machine. Specifically, a VirtualBox virtual machine environment running on a Dell Dimension 9150 under Windoze 7 x64. The intention was to test Fedora 16 in various scenarios: * A clean installation * An upgrade from Fedora 15 * An upgrade from Fedora 14 (because I want to avoid the alpha point zero release of Gnome 3 present in Fedora 15)
Comment 24 Scott Marshall 2011-10-18 06:32:21 EDT
So the question I now have is whether the update.img fix mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=722952#c15 is still viable given that the installation media I am using has a later version of anaconda than was originally logged?
Comment 25 David Lehman 2011-10-18 13:06:34 EDT
(In reply to comment #24) > So the question I now have is whether the update.img fix mentioned in > https://bugzilla.redhat.com/show_bug.cgi?id=722952#c15 is still viable given > that the installation media I am using has a later version of anaconda than was > originally logged? The fix from that image is now in anaconda. You have found a way to hit a similar, but different, bug. I think I can reproduce it here. I'll let you know when I have a fix to test. adamw: do you want this handled in a separate bug for tracking purposes?
Comment 26 Scott Marshall 2011-10-18 17:52:26 EDT
(In reply to comment #25) > > The fix from that image is now in anaconda. You have found a way to hit a > similar, but different, bug. I think I can reproduce it here. I'll let you know > when I have a fix to test. > I had been deciding which layout method I was going to use out of "replace existing system" or "custom layout". I had started down the replace existing system track (thinking it would upgrade using the existing layout), but didn't like the way the default (replacement) layout it was going to use, so back-tracked to the selection menu and went down the custom layout track instead. This read the existing LV structure I had from the Fedora 15 VM, and presented them to me for allocation to various file-systems. I elected at this point to create 3 additional LVs in addition to assigning the existing LVs to swap and ext4 file-systems. Now I don't know whether the crash was because I'd started down a different installation path before backing up to choose a custom layout, or not. However, that was what I'd done, so if you're having trouble re-creating the scenario, this may help.
Comment 27 David Lehman 2011-10-18 18:58:26 EDT
It definitely has to do with the fact that you tried initially to reuse your existing root lv without reformatting it. Anyway, I reproduced a bug and I'm fairly certain it's the same one you hit. I have an updates image you can try out if you like: http://dlehman.fedorapeople.org/updates-lvm.2.img
Comment 28 Scott Marshall 2011-10-19 03:08:27 EDT
(In reply to comment #27) > It definitely has to do with the fact that you tried initially to reuse your > existing root lv without reformatting it. Anyway, I reproduced a bug and I'm > fairly certain it's the same one you hit. I have an updates image you can try > out if you like: > > http://dlehman.fedorapeople.org/updates-lvm.2.img Okay, I've added the "updates=http://dlehman.fedorapeople.org/updates-lvm.2.img" argument to the boot line, and that appears to have fixed the problem. I repeated the actions outlined earlier, and this time the system rewrote the LVM structure as I'd defined it. I will repeat the process later with another copy of a VM that I have just to ensure consistency, and will report back when done (probably a couple of days or so). Anyway, so far, so good.
Comment 29 Fedora Update System 2011-10-19 14:43:38 EDT
anaconda-16.22-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/anaconda-16.22-1.fc16
Comment 30 Fedora Update System 2011-10-20 00:03:46 EDT
anaconda-16.22-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.