Closed j-mracek closed 6 months ago
I think that formal description was valid in past. I remember that DNF had a problem in inheritance of kernel reason therefore it somehow mark all installonly packages as user installed or unknown. Hopefully the issue is gone.
Anyway I have a bad news. DNF does not keep reason of installonly packages. But I have to doublecheck
I tried following: Note: Issue confirmed with standard dnf
# dnf repoquery --installed kernel* --qf="%{name} %{reason}"
kernel user
kernel-core user
kernel-headers unknown
kernel-modules user
kernel-modules-core user
kernel-modules-extra dependency
kernel-srpm-macros dependency
# sudo dnf upgrade kernel*
Last metadata expiration check: 2:58:48 ago on Fri 08 Mar 2024 11:14:59 AM CET.
Dependencies resolved.
==============================================================================================================================================================================================
Package Architecture Version Repository Size
==============================================================================================================================================================================================
Installing:
kernel x86_64 6.7.7-100.fc38 updates 161 k
kernel-core x86_64 6.7.7-100.fc38 updates 16 M
kernel-modules x86_64 6.7.7-100.fc38 updates 59 M
kernel-modules-core x86_64 6.7.7-100.fc38 updates 33 M
Installing dependencies:
kernel-modules-extra x86_64 6.7.7-100.fc38 updates 2.6 M
Removing:
kernel x86_64 6.6.11-100.fc38 @System 0
kernel-core x86_64 6.6.11-100.fc38 @System 66 M
kernel-modules x86_64 6.6.11-100.fc38 @System 56 M
kernel-modules-core x86_64 6.6.11-100.fc38 @System 31 M
kernel-modules-extra x86_64 6.6.11-100.fc38 @System 2.4 M
Transaction Summary
==============================================================================================================================================================================================
Install 5 Packages
Remove 5 Packages
Total download size: 111 M
Is this ok [y/N]: y
Downloading Packages:
(1/5): kernel-6.7.7-100.fc38.x86_64.rpm 554 kB/s | 161 kB 00:00
(2/5): kernel-core-6.7.7-100.fc38.x86_64.rpm 6.2 MB/s | 16 MB 00:02
(3/5): kernel-modules-extra-6.7.7-100.fc38.x86_64.rpm 2.0 MB/s | 2.6 MB 00:01
(4/5): kernel-modules-core-6.7.7-100.fc38.x86_64.rpm 8.0 MB/s | 33 MB 00:04
(5/5): kernel-modules-6.7.7-100.fc38.x86_64.rpm 12 MB/s | 59 MB 00:04
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 21 MB/s | 111 MB 00:05
Running transaction check
...
Installed:
kernel-6.7.7-100.fc38.x86_64 kernel-core-6.7.7-100.fc38.x86_64 kernel-modules-6.7.7-100.fc38.x86_64 kernel-modules-core-6.7.7-100.fc38.x86_64 kernel-modules-extra-6.7.7-100.fc38.x86_64
Removed:
kernel-6.6.11-100.fc38.x86_64 kernel-core-6.6.11-100.fc38.x86_64 kernel-modules-6.6.11-100.fc38.x86_64 kernel-modules-core-6.6.11-100.fc38.x86_64
kernel-modules-extra-6.6.11-100.fc38.x86_64
Complete!
# dnf repoquery --installed kernel* --qf="%{name} %{reason}"
(7, "Failed to connect to 127.0.0.1 port 9050 after 201 ms: Couldn't connect to server")
Disabling torproxy plugin: cannot connect to the Tor network
kernel unknown
kernel-core unknown
kernel-headers unknown
kernel-modules unknown
kernel-modules-core unknown
kernel-modules-extra unknown
kernel-srpm-macros dependency
I did a quick test on fresh F39 virtual machine where it seems OK. But your case doesn't look all right, indeed.
[root@localhost ~]# dnf repoquery --installed kernel* --qf="%{name}-%{evr} %{reason}"
kernel-6.5.6-300.fc39 user
kernel-core-6.5.6-300.fc39 dependency
kernel-modules-6.5.6-300.fc39 dependency
kernel-modules-core-6.5.6-300.fc39 dependency
[root@localhost ~]# dnf upgrade -q -y "kernel*"
Importing GPG key 0x18B8E74C:
Userid : "Fedora (39) <fedora-39-primary@fedoraproject.org>"
Fingerprint: E8F2 3996 F232 1864 0CB4 4CBE 75CF 5AC4 18B8 E74C
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-39-x86_64
Installed:
kernel-6.7.7-200.fc39.x86_64 kernel-core-6.7.7-200.fc39.x86_64
kernel-modules-6.7.7-200.fc39.x86_64 kernel-modules-core-6.7.7-200.fc39.x86_64
[root@localhost ~]# dnf repoquery --installed kernel* --qf="%{name}-%{evr} %{reason}"
kernel-6.5.6-300.fc39 user
kernel-6.7.7-200.fc39 user
kernel-core-6.5.6-300.fc39 dependency
kernel-core-6.7.7-200.fc39 dependency
kernel-modules-6.5.6-300.fc39 dependency
kernel-modules-6.7.7-200.fc39 dependency
kernel-modules-core-6.5.6-300.fc39 dependency
kernel-modules-core-6.7.7-200.fc39 dependency
But still - we do not plan to change autoremove
command to protect installonly packages, do we?
I'd like to merge this doc PR and file a new one to investigate kernel reasons.
Please do not merge it till the installonly packages reason issue is properly investigated.
The trigger of the issue with reasons is removal of one of the installonly packages.
@j-mracek I think this is good to go now. Any complaints against removing Blocked
label and merging?
Installonly packages are once more mentioned as those not affected by autoremove command in
dnf history userinstalled
description: https://github.com/rpm-software-management/dnf/blob/96f8d79c37e119ff56f730797865121b63241a6b/doc/command_ref.rst#L800-L806I think this command also does not do any special handling for installonly packages and the documentation should be updated accordingly.