Bug 865247
| Summary: | FormatSetupError: invalid device specification | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Vít Ondruch <vondruch> | ||||||||||||||||||||||||||||
| Component: | anaconda | Assignee: | David Lehman <dlehman> | ||||||||||||||||||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||||||
| Version: | 18 | CC: | awilliam, g.kaviyarasu, jonathan, vanmeeuwen+fedora, vhumpa | ||||||||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||||||||||
| Whiteboard: | abrt_hash:df19160bac314502742d95a311e065b4428e6056236d75f88d5f7f3e784baa97 | ||||||||||||||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||||||||||
| Last Closed: | 2012-11-23 04:43:25 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: | |||||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||||
Created attachment 625321 [details]
File: anaconda-tb
Created attachment 625322 [details]
File: product
Created attachment 625323 [details]
File: type
Created attachment 625324 [details]
File: storage.log
Created attachment 625325 [details]
File: version
Created attachment 625326 [details]
File: environ
Created attachment 625327 [details]
File: anaconda.log
Created attachment 625328 [details]
File: syslog
Created attachment 625329 [details]
File: hashmarkername
Created attachment 625330 [details]
File: packaging.log
Created attachment 625331 [details]
File: cmdline_file
Created attachment 625332 [details]
File: release
Created attachment 625333 [details]
File: program.log
*** Bug 866372 has been marked as a duplicate of this bug. *** anaconda-18.19-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.19-1.fc18 Package anaconda-18.19-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.19-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16528/anaconda-18.19-1.fc18 then log in and leave karma (feedback). This works in TC6. Nevertheless, the password is cached in between luks volumes, e.g. I unlock one volume, click on other and the password is pre-entered. Is that intentional? I would say the field should be reset after unlock. (In reply to comment #17) > This works in TC6. > > Nevertheless, the password is cached in between luks volumes, e.g. I unlock > one volume, click on other and the password is pre-entered. Is that > intentional? I would say the field should be reset after unlock. It is intentional. In the past, we have gone so far as to unlock any other volumes that use the same passphrase to prevent users from having to enter the same passphrase several times. (In reply to comment #18) > (In reply to comment #17) > > This works in TC6. > > > > Nevertheless, the password is cached in between luks volumes, e.g. I unlock > > one volume, click on other and the password is pre-entered. Is that > > intentional? I would say the field should be reset after unlock. > > It is intentional. In the past, we have gone so far as to unlock any other > volumes that use the same passphrase to prevent users from having to enter > the same passphrase several times. But you are not going that way anymore I suppose, or is it regression? Since I have to unlock every volume separately, although using the same password. This bug looks to have been fixed for many anaconda builds now but missed being closed. If you find you are still experiencing it with Fedora 18 Beta (RC1) or later, please re-open the bug. (ref comment #17) |
Description of problem: 1. Enter password for encrypted volume 2. Press Unlock Version-Release number of selected component: anaconda-18.14 Additional info: libreport version: 2.0.14 cmdline: /usr/bin/python /sbin/anaconda kernel: 3.6.1-1.fc18.x86_64 description: :The following was filed automatically by anaconda: :anaconda 18.14 exception report :Traceback (most recent call first): : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/__init__.py", line 342, in setup : raise FormatSetupError("invalid device specification") : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/luks.py", line 168, in setup : DeviceFormat.setup(self, *args, **kwargs) : File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1837, in on_unlock_clicked : device.format.setup() :FormatSetupError: invalid device specification