Description of problem: Currently dnf will remove all kernels Could the default be to keep running kernel, so not to inadvertently bork box. We've all got distracted in real life incl work :( For those who do need to remove all it shoud be specific with "dnf remove kernel --all" the script kiddies can: cd /usr/bin/local/ | cat "dnf kernel remove --all" > dnfk ## or similar
I just want to state for the record, that the original proposal on ML was not to hack up something special for kernel or any other package. The proposal was essentially to block removal of installonly packages (kernel is one of them) unless a specific version was given. The --all (or whatever else) was proposed to be a switch giving signal to erase all versions of the installonly package in question.
(In reply to Jan Zeleny from comment #1) > I just want to state for the record, that the original proposal on ML was > not to hack up something special for kernel or any other package. > > The proposal was essentially to block removal of installonly packages > (kernel is one of them) unless a specific version was given. The --all (or > whatever else) was proposed to be a switch giving signal to erase all > versions of the installonly package in question. Sorry forgot to refer to op. As long as "current" behaviour can be changed, is main problem.
Hello, the current behavior of not treating some packages special is deliberate and by-design, as documented by [1]. We will consider changing it only after a substantial number of users asks for it, so far I have heard more arguments in favor of the current behavior than against it. [1] http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel
I am for changing this to keep the running kernel. What would the use case be removing the running kernel?
removing the running kernel makes only in 1 out of 10000 cases sense and these could use "rpm" directly if someone maintains 10, 20, 30, 100 fedora instances and some of the are testing machines currently after all have the last recent one and need for boot the old one is unlikely a "distribute-command.sh 'yum -y remove kernel'" makes a cleanup without any danger and without grab around which kernel-vesions are installed on what machine the kernel *is* a special package and always was in general it would be a huge step backwards if DNF compared to YUM let you damage your system easily and will for many long years fedora user be a valid reason not to touch it as long YUM is wokring in any way
The yum behavior of explicit remove succeeding without actually doing what it was told to do is just counter-intuitive. Adding "critical package" protection for the innocent can be achieved in other ways without adding special package name-dependent quirks.
I like the current behavior of DNF or my proposal from ML [1], referred by jzeleny in comment 1. This would allow DNF to work consistently. [1] https://lists.fedoraproject.org/pipermail/devel/2014-January/193568.html
(In reply to Ales Kozumplik from comment #3) > We will consider changing it only after a substantial number of users asks > for it, so far I have heard more arguments in favor of the current behavior > than against it. > Heh, you didn't just call for a poll to be taken in a bugzilla ticket did you? ;-) Maybe specify where users who are interested in this should register their votes. (or change from "substantial number of users" to "use cases" or some other criteria.)
While I can see where there might be some special situation where deleting/erasing the currently running kernel might be the right thing to do, I believe this is the exception and not the rule. So, by all means, provide some "special" mode such as "erase-all" which will delete every copy but leave erase/remove alone to skip deleting the running kernel. After long using yum, it is just NOT intuitive that the running kernel would be deleted. I believe that the developers need to a lead from the medical profession: "First, do no harm!" BTW, overall, I have been impressed with dnf and am using it most of the time instead of yum.
FWIW I think the suggestion from c#1 is sensible, and in fact I just wrote and then discarded a comment which re-invented it :) It's not 'magic' behaviour for a specific package, it's sensible behaviour for a clearly defined case (multiple copies of a single package installed) where the issued command is clearly ambiguous and guessing the user's intent could be dangerous.
(In reply to Toshio Ernie Kuratomi from comment #8) > Heh, you didn't just call for a poll to be taken in a bugzilla ticket did > you? ;-) If there's enough CCs in this bug (>40) I will consider the proper way to implement something that prevents 'dnf erase kernel' from removing the running kernel. The known trolls (measured by activity on the list) from fedora-devel are not counted into the 40 of course.
I am in favor of keeping the running kernel. I can see accidentally issuing dnf remove kernel* when you mean to issue dnf remove kernel-3.xyz* or similar. Why 40 CCs? Why not 25? What is the highest number of ccs in other dnf bzs? TIA
I think that removing the running kernel should be blocked. If none of the other installed kernels are currently working this can make it hard to fix up your system. Note that just keeping one copy of an install only package doesn't protect against this. Separately, I think there should be a way to configure a list of packages that shouldn't be completely removed.
I think removing the running kernel is design flaw, which should block dnf from being made default in Fedora.
I didn't troll in the ML, I would like to have kernel treated specially.
I found out this morning that some people might be confused about the updates scenario vs. kernel: just to be sure: DNF keeps the last installonly_limit kernels installed, but this *always* includes the running kernel. So by doing 'dnf -y upgrade' one can never end up in a situation with the running kernel removed.
(In reply to Ales Kozumplik from comment #16) > I found out this morning that some people might be confused about the > updates scenario vs. kernel: just to be sure: DNF keeps the last > installonly_limit kernels installed, but this *always* includes the running > kernel. So by doing 'dnf -y upgrade' one can never end up in a situation > with the running kernel removed. Since that was my main concern I suppose you can discount my CC (unless I was already included as one of the trolls, not sure how that's decided). However this still looks like special handling to me, just that it only applies for updates and not explicit removes. Also installonly's original meaning (IIRC) was to cause old kernels to get removed (since in the distant past kernels just kept getting added), i.e. it provided a sort of lagged 'replaces' for a package that didn't normally replace. It sounds like dnf has inverted that meaning (which I'm not sure is a problem since installonly has been switched on so long). I've always regarded update as a combined install (new) and erase (old), from which point of view it's more consistent to have remove obey the same rules for removal as update, with explicit override if needed. But update behaviour was my real issue with this, if specifically removing kernels I would normally do it by version. Behaviour with multiple versions of a package is an odd corner case though: at one time there were very few packages where multiple versions could or would be installed (kernel being one of them), now multiple architectures makes this much more common and I can see the use of this behaviour for that. Being a corner case whatever happens is going to be to some degree special.
I am wondering about comment 16's meaning. You appear to say two conflicting things. One is that the last install_only kernels are kept. (Normally one would assume that last either means the most recent kernels or the kernels with the highest version numbers.) And that this set always includes the running kernel. (Which wouldn't necessarily be the case with the normal meaning of last.) Is the set of preserved kernels really the running kernel plus the last install_only limit minus one of the remaining kernels?
(...still like to be on the CC, just not as a 'vote')
Since I have mentioned that this problem is a cost problem for Red Hat that might make me a troll. However I am going to add myself to the cc list anyway.
From what I can tell of reading the history of this issue and/or bug, it looks to me like a situation where the request for changing "Currently dnf will remove all kernels" is the correct path to take. Not certain why a "number of complaints" had to be met to get this fixed. It seems clear that, at the minimum, an option should be added to allow the user to force dnf to not remove kernals Paul
I am for keeping *at least* the running kernel shielded from accidental removal. As a compromise, the running kernel may be removed only if it is specifically mentioned by version.
I'm fully agree with comment #22 and all other who want to add some protection from accidentally removing the kernel. I also strongly disagree with the decision mechanism using cc's on the bug. That said, it seems that the DNF team has made their decision based on the arguments presented here. As long as there are no more interesting arguments (I don't see any) this probably makes further discussion in this bug useless (?) My personal opinion is that this issue should be handled by FESCO before dnf actually replaces yum so we can get a final verdict. However, I'm not motivated enough to actually file that issue.
(In reply to Ales Kozumplik from comment #16) > I found out this morning that some people might be confused about the > updates scenario vs. kernel: just to be sure: DNF keeps the last > installonly_limit kernels installed, but this *always* includes the running > kernel. So by doing 'dnf -y upgrade' one can never end up in a situation > with the running kernel removed. If this is the case then I'm fine with it. Earlier discussion on the Fedora Users list seemed to imply that this would not be the default behaviour, which if true in my view would be quite literally asking for trouble.
(In reply to Patrick O'Callaghan from comment #24) > If this is the case then I'm fine with it. Earlier discussion on the Fedora > Users list seemed to imply that this would not be the default behaviour, > which if true in my view would be quite literally asking for trouble. The problem is not with 'dnf update kernel', the problem is with 'dnf erase kernel' # dnf erase kernel ... Removing: kernel x86_64 3.14.3-200.fc20 @System 135 M kernel x86_64 3.14.6-200.fc20 @System 135 M kernel x86_64 3.14.7-200.fc20 @System 135 M ... Transaction Summary ================================================================================ Remove 31 Packages ... # uname -a Linux xxx.yyy.zzz.aa 3.14.7-200.fc20.x86_64 #1 SMP Wed Jun 11 22:38:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux # Compare with # yum erase kernel ... Removing: kernel x86_64 3.14.3-200.fc20 @updates 135 M kernel x86_64 3.14.6-200.fc20 @updates 135 M ... Transaction Summary ================================================================================ Remove 2 Packages (+2 Dependent packages) ... # Note that with 'dnf erase kernel' the running kernel is set to be romved, and that 29 other packages also will be removed doing this. That is the problem.
Updates can be a problem. If you aren't running the latest kernels (because of say dracut problems or just wanting to use nondebug rawhide kernes), removing the running kernel could happen. That would prevent loading modules that aren't already loaded and could require a rescue operation on the next boot.
Jan Zelený suggested reopening this on the Fedora users' mailing list. So I'm taking him up on that. :)
> The problem is not with 'dnf update kernel', the problem is with 'dnf erase > kernel' A number of times, without changing the default of 3 installed kernels, I've selectively removed specific kernels to keep particular ones installed. It wouldn't have been hard to remove the running kernel by mistake, if it wasn't prevented. Unless there's some valid use case for removing the running kernel, it should be prevented, even if it means a few more lines of code.
Here's a plan: provide "Protected Packages" plugin that would prevent any transaction that removes the running kernel from occurring and also do that for packages that mark themselves (via provides) as protected (bug 1111855).
thank you!
(In reply to Ales Kozumplik from comment #29) > Here's a plan: provide "Protected Packages" plugin that would prevent any > transaction that removes the running kernel from occurring and also do that > for packages that mark themselves (via provides) as protected (bug 1111855). I don't care how it's implemented, but it needs to be the default behaviour.
This has got to be the silliest thing I've ever seen, but whatever. You enter the command dnf remove dnf, and guess what? It removes dnf. You enter the command dnf remove kernel, and guess what, it removes the kernel. What a concept, it does what you tell it to do. Not withstanding the fact that: 1. You have to be in root mode to invoke 2. It lists everything it is going to do, and you have to explicitly say YES. So we're spending valuable developer time on things like this, when there are certainly more important things that need attention. Just astounding.
(In reply to Gerald Cox from comment #32) > This has got to be the silliest thing I've ever seen, but whatever. You > enter the command dnf remove dnf, and guess what? It removes dnf. You > enter the command dnf remove kernel, and guess what, it removes the kernel. > What a concept, it does what you tell it to do. > > Not withstanding the fact that: > 1. You have to be in root mode to invoke > 2. It lists everything it is going to do, and you have to explicitly say > YES. > > So we're spending valuable developer time on things like this, when there > are certainly more important things that need attention. Just astounding. Agree, but having a general purpose plugin to protect user-defined packages, can be useful for some users, who is afraid of shooting themself in the foot. Then it up to the user to add the packages they what to be protected. Like the original plugin from yum-utils, before it got included into yum base.
(In reply to Gerald Cox from comment #32) > This has got to be the silliest thing I've ever seen, but whatever. I do not see anything silly about this. Yum has such such a protection, apt has it ... but dnf doesn't have it. > So we're spending valuable developer time on things like this, when there > are certainly more important things that need attention. I disagree ... To me, the folks you call developers, are lacking sufficient experience to comprehend what they are doing: Something stupid. > Just astounding. Seems to me, as if each generation of devs has to go a learning curve themselves until they accept the experiences others went though.
@Gerald Cox: if you don't have a clue about usability be silent a) yum protects b) if dnf does not it is a step backwards c) wihtout cleanup systems is harder and dangerous d) not everybody re-installs it's OS twice a year, i maintain systems orginally installed 2008 with FC9 and guess why they survive dist-upgrades all the years without complications and dep-problems because only *really* needed packages are installed and without that protection you risk by find out which ones kill your setup and what you finally do not understand is that there are people like me *testing* fedora packages, testing *very* kernel update straight ahead from koji and there where kernel-series which where unbootable over a long time have fun if the one and only kernel is your running one and get removed by a upgrade - that would be the last time the affected user ever tried testing updates at all so - fine *for you* if you don't need that - but don't call people silly which have *damned* good reasons why they want to avoid steps backwards and make OS maintainance more dangerous than before - otherwise the only person who is proved to be silly is the one calling others so
Hey folks. There are 47 people cc'ed on this bug. Can we please be kind to them and refrain from discussion here unless you have some new information that hasn't already been noted in the last 35 comments? If you would like to discuss back and forth, please take it to private emails. Thanks.
(In reply to Ales Kozumplik from comment #29) > Here's a plan: provide "Protected Packages" plugin that would prevent any > transaction that removes the running kernel from occurring and also do that > for packages that mark themselves (via provides) as protected (bug 1111855). I'd suggest another course of action, because this doesn't seem right to me. You could provide a "package protection" extension point in DNF with a (hopefully) well-defined API and let plugins use this extension point to protect packages. Depending on the context, you might want to be able to remove a package anyway (I'm thinking chroot/mock, probably others too). With this you could implement different policies: - protect the running kernel - check against a list of packages - rely on Provides tags With at least 3 use cases, you could definitely run into potential pitfalls and identify upfront what should be needed/avoided in the API.
Provided upstream by 247ed2a.
thank you - hopefully there will arrive a new build at rawhide soon
dnf-plugins-core-0.1.1-2.fc20, dnf-0.5.3-1.fc20, hawkey-0.4.17-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dnf-0.5.3-1.fc20,hawkey-0.4.17-1.fc20,dnf-plugins-core-0.1.1-2.fc20
Package dnf-plugins-core-0.1.1-2.fc20, dnf-0.5.3-1.fc20, hawkey-0.4.17-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-plugins-core-0.1.1-2.fc20 dnf-0.5.3-1.fc20 hawkey-0.4.17-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-8167/dnf-0.5.3-1.fc20,hawkey-0.4.17-1.fc20,dnf-plugins-core-0.1.1-2.fc20 then log in and leave karma (feedback).
dnf-plugins-core-0.1.1-2.fc20, dnf-0.5.3-1.fc20, hawkey-0.4.17-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.