problem with multiple kernel versions

English Install/Boot/Login
1

I’m running 11.2 with standard repositories (plus packman). I want to install a recent kernel and then compile some variations of it (to investigate a hardware problem).

So I took these steps:
(1) add the 11.2 Kernel:/HEAD repository
(2) enable multiversion in zypp.conf
(3) use YaST software management to select the kernel development pattern

Note that at the moment, the standard 11.2 kernel ( 2.6.31.14-0.6-desktop) is in use and I have not selected any packages from HEAD.

But it has installed 2.6.37-41.1 versions of all the kernel packages I didn’t already have (source & docs etc) instead of the 2.6.31 versions. /usr/src/linux symlinks to linux-2.6.37-41 instead of to a directory for the running kernel!

Why?

I think:

(1) it should have loaded the packages corresponding to the running kernel
(2) it’s not supposed to switch repositories

2

I’m running 11.2 with standard repositories (plus packman). I want to install a recent kernel and then compile some variations of it (to investigate a hardware problem).

So I took these steps:
(1) add the 11.2 Kernel:/HEAD repository
(2) enable multiversion in zypp.conf
(3) use YaST software management to select the kernel development pattern

Note that at the moment, the standard 11.2 kernel ( 2.6.31.14-0.6-desktop) is in use and I have not selected any packages from HEAD.

But it has installed 2.6.37-41.1 versions of all the kernel packages I didn’t already have (source & docs etc) instead of the 2.6.31 versions. /usr/src/linux symlinks to linux-2.6.37-41 instead of to a directory for the running kernel!

Why?

I think:

(1) it should have loaded the packages corresponding to the running kernel
(2) it’s not supposed to switch repositories
Hello djh-novell and sorry for any issues you may have had. There seems to be some confusion over two different issues.

**1. Adding the ability to maintain more than one kernel version to select from in your grub menu.lst OS menu selection file.
**
The accepted way to do this for openSUSE 11.2 is to:

edit the file /etc/zypp/zypp.conf to say:

    ##
    ## Packages which can be installed in different versions at the same time.
    ##
    ## Packages are selected either by name, or by provides. In the later case
    ## the string must start with "provides:" immediately followed by the capability.
    ##
    ## Example:
    ##    kernel                - just packages whith name 'kernel'
    ##    provides:multiversion(kernel)   - all packages providing 'multiversion(kernel)'
    ##                      (kenel and kmp packages should do this)
    ## Valid values:
    ##    Comma separated list of packages.
    ##
    ## Default value:
    ##    empty
    ##
    # multiversion = provides:multiversion(kernel)

    multiversion = kernel-desktop

**2. Install the most recent Kernel from Kernel/Head

**The accepted way to do this for openSUSE 11.2 is to add the following repository in YaST / Software / Software Repositories:

Index of /repositories/Kernel:/HEAD/openSUSE_11.2

Now, this will make available to you the most recent stable kernel 2.6.37, which is WAY ABOVE the kernel version 2.6.31 that came with openSUSE 11.2. So the question is, what was it you were trying to do? Normally, if you add the first option, you simply get the ability to keep and use older kernels that you have installed in the 2.6.31 line and if a newer one comes out, you can install it, without removing your old one. But, all versions were in the 2.6.31 line. Having more than one kernel choice is a good thing should one of the kernels be messed up in some way that does happen ever so often.

Once you added in the Kernel/Head repository, not only can you install kernels in the 2.6.31 line, but you can also install the most recent version, up to 2.6.37 something at present. Now, since you did enable the multiversion kernel ability, having more than one kernel version is OK and you do not need to use or even remove the kernels you do not use unless you are really running low on disk space.

So, what was it you wanted to do really and how does that differ from what really happened? I can tell you I can supply a script to install any kernel version you like by compiling your own even including modification of kernel defaults using the bash script called SAKC, but it does not sound like whet you did is giving you want you wanted.

Thank You,

3

Hi, thanks for your reply. I don’t think I’m confused. Perhaps I didn’t explain clearly enough.

I had found two ways to set the multiversion parameter: the way commented in the zypp.conf file (which is what I did) and the way described at openSUSE Lizards

I didn’t find your “accepted” way. Is there other useful information wherever that is documented?

