Removing alt Installed Kernel safely

Howdy,
Hoping for some verification before I proceed.

Situation:
An alt kernel was installed side by side with the current mainstream kernel during an experimental NIC driver install. Unfortunately, since the experiment failed I would now like to remove all traces of the alt kernel since it was given a version ahead of the current main version and I would like to avoid all possibilities of contention should a future kernel upgrade use the experimental alt kernel’s version number.

Question:
Can the alt kernel be removed safely by simply removing all files with that version in the filename in the /boot/ directory, then modify the GRUB bootloader to no longer point to the alt kernel files? The directory /usr/src is empty so I assume that the experimental kernel was built using the same kernel sources as the mainstream kernel so nothing there needs to be removed.

So, in my situation you can see by the following that kernel versions are installed

Current mainstream kernel (I want to keep)
2.6.34.7-0.3-desktop
**Alt experimental kernel **(I want to purge)
2.6.34-12-desktop

Contents of /boot/

SuSEbox:/boot # ls
backup_mbr                           symtypes-2.6.34.7-0.3-desktop.gz
boot                                 symvers-2.6.34-12-desktop.gz
boot.readme                          symvers-2.6.34.7-0.3-desktop.gz
config-2.6.34-12-desktop             System.map-2.6.34-12-desktop
config-2.6.34.7-0.3-desktop          System.map-2.6.34.7-0.3-desktop
grub                                 vmlinux-2.6.34-12-desktop.gz
initrd                               vmlinux-2.6.34.7-0.3-desktop.gz
initrd-2.6.34-12-desktop             vmlinuz
initrd-2.6.34.7-0.3-desktop          vmlinuz-2.6.34-12-desktop
message                              vmlinuz-2.6.34.7-0.3-desktop

Proposed solution:

