Red Hat Bugzilla – Bug 722952
FormatDestroyError: error wiping old signatures from /dev/tmp: 1
Last modified: 2011-10-20 00:03:46 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
File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/deviceaction.py", line 483, in execute
File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 316, in processActions
File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 383, in doIt
File "/usr/lib64/python2.7/site-packages/pyanaconda/packages.py", line 122, in turnOnFilesystems
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
File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1200, in nextClicked
FormatDestroyError: error wiping old signatures from /dev/tmp: 1
Created attachment 513637 [details]
Attached traceback automatically from anaconda.
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.
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.
Cannot reproduce this after 5 ties. Closing.
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.
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
lv_opt - /opt ext4
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.
Created attachment 523350 [details]
Created attachment 523351 [details]
Created attachment 523352 [details]
Created attachment 523353 [details]
Created attachment 523354 [details]
Created attachment 523355 [details]
Created attachment 523356 [details]
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
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:
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.
I can confirm that the update.img from comment 15 fixes this particular issue.
This will be in anaconda-16.19-1.
anaconda-16.19-1.fc16 has been submitted as an update for Fedora 16.
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.
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.
Created attachment 528776 [details]
Anaconda 16.20 traceback
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)
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?
(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?
(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.
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:
(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:
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.
anaconda-16.22-1.fc16 has been submitted as an update for Fedora 16.
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.