Unexpected Kernel Removal In The Transaction
Introduction
When working with the DNF package manager on Fedora systems, users may encounter unexpected behavior when running transactions. One such issue arises when the number of installed kernels exceeds the installonly_limit
configuration option. In this article, we will delve into the details of this problem, explore its causes, and discuss potential solutions.
Understanding the installonly_limit
Configuration Option
The installonly_limit
configuration option is used to control the number of installed kernel versions on a system. When this limit is exceeded, DNF will automatically remove excess kernel versions to make room for new installations. However, this behavior can lead to unexpected kernel removals, even when the kernel package is not part of the transaction.
Example Scenario
Let's consider an example scenario where we have three kernel versions installed on our system:
❯ rpm -q kernel
kernel-6.13.4-100.fc40.x86_64
kernel-6.13.5-100.fc40.x86_64
kernel-6.8.5-301.fc40.x86_64
We can check the current value of the installonly_limit
configuration option using the following command:
❯ dnf --dump-main-config | grep installonly_limit
installonly_limit = 3
Now, let's try to install a random package, such as acpi
, while setting the installonly_limit
option to 2:
❯ dnf5 --assumeno --setopt=installonly_limit=2 install acpi
Package Arch Version Repository Size
Removing:
kernel x86_64 6.8.5-301.fc40 fedora 0.0 B
kernel-core x86_64 6.8.5-301.fc40 fedora 66.4 MiB
kernel-modules x86_64 6.8.5-301.fc40 fedora 58.0 MiB
kernel-modules-core x86_64 6.8.5-301.fc40 fedora 32.4 MiB
Installing:
acpi x86_64 1.7-23.fc40 fedora 47.5 KiB
Transaction Summary:
Installing: 1 package
Removing: 4 packages
Total size of inbound packages is 27 KiB. Need to download 27 KiB.
After this operation, 157 MiB will be freed (install 47 KiB, remove 157 MiB).
Operation aborted by the user.
As we can see, DNF has automatically removed the kernel version 6.8.5-301.fc40
to make room for the new installation of acpi
.
Comparison with DNF 4
To put this behavior into perspective, let's compare it with the behavior of DNF 4. When we run the same transaction with DNF 4, we get a different result:
❯ dnf4 --assumeno --setopt=installonly_limit=2 install acpi
Dependencies resolved.
=========================================================================================
Package Architecture Version Repository Size
=========================================================================================
Installing:
acpi x86_64 1.7-23.fc40 fedora 27 k
Transaction Summary
=========================================================================================
Install 1 Package
Total size: 27 k
Installed size: 47 k
Operation aborted.
In this case, DNF 4 does not remove any kernel versions, and the transaction is completed successfully.
Conclusion
The unexpected kernel removal in the transaction is a regression in DNF compared to its predecessor, DNF 4. This behavior can lead to unexpected kernel removals, even when the kernel package is not part of the transaction. To avoid this issue, users can lower the installonly_limit
configuration option or use DNF 4. However, it is recommended to report this issue to the Fedora bug tracker and follow the progress of the related bug.
Related Fedora Bug
The related Fedora bug is tracked in Bugzilla under the following link:
https://bugzilla.redhat.com/show_bug.cgi?id=2350483
Recommendations
To avoid the unexpected kernel removal in the transaction, users can follow these recommendations:
- Lower the
installonly_limit
configuration option to a value that is sufficient for their needs. - Use DNF 4, which does not exhibit this behavior.
- Report this issue to the Fedora bug tracker and follow the progress of the related bug.
Q: What is the installonly_limit
configuration option?
A: The installonly_limit
configuration option is used to control the number of installed kernel versions on a system. When this limit is exceeded, DNF will automatically remove excess kernel versions to make room for new installations.
Q: Why is the installonly_limit
configuration option causing unexpected kernel removals?
A: The installonly_limit
configuration option is causing unexpected kernel removals because DNF is removing excess kernel versions even when the kernel package is not part of the transaction. This behavior is a regression in DNF compared to its predecessor, DNF 4.
Q: How can I check the current value of the installonly_limit
configuration option?
A: You can check the current value of the installonly_limit
configuration option using the following command:
❯ dnf --dump-main-config | grep installonly_limit
installonly_limit = 3
Q: How can I lower the installonly_limit
configuration option?
A: You can lower the installonly_limit
configuration option by setting it to a value that is sufficient for your needs. For example, you can set it to 2 using the following command:
❯ dnf5 --assumeno --setopt=installonly_limit=2 install acpi
Q: What is the difference between DNF 4 and DNF 5 in terms of kernel removals?
A: DNF 4 does not remove any kernel versions when the installonly_limit
configuration option is exceeded, whereas DNF 5 removes excess kernel versions even when the kernel package is not part of the transaction.
Q: How can I avoid unexpected kernel removals?
A: You can avoid unexpected kernel removals by lowering the installonly_limit
configuration option or using DNF 4. Additionally, you can report this issue to the Fedora bug tracker and follow the progress of the related bug.
Q: What is the related Fedora bug?
A: The related Fedora bug is tracked in Bugzilla under the following link:
https://bugzilla.redhat.com/show_bug.cgi?id=2350483
Q: What are the recommendations for avoiding unexpected kernel removals?
A: The recommendations for avoiding unexpected kernel removals are:
- Lower the
installonly_limit
configuration option to a value that is sufficient for your needs. - Use DNF 4, which does not exhibit this behavior.
- Report this issue to the Fedora bug tracker and follow the progress of the related bug.
By following these recommendations, you can minimize the risk of unexpected kernel removals and ensure a smooth transaction experience with DNF.