Bug 1049310 - Keep running kernel
Keep running kernel
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dnf-plugins-core (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ales Kozumplik
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-07 06:49 EST by Frank Murphy
Modified: 2014-07-08 22:30 EDT (History)
51 users (show)

See Also:
Fixed In Version: dnf-plugins-core-0.1.1-2.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-08 22:30:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frank Murphy 2014-01-07 06:49:35 EST
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
Comment 1 Jan Zeleny 2014-01-07 06:56:33 EST
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.
Comment 2 Frank Murphy 2014-01-07 07:00:55 EST
(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.
Comment 3 Ales Kozumplik 2014-01-07 07:42:43 EST
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
Comment 4 Lars E. Pettersson 2014-01-07 07:58:37 EST
I am for changing this to keep the running kernel.

What would the use case be removing the running kernel?
Comment 5 Harald Reindl 2014-01-07 07:59:25 EST
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
Comment 6 Panu Matilainen 2014-01-07 08:03:15 EST
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.
Comment 7 Vít Ondruch 2014-01-07 08:42:10 EST
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
Comment 8 Toshio Ernie Kuratomi 2014-01-07 13:39:08 EST
(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.)
Comment 9 Gene Czarcinski 2014-01-07 15:06:59 EST
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.
Comment 10 Adam Williamson 2014-01-08 02:04:03 EST
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.
Comment 11 Ales Kozumplik 2014-01-08 02:46:48 EST
(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.
Comment 12 Clyde E. Kunkel 2014-01-09 10:18:37 EST
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
Comment 13 Bruno Wolff III 2014-01-09 11:42:42 EST
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.
Comment 14 Ralf Corsepius 2014-01-09 12:11:55 EST
I think removing the running kernel is design flaw, which should block dnf from being made default in Fedora.
Comment 15 Orcan Ogetbil 2014-01-09 22:16:50 EST
I didn't troll in the ML, I would like to have kernel treated specially.
Comment 16 Ales Kozumplik 2014-01-10 03:22:00 EST
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.
Comment 17 Ian Malone 2014-01-10 07:28:20 EST
(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.
Comment 18 Bruno Wolff III 2014-01-10 09:09:18 EST
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?
Comment 19 Ian Malone 2014-01-10 10:43:42 EST
(...still like to be on the CC, just not as a 'vote')
Comment 20 Stephen John Smoogen 2014-01-10 12:00:44 EST
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.
Comment 21 Paul 2014-06-16 02:58:04 EDT
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
Comment 22 Rejy M Cyriac 2014-06-16 03:50:43 EDT
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.
Comment 23 Alec Leamas 2014-06-16 04:18:00 EDT
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.
Comment 24 Patrick O'Callaghan 2014-06-16 07:11:04 EDT
(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.
Comment 25 Lars E. Pettersson 2014-06-16 08:19:21 EDT
(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.
Comment 26 Bruno Wolff III 2014-06-16 09:17:01 EDT
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.
Comment 27 Matthew Miller 2014-06-16 16:35:11 EDT
Jan Zelený suggested reopening this on the Fedora users' mailing list. So I'm taking him up on that. :)
Comment 28 Andre Robatino 2014-06-16 16:48:59 EDT
> 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.
Comment 29 Ales Kozumplik 2014-06-23 05:07:06 EDT
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).
Comment 30 Harald Reindl 2014-06-23 05:34:58 EDT
thank you!
Comment 31 Patrick O'Callaghan 2014-06-23 07:26:08 EDT
(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.
Comment 32 Gerald Cox 2014-06-23 11:38:17 EDT
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.
Comment 33 Tim Lauridsen 2014-06-23 12:35:34 EDT
(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.
Comment 34 Ralf Corsepius 2014-06-23 12:47:56 EDT
(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.
Comment 35 Harald Reindl 2014-06-23 12:48:19 EDT
@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
Comment 36 Kevin Fenzi 2014-06-23 12:53:05 EDT
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.
Comment 37 Dridi Boukelmoune 2014-06-24 04:43:06 EDT
(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.
Comment 38 Ales Kozumplik 2014-07-02 11:03:13 EDT
Provided upstream by 247ed2a.
Comment 39 Harald Reindl 2014-07-02 11:05:05 EDT
thank you - hopefully there will arrive a new build at rawhide soon
Comment 40 Fedora Update System 2014-07-07 05:11:48 EDT
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
Comment 41 Fedora Update System 2014-07-07 21:04:09 EDT
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).
Comment 42 Fedora Update System 2014-07-08 22:30:03 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.