mv /boot/*2.6.34-12*

PS. And I suppose it might always be safer to actually move the files to a backup location instead of deleting altogether…

TIA,
Tony

tsu2, if you have not done so, you need to modify how YaST treats kernel installs so that it will maintain multiple kernel versions. Here is a thread on how that works.

Keeping the current kernel when doing a kernel update through yast

The question to you is, how did you install this extra kernel? Did you use YaST? Have you already modified YaST to maintain more than one kernel version? Once YaST allows more than once kernel version, you only need to uncheck the kernel you do not want to have it removed from boot and removed from your grub menu.lst file.

From a practical matter, removing the kernel from boot and removing it from your menu.lst file manually simply removes the kernel as a load option. If it was not installed by YaST, that is all you need to do. If it was installed by YaST, use YaST to remove it so it will not show up as being installed.

One final note, having extra kernels installed and extra options in your menu.lst file does not hurt anything in any way and if you are fearful of losing anything then leave them as it is of no consequence to have more than one kernel present, even if you never use it.

Thank You,

Thx for replying…
Someone else created the compilation script and since I already have 2 working kernels I’m sure the system already supports multi-kernel and everything to this point on my machine has been done through YAST, but I wonder if that really relates to however the alt kernel was created by the NIC compilation script.

I’m unclear where I can just “uncheck” to remove an existing kernel…

Yes, I understand normally nothing is to be feared by retaining alt kernels, but in this case the situation is slightly different… The alt kernel has a later version number than the mainstream kernel so there does appear to be a risk by leaving it in place.

Tony

Unckeck what ? If you don’t want to keep older kernels in the future, comment out the appropriate line back in /etc/zypp/zypp.conf, as shown in the link posted by jdmcdaniel3. If you want to remove older kernels currently installed, take a look at the installed packages with

rpm -qa | krep kernel

Remove those you don’t need with

zypper rm kernel-desktop-xxx

zypper rm kernel-desktop-xxx

I like that solution very much for any multiple kernel installed by YaST please_try_again. Very nice! What if you installed the kernel outside of YaST, would this command do anything?

Thank You,

nope. unless you also package your kernels in rpms, which I believe should be possible. This command just removes a kernel package which was installed like any other package.

OK
Sorry for being a bit dense, I guess I’m basically focusing mainly on the desired result rather than carefully reading every detail which is my fault.

Inspecting zypp.conf, it looks like the line is not already commented out, but should that mean that the kernel could still be “multi-kernel” but just not yet configurable by YAST? — I suppose it looks like it can’t hurt to remove the comment in zypper.conf which looks to enable the multi-kernel config in YAST

And, maybe part of what is making this a bit confusing is the idea of what diffs there are within a multi-kernel system. I already understand that a kernel upgrade is different because the kernel is modified so past kernel features are superceded and generally lost. In a multi-kernel system I’m led to believe that you don’t have a single kernel that supports multiple versions, there are separate kernel files for each version (would like verification)? If each kernel version should have its own file(s) then is it really certain that a whole set of RPMs would be installed to support and define each version?

Thx for the suggestion regarding removing rpms related to the kernel version, I’ll take a look at that possibility, too.

Tony

If it’s NOT commented out, you’re enabling multi-kernel. This is not the default. Norrmally you would uncomment this line yourself if you want to keep multiple kernel versions (in openSUSE).

I suppose it looks like it can’t hurt to remove the comment in zypper.conf which looks to enable the multi-kernel config in YAST

It does enable multi-kernel. Otherwise it doesn’t hurt.

If each kernel version should have its own file(s) then is it really certain that a whole set of RPMs would be installed to support and define each version?

Not a whole set, just the kernel package, as well as kernel sources and headers. It’s not such a big deal. The modules are located in subdirectories of /lib/modules for the different kernels.

On 2010-10-09 22:06, tsu2 wrote:

> So, in my situation you can see by the following that kernel versions
> are installed
>
> Current mainstream kernel (I want to keep)
> 2.6.34.7-0.3-desktop
> *Alt experimental kernel *(I want to purge)
> 2.6.34-12-desktop

Just become root in a terminal, and run:



rpm -qa | grep -i kernel


You will get a response like:

kernel-desktop-2.6.34.7-0.3…
kernel-desktop-2.6.34-12…

and a few more, perhaps. Now run



rpm --erase kernel-desktop-2.6.34-12  etc.


If you list all the kernel related packages in the same line, it will not complain and work.
Actually, that is probably the reverse command of the one you used to install that test kernel.

That’s the manual way. It is also possible to do it via yast once multikernel is activated.

> PS. And I suppose it might always be safer to actually move the files
> to a backup location instead of deleting altogether…

You have the original rpms they told you to install to do the testing, no? That’s all you need.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

A summary of what I ended up doing, and hopefully a proper guide for others who attempt this. Thx to all who contributed to this thread, NOTE that following prior posts in this thread resulted in a less than desirable result but was enough to enable me to work my way through the difficulties. At the end of this post which describes the problems I ran into, I will summarize what I consider the proper and best way to remove an alt kernel, and NOTE that this is different than what I returned searching Forums posts which generally suggested just deleting files in the /boot/ directory, which prompted my original posting since it made me uncomfortable to just delete files when I felt something like a kernel could/would have dependencies which wouldn’t be addressed by a straightforward deletion.

First,
The procedure relating to enabling or disabling zypp.conf doesn’t seem to have any effect on enabling or disabling a multi-kernel option in YAST on my machine, the referenced thread might apply only to SuSE 11.4, can anyone really verify it should also be a feature in OpenSuSE 11.3?

The rpm searching for packages with “kernel” in the title worked fine, and as suggested I used the zypper command to remove the desktop kernel. This proceeded as expected, zypper determined that while removing this kernel package another package needed to be downloaded and installed.

But, after re-booting I was aghast that after running the RPM search again, I found the kernel package which should have been removed still present. Opening YAST, the kernel package is not listed.

Zypper appeared to have not found all dependencies and zypper now did not agree with rpm.

Running zypper again trying to remove the kernel package resulted in a quick command prompt (nothing really happened).

Running the RPM command to remove/erase the kernel package returned two package dependencies. Rather than type long filenames, I was able to find both packages and removed using YAST.

I then re-ran RPM erase to remove the kernel package.

Re-inspecting the /boot/ directory, it appears that finally the RPM command removed all files related to the removed kernel without need for any manual deletion.

Lastly, I used YAST to modify the bootloader removing the now worthless GRUB entries.

Before summarizing, this has resulted in a couple questions in my mind,

  1. As mentioned above, should the multi-kernel option have been displayed in OpenSuSE 11.3?
  2. Am curious about the definition of “multi-kernel” – I’m wondering if there is such a thing as a single kernel file that supports multiple kernels as opposed to kernels residing separately in different files side by side. If this is so, then it might answer why the multi-kernel option didn’t exist on my machine.

SUMMARY:

I recommend using only RPM commands, for some reason normally reliable zypper can be faulty.

1. Search for the kernel package to be deleted

rpm -qa | grep kernel

2. Use RPM to remove the appropriate package, the following references a “desktop” kernel. The first time you run this will likely error returning package dependencies which need to be resolved first. Resolve those dependencies first using your RPM manager of choice (Any will do, ie RPM, ZYPPER, YAST, etc). After the dependecies have been resolved, re-run removing the kernel itself.

rpm --erase *kernel-desktop-2.6.34-12*

3. Verify results, ie. check to see whether any files with the removed kernel version in the filename still exist in /boot/, they should all be removed. If you’re good, then one more step,

4. Open YAST > System > Bootloader and remove the appropriate entry in GRUB, of course make sure you don’t make a mistake here or your system won’t boot next time without repairing.

HTH and thx again to all,
Tony

I don’t think you can call your bad luck with zypper a guide for anybody.

It is in 11.3, in 11.2, in 11.1 … and it has been in openSUSE for a while. It does what’s expected without a doubt.

Maybe you didn’t remove them properly.

And I do not agree with the rest of your post. You should use rpm directly when you don’t have the choice, not because you’re getting confused with zypper. The remedy to your frustrations is not a solution for the rest of the world. A more appropriate title to that thread would have been “Removing alt kernel approximately” rather than “safely”.

On 2010-10-12 10:06, please try again wrote:

> tsu2;2236811 Wrote:
>> The procedure relating to enabling or disabling zypp.conf doesn’t seem
>> to have any effect on enabling or disabling a multi-kernel option in
>> YAST on my machine, the referenced thread might apply only to SuSE 11.4,
>> can anyone really verify it should also be a feature in OpenSuSE 11.3?

> It is in 11.3, in 11.2, in 11.1 … and it has been in openSUSE for a
> while. It does what’s expected without a doubt.

The line “multiversion = provides:multiversion(kernel)” is only supported from 11.3 onwards. On 11.2
you have to give the list of packages separated by commas. This has be confirmed by devs this very week.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

On 2010-10-12 05:06, tsu2 wrote:

> searching Forums posts which generally suggested just deleting files in
> the /boot/ directory,

That post would be from a newbie.

> First,
> The procedure relating to enabling or disabling zypp.conf doesn’t seem
> to have any effect on enabling or disabling a multi-kernel option in
> YAST on my machine, the referenced thread might apply only to SuSE 11.4,
> can anyone really verify it should also be a feature in OpenSuSE 11.3?

Yes, the feature works, but perhaps you did not use the appropriate syntax.

11.3:

multiversion = provides:multiversion(kernel)

11.2:

multiversion = kernel-default,kernel-default-devel,kernel-source,kernel-syms,etc

and the names have to be the correct ones.

> The rpm searching for packages with “kernel” in the title worked fine,
> and as suggested I used the zypper command to remove the desktop kernel.
> This proceeded as expected, zypper determined that while removing this
> kernel package another package needed to be downloaded and installed.

You can not use zypper to uninstall the kernel if multiversion is not active, because you can not
“live” without a kernel. It would try to install the same or another one.

There is also a difference with zypper about case, but I’m fuzzy about the details right now. IIRC,
zypper is not always case sensitive, but rpm is.

> * _ S U M M A R Y : _ *
>
> I recommend using only RPM commands, for some reason normally reliable
> zypper can be faulty.
>
> 1. SEARCH FOR THE KERNEL PACKAGE TO BE DELETED
>
>
> Code:
> --------------------
> rpm -qa | grep kernel
> --------------------

“grep -i kernel” to be sure.

> 2. Use RPM to remove the appropriate package, the following
> references a “desktop” kernel. The first time you run this will likely
> error returning package dependencies which need to be resolved first.
> Resolve those dependencies first using your RPM manager of choice (Any
> will do, ie RPM, ZYPPER, YAST, etc). After the dependecies have been
> resolved, re-run removing the kernel itself.

Just query rpm to list them, and enter all those names in the rpm command line. No need to bother a
package manager. Type long names? Who needs to type? Use mouse copy-paste. What, you are in text
mode? It also works (search for “gpm”).

> 3. Verify results, ie. check to see whether any files with the
> removed kernel version in the filename still exist in /boot/, they
> should all be removed. If you’re good, then one more step,
>
> 4. Open YAST > System > Bootloader and remove the appropriate entry in
> GRUB,
of course make sure you don’t make a mistake here or your
> system won’t boot next time without repairing.

Just use a text editor and save you time :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

That’s right (just checked on 11.1).

Yes, that was obviously the mistake.

Or use zipper and it should remove the obsolete boot entries.

After some thought, the evidence strongly suggests that the kernel was installed as an RPM but was not installed using zypper or YAST, my guess is that it was installed using RPM.

This has revealed something new to me, up until now I thought that Zypper/YAST was fully adequate in managing all SuSE RPMs but this has shown that not to be completely true and is likely at the root of why

  • The multi-kernel YAST feature did not work
  • Zypper did not understand or discover the kernel RPM’s dependencies

It seems one of the lessons to be learned is that Zypper/YAST is not completely equivalent to RPM and although Zypper/YAST might be fine most of the time, it’s likely that only RPM will be successful all the time (or at least all the time for any packages installed by Zypper, YAST, RPM and I would guess YUM). RPM seems to be a “lower level” application for RPM management and if Zypper/YAST is to be more reliable then they have to do a better job inspecting and importing RPM module attributes.

This makes me wonder if the same RPMs I removed are installed again using Zypper/YAST, the result might be that the YAST multi-kernel function would work and zypper would fully manage the RPM (I would have to tear apart the install script to test this, not something I really want to do).

Given the above, my original question whether there are different multi-kernel file configurations may have no importance, it’s simply enough in my situation that YAST didn’t understand or discover the configuration setup by a non Zypper/YAST install… Although I’m still curious for the future whether all multi-kernel setups will follow the same file structure pattern or not.

A few comments to suggestions of mistakes I might have made (but I think not)

  • Any suggestion that I entered an incorrect command is very unlikely. The file zypp.config already has the entry correctly entered but commented out. I just uncommented the line, saved the file and rebooted. Should I have done anything differently and what could be more bone head proof?

  • Don’t get me wrong, but calling my zypper mis-adventure simply bad luck is a bit cavalier. The point is that zypper didn’t appear to fail, it actually seemed to succeed but was faulty. It’s the first time it’s ever happened to me, and the way it failed is surprising and perhaps revealing. If you think I did something wrong, I didn’t leave anything out and the procedure should have been simple and therefor no room for “confusion.”

Regarding the -i flag in the grep command, if that does configure a case-insensitive search of the string I agree that is an improvement and fortunately was not critical to my use this time.

Tony

On 2010-10-13 02:06, tsu2 wrote:
>
> After some thought, the evidence strongly suggests that the kernel was
> installed as an RPM but was not installed using zypper or YAST, my guess
> is that it was installed using RPM.

Well, you should know what you used to install it :slight_smile:

> This has revealed something new to me, up until now I thought that
> Zypper/YAST was fully adequate in managing all SuSE RPMs but this has
> shown that not to be completely true and is likely at the root of why
>
> - The multi-kernel YAST feature did not work

Probably you used the wrong syntax.

Notice that the “provides…” think is new and needs something on the rpm, I believe. It might not
work for external or special rpms. In that case, you have to list the rpm names instead (the old
syntax).

> - Zypper did not understand or discover the kernel RPM’s dependencies

It surely did. However, if the repo where it came from was not set up, it is impossible that zypper
could say much. The package would appear in red.

> It seems one of the lessons to be learned is that Zypper/YAST is not
> completely equivalent to RPM

It never is. Zypper and yast both call rpm to do the actual installation/removal of packages. That’s
why I told you to use rpm directly, without intermediaries.

To clarify, yast and zypper see anything installed, because they query the rpm database. What they
offer to install is different, the packages have to be somewhere (a repo) that they see. And if you
ask they will offer to uninstall anything already installed - although how they present it when
there are two packages installed of the same name but different version, I don’t remember exactly
just now.

> - Any suggestion that I entered an incorrect command is very unlikely.
> The file zypp.config already has the entry correctly entered but
> commented out. I just uncommented the line, saved the file and rebooted.
> Should I have done anything differently and what could be more bone head
> proof?

Yes, don’t reboot. It doesn’t make any difference.
Ok, it makes some difference, yes… that you waste some minutes :-p


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)