Bug 627153
Created an attachment (id=440861) Attached traceback automatically from anaconda. I chose Basic Storage then Cutom Layout for partionning. Anaconda crashes when I wanted to modify the NTFS partition on my system /dev/sda10. I used Fedora 14 Alpha GNOME Live CD. Created an attachment (id=441993) Attached traceback automatically from anaconda. Can you try with the non-livecd, add updates=http://clumens.fedorapeople.org/627153.img and see if that fixes this issue for you? It would probably help to first verify you hit the problem on the non-livecd before attempting with the updates image. I had the same problem with the F14 alpha DVD. What do we have to do with the .img file ? Thanks for explaining. https://fedoraproject.org/wiki/Anaconda/Updates#Updates_from_the_Network should explain it. Created attachment 445559 [details]
Testing 627153.img anaconda updates
Hello, the 627153.img does not work either. I took the debug file from anaconda. I stay tuned from other updates from you.
Stupid typo. Can you try again with the same URL? It works better but not perfectly. I can now modifiy the NTFS partition information (mount point, shrink it and encrypt it) by selecting it and clicking on the Modify button. However, anaconda does not take into account a mount point set in this dialog box. I want to mount this ntfs partition into a /data folder and anaconda does not seems to add this info. I have no error message however... and other tty seems OK to me. I think that's a separate issue, covered by bug 630140 and possibly bug 628301. Created attachment 452620 [details]
Attached traceback automatically from anaconda.
Hello, the error also happend with Fedora 14 Beta! At first I selected my two linux partitions (ext4, ext2) and deleted them. Now I created a new partition (filesystem: ext2, mountpoint: / ) from the free space. Finally I choosed my existing ntfs-partition and clicked on [modify] the set the mountpoint in the options-dialog, yet the error occurred. -> The crash report was generated. Created attachment 456119 [details]
Attached traceback automatically from anaconda.
Owch! How was this fix not pulled into F14? :( We're probably missing tests for NTFS stuff and general interoperability with Windows systems... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers (In reply to comment #14) > Owch! How was this fix not pulled into F14? :( We're probably missing tests for > NTFS stuff and general interoperability with Windows systems... > > > > -- > Fedora Bugzappers volunteer triage team > https://fedoraproject.org/wiki/BugZappers Odd, a fix for this issue was included in F-14-RC1 according to http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=27c371907d7afa6be837f974c6670a9cdbfad723. I also confirmed the fix is applied to anaconda-14.22-1.fc14.src.rpm. Perhaps that doesn't resolve the issue as expected? Moving back to ASSIGNED. Added a stub to Common_F14_Bugs (https://fedoraproject.org/wiki/Common_F14_bugs#modify_ntfs) to document this failure and note any workarounds/updates.img's when available. That wasn't a fix for this issue. That was a fix for #637319. Different, unrelated bugs. I confirmed that this bug still exists in RC1. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers (In reply to comment #18) > That wasn't a fix for this issue. That was a fix for #637319. Different, > unrelated bugs. I confirmed that this bug still exists in RC1. Ah apologies. That commit I linked to is the only ntfs related commit I found when glancing at the git shortlog for anaconda. Asking clumens for help locating the proper fix. Once identified, I'll supply an updates.img and update the Common_F14_Bug doc. 'unrelated' may be too strong, they may have some relation...but I was involved in testing both bugs and I confirmed that the other one is definitely fixed in rc1 and this one is definitely still present, at least. =) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Clumens directed me to the correct fix for this issue (see http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=1010f3a7db9410c09b41595a3632d7f983a7e5a9). I'll provide an updates.img for testing shortly. I have uploaded an updates.img that includes the fix from comment#21 and is intended to be used with F-14-RC1. The updates.img is available at http://jlaska.fedorapeople.org/updates/627153.img. Instructions for how to use an updates.img are available at http://fedoraproject.org/wiki/Anaconda/Updates. Is someone able to confirm that the updates.img resolves the reported problem? Thanks! AdamW: I'm tempted to close this issue as CLOSED RAWHIDE since it is fixed in rawhide and not intended to be resolved in F-14. Is that the correct resolution? Created attachment 456998 [details]
Attached traceback automatically from anaconda.
*** Bug 649029 has been marked as a duplicate of this bug. *** Created attachment 457268 [details]
Attached traceback automatically from anaconda.
Anaconda -- Basic Storage, Custom Layout, selected an existing NTFS partition, clicked "Edit", then it failed. (In reply to comment #26) > Anaconda -- Basic Storage, Custom Layout, selected an existing > NTFS partition, clicked "Edit", then it failed. Thanks for the feedback Dale. Please see https://fedoraproject.org/wiki/Common_F14_bugs#modify_ntfs for further details on this issue. Created attachment 457444 [details]
Attached traceback automatically from anaconda.
James, (In reply to comment #22) [...] > http://jlaska.fedorapeople.org/updates/627153.img. [...] > Is someone able to confirm that the updates.img resolves the reported problem? I can confirm that with plain F14 release anaconda I have the same problem as described in comment #12. Using the updates image 627153.img allows me to double-click an NTFS partition and see the edit dialog. I did not attempt to change the partition as I have no need to shrink it. side note: unrelated to this I have a RAID assembly problem, but that should not skew the results for this test as the NTFS partition is not even on the same disk as the raid members. Long story short; your updates.img fixes this bug. (In reply to comment #29) > Long story short; your updates.img fixes this bug. Thanks for the feedback Patrick. This issue can probably be CLOSED NEXTRELEASE as we have no mechanism for fixing anaconda in F-14 already. Although, I'm not sure whether we would want to push an update so future live images have this support (unclear). I'll let the anaconda-devel folks weigh in on that. Regardless, this issue will be resolved in rawhide and F-15. Thanks! Created attachment 458196 [details]
Attached traceback automatically from anaconda.
Created attachment 458276 [details]
Attached traceback automatically from anaconda.
Created attachment 460167 [details]
Attached traceback automatically from anaconda.
Created attachment 460921 [details]
Attached traceback automatically from anaconda.
Created attachment 460922 [details]
Attached traceback automatically from anaconda.
Created attachment 461086 [details]
Attached traceback automatically from anaconda.
Created attachment 461216 [details]
Attached traceback automatically from anaconda.
Created attachment 461764 [details]
Attached traceback automatically from anaconda.
Created attachment 461850 [details]
Attached traceback automatically from anaconda.
Created attachment 462407 [details]
Attached traceback automatically from anaconda.
Created attachment 468034 [details]
Attached traceback automatically from anaconda.
Created attachment 472364 [details]
Attached traceback automatically from anaconda.
Created attachment 474749 [details]
Attached traceback automatically from anaconda.
Created attachment 481626 [details]
Attached traceback automatically from anaconda.
Created attachment 483011 [details]
Attached traceback automatically from anaconda.
Created attachment 489668 [details]
Attached traceback automatically from anaconda.
Created attachment 492263 [details]
Attached traceback automatically from anaconda.
Created attachment 494642 [details]
Attached traceback automatically from anaconda.
Created attachment 497237 [details]
Attached traceback automatically from anaconda.
Created attachment 498920 [details]
Attached traceback automatically from anaconda.
Created attachment 499259 [details]
Attached traceback automatically from anaconda.
|
The following was filed automatically by anaconda: anaconda 14.15 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/pyanaconda/iw/partition_ui_helpers_gui.py", line 237, in resizeOptionCB formatcb.set_sensitive(not widget.get_active()) File "/usr/lib/python2.7/site-packages/pyanaconda/iw/partition_ui_helpers_gui.py", line 393, in createPreExistFSOptionSection resizeOptionCB(resizecb, (formatcb, resizesb)) File "/usr/lib/python2.7/site-packages/pyanaconda/iw/partition_dialog_gui.py", line 514, in __init__ (row, self.fsoptionsDict) = createPreExistFSOptionSection(self.origrequest, maintable, row, self.mountCombo, self.storage, luksdev=luksdev) File "/usr/lib/python2.7/site-packages/pyanaconda/iw/partition_gui.py", line 1672, in editPartition isNew = isNew, restrictfs = restrictfs) File "/usr/lib/python2.7/site-packages/pyanaconda/iw/partition_gui.py", line 1640, in editCB self.editPartition(device) AttributeError: 'NoneType' object has no attribute 'set_sensitive'