[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