I can’t find the place to set the system to keep multiple kernels. For the first time in a long time, updates are giving me grief. I’ve kept the last working nvidia driver in case I need it.
Now I would like to keep one old kernel when I update to the new one. I had a lab rat that never got rid of old kernels and that was too much. It is possible to keep the last working kernel when you update, isn’t it?
It is possible by editing the line referring to “multiversion” in /etc/zypp/zypp.conf, but frankly: I think that is a bad idea. Updated kernels provide crucial security bugfixes, so older kernels should not be used anymore.
On Wed, 27 Oct 2010 22:06:03 +0530, gropiuskalle
<gropiuskalle@no-mx.forums.opensuse.org> wrote:
>
> It is possible by editing the line referring to “multiversion” in
> /etc/zypp/zypp.conf, but frankly: I think that is a bad idea. Updated
> kernels provide crucial security bugfixes, so older kernels should not
> be used anymore.
>
>
it’s useful when using release candidate kernels. those get updated even
without security fixes, and sometimes the latest one isn’t so great.
–
phani.
I am one of those that got hit by the nvidia driver not working with the last 2 kernel updates. That is why I wanted to revert to the older kernel in an emergency, like today when I lost the desktop again. Luckily, nvidia is fixed by rolling back the driver and not the kernel. But someday that might not be true.
Point taken, but I am sure Prexy is referring to standard kernels provided by the ‘update’-repository. Again: this is not a good idea.
Prexy: instead of fiddling with the kernel you should work on less critical parameters, in this case the NVidia-driver. I have read about the bug you mention, but it can easily be solved by uninstalling the driver from the NVidia-repo and using the .run-file from the NVidia-site instead (search this forum for more info on that).
On 2010-10-27 20:06, gropiuskalle wrote:
>
> “phanisvara” Wrote:
>> it’s useful when using release candidate kernels. those get updated even
>> without security fixes, and sometimes the latest one isn’t so great.
>
>
> Point taken, but I am sure Prexy is referring to standard kernels
> provided by the ‘update’-repository. Again: this is not a good idea.
It is a very good and useful idea, because sometimes the new kernel simply does not work. Often the
update puts the wrong options and it doesn’t boot. In that case you need booting with some other
kernel, repair the problem, if possible, and then go back to the newer kernel, if possible.
If the new one doesn’t boot, you have to use the old one while you report the problem and wait for a
newer kernel that corrects it. It is no use at all to insist on running a kernel that does not run.
Having the old kernel intact is far easier and faster than booting with a dvd, reinstall the dvd
kernel, and then upgrade to another version.
Method: edit /etc/zypp/zypp.conf.
11.3:
Uncomment the line:
multiversion = provides:multiversion(kernel)
11.2:
Add a line listing all kernel packages separated by commas:
multiversion =
kernel-desktop,kernel-debug-devel,kernel-desktop-devel,kernel-source,kernel-syms,kernel-xen-devel,preload-kmp-desktop,alsa-driver-kmp-desktop
It does not apply only to the kernel, any package can be listed here.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
This has been discussed in the german subforum recently (→here), Akoellh and Knurpht have provided some very good arguments against this feature. For me the most crucial one is that if an updated Kernel will not work (and in many cases the actual source is not the Kernel itself) many users will simply boot the old one = problem “solved”. I am sure many users who, for example, have installed an NVidia-driver “the hard way” (via .run-file from the NVidia site) would switch back to the unfixed Kernel because the updated one would not start an X-sever. Other reasons include the chaos two different sets of KMP modules would cause (which would make even working kernels possibly unusable), also one would need to multi-install kernel sources, -devel-packages etc. as well, for example to successfully rebuild kernel modules for VirtualBox and the like.
In short: one could easily get even more problems because of the multi-option.
For those who understand these parameters, multiversion might be a possible option, for most it definitely is not.
Hello gropiuskalle. I would like to put by 2 cents in here since I don’t speak German. If my two options are:
OR
I then select option number 2, every time.
Now if the problem with option 2 is a fear that a user will keep using an older kernel would ignore the fact that yet newer kernel updates will come along, which can optionally be loaded by the user just as before and which by default, become the new default kernel to load, which the user must make a choice to avoid.
Now if there is third choice that says we will not distribute defective kernels, I would pick that choice. But not allowing the ability to maintain more than one kernel version is no solution at all. It makes no sense to me at all to not allow such a choice to maintain more than one kernel version and to let anyone that asks how to do such a thing to be given the exact instructions on how it is done.
Thank You,
But: those updated kernels are heavily tested before provided via update. If they “break” something, then one should try to solve that. “Break” is pretty much open for interpretations. I use SuSE since version 10.0 and never have experienced a kernel not being able to boot properly or the like. Some have broken something (I point to the NVidia-.run-example once again), but the kernel itself was always healthy.
- Keep previous kernel version. If update breaks kernel, then reboot and drop back to previous version.
I then select option number 2, every time.
Now if the problem with option 2 is a fear that a user will keep using an older kernel would ignore the fact that yet newer kernel updates will come along, which can optionally be loaded by the user just as before and which by default, become the new default kernel to load, which the user must make a choice to avoid.
Again, take the above example; if someone installed the NVidia-driver, the only kernel able to start the X-server will be the one he build the NVidia module with. I see many threads where users are unaware of the things to do after such an update of the kernel and they often do not ask “How do I properly recompile the NVidia module” or “…the VirtualBox module” but “How do I reinstall the previous kernel”.
But not allowing the ability to maintain more than one kernel version is no solution at all. It makes no sense to me at all to not allow such a choice to maintain more than one kernel version and to let anyone that asks how to do such a thing to be given the exact instructions on how it is done.
Well, I myself provided a way to multiboot several kernels, so I never aimed for “not allowing”. 
I just say it’s not a good idea.
First off gropiuskalle, I very much appreciate your point by point discussion. It helps look at the point of view from others. I will say that fundamentally, I think the option to maintain more than one kernel should even be the default, but perhaps those that really determine what happens do not. To that end, I feel it is OK, to tell anyone that has had a bad experience with a kernel update, to suggest an ability to maintain more than one version, just in case. I would point to the many problems recently that did not keep one from loading, but which often disabled mice and keyboard functions. Such a problem to a user, with no understandable way back, may decide enough is enough and never use openSUSE again. One thing is for sure, my over all opinion of this issue and openSUSE will not likely be changed, but I am not going anywhere, but plan on staying in the middle of it all for better or worse. Thanks again for your opinions.
Thank You,
That’s fine for you, you know what to do. But a newbie gets a black screen and says that’s it, I’m leaving.
IMO both problems should be solved.
The video driver should be updated to match the kernel using DKMS, or whatever. It’s just got to work.
And there should be the ability to return to a previous kernel in a pinch. It’s reckless to take a leap of faith and remove the previous kernel even if the replacement works 99.999% of the time. Because the remedy is to get a kernel off the boot media, which is a lot of hassle. Even sysadmins make errors. Even Novell builders make errors that might make a kernel unusable for a small fraction of people. Maybe you haven’t experienced it that’s all. RHEL keeps the current and 2 previous kernels. Do you think they might know something about good sysadmin practice?
But a newbie gets a black screen and says that’s it, I’m leaving.
Well, I might sound a bit conservative here, but to me Linux basically is a system which the user has to learn how to control. Workarounds like booting insecure kernels are not appropriate to me. One of the major aspects of Linux is security.
It’s just got to work.
True. So make it work. And learn how to.
And please note I never said this option should be taken away - if one is afraid of being confronted with a situation so desperate that he has to fall back on the previous kernel, go ahead, it’s possible. Again, all I say is that this is not a good idea. Because it is insecure. I contribute to several forums as well and therefore know quite well that comfort mostly wins against sanity, that’s why I think multiversion should not be default.
And frankly, I don’t care much about users leaving openSUSE or Linux in general because of a bash prompt (a.k.a. “black screen”). What is this about? Market share? C’mon… I prefer a secure and controlable system over a popular one any time. That’s why I am using Linux.
RHEL keeps the current and 2 previous kernels. Do you think they might know something about good sysadmin practice?
Do you really mean to say that keeping an unfixed kernel is good practice?
I see you are one of those people who are under the misapprehension that good practice can be enforced solely through preventing people from doing certain things.
FYI RHEL makes the latest kernel the default, but leaves the last two around. So the sysadmin would have to explicitly choose to boot an old kernel. If you do nothing, you get the new kernel by default, no hassles there. Same thing with multiversion in openSUSE. You also get multiversion in Ubuntu but the user normally doesn’t even see the GRUB screen unless they hit ESC.
You are being inconsistent here. You say what’s the problem with using the bash shell to fix a video driver problem, I can do it why can’t they, then you don’t trust the RHEL sysadmin with a couple of old kernels lying around. It’s as if you think other people are not as responsible as you and can’t be trusted.
I see you are one of those people who are under the misapprehension that good practice can be enforced solely through preventing people from doing certain things.
You seem to have trouble reading my comments, so I repeat: it is possible. No one is preventing others from doing whatever they want. I don’t, SuSE doesn’t, Linux doesn’t. But it is insecure using applications / packages / kernels who have bugs. Period. If one can’t cope with an X-server not starting, then maybe Linux is not for him. I am not saying options should be taken away, I am saying not everything that is possible is the best way. Some options even offer bad ways.
You are being inconsistent here. You say what’s the problem with using the bash shell to fix a video driver problem, I can do it why can’t they, then you don’t trust the RHEL sysadmin with a couple of old kernels lying around. It’s as if you think other people are not as responsible as you and can’t be trusted.
You try to pull this discussion to pretty abstract levels, I am trying to to stay factual. Kernels with proven bugs should not be booted. Especially when you are a sysadmin running a server.
You would not be saying that if the choice is between bringing up a system in a moment because of a problem that the new kernel has caused or being offline while you restore a previous kernel from backup or boot media. Everything is black and white for you, kernel has bugs, so it must never be booted. When you run the previous kernel you are in no worse position than before the update. The previous kernel gives you the ability to roll back quickly as opposed to roll back painfully. It’s equally slightly insecure in both cases.
Following your kind of reasoning, you should never give a spare key to your house to a nearby relative. It increases the risk of your key falling into the wrong hands. If you lock yourself out, you should always expect to call in a locksmith.
If you don’t understand this parable, perhaps you don’t understand risk tradeoffs.
You would not be saying that if the choice is between bringing up a system in a moment because of a problem that the new kernel has caused or being offline while you restore a previous kernel from backup or boot media.
Another abstract level reached. You might enjoy this kind of discussion, for me that’s quite boring, because it’s irrelevant. You argue on the assumption that kernel updates will possibly trash a system, and while that is a possibility, it is very unlikely. This thread on the other hand started like this:
…and this is the attitude I am referring to - roll back to an insecure kernel instead of solving the actual problem, in this case: a GFX module not working properly.
If you don’t understand this parable, perhaps you don’t understand risk tradeoffs.
I do understand, but to tell you the truth: I trust my relatives more than myself.
I follow a pretty simple way when it comes to security (ah, how often have I quoted this motto?):
Security is not a state, but a concept.
Are you saying that a kernel update is 100% reliable and never goes wrong? You have more confidence than I do, or less experience with actual events. And anyway, if it goes right like you say, nobody will reach for the old kernel.
In fact, I haven’t commented on the OP’s request. As I said before, that is really a different problem and should be solved by making the video driver update reliable. Other distros can do it, openSUSE is lagging in this, requiring people to resort to nvidia.run, etc. Both you and the OP are making the same conflation of the two problems. He’s understandably wanting to get his system working by reverting, which is not the best way of doing it, and you are just saying don’t do this, without offering a way forward. Which is to fix the video driver problem at the distro level. For the sake of newbies, not you obviously.
Having a multiversion option remains useful. By default you still get the latest kernel. To get an older kernel you have to intervene at the boot screen. Only if you go inside the boot setup can you change the default. Unlike you, I don’t see a huge risk there. Sure it can be abused, but so can any of a number of options. You like a system you can tweak, so why don’t you trust that other people can be as discerning as you in using that freedom?
Another aspect to this issue is that of multiple kernels where a custom kernel later than the one offered by Opensuse Update is the system default.
I’m running a custom 2.6.36 which is set as my system default. I have the KDE updater applet running, automating my updates. Yesterday there was a new kernel, and this morning I find myself booting into an earlier version of the kernel since the update process reset my default kernel to the one just downloaded since the system assumes that is the most recent one.
Problem is that the default opensuse kernel is broken for me (See thread “11.3 slower than 11.2?”) and it is pretty obvious to me when I am in the wrong kernel. When it happens I have to hard stop my machine, reboot and reset the system default. A simple fix - a nuisance, that is all.
Woof. Never expected this when I posted.
Mine is the perspective of a low-skill, enthusiastic, user. Please note that I stated I solved the problem, not by rolling back the kernel, but by rolling back the driver. I know enough not to try to fix an ipod with a hammer. Going through the exercise of rolling back the driver twice in one week reminded me of the times that I so hashed up the system trying to fix things that my only option was a re-install. Had I been able to roll back the kernel to a working system, I would have been able to repair the mess I made by using this forum and other online resources. I have done this on my old test machine. I look at having the “last working kernel” as a bit of insurance.
The security argument is just not convincing to me. I do a zypper up at least once a day. What if I was one of those people that did it only once a month? Wouldn’t I be in greater danger for that month than I am rolling back the kernel for a day or two until I got a problem sorted out? If my old pc, sitting out here on the edge of the internet, is that vulnerable, then linux is not as secure as I thought.
This is the last time I am writing this again, because I really hate discussions running in circles.
It’s up to them.
I don’t care if someone wants to go that way. They don’t need me to trust them. I will still be using SuSE even if keeping obsolete kernels will become default. Everybody has a choice. If anyone feels the need, go on, fiddle with incompatible modules, mixed up KMPs and unfixed security bugs. All I say is that this is a inadequate way.
Got it? Good.
Read this thread again… (hint: post #5).
Take a peek in some Ubuntu-forums and you will see that this a false assumption. Again: the need for comfort mostly wins over sanity.
You could work with repository priorities or package locks to prevent that.