[rhel7-branch/master][PATCH] Fix target partition selection for standard partitions
David Lehman
dlehman at redhat.com
Thu Jan 30 16:04:05 UTC 2014
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 at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
>
>
> _______________________________________________
> anaconda-patches mailing list
> anaconda-patches at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
More information about the anaconda-patches
mailing list