**2. Install the most recent Kernel from Kernel/Head

**The accepted way to do this for openSUSE 11.2 is to add the following repository in YaST / Software / Software Repositories:

Index of /repositories/Kernel:/HEAD/openSUSE_11.2

Now, this will make available to you the most recent stable kernel 2.6.37, which is WAY ABOVE the kernel version 2.6.31 that came with openSUSE 11.2. So the question is, what was it you were trying to do?

Well, as I said, I’m trying to install a recent kernel and as you say 2.6.37 is the most recent stable kernel. So as I said, I added that repository.

Since (a) I don’t want to find myself with an unbootable machine and (b) I said I want to compile multiple variations of that kernel, I also want multiversion.

So, what was it you wanted to do really and how does that differ from what really happened?

What I wanted to do is what I said I wanted to do. How it differs is that YaST installed dependent packages such as kernel-docs and kernel-source from a completely different version to the only kernel that is installed. I consider that YaST is broken in that regard for the two reasons that I gave. I think it should either have installed the packages corresponding to the installed kernel or given me a conflict resolution dialog or an error dialog.

I expect I can get to where I want by manually selecting the .31 dependent packages and the .37 kernel-desktop package (checking carefully to catch every affected package).

I can tell you I can supply a script to install any kernel version you like by compiling your own even including modification of kernel defaults using the bash script called SAKC

I think I can install any vanilla kernel by downloading from kernel.org and compiling but I wanted to do a quick functional check with the precompiled HEAD kernel first and then test the compilation system by recompiling it.

4

Humm, well I don’t think YaST is broken, but perhaps a misunderstanding of what it will do with your settings. If you added the multiversion option:

multiversion = provides:multiversion(kernel)

which was an example and commented out, every kernel file will contain multiple versions.

If you used my suggested entry:

multiversion = kernel-desktop

Only the kernel for kernel-desktop will have multiple versions and since most people use this version, since they are not using a server, this only loads the files you really use for a standard desktop. On my computer, using the first entry would duplicate seven different kernel versions while using my original suggestion will only duplicate one kernel version, the one you most often use. I am not sure about these being in a manual, but using the latter option has been recommended in the forum before by very knowledgeable openSUSE users.

With your multiple version for all kernel active, you can uncheck kernel versions you do not want to keep, always leaving at least one, for the most recent 2.6.31 kernel you have installed. An installed kernel that you uncheck will be removed. When updating to 2.6.37 though, you need to keep both source files on board. Again, while perhaps a surprise to you, since you had not been using the mutiversion configuration before, what you describe is normal operation of which I have observed before.

Thank You,

5

jdmcdaniel3 wrote:
> Humm, well I don’t think YaST is broken, but perhaps a
> misunderstanding of what it will do with your settings. If you added
> the multiversion option:
>
> multiversion = provides:multiversion(kernel)
>
> which was an example and commented out, every kernel file will
> contain multiple versions.

I think we’re still talking at cross purposes. I take it here that you
mean that YaST will provide check boxes for each available version of
each kernel package. Whether or not I choose to install them is up to
me. Presumably the developer/maintainer thought that was a reasonable
example to use.

> If you used my suggested entry:
>
> multiversion = kernel-desktop
>
> Only the kernel for kernel-desktop will have multiple versions and
> since most people use this version, since they are not using a
> server, this only loads the files you really use for a standard
> desktop. On my computer, using the first entry would duplicate seven
> different kernel versions while using my original suggestion will
> only duplicate one kernel version, the one you most often use.

AFAICT, whichever entry is used, nothing is duplicated. Specific
versions of packages are only installed when they are selected. Filling
one check box installs one version of one package (plus any
dependencies). That was certainly my experience.

The issue that I believe to be a usability bug is that when, for
example, the kernel-source package was chosen by clicking on the list of
packages in the upper right of the YaST Qt window, YaST chose to install
the kernel-source package from the “Kernel:/HEAD/11.2” repository when
no other package on the machine was installed from that repository and
in particular the running kernel was not (it was from the Updates
repository).

That leads to a situation where the single copy of kernel source does
not match the only kernel installed on the machine; a situation that is
prone to subsequent mistakes.

Consequently, YaST would be more usable IMHO if it either:

(1) chose to resolve the repository for the kernel-source as the same
repository as the kernel (which is my understanding of existing policy), or

(2) presented a conflict resolution dialog so the user could make an
explicit choice to resolve the ambiguity, or

(3) presented an error dialog that forced the user to backtrack and
manually choose from the list of versions

Obviously, if the package is initially chosen instead from the list of
versions in the lower right of the window, there is no ambiguity or problem]

> I am not sure about these being in a manual, but using the latter
> option has been recommended in the forum before by very knowledgeable
> openSUSE users.

I’m not a regular forum user and don’t believe it is the right place for
documentation. Official docs or the wiki seem a more natural place. And
google turned up other recommendations, not this forum one.

> With your multiple version for all kernel active, you can uncheck
> kernel versions you do not want to keep, always leaving at least one,
> for the most recent 2.6.31 kernel you have installed. An installed
> kernel that you uncheck will be removed. When updating to 2.6.37
> though, you need to keep both source files on board.

Yes, that is how I expect it to work.

> Again, while perhaps a surprise to you, since you had not been using
> the mutiversion configuration before, what you describe is normal
> operation of which I have observed before.

It may well be the existing behaviour but I continue to think that it is
counterintuitive and could be improved as I suggest. In particular, it
appears to violate the repository-crossing rules that were introduced.

Cheers, Dave

PS Checking both the .31 and .37 versions of all the kernel packages I
am interested in did get me to a useful state where I am able to boot
either kernel. So I’m able to get on with my task.

6

PS Checking both the .31 and .37 versions of all the kernel packages I
am interested in did get me to a useful state where I am able to boot
either kernel. So I’m able to get on with my task.
Well at least you are in a running state and I am not sure we could ask for anything else. If you think that something is not working properly, you could report an issue using openFATE here:

https://features.opensuse.org/

Thank You,

7

The same one I use (but on 11.3).

That’s the way it seems to be working here.

I understand and agree that the outcomes of your example are wholly undesirable. However I haven’t experienced your problem (on 11.3), probably since I always update the currently installed kernel packages by manual selection of radio buttons under YaST’s Version tab. So I do select in the upper right pane, and that’s ok. Am I correct in assuming you used a hypothetical example?

Your original problem resulted from:

(3) use YaST software management to select the kernel development pattern

Again I don’t use any “pattern” for kernel upgrades, so I haven’t seen the problem, although it wouldn’t surprise me. Assuming that before upgrading via the pattern, kernel-source wasn’t installed, I don’t see why it should then do so without providing interaction with the user, and IIRC kernel-source is never installed by default. It looks like a bug to me.

It might be interesting to see if using zypper commands to install the “pattern” produced the same result (or not), using the same repo configuration.

8

consused wrote:
> I understand and agree that the outcomes of your example are wholly
> undesirable. However I haven’t experienced your problem (on 11.3),
> probably since I always update the currently installed kernel
> packages by manual selection of radio buttons under YaST’s Version
> tab. So I do select in the upper right pane, and that’s ok.

I’m confused by that. The only Versions tab I see is on the pane that is
in the lower right of the window. This is 11.2 Qt interface. To
install/upgrade something I can either click on an explicit version in
that Versions tab or I can click on the multivalue check box in the top
pane (Keep/Install/Delete/Upgrade etc) in which case YaST decides what
version to use.

> Am I correct in assuming you used a hypothetical example?

No, it’s real life. I’m just reporting what I did when trying to set
myself up to be able to compile a recent kernel.

> Your original problem resulted from:
>> (3) use YaST software management to select the kernel development
>> pattern
> Again I don’t use any “pattern” for kernel upgrades, so I haven’t
> seen the problem, although it wouldn’t surprise me. Assuming that
> before upgrading via the pattern, kernel-source wasn’t installed, I
> don’t see why it should then do so without providing interaction with
> the user, and IIRC kernel-source is never installed by default. It
> looks like a bug to me.

Your assumption is correct.

> It might be interesting to see if using zypper commands to install
> the “pattern” produced the same result (or not), using the same repo
> configuration.

Yes, I might try that but my focus is to get the kernel compilation(s)
done as I’m trying to chase down a hardware issue.

Cheers, Dave