Bugzilla – Bug 1199895
PackageKit does not honor zypper package locks
Last modified: 2022-11-22 14:26:31 UTC
I opened a bug report on 2 Jun 2019. https://github.com/PackageKit/PackageKit/issues/325 A pull request has been made for merging a fix on 17 April 2022. https://github.com/PackageKit/PackageKit/pull/543 3 years ! Stefan Dirsch suggest to me to ask you to "to add the fix from github to our package, since apparently nobody is looking into the issue and the fix upstream. :-(" see comment #9 here https://bugzilla.opensuse.org/show_bug.cgi?id=1199791 Thanks
GNOME package. Reassigning to this component. Adding developer, who made the latest changes since March 2020 ...
Thanks
Thanks. @Jonathan, could you spend some time to review it. If it is a patch as safe as it looks like, we might want a backport before an upstream acceptance?
This is an autogenerated message for OBS integration: This bug (1199895) was mentioned in https://build.opensuse.org/request/show/980018 Factory / PackageKit
I think we can close this as fixed now the fixes submitted for factory/TW and Leap >= 15.3.
TUMBLEWEED PackageKit does not honor zypper package locks. More in yast software manager, the icon stays "forbidden" instead of "installed".
*** Bug 1201239 has been marked as a duplicate of this bug. ***
Also confirming this in Tumbleweed, see zypper ll output below # | Name | Type | Repository | Comment --+---------------------------+---------+------------+-------- 1 | nvidia-computeG06 | package | (any) | 2 | nvidia-computeG06-32bit | package | (any) | 3 | nvidia-gfxG06-kmp-default | package | (any) | 4 | nvidia-glG06 | package | (any) | 5 | nvidia-glG06-32bit | package | (any) | 6 | x11-video-nvidiaG06 | package | (any) | 7 | x11-video-nvidiaG06-32bit | package | (any) | However updating through discover (via the interface or plasma widget) ignores these
(In reply to Ellis Kenyo from comment #9) > Also confirming this in Tumbleweed, see zypper ll output below > > # | Name | Type | Repository | Comment > --+---------------------------+---------+------------+-------- > 1 | nvidia-computeG06 | package | (any) | > 2 | nvidia-computeG06-32bit | package | (any) | > 3 | nvidia-gfxG06-kmp-default | package | (any) | > 4 | nvidia-glG06 | package | (any) | > 5 | nvidia-glG06-32bit | package | (any) | > 6 | x11-video-nvidiaG06 | package | (any) | > 7 | x11-video-nvidiaG06-32bit | package | (any) | > > However updating through discover (via the interface or plasma widget) > ignores these Did `pkcon get-updates` list these locked packages?
Looking at the code, it seems rather odd that PackageKit would have to explicitly deal with locked packages. IIUC, they should be part of the regular solving and influence the decisions at that stage already. Maybe the backend is doing something wrong that it's not happening?
(In reply to Jonathan Kang from comment #10) > (In reply to Ellis Kenyo from comment #9) > > Also confirming this in Tumbleweed, see zypper ll output below > > > > # | Name | Type | Repository | Comment > > --+---------------------------+---------+------------+-------- > > 1 | nvidia-computeG06 | package | (any) | > > 2 | nvidia-computeG06-32bit | package | (any) | > > 3 | nvidia-gfxG06-kmp-default | package | (any) | > > 4 | nvidia-glG06 | package | (any) | > > 5 | nvidia-glG06-32bit | package | (any) | > > 6 | x11-video-nvidiaG06 | package | (any) | > > 7 | x11-video-nvidiaG06-32bit | package | (any) | > > > > However updating through discover (via the interface or plasma widget) > > ignores these > > Did `pkcon get-updates` list these locked packages? The only mention of nvidia is `kernel-firmware-nvidia` currently
(In reply to Fabian Vogt from comment #11) > Looking at the code, it seems rather odd that PackageKit would have to > explicitly deal with locked packages. IIUC, they should be part of the > regular solving and influence the decisions at that stage already. Maybe the > backend is doing something wrong that it's not happening? It would be much easier if that's ture. But it seems that libzypp marks those locked packages "ToBeInstalled" after resolving. Unfortunately, with my little knowledge of libzypp and its poor documentation, I didn't find anything wrong with PackageKit's zypp backend.
Are some pk_backend logs available, so we can see what is happening?
I can't tell that I fully understand what PK is doing, but I've got a suspect. Some of your *_tread functions use your PoolStatusSaver to capture the status of all PoolItems and to restore it when the function is left. This is needed, because the code makes heavy use of calling PoolItem::statusReset(). Doing this you clear all status information including the bit that tells that the package is locked. I guess your funtions using a pattern like ResPool pool = zypp_build_pool (zypp, true); PoolStatusSaver saver; ... are safe because they restore all status changes the may have applied. Others like backend_what_provides_thread may persistently clear the status of items: > if(g_ascii_strcasecmp("drivers_for_attached_hardware", values[0]) == 0) { > ... > for (ResPool::byKind_iterator it = pool.byKindBegin (ResKind::package).... > ... > it->statusReset (); > } This may be where you lose the locks. But also be careful with your PoolStatusSaver implementation. The ResPool::instance().proxy().saveState/restoreState calls it uses are not stacked. So you must not nest your PoolStatusSaver instances. restoreState restores the last saveState, no matter from where you called it.
(In reply to Michael Andres from comment #15) > I can't tell that I fully understand what PK is doing, but I've got a > suspect. > > Some of your *_tread functions use your PoolStatusSaver to capture the > status of all PoolItems and to restore it when the function is left. > > This is needed, because the code makes heavy use of calling > PoolItem::statusReset(). Doing this you clear all status information > including the bit that tells that the package is locked. > > > I guess your funtions using a pattern like > ResPool pool = zypp_build_pool (zypp, true); > PoolStatusSaver saver; > ... > are safe because they restore all status changes the may have applied. Thanks for these intuitive information. > > > Others like backend_what_provides_thread may persistently clear the status > of items: > > if(g_ascii_strcasecmp("drivers_for_attached_hardware", values[0]) == 0) { > > ... > > for (ResPool::byKind_iterator it = pool.byKindBegin (ResKind::package).... > > ... > > it->statusReset (); > > } > This may be where you lose the locks. > Hmm. Actually locked packages didn't lose "locked" status. The recent patch uses this "isLocked()" call to detect whether an item is locked. I think the problem is that they gained "ToBeInstall" status even they were locked, after doing a "resolver->doUpgrade()" for tumbleweed. > for (; it != e; ++it) { > if (it->status().isLocked()) { > // We pretend locked packages are not upgradable at all since > // we can't represent the concept of holds in PackageKit. > // https://github.com/PackageKit/PackageKit/issues/325 > continue; > } else if (it->status().isToBeInstalled()) { > ui::Selectable::constPtr s = > ui::Selectable::get((*it)->kind(), (*it)->name()); > if (s->hasInstalledObj()) > pks.insert(*it); > } > }
(In reply to Jonathan Kang from comment #16) > ... I think the problem is that they gained "ToBeInstall" status > even they were locked, after doing a "resolver->doUpgrade()" > for tumbleweed. I can hardly imagine how this should happen in PK only. If a locked package has to be amended, the resolver will raise the problem and someone has to select the appropriate solution ('removing the lock' rather than 'drop the jpb'). Is someone able to reproduce it or has a system where this happened? If resolver->doUpgrade() (DUP) was called and the result is committed, zypp should auto-write a testcase. The testcase is named /var/log/updateTestcase-YYYY-MM-DD-hh-mm-ss (date the dup was performed). The pk_backend_zypp[_#] log should also show a line like > ... [zypp] Testcase.cc(createTestcase):388 createTestcase done at /var/log/updateTestcase-2022-07-07-11-06-04 if a testcase was written. If one is available somewhere, it should reveal what happenend during DUP. The corresponding pk_backend_zypp log would be helpfull as well.
I'm bit lost here. Even without the previously applied PackageKit-zypp-locked-packages.patch, "pkcon get-updates" doesn't list those locked packages. @Episteme Can you still reproduce this? If yes, please provide what's requested in comment#17.
(In reply to Jonathan Kang from comment #16) > Hmm. Actually locked packages didn't lose "locked" status. At least bug 1190267 indicates that this happens. So even if it turns out not to be the reason for the issue here, it's worth closing this hole. I'm currently trying to figure out if statusReset is actually exclusively used by PK. If so we can amend the semantic to reset originally locked packages to this state, rather than clearing the status as it does now. Otherwise I'd introduce a new method in libzypp which PK may call instead of statusReset.
@Jonathan I checked out the factory version of PK to have all the patches you apply on top of the git branches. But IMO the situation in backend_what_provides_thread() is not different. If the 'g_ascii_strcasecmp("drivers_for_attached_hardware"..' condition matches, you run the solver and the following for-loop that iterates over all packages in the pool unconditionally calls statusReset(). This call clears all locks in the pool. If you later happen to build and commit some transaction with this pool, all package locks are gone (which is e.g. what #1190267 experiences). You should not statusReset locked packages unless you want to remove the lock.
(In reply to Michael Andres from comment #19) > (In reply to Jonathan Kang from comment #16) > > Hmm. Actually locked packages didn't lose "locked" status. > > At least bug 1190267 indicates that this happens. So even if it turns out > not to be the reason for the issue here, it's worth closing this hole. > > I'm currently trying to figure out if statusReset is actually exclusively > used by PK. If so we can amend the semantic to reset originally locked > packages to this state, rather than clearing the status as it does now. > Otherwise I'd introduce a new method in libzypp which PK may call instead of > statusReset. statusReset() is called to revert back to its original state, when an transaction fails or is simulated. > This call clears all locks in the pool. If you later happen to build and > commit some transaction with this pool, all package locks are gone (which is > e.g. what #1190267 experiences). > > You should not statusReset locked packages unless you want to remove the > lock. Yep. This is true. I just did an testing and found out that "pkcon what-provides drivers_for_attached_hardware" does clear the locked flags of all pool items. However, after this command finished, those locked packages stays locked. I guess those changes are not committed to the pool. Calling statusReset() is wrong indeed and we should definitely fix this.
Using something like this should do: void cleanStatus( const PoolItem & pi_r ) { if ( not pi_r.status().isLocked() ) pi_r.statusReset(); }
(In reply to Michael Andres from comment #22) > Using something like this should do: > void cleanStatus( const PoolItem & pi_r ) > { > if ( not pi_r.status().isLocked() ) > pi_r.statusReset(); > } One question, for methods that call `PoolStatusSaver saver;`, is it still necessary to call cleanStatus on each pool item?
Depends on what you do between 'not cleaning the pool' and restoring the last snapshot taken by a PoolStatusSaver. As I said above, you must be sure the PoolStatusSaver instances are not nested! It is not maintaining a stack. If you 'mess up' the pool and then happen to call a method that takes another snapshot the 'mess' will be restored. It's hard for me to suggest something, because I do not know how PK and the backend interact. E.g. If each and every call into the backend wants to start with a fresh and tidy pool it might be better to clean up the pool at the beginning rather than taking a snapshot of a hopefully clean pool. But this also requires, that internally these entry functions are not used, otherwise you may clear valid results in the pool. OTOH if it's expected to leave the pool in a specific sate, I'd prefer a nestable status saver. So every action may take it's snapshot, try out something and then decide whether to leave the result in the pool or revert to the original state.
JFYI: The libzypp updates mention this bug, because in linzypp-17.31.0 we introduced a new method: Add PoolItem::statusReinit to reset the status it's initial state in the ResPool (bsc#1199895) This may either be 'KEEP_STATE bySOLVER' or 'LOCKED byUSER' if the PoolItem matched a hard lock defined in /etc/zypp/locks. Unlike if ( not pi_r.status().isLocked() ) pi_r.statusReset(); just calling pi_r.statusReinit(); will set the status to the value it had when the item was initially loaded into the pool. So it does not depend on whether the item is currently locked. /etc/zypp/locks just defines the initial lock state. The lock could have been acquired or removed since. It's however up to you to decide which semantic applies better to your workflow.
This is an autogenerated message for OBS integration: This bug (1199895) was mentioned in https://build.opensuse.org/request/show/993936 Factory / PackageKit
*** Bug 1190267 has been marked as a duplicate of this bug. ***
Hello, while testing S:M:24915:275232 (packagekit update for SLE15SP3) I'm having some issues reproducing this issue. What I have tried: I know that there is a tigervnc pending update,so: # zypper al tigervnc Specified lock has been successfully added. ligur:~ # zypper ll # | Name | Type | Repository | Comment --+----------+---------+------------+-------- 1 | tigervnc | package | (any) | But now: # pkcon update Getting updates [=========================] Finished [=========================] Refreshing software list [=========================] Testing changes [=========================] Finished [=========================] Fatal error: the to be installed patch:SUSE-SLE-Module-Basesystem-15-SP3-2022-3012-1.noarch conflicts with 'tigervnc.x86_64 < 1.9.0-150100.19.20.1' provided by the installed tigervnc-1.9.0-150100.19.17.1.x86_64 It says that it "conflicts" with the updated package. Removing the lock solves the issue. Is there another way to reproduce this issue? (I have the same behaviour before/after applying packagekit update)
SUSE-RU-2022:3113-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1199895 CVE References: JIRA References: Sources used: openSUSE Leap 15.4 (src): PackageKit-1.2.4-150400.3.3.1 SUSE Linux Enterprise Workstation Extension 15-SP4 (src): PackageKit-1.2.4-150400.3.3.1 SUSE Linux Enterprise Module for Desktop Applications 15-SP4 (src): PackageKit-1.2.4-150400.3.3.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-RU-2022:3114-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1199895 CVE References: JIRA References: Sources used: openSUSE Leap 15.3 (src): PackageKit-1.1.13-150200.4.26.1 SUSE Linux Enterprise Workstation Extension 15-SP3 (src): PackageKit-1.1.13-150200.4.26.1 SUSE Linux Enterprise Module for Desktop Applications 15-SP3 (src): PackageKit-1.1.13-150200.4.26.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
(In reply to Ednilson Miura from comment #32) > Hello, while testing S:M:24915:275232 (packagekit update for SLE15SP3) I'm > having some issues reproducing this issue. > What I have tried: > > I know that there is a tigervnc pending update,so: > > # zypper al tigervnc > Specified lock has been successfully added. > ligur:~ # zypper ll > > # | Name | Type | Repository | Comment > --+----------+---------+------------+-------- > 1 | tigervnc | package | (any) | > > But now: > # pkcon update > Getting updates [=========================] > Finished [=========================] > Refreshing software list [=========================] > Testing changes [=========================] > Finished [=========================] > Fatal error: the to be installed > patch:SUSE-SLE-Module-Basesystem-15-SP3-2022-3012-1.noarch conflicts with > 'tigervnc.x86_64 < 1.9.0-150100.19.20.1' provided by the installed > tigervnc-1.9.0-150100.19.17.1.x86_64 > > It says that it "conflicts" with the updated package. Removing the lock > solves the issue. > > Is there another way to reproduce this issue? (I have the same behaviour > before/after applying packagekit update) Maybe try locking packages that doesn't belong to a patch upate.
SUSE-RU-2022:3222-1: An update that has 5 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1199895,1200993,1201092,1201576,1201638 CVE References: JIRA References: Sources used: SUSE Linux Enterprise Server for SAP 15 (src): libzypp-17.31.0-150000.3.101.1, zypper-1.14.55-150000.3.75.1 SUSE Linux Enterprise Server 15-LTSS (src): libzypp-17.31.0-150000.3.101.1, zypper-1.14.55-150000.3.75.1 SUSE Linux Enterprise Installer 15 (src): libzypp-17.31.0-150000.3.101.1, zypper-1.14.55-150000.3.75.1 SUSE Linux Enterprise High Performance Computing 15-LTSS (src): libzypp-17.31.0-150000.3.101.1, zypper-1.14.55-150000.3.75.1 SUSE Linux Enterprise High Performance Computing 15-ESPOS (src): libzypp-17.31.0-150000.3.101.1, zypper-1.14.55-150000.3.75.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-RU-2022:3220-1: An update that has 5 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1199895,1200993,1201092,1201576,1201638 CVE References: JIRA References: Sources used: openSUSE Leap 15.4 (src): libzypp-17.31.0-150400.3.6.1, zypper-1.14.55-150400.3.6.1 SUSE Linux Enterprise Module for Basesystem 15-SP4 (src): libzypp-17.31.0-150400.3.6.1, zypper-1.14.55-150400.3.6.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-RU-2022:3221-1: An update that has 5 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1199895,1200993,1201092,1201576,1201638 CVE References: JIRA References: Sources used: SUSE Linux Enterprise Server for SAP 15-SP1 (src): libzypp-17.31.0-150100.3.84.1, zypper-1.14.55-150100.3.61.1 SUSE Linux Enterprise Server 15-SP1-LTSS (src): libzypp-17.31.0-150100.3.84.1, zypper-1.14.55-150100.3.61.1 SUSE Linux Enterprise Server 15-SP1-BCL (src): libzypp-17.31.0-150100.3.84.1, zypper-1.14.55-150100.3.61.1 SUSE Linux Enterprise Installer 15-SP1 (src): libzypp-17.31.0-150100.3.84.1 SUSE Linux Enterprise High Performance Computing 15-SP1-LTSS (src): libzypp-17.31.0-150100.3.84.1, zypper-1.14.55-150100.3.61.1 SUSE Linux Enterprise High Performance Computing 15-SP1-ESPOS (src): libzypp-17.31.0-150100.3.84.1, zypper-1.14.55-150100.3.61.1 SUSE Enterprise Storage 6 (src): libzypp-17.31.0-150100.3.84.1, zypper-1.14.55-150100.3.61.1 SUSE CaaS Platform 4.0 (src): libzypp-17.31.0-150100.3.84.1, zypper-1.14.55-150100.3.61.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-RU-2022:3223-1: An update that has 5 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1199895,1200993,1201092,1201576,1201638 CVE References: JIRA References: Sources used: openSUSE Leap Micro 5.2 (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 openSUSE Leap 15.3 (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 SUSE Manager Server 4.1 (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 SUSE Manager Retail Branch Server 4.1 (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 SUSE Manager Proxy 4.1 (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 SUSE Linux Enterprise Server for SAP 15-SP2 (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 SUSE Linux Enterprise Server 15-SP2-LTSS (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 SUSE Linux Enterprise Server 15-SP2-BCL (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 SUSE Linux Enterprise Module for Basesystem 15-SP3 (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 SUSE Linux Enterprise Micro 5.2 (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 SUSE Linux Enterprise Micro 5.1 (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 SUSE Linux Enterprise Installer 15-SP2 (src): libzypp-17.31.0-150200.42.1 SUSE Linux Enterprise High Performance Computing 15-SP2-LTSS (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 SUSE Linux Enterprise High Performance Computing 15-SP2-ESPOS (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 SUSE Enterprise Storage 7 (src): libzypp-17.31.0-150200.42.1, zypper-1.14.55-150200.36.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
@Jonathan:(In reply to Jonathan Kang from comment #35) > (In reply to Ednilson Miura from comment #32) > > Fatal error: the to be installed > > patch:SUSE-SLE-Module-Basesystem-15-SP3-2022-3012-1.noarch conflicts with > > 'tigervnc.x86_64 < 1.9.0-150100.19.20.1' provided by the installed > > tigervnc-1.9.0-150100.19.17.1.x86_64 > > > > It says that it "conflicts" with the updated package. Removing the lock (It says that it "conflicts" with the installed tigervnc-1.9.0-150100.19.17.1) > > solves the issue. > > Maybe try locking packages that doesn't belong to a patch upate. (I guess usually you don't know in advance, that a patch will be released for a locked package.) PK displays the ResolverProblem::description only. But every ResolverProblem also provides a ProblemSolutionList (returned by [ResolverProblem::solutions [1]). From the resolvers POV there are - as almost always - multiple ways to solve an issue. Here: either - not applying the patch or - removing the lock to enable updating the package. If PK would show the 'proposed soulutions' together with the problem, it might be easier to figure out how to overcome the issue. [1] https://github.com/openSUSE/libzypp/blob/master/zypp/ResolverProblem.h#L72
(In reply to Michael Andres from comment #40) > @Jonathan:(In reply to Jonathan Kang from comment #35) > > (In reply to Ednilson Miura from comment #32) > > > Fatal error: the to be installed > > > patch:SUSE-SLE-Module-Basesystem-15-SP3-2022-3012-1.noarch conflicts with > > > 'tigervnc.x86_64 < 1.9.0-150100.19.20.1' provided by the installed > > > tigervnc-1.9.0-150100.19.17.1.x86_64 > > > > > > It says that it "conflicts" with the updated package. Removing the lock > > (It says that it "conflicts" with the installed > tigervnc-1.9.0-150100.19.17.1) > > > > solves the issue. > > > > Maybe try locking packages that doesn't belong to a patch upate. > > (I guess usually you don't know in advance, that a patch will be released > for a locked package.) > > PK displays the ResolverProblem::description only. But every ResolverProblem > also provides a ProblemSolutionList (returned by [ResolverProblem::solutions > [1]). > > From the resolvers POV there are - as almost always - multiple ways to solve > an issue. Here: > either - not applying the patch > or - removing the lock to enable updating the package. > > If PK would show the 'proposed soulutions' together with the problem, it > might be easier to figure out how to overcome the issue. > > > [1] > https://github.com/openSUSE/libzypp/blob/master/zypp/ResolverProblem.h#L72 Yes, this is definitely something that needs to be improved at PackageKit side. From what I know about PackageKit, it doesn't offer a mechanism to do problems solving. I'll raise this issue upstream and maybe prepare a patch for this.
Should be fully fixed now. Closing this.
SUSE-RU-2022:4164-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1199895,1202585 CVE References: JIRA References: Sources used: openSUSE Leap 15.4 (src): PackageKit-1.2.4-150400.3.6.1 SUSE Linux Enterprise Workstation Extension 15-SP4 (src): PackageKit-1.2.4-150400.3.6.1 SUSE Linux Enterprise Module for Desktop Applications 15-SP4 (src): PackageKit-1.2.4-150400.3.6.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
openSuse Tumbleweed I confirm that the problem is fixed.