Description of problem: dnf list extras gives inconsistent/incorrect results after some items have been updated Version-Release number of selected component (if applicable): Various & not predictable (as far as I can see) How reproducible: Intermittently after updates. Steps to Reproduce: 1. Allow dnf/yum to update something. 2. run dnf list extras & note items labelled as @System 3. Actual results: [root@loki monitor]# dnf list extras Last metadata expiration check performed 0:32:01 ago on Mon Mar 14 09:28:03 2016. Extra Packages glibc.i686 2.21-13.fc22 @System glibc-common.i686 2.21-13.fc22 @System gvfs.i686 1.24.3-1.fc22 @System gvfs-afc.i686 1.24.3-1.fc22 @System gvfs-afp.i686 1.24.3-1.fc22 @System gvfs-archive.i686 1.24.3-1.fc22 @System gvfs-fuse.i686 1.24.3-1.fc22 @System gvfs-goa.i686 1.24.3-1.fc22 @System gvfs-gphoto2.i686 1.24.3-1.fc22 @System gvfs-mtp.i686 1.24.3-1.fc22 @System gvfs-smb.i686 1.24.3-1.fc22 @System kernel.i686 4.3.6-201.fc22 @updates kernel.i686 4.4.3-201.fc22 @updates kernel-core.i686 4.3.6-201.fc22 @updates kernel-core.i686 4.4.3-201.fc22 @updates kernel-modules.i686 4.3.6-201.fc22 @updates kernel-modules.i686 4.4.3-201.fc22 @updates libpagemaker.i686 0.0.3-1.fc22 @System libsmbclient.i686 2:4.2.9-0.fc22 @System libwbclient.i686 2:4.2.9-0.fc22 @System openssl.i686 1:1.0.1k-14.fc22 @System openssl-libs.i686 1:1.0.1k-14.fc22 @System perl.i686 4:5.20.3-329.fc22 @System perl-Pod-Escapes.noarch 1:1.06-329.fc22 @System perl-libs.i686 4:5.20.3-329.fc22 @System perl-macros.i686 4:5.20.3-329.fc22 @System quota.i686 1:4.02-3.fc22 @System quota-nls.noarch 1:4.02-3.fc22 @System samba-client.i686 2:4.2.9-0.fc22 @System samba-client-libs.i686 2:4.2.9-0.fc22 @System samba-common.noarch 2:4.2.9-0.fc22 @System samba-common-libs.i686 2:4.2.9-0.fc22 @System samba-libs.i686 2:4.2.9-0.fc22 @System [root@loki monitor]# dnf list obsoletes Last metadata expiration check performed 0:34:42 ago on Mon Mar 14 09:28:03 2016. Expected results: [root@loki monitor]# dnf list extras Last metadata expiration check performed 0:32:01 ago on Mon Mar 14 09:28:03 2016. Extra Packages kernel.i686 4.3.6-201.fc22 @updates kernel.i686 4.4.3-201.fc22 @updates kernel-core.i686 4.3.6-201.fc22 @updates kernel-core.i686 4.4.3-201.fc22 @updates kernel-modules.i686 4.3.6-201.fc22 @updates kernel-modules.i686 4.4.3-201.fc22 @updates Additional info: This could be a duplicate of other @System commented bugs & it happens randomly but more rarely on an FC23 machine.
Is the output always the same (more or less)? Can you post output of `dnf repoquery --available glibc.i686`, please?
Yes, but it's not specific to a particular package or group of packages, it seems to be whatever was updated recently. The "problem" has "gone away" overnight, but it will be back in a similar form after another update. Here is the output of, dnf repoquery --available glibc.i686 as requested... [root@loki ~]# dnf repoquery --available glibc.i686 Last metadata expiration check performed 2:37:39 ago on Tue Mar 15 06:35:49 2016. glibc-0:2.21-13.fc22.i686 glibc-0:2.21-5.fc22.i686 I guess it could just be a repo inconsistency at the time I run "dnf list extras" but it would be nice if there were a way of knowing that (maybe there is & I just ain't aware of the dnf command - yet ;-)
I am sorry, but we cannot reproduce it. Please could you try before upgrade run dnf list extras and note if packages that will be upgraded are marked as @System or if you can better specified condition that trigger reported behavior. You also wrote that it happens more rarely on an FC23 machine, when it happens more often?
I think it's rare on FC23 because updates seem rare. On one FC22 machine today... yum.log shows... Mar 30 04:17:29 Updated: gtk2.x86_64 2.24.30-1.fc22 Mar 30 04:17:31 Updated: gtk2-devel.x86_64 2.24.30-1.fc22 Mar 30 04:17:31 Updated: gtk2-immodule-xim.x86_64 2.24.30-1.fc22 Mar 30 04:17:37 Updated: google-chrome-stable.x86_64 49.0.2623.110-1 Mar 30 04:17:38 Updated: libsrtp.x86_64 1.5.4-3.fc22 So these were updated overnight (by yum? - I run yum-cron on fc22's as I can't seem to run the dnf update at a "reliable" time using the dnf-automatic.service/ dnf-automatic.timer/dnf-makecache.timer methods. I don't want the time it runs to change every time I reboot) Then this morning (Kernel being listed is ok I understand why they are "extras")... [root ~]# date Wed Mar 30 09:46:11 AEDT 2016 [root ~]# dnf list extras Last metadata expiration check performed 0:15:00 ago on Wed Mar 30 09:31:20 2016. Extra Packages gtk2.x86_64 2.24.30-1.fc22 @System gtk2-devel.x86_64 2.24.30-1.fc22 @System gtk2-immodule-xim.x86_64 2.24.30-1.fc22 @System kernel.x86_64 4.4.4-200.fc22 @System kernel.x86_64 4.4.5-200.fc22 @System kernel-core.x86_64 4.4.4-200.fc22 @System kernel-core.x86_64 4.4.5-200.fc22 @System kernel-devel.x86_64 4.4.4-200.fc22 @System kernel-devel.x86_64 4.4.5-200.fc22 @System kernel-modules.x86_64 4.4.4-200.fc22 @System kernel-modules.x86_64 4.4.5-200.fc22 @System kernel-modules-extra.x86_64 4.4.4-200.fc22 @System kernel-modules-extra.x86_64 4.4.5-200.fc22 @System libsrtp.x86_64 1.5.4-3.fc22 @System [root ~]# dnf update Last metadata expiration check performed 0:15:04 ago on Wed Mar 30 09:31:20 2016. Dependencies resolved. Nothing to do. Complete! [root ~]# dnf list extras Last metadata expiration check performed 0:15:42 ago on Wed Mar 30 09:31:20 2016. Extra Packages gtk2.x86_64 2.24.30-1.fc22 @System gtk2-devel.x86_64 2.24.30-1.fc22 @System gtk2-immodule-xim.x86_64 2.24.30-1.fc22 @System kernel.x86_64 4.4.4-200.fc22 @System kernel.x86_64 4.4.5-200.fc22 @System kernel-core.x86_64 4.4.4-200.fc22 @System kernel-core.x86_64 4.4.5-200.fc22 @System kernel-devel.x86_64 4.4.4-200.fc22 @System kernel-devel.x86_64 4.4.5-200.fc22 @System kernel-modules.x86_64 4.4.4-200.fc22 @System kernel-modules.x86_64 4.4.5-200.fc22 @System kernel-modules-extra.x86_64 4.4.4-200.fc22 @System kernel-modules-extra.x86_64 4.4.5-200.fc22 @System libsrtp.x86_64 1.5.4-3.fc22 @System [root ~]# So is it possible that because the update was done overnight by yum-cron that dnf now does not know about it? but the same is happening on the other machines. [root ~]# dnf list libsrtp gtk2 gtk2-devel gtk2-immodule-xim Last metadata expiration check performed 0:34:47 ago on Wed Mar 30 09:31:20 2016. Installed Packages gtk2.x86_64 2.24.30-1.fc22 @System gtk2-devel.x86_64 2.24.30-1.fc22 @System gtk2-immodule-xim.x86_64 2.24.30-1.fc22 @System libsrtp.x86_64 1.5.4-3.fc22 @System Available Packages gtk2.i686 2.24.29-1.fc22 updates gtk2-devel.i686 2.24.29-1.fc22 updates gtk2-immodule-xim.i686 2.24.29-1.fc22 updates libsrtp.i686 1.5.0-2.fc22 fedora [root ~]# Noting the above, the yum log for a 686 fc22 machine shows an update to Mar 30 05:11:59 Updated: gtk2.i686 2.24.30-1.fc22 Mar 30 05:12:04 Updated: gtk2-devel.i686 2.24.30-1.fc22 Mar 30 05:12:05 Updated: libsrtp.i686 1.5.4-3.fc22 So maybe this is more a case of inconsistent mirrors than anything else? However... on the 686 machine, [root@loki ~]# dnf list libsrtp gtk2 gtk2-devel Last metadata expiration check performed 2:48:29 ago on Wed Mar 30 07:25:57 2016. Installed Packages gtk2.i686 2.24.30-1.fc22 @System gtk2-devel.i686 2.24.30-1.fc22 @System libsrtp.i686 1.5.4-3.fc22 @System [root@loki findsuid]# dnf list extras Last metadata expiration check performed 2:48:39 ago on Wed Mar 30 07:25:57 2016. Extra Packages kernel.i686 4.4.4-200.fc22 @System kernel.i686 4.4.5-200.fc22 @System kernel-core.i686 4.4.4-200.fc22 @System kernel-core.i686 4.4.5-200.fc22 @System kernel-modules.i686 4.4.4-200.fc22 @System kernel-modules.i686 4.4.5-200.fc22 @System [root@loki ~]# So although they are "@System" they don't show up as "extras". On another FC22... yum.log says, Mar 30 03:58:28 Updated: gtk2.x86_64 2.24.30-1.fc22 Mar 30 03:58:28 Updated: gtk2-immodule-xim.x86_64 2.24.30-1.fc22 Mar 30 03:58:29 Updated: libsrtp.x86_64 1.5.4-3.fc22 [root@muneela ~]# dnf list libsrtp gtk2 gtk2-devel gtk2-immodule-xim Last metadata expiration check performed 0:12:09 ago on Wed Mar 30 10:11:26 2016. Installed Packages gtk2.x86_64 2.24.30-1.fc22 @System gtk2-immodule-xim.x86_64 2.24.30-1.fc22 @System libsrtp.x86_64 1.5.4-3.fc22 @System Available Packages gtk2.i686 2.24.30-1.fc22 updates gtk2-devel.i686 2.24.30-1.fc22 updates gtk2-devel.x86_64 2.24.30-1.fc22 updates gtk2-immodule-xim.i686 2.24.30-1.fc22 updates libsrtp.i686 1.5.4-3.fc22 updates [root@muneela ~]# dnf list extras Last metadata expiration check performed 0:13:15 ago on Wed Mar 30 10:11:26 2016. Extra Packages kernel.x86_64 4.4.4-200.fc22 @System kernel.x86_64 4.4.5-200.fc22 @System kernel-core.x86_64 4.4.4-200.fc22 @System kernel-core.x86_64 4.4.5-200.fc22 @System kernel-devel.x86_64 4.4.4-200.fc22 @System kernel-devel.x86_64 4.4.5-200.fc22 @System kernel-modules.x86_64 4.4.4-200.fc22 @System kernel-modules.x86_64 4.4.5-200.fc22 @System [root@muneela ~]# So why does one machine see them as extras? & the others do "sometimes" with other packages recently updated but not always consistently on all machines? Should I dnf clean all or something? Can I go back yum? Where "package-cleanup --quiet --orphans" gave me what I wanted consistently for years?
On the previously problematic machine the following updates were logged in yum.log last night, Mar 31 04:57:45 Updated: openssh.x86_64 6.9p1-11.fc22 Mar 31 04:57:46 Updated: gnutls.x86_64 3.3.22-1.fc22 Mar 31 04:57:46 Updated: gnutls-dane.x86_64 3.3.22-1.fc22 Mar 31 04:57:47 Updated: gnome-documents-libs.x86_64 3.16.6-1.fc22 Mar 31 04:57:49 Updated: gnome-documents.x86_64 3.16.6-1.fc22 Mar 31 04:57:49 Updated: gnutls-utils.x86_64 3.3.22-1.fc22 Mar 31 04:57:50 Updated: openssh-server.x86_64 6.9p1-11.fc22 Mar 31 04:57:50 Updated: openssh-clients.x86_64 6.9p1-11.fc22 Mar 31 04:57:51 Updated: openssh-askpass.x86_64 6.9p1-11.fc22 Mar 31 04:57:52 Updated: gnome-abrt.x86_64 1.2.0-5.fc22 dnf list extras gives correct output, Last metadata expiration check performed 1:20:59 ago on Thu Mar 31 06:39:07 2016. Extra Packages kernel.x86_64 4.4.4-200.fc22 @System kernel.x86_64 4.4.5-200.fc22 @System kernel-core.x86_64 4.4.4-200.fc22 @System kernel-core.x86_64 4.4.5-200.fc22 @System kernel-devel.x86_64 4.4.4-200.fc22 @System kernel-devel.x86_64 4.4.5-200.fc22 @System kernel-modules.x86_64 4.4.4-200.fc22 @System kernel-modules.x86_64 4.4.5-200.fc22 @System kernel-modules-extra.x86_64 4.4.4-200.fc22 @System kernel-modules-extra.x86_64 4.4.5-200.fc22 @System No other machines exibited unexpected behaviour - till next time.
I speak too soon - it seems for a while on a machine running RHEL... # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.7 (Santiago) # package-cleanup --quiet --orphans tar-1.23-14.el6.x86_64 tmpwatch-2.9.16-6.el6.x86_64 (I've deleted those "orphans" there's a good reason for) These entries are in yum.log Mar 19 03:40:20 Updated: 2:tar-1.23-14.el6.x86_64 Mar 19 03:40:20 Updated: tmpwatch-2.9.16-6.el6.x86_64 other packages have updated since. # yum list tar tmpwatch Loaded plugins: product-id, rhnplugin, security, subscription-manager This system is receiving updates from RHN Classic or RHN Satellite. Installed Packages tar.x86_64 2:1.23-14.el6 @rhel-x86_64-server-6 tmpwatch.x86_64 2.9.16-6.el6 @rhel-x86_64-server-6 (I've asked the sysadmin to log this through the RHEL channel) People may wonder why we run these "orphan" checks. It makes life easier during a major upgrade if you've dealt with such orphans when they first occur, it also shows what may have been installed outside of the normal package management systems that might need to be justified.
Perfect, finally we know the reason. You have used DNF along with yum. Yum did the upgrade and set the information into yumdb, not dnfdb. Please, use dnf-automatic. If you still use yum in parallel with DNF. Run: "dnf-2 migrate" to transfer transaction metadata into dnfdb. It should work then, if not reopen this.
Maybe not... [root@halfmoon ~]# dnf-2 migrate Last metadata expiration check performed 2:06:06 ago on Thu Mar 31 21:43:16 2016. Migrating history data... Migrating YUMDB data... Loaded plugins: langpacks 4710 YUMDB records found, 4710 migrated, 0 skipped/preserved Migrating groups data... Group 'gnome-desktop-environment' does not exist, skipping. [root@halfmoon monitor]# dnf list extras Last metadata expiration check performed 2:12:13 ago on Thu Mar 31 21:43:16 2016. Extra Packages gnome-abrt.x86_64 1.2.0-5.fc22 @updates gnome-documents.x86_64 3.16.6-1.fc22 @updates gnome-documents-libs.x86_64 3.16.6-1.fc22 @updates gnutls.x86_64 3.3.22-1.fc22 @updates gnutls-dane.x86_64 3.3.22-1.fc22 @updates gnutls-utils.x86_64 3.3.22-1.fc22 @updates kernel.x86_64 4.4.4-200.fc22 @updates kernel.x86_64 4.4.5-200.fc22 @updates kernel-core.x86_64 4.4.4-200.fc22 @updates kernel-core.x86_64 4.4.5-200.fc22 @updates kernel-devel.x86_64 4.4.4-200.fc22 @updates kernel-devel.x86_64 4.4.5-200.fc22 @updates kernel-modules.x86_64 4.4.4-200.fc22 @updates kernel-modules.x86_64 4.4.5-200.fc22 @updates kernel-modules-extra.x86_64 4.4.4-200.fc22 @updates kernel-modules-extra.x86_64 4.4.5-200.fc22 @updates openssh.x86_64 6.9p1-11.fc22 @updates openssh-askpass.x86_64 6.9p1-11.fc22 @updates openssh-clients.x86_64 6.9p1-11.fc22 @updates openssh-server.x86_64 6.9p1-11.fc22 @updates [root@halfmoon monitor]# dnf update Last metadata expiration check performed 2:13:04 ago on Thu Mar 31 21:43:16 2016. Dependencies resolved. Nothing to do. Complete! [root@halfmoon monitor]#
Isn't yum deprecated & redirected to dnf? Isn't yum-cron simply redirecting the activity to dnf?
Is anyone going to include in the dnf-automatic documentation a method of effectively replacing yum-cron? ie. making sure that people know how to get dnf to run at a specific time? or at least give pointers to it. What was once so easy with cron is now so obfurscated with systemd.timers we need to help people!