On Thu, 2014-01-30 at 09:33 +0100, Martin Kolman wrote:
On Wed, 2014-01-29 at 13:16 -0600, David Lehman wrote:
> On Wed, 2014-01-29 at 19:01 +0100, Martin Kolman wrote:
> > While I have not been able to track down the one mysterious on_selected_clicked
callback
> > that was wiping out the users disk choice, just saving the results once the
disk is selected
> > also solves the issues and saves the user the need to click on the "Update
Settings" button.
> >
> > Hopefully this won't trigger something else in the custom partitioning
minefield.
>
> See anaconda commit 77cec673a4e06d7f.
Well, that code is already there in both master & rhel7-branch. For the
matter, it appears to be equally broken in both Fedora and RHEL7.
Whoops -- so much for the simple solution.
BTW, this is what I do to reproduce the issue on both Fedora & RHEL7:
0) I prepare a VM with at least 2 disks
1) use a kickstart with "autopart --type=plain", so that standard
partitioning is the default partitioning method
2) start the installation, enter the storage spoke, make sure at
least two disks are selected
3) then I select that I want to do custom partitioning and enter
the custom spoke
3) add some partition that will fit on both disks,
it will get placed on one of them
4) select the partition, click the wrench icon, select the other disk,
then click "select"
After this, the update button is insensitive and the partition is still
on the same disk. Your selection is also lost - you can enter the select
disk dialog as many times as you wish and the both disks are always
selected and the update button is always insensitive after you click
select in the dialog.
I see. It is intentional that the partition is not altered until you
click the update button, but of course not intentional that disk set
changes are lost.
If you change the partition type to LVM and back, everything works fine.
Same thing if you select a different default partitioning type (so no
"autopart --type=plain").
That's interesting. The only device types that run on_configure_clicked
through to the end are partition and raid. If it only happens with those
I'd say the problem is originating somewhere near the end of
on_configure_clicked.
Regarding "77cec673a4e06d7f", I've checked that:
self.window.show_all()
return
+ if set(disks) != self._device_disks:
+ self._applyButton.set_sensitive(True)
+
self._device_disks = disks
self._populate_raid(self._get_raid_level())
This part is executed right after the select button is
clicked and correctly enables the update/apply button,
but after that another on_selected_clicked callback
runs, which triggers a _populate_right_side call,
that sets the button insensitive again and wipes out
the selected disk by previous values.
So far I have not been able to track back how this
freak on_selected_clicked callback is triggered,
but it does not run after you switch to LVM and back
(as mentioned above).
Dumping a traceback into the log every time on_selected_clicked runs
might help here.
I've been thinking about inhibiting the next
on_selected_clicked callback after the disk selection
dialog, but as it does not run after the LVM workaround
is used, it might end up inhibiting some another
unrelated on_selected_clicked call, breaking something else.
Yes, that sounds risky.
>
> >
> > Martin Kolman (1):
> > Fix disk selection for standard partitions (#1029798)
> >
> > pyanaconda/ui/gui/spokes/custom.py | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
>
>
> _______________________________________________
> anaconda-patches mailing list
> anaconda-patches(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
_______________________________________________
anaconda-patches mailing list
anaconda-patches(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches