Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 722952
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> | ||||||||||||||||||||||
Severity: | medium | Docs Contact: | |||||||||||||||||||||||
Priority: | unspecified | ||||||||||||||||||||||||
Version: | rawhide | CC: | anaconda-maint-list, awilliam, cyberrider, david.filiatrault, jonathan, kparal, pschindl, vanmeeuwen+fedora | ||||||||||||||||||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||||||||||||||||||
Target Release: | --- | ||||||||||||||||||||||||
Hardware: | x86_64 | ||||||||||||||||||||||||
OS: | Linux | ||||||||||||||||||||||||
Whiteboard: | anaconda_trace_hash:7fe6e40fab8cc75390bb874ec005caac17896f897fa3b21e91ba88f7fd438257 | ||||||||||||||||||||||||
Fixed In Version: | anaconda-16.22-1.fc16 | Doc Type: | Bug Fix | ||||||||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||||||||
Last Closed: | 2011-09-24 04:36:35 UTC | Type: | --- | ||||||||||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||||
Embargoed: | |||||||||||||||||||||||||
Bug Depends On: | |||||||||||||||||||||||||
Bug Blocks: | 713568 | ||||||||||||||||||||||||
Attachments: |
|
Description
Clyde E. Kunkel
2011-07-18 15:27:11 UTC
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 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 Created attachment 523350 [details]
existing_layout.png
Created attachment 523351 [details]
new_layout.png
Created attachment 523352 [details]
anaconda.log
Created attachment 523353 [details]
anaconda-tb-Ddv7Ye
Created attachment 523354 [details]
program.log
Created attachment 523355 [details]
storage.log
Created attachment 523356 [details]
syslog
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 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 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. https://admin.fedoraproject.org/updates/anaconda-16.19-1.fc16 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: http://dlehman.fedorapeople.org/updates-lvm.2.img (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. anaconda-16.22-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/anaconda-16.22-1.fc16 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. |