Hide Forgot
Created attachment 837564 [details] The exception information the system record. Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Boot in EFI mode from DVD. 2. Turn to "STORAGE" configuration when the anaconda GUI load up. 3. Choose "Custom partitioning", delete all the partitions that already existed. 4. Add new mount point as "/", capacity set 51200MB, fs set xfs. Then just click "done" and "accept changes". Here, I do not create any other partitions(even the *ESP*) in order to find out what will happen while some errors exist in the partitions configuration. 5. When turned back to the "installation summary page"(I'v no idear how to name it, just call it like this), *TRY* to turn to "STORAGE" configuration again. Actual results: 1. After step 4, turn to the anaconda "installation summary page", and "Error checking storage configure" alarm shows on it. 2. After step 5, the anaconda crash or halted and the GUI cannot refresh. Sometimes a exception threw, but sometimes not. Expected results: 1. After step 5, I can continue the configuration of partition, util the configure is correct. Additional info:
Created attachment 839292 [details] anaconda-tb
Looks similar to bug 974255
Yes to Comment #3.
In trying to reproduce this bug I instead reproduced 1032654.
Posted a patch set for review that does not directly address this problem but ought to help clarify it a bit. It's the same patch that I posted for #974255 a while ago.
Steps to reproduce #1032654 are pretty simple. 1) qemu-kvm -hda disk1 -hdb disk2 -m 1G -cdrom boot.iso 2) Choose "Installation Destination" spoke 3) Select both disks, press "Done" 4) In "Installation Options" dialogue select "Automatically configure" and press "Continue" 5) Select "Installation Destination" spoke 6) Press "Done" 7) In "Installation Options" dialogue choose "I want to review/modify" and press "Continue" 7a) Choose "Click here to create them automatically" 8) Press "Done" and in "Summary of Changes" dialogue press "Accept Changes" 9) Choose "Installation Destination" spoke once more 10) Unselect first disk, and press "Done" 11) In "Installation Options" dialogue choose "Custom Partitioning" At the last step you go directly back to the main hub and get the stack trace noted above.
Or, 1) In "Installation Destination" select both disks and click "Done". 2) In "Installation Options" dialogue choose "I want to review/modify" and press "Continue" 3) Add a new mountpoint as specified in original report and press "Done" 4) In "Summary of Changes" dialog press "Accept Changes" 5) Choose "Installation Destination" again, unselect first disk, and press "Done" 6) In "Installation Options" dialogue choose "Custom Partitioning" 7) Return immediately to main hub and encounter same stack trace
There's little point in splitting these out to separate bugs because they all fit into the larger category of DeviceFormat objects, i.e., instances of DeviceFormat and not of any of its subclasses, ending up where they don't belong.
An interesting point is that the ids obtained by the Python id function don't seem to be behaving as appropriate. That is, I can find the id generated like this for the particular format where the crash occurs. Then, I can search for that id among the ids of all the DeviceFormat objects returned by getFormat (with a little editing of the code to log this), and I can't find that id among any of the device formats so generated. If I generate an internal counter-based id for every DeviceFormat, I can locate the one at the failure point and also where it was first generated quickly and precisely. This is a strong argument for switching over to this kind of id, especially as they are generated in sequence, which is useful to a person debugging. It is probably a good idea to come up with an abstraction for this.
As it happens, the format which is the culprit in this case is the one with id (2), the format generated for the first disk examined, which is a DiskDevice. The previous formats aren't associated w/ any device, but represent the default filesystem.
It is likely that the commit that fixed #1027845 (ec045750ff8d63bedd7a2eb5860b24b8a0b016aa) should be cherry-picked to this branch. It removes devices that the user removes, instead of just hiding them.
Pushed patch described in Comment#6 to master.
Posted another patch that should make the logging in storage.log more informative for debugging DeviceFormat has no attribute errors like this one.
I couldn't reproduce the original bug. I used method described here: https://fedoraproject.org/wiki/Testing_secureboot_with_KVM.
Pushed patch described in Commment #14 to master.
*** Bug 1034324 has been marked as a duplicate of this bug. ***
Please let me know if you can still reproduce this in current version. Thanks! - mulhern
(I didn't actually do this, but I'd be willing to bet some cash it is accurate.) Steps to reproduce: 1. set up an lvm layout that spans two disks in custom spoke 2. return to disk selection and hide one of the two disks 3. return to the custom spoke and try to change the size of an lv in the aforementioned vg 4. bang! DeviceTree.hide needs some code to make sure that when it cancels creation of a pv it also cancels the rest of that lvm layout (from other disks) since the layout is in all likelihood broken.
Cannot reproduce. I think it's getting to be a candidate for fixed in current version.
Ok. I do get a problem but it shows up slightly differently. 1. Go to Installation Destination spoke 2. Select "custom partitioning" radio button, choose two disks, 8GB and 20GB and press "Continue" 3. On "Manual Partitioning" press Create button. The LVM layout spans the two disks. 4. Press Done and Accept Changes and return to hub. 5. Unselect first disk, make sure "custom partitioning" radio button is selected, press continue. 6. See screenshot for not quite right situation.
Created attachment 863350 [details] Screenshot showing funky display of disk situation that should be cleaned up
The attached patch fails miserably because it creates cyclical dependencies in the action graph which therefore can not be topologically sorted. It may actually succeed in doing the correct thing in devicetree.DeviceTree.hide.
Created attachment 864826 [details] Patch that doesn't work
Created attachment 865197 [details] Possible fix to half the problem New patch that leads to Unknown OS/Unknown format display in custom spoke which is probably correct.
The Unknown OS/Unknown Format display then leads the the same stack trace as with bz#1032895.
Unknown OS/Unknown format is ok, but "New Rhel7..." page should be there as well, even if is empty.
Blivet side of patch acked.
bz#996078 has a commit associated with it in master which I think should fix the rest of the problem. Oddly enough, that commit isn't in RHEL7 branch, but bz#996078 has Verified status.
Applying that commit results in a stack trace because the accordion is empty since the partition is no longer in unusedDevices but the "New ..." page is not made either. list index out of range at @line 1020 firstPage = self._accordion.allPages[0]
Posted again.
Things are better, with a blivet only patch set, which improves the removal of devices and actions in devicetree.DeviceTree.hide(). So, when we get rid of the disk, lvs and pvs get removed and we end up back at the special CreateNew page. What is still going wrong is that there is virtually no space on the one remaining device.
Created attachment 866415 [details] Screenshot showing CreateNew screen with almost no free space The CreateNew page is correct, but that missing free space is wrong.
The problem is that shouldClear() returns False on this disk because: 1) self.config.clearNonExistent is False and 2) it's a disk 3) it's format does not exist It's format is DiskLabel. After all other actions have been canceled two actions remain: A destroy format and a create format. The second action creates the DiskLabel format which does not exist, replacing the DeviceFormat, which does exist. The other action destroys the format. It's these two actions which are causing the problem, looks like.
Comment #34 diagnosis is incorrect. I believe that shouldClear is doing the correct thing and that it is probably subsequent code in getFreeSpace() that calculates available free space incorrectly. The DestroyFormat and CreateFormat actions would be created automatically even if no other action were taken.
It seems that the problem is that the remaining disk, sdc, has a format of DiskLabel when it should have a format of DeviceFormat. It still has the two associated actions, destroy format DeviceFormat and CreateFormat disklabel.
Posted again. At this point it is believed that there are no more remaining problems to be fixed.
Tiny anaconda side of this acked by vpodzime, but most of it is on blivet side.
Pushed tiny anaconda side, which is independent, posted new version of blivet side.
Posted again with a much simpler patch.
Posted and acked.
Verified on: RHEL-7.0-20140314.0 python-blivet-0.18.32-1.el7
This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request.