Bug 326269

we need the yast logs. You installed with online repositories, right? The likely reason: factory has different kmp modules, because it didn't yet sync out.

Created attachment 173254 [details]
yast2 log files

SLED 10 SP1 cpuinfo for same machine
$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 2.00GHz
stepping        : 6
cpu MHz         : 600.000
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2
bogomips        : 1200.35

I did get a warning that there were no installable providers of tpkmp module, so I said not to install the module.

yes I did add the default online repositories.

so the tpctl-kmp-bigsmp-4.17_2.6.22.5_21-126.i586 package got installed, but not the tpctl-kmp for the default kernel.

Conflict seen during installation. Selected do not install tpctl-kmp option in the conflict dialog.

#### YaST2 conflicts list - generated 2007-09-19 05:17:24 ####

No valid solution found with just resolvables of best architecture.
    With this run only resolvables with the best architecture have been regarded.
    Regarding all possible resolvables takes time, but can come to a valid result.
    Conflict Resolution:
        ( ) Make a solver run with ALL possibilities.
tpctl-kmp-default cannot be installed due to missing dependencies
    There are no installable providers of kernel(default:vmlinux) == 15bc5ed895373c98 for tpctl-kmp-default-4.17_2.6.22.5_21-126.i586[http://download.opensuse.org/repositories/openSUSE:10.3/standard/]
    === tpctl-kmp-default-4.17_2.6.22.5_21-126.i586[http://download.opensuse.org/repositories/openSUSE:10.3/standard/] ===
        tpctl-kmp-default-4.17_2.6.22.5_21-126.i586[http://download.opensuse.org/repositories/openSUSE:10.3/standard/] is needed by tpctl-4.17-126.i586[http://download.opensuse.org/repositories/openSUSE:10.3/standard/] (tpctl-kmp)
        kernel-default-2.6.22.5-23.i586[openSUSE-10.3-OSS-Gnome 10.3] is needed by tpctl-kmp-default-4.17_2.6.22.5_21-126.i586[http://download.opensuse.org/repositories/openSUSE:10.3/standard/] (kernel-default == 2.6.22.5-23)
        kernel-default-2.6.22.5-21.i586[http://download.opensuse.org/repositories/openSUSE:10.3/standard/] provides kernel(default:vmlinux) == 15bc5ed895373c98, but another version of that package is already installed.
    (null)
    Conflict Resolution:
        ( ) do not install tpctl-kmp-default
        ( ) Ignore this requirement just here

#### YaST2 conflicts list END ###

Stefan, this is what we were talking about.

Could you please generate a testcase ?
You do not have to finish the installation. Just go to the single-selection an generate a testcase. Then you can cancel the installation.

I created one - having a thinkpad too

Created attachment 173389 [details]
test case

ok, I analyzed the problem. It's a CD only one and only if the CD kernel is different than the one in the FTP repository. This won't be the case for the final 10.3, this is a Factory vs. RC1 issue.

There is a requirement for _any_ tpctl-kmp module from the tpctl utility installed on thinkpads. As the default one does not work (locked by Tim), the next best one is installed - which drags in kernel and kmp from FTP, which are in sync -> not booting kernel.

This problem should be fixed in general or at least Yast needs to create a warning when two kernels are selected

In installation workflow YaST has evaluate all available kernels and selects the best. It should not be a problem to compare the solverresult with this kernel list and report a popup in YaST. 
Klaus, Stano, Jiri, Lukas what do you think ?

Definitely not for 10.3 so I'd rather leave the discussion open before making any decision. Let's talk about the problem in more general way after 10.3 is GM, please.

comment #12: One more reason to treat 'kernel' packages in a special way.

Adding Michael Schröder for further discussion.

Stano, could you or Klaus carry on this discussion. I fear that otherwise nothing happens. :-)

Well, I have several ideas to solve this issue on the YCP level:

- YaST when selecting a kernel sets all the other possible kernels to the "Taboo" state; this should prevent the solver from selecting other kernels; however, when user selects two kernels, I'm afraid that the problem is back

- YaST can (via analyzing the dependencies and provided the kmp packages have consistent names) check which kmp packages are selected only for one kernel and not for the other one which is selected for installation. In case of inconsistencies found, YaST can preselect missing kmp packages.

Stefan, I'm not sure this doesn't confuse the solver even more. What do you think?

you can set the other kernels to taboo, because they really should not be normal solvables. If the user selects two kernels, he hopefully checked both apply to his hardware.

Schubi, *ping*

I would prefer first choice of Jiri's suggestion. We have currently similiar
problems concerning system update. The distupgrade machamism selects one kernel
for update. YaST select an addition kernel. No error will be produced.
This problem would also be solved by the way ;-)

see [Bug 382208] Update wants to install two kernel

Lado, yast2-packager selects the kernel.

Lukas, SelectKernelPackages() in update_proposal.ycp should be also updated to set the other packages to taboo...

There's a problem with tabooing all other kernels (except the proposed one):

The kernels from addon products will be also tabooed (e.g. there is kernel-rt in SLERT). That's wrong.

The same problem is with kernel-xen, it can be installed in parallel to the standard kernel and it is part of the Xen pattern so it should not be tabooed...

Any idea?

(In reply to comment #25 from Ladislav Slezak)
> Lukas, SelectKernelPackages() in update_proposal.ycp should be also updated to
> set the other packages to taboo...

Frankly, I don't think that this function even belongs to update proposal as it is about selecting packages to upgrade/install/taboo... This definitely belongs to packager.

Function SelectKernelPackages() from update_proposal.ycp has been moved to Packages.ycp (module).

yast2-packager-2.17.27
yast2-update-2.17.7

The problem is still not solved and I think that tabooing kernel package is a wrong way, see comment #26.

So it seems that we should use the second solution from comment #19.
Or something else.... Any idea?

With 11.1, both kernels will have their section in the menu (in fact created by the kernel's post-install script), which means that the system will be bootable.

However, this does not say anything about ensuring correct kmp packages are selected.

Sorry, no time to implement this.

(Moreover I'd like not to touch the kernel selection code, it's pretty complicated even without any KMP magic...)