Bug 231153

Created attachment 111215 [details]
yast

Created attachment 111216 [details]
hardware info

Bigsmp kernel doesn't exist for 64-bit (PAE is available only in 32-bit systems), but 64-bit CPU can run 32-bit kernel (the CPU is backward compatible) so the package should be displayed in yast.

kernel-bigsmp is not selected for update/installation in the screenshot. Could you comment that? Attach yast logs, please (see http://en.opensuse.org/Bugs/YaST)

I agree that the 32-bit kernel can run on the 64-bit CPU. But after installing the 64-bit SUSE, changing the kernel to a 32-bit kernel breaks the system. Therefore I do not think a 32-bit kernel should be shown for a 64-bit installation. 

I made the screenshot after deleting the kernel manual. Therefore it is not selected. It was only to show that it is possible to select the kernel.

This evening I will try to redo the update and save the yast log.

Created attachment 111277 [details]
yast2 log

I have found the original log of yast. Please let me know if additional information is needed.

Please, attach the complete logs. The provided file doesn't contain any useful information. (see http://en.opensuse.org/Bugs/YaST)

Created attachment 117260 [details]
yast log

Sorry for not providing the correct information. Attached is the complete yast log.

The reason is that kernel-bigsmp is required by selected nvidia-gfx-kmp-bigsmp.

The strange thing is that nvidia-gfx-kmp-bigsmp-1.0.963
1_2.6.18.2_34-0.1.i586 is selected which of course requires kernel-bigsmp(i386).
(Nvidia package for x86_64 requires kernel-default which exists for x86_64, that's OK.)

The only think which I can find in the log is:

2006-12-26 12:43:54 <1> reken(8916) [qt-pkg] YQPkgObjList.cc(showLicenseAgreement):1115 User confirmed license agreement for nvidia-gfx-kmp-bigsmp


Another suspicious thing is that the log contains many errors:

2006-12-26 13:04:12 <1> reken(8916) [qt-pkg] YQPackageSelector.cc(installSubPkgs):1246 Installing subpackage (null)            

Stefan, what does it mean? When and why it can happen? Can it be related to the bug? Can be the wrong package selected by "update to newer version"? 

Schubi, any idea why was nvidia*.i586 selected?

(In reply to comment #8)
> Another suspicious thing is that the log contains many errors:
> 
> 2006-12-26 13:04:12 <1> reken(8916) [qt-pkg]
> YQPackageSelector.cc(installSubPkgs):1246 Installing subpackage (null)          
> 
> Stefan, what does it mean? When and why it can happen? 
> Can it be related to the bug? 

No.

> Can be the wrong package selected by "update to newer version"? 

No.

Those are the only places where that function is ever called:

void
YQPackageSelector::installDevelPkgs()
{
    installSubPkgs( "-devel" );
}

void
YQPackageSelector::installDebugInfoPkgs()
{
    installSubPkgs( "-debuginfo" );
}


i.e. when you use the "install matching -devel packages" or "install matching -debuginfo packages" menu entries.

This is not even remotely connected with kernel or -kmp packages.

The "Installing subpackage (null)" message is a bug allright, but only a very minor one because y2milestone() and the underlying _doprnt() GLIBC functions catch it: This is an attempt to output an empty QString. I fill fix this (for 10.3, no reason for a 10.2 or SP1 patch).

But the UI does not do anything special with kernel or -kmp packages. They are just ordinary packages for the UI.

Schubi, any idea why was the -kmp package selected?

John, could you describe exact steps to reproduce the problem?

No I do not know the exact steps but maybe I accidentally selected the nvidia-gfx-kmp-bigsmp-1.0.963
1_2.6.18.2_34-0.1.i586 instead of the 64 bit nvida-gfx-kmp. 

But the easy way to reproduce the problem is just selecting the kernel-bigsmp. Yast offers this possibility and issues no warning if selected but it will break the system. In my opinion a 32-bit kernel should not be shown at a 64-bit installation. And, at least, if selected a warning should be issued. 

Ah, I see. This is the same problem as what we had with java-1_5_0-sun-plugin (huge loads of useless bug reports, but the package simply doesn't work on x86_64 as it's an i586-only package).

I agree that YaST should have a feature to hide packages of a different architecture from the user if they won't work. This should be either hardcoded somewhere or be made available via the repository metadata (like a "no-x86_64" flag).

Some packages to start with:

java-1_5_0-sun-plugin
kernel-bigsmp
*-kmp-bigsmp

Btw., YUM already has a similar feature. It's the "exactarchlist" option in /etc/yum.conf. These are packages whose architecture must exactly match the system, and where a "compatible architecture" is not sufficient.

Maybe YaST can implement something similar? It can help preventing broken user installations.

John, could you please provide a testcase:
http://en.opensuse.org/Bugs/YaST#I_want_to_report_a_bug_related_to_package_dependencies_and_libzypp_solver._Which_logs_to_attach.3F

Created attachment 119216 [details]
yast log

Here are the logs of only selecting the nvidia-gfx-kmp-bigsmp

I did first try to select the kernel-bigsmp, but there was a clear warning. With selecting the nvidia there is no warning.

I hope this provide the needed information. I did not run with the options for additional output because those options resulted in a log file of 300Mb.

Sorry, that does not help here.
The generated testcase described in comment #14 would be enough:
"Since OpenSUSE 10.2/SLES10 SP1 you can create additional information by selecting the menue entry Extras/Generate_Dependency_Resolver_Test_Case in the single package selection frame. You will be asked for generating the logfiles which you should add to the bugzilla entry as described"


The directory /var/log/YaST2/solverTestcase would be enough.

Thank you again;-)

Created attachment 119568 [details]
Dependency_Resolver_Test_Case

Sorry for not providing the correct information. I hope this is what your looking for. I first selected the nvidia driver then run the create_dependency_Resolver_Test_Case.

Thanks, now it is clearlier:
On your system installed:
nvidia-gfx-kmp-default(x86_64), kernel-default(x86_64)
You are selecting
U_Tu_[S1:0][package]nvidia-gfx-kmp-bigsmp-1.0.9631_2.6.18.2_34-0.1.i586 
for installation.
The solver adds:
U_Ts_[S6:1][package]kernel-bigsmp-2.6.18.2-34.i586
which is correct.

So you have two kernels with different archtectures but WITH correct modules on your system. This should work. 
Stefan, could you please evaluate why it does not work ?

I wonder how you managed to select a 32bit kmp package with YaST2 ?!? On a 64bit system I can only select 64bit KMP packages. What did you do exactly
to install the nvidia driver on your system?

First a comment on comment #18:
> So you have two kernels with different archtectures but WITH correct modules > on your system. This should work. 
> Stefan, could you please evaluate why it does not work ?
If a 32-bit kernel is loaded with a 32-bit module but evering else is 64-bit how can a system ever work??

To comment #19:
Both the 32-bit nvidia and 32bit kernel are just selectable by Yast. See yast.png in the attachments. I did nothing special. This bug report is about the posibility to select the 32bit kernel and nvidia module without a warning. 

Maybe the 32bit module and kernel are selectable in Yast because there is no 64-bit bigsmp module. But being able to select the 32-bit kernel without a warning is the bug I try to report with this bug report.

> See yast.png in the attachments.
Which attachment?

The first attachment, created at 2006-12-30 00:38 MST, size 91.49 KB

I can't see a nvidia-gfx-kmp package on this screenshot. Anyway, it's a YaST bug to make it selectable with a 64bit kernel having installed.

The nvidia is not in the screenshot because I could not get both the 32-bit kernel and the 32-bit nvidia module in one screen shot. But also the shown 32-bit kernel should also not be selectable.

comment #23. No it is not a YaST bug. You can install two different kernels on an system. kernel-bigsmp-2.6.18.2-34.i586 is also valid cause it runs on a 64 Bit machine. If not, the dependencies of the kernel or nvidia are wrong.

Yes I agree the 32-bit kernel can run at a 64 bit machine, provided that an 32-bit instalation has be done. But is this case an 64-bit instalation has been done. So most other packages are 64 bit. Booting with an 32-bit kernel with all programs 64 bit will not work in my opinion, and did not work in my case. Therefore the 32-bit kernel should NOT be selectable at an 64-bit instalation. 

I cannot reproduce this. I only can select the 64bit packages. Is there at least a possibility to distinguish the 32- and 64-bit nvidia-gfx packages? Or do you see all nvidia-gfx packages as duplicates?

comment #26. Then the i586 kernel should conflict with e.G. aaa_base (x86_64)
Or how should we define a x86_64 system ? There is no defined criterion.
	

Ok. Stefan explained to me that you can select the i586/x86_64 package below
via Details (64bit is the default), so you selected the 32bit version by intention). This again triggered the installation of the 32bit kernel, which had problems with having a 64bit KMP package/kernel module installed. I'm sorry, but when you do such things, you're on your own. Finally closing as INVALID.

Sorry for re-opening the bug, but I really think this should be fixed, maybe in upcoming versions of SUSE.

I did select the 32-bit Nvidia by intention because I was asked (comment #14) to create a test case. When the problem originally occurred I did not selected it intentionally. I did probably select the wrong Nvidia driver and thereby the 32-bit kernel was automatically selected. I did not receive any warning that I was going to install a 32-bit kernel. 

If you select the 32-bit  Nvidia driver there is no description that it is a 32-bit version. This can only been seen in the technical data. The same is true for the bigsmp-kernel. If selected the following information is provided:

“kernel-bigsmp - Kernel with PAE Support

This kernel supports up to 64GB of main memory. It requires Physical Addressing Extensions (PAE), which were introduced with the Pentium Pro processor. “

I have a machine with 4Gb of memory and problems to load the network driver with this amount of memory. Why should I directly understand that selecting this package is 32-bit? In previous versions of SuSE there was a 64-bit big-smp kernel and I did need that kernel for installation of a system with 12Gb of memory.  Therefor I was not surprised to see the big-smp kernel be selected.

After re-booting and seeing some error messages and having a crashed system it took me quit a lot of time to find out I did install a 32-bit kernel.

To summarize: I don't think many users will directly know that those packages break there system. At a 64-bit installation these packages will never work. So hiding these packages or issue a clear waring will make (the new version of) SUSE even more user friendly. This approach was already suggested by Comment #12 From Andreas Hanke. I do not understand way the bug was closed and the suggestion by Andreas was not followed.

John, I tested your scenario on a 64bit machine, and the 64bit package was the default package, when selecting any nvidia-gfx-kmp-<whatever> package. There's no need to check the technical data as long as you don't want to install the 32bit package on a 64bit machine - as you obviously did.

Anyway, I think it's a good idea to give you a warning when you install a 32bit package (which is also available as 64bit version). Therefore we can
let this open as enhancement.

Again, I did NOT want to select a 32 bit packages. The problem is that there is NO 64-bit bigsmp-kernel so only the 32-bit is shown is yast and this can only be seen in the technical data. In this case your proposal will not work because there is NO 64-bit version available and NO warning will be issued. Please try to select the nvidia-gfx-kmp-bigsmp and see what happens. 

Ok. Now I understand. But I still wonder why you selected the bigsmp-kernel
package, when there is no bigsmp-kernel available on x86_64. If you select manually a kmp package you always need to make sure you select the correct one.

I probably selected wrongly the nvidia-gfx-kmp-bigsmp instead the normal. But at the moment of selection I did not know that it was an 32-bit version and that there was no x86_64. 

The bug report more about if Yast should show packages which only can break the system and is of no use for the installed system. I think it is best not to show those packages so less users mistaces are made and SUSE will be more user friendly. Comment #12 gives a good solution.

>I probably selected wrongly the nvidia-gfx-kmp-bigsmp instead the normal. But
>at the moment of selection I did not know that it was an 32-bit version and
>that there was no x86_64. 
At this moment there's no need to take care about 32/64bit. When you manually select KMP packages make sure to select the one for the correct kernel.

(In reply to comment #12)
> Ah, I see. This is the same problem as what we had with 
> java-1_5_0-sun-plugin
> (huge loads of useless bug reports, but the package simply doesn't work on
> x86_64 as it's an i586-only package).
> 
> I agree that YaST should have a feature to hide packages of a different
> architecture from the user if they won't work. This should be either 
> hardcoded somewhere or be made available via the repository metadata (like 
> a "no-x86_64" flag).
> 
> Some packages to start with:
> 
> java-1_5_0-sun-plugin
> kernel-bigsmp
> *-kmp-bigsmp

Should that indeed be necessary and desirable, this has to be done via dependencies. The UI will not hide away packages from the user based on black magic or hardcodes lists.

(In reply to comment #34)
> The bug report more about if Yast should show packages which only can break 
> the system and is of no use for the installed system. I think it is best not 
> to show those packages so less users mistaces are made and SUSE will be more 
> user friendly. Comment #12 gives a good solution.

The single package selection is an expert tool. Its very idea is to let experts tweak the packages they'll get on their system as they see fit.

The package selector UI will not hide away packages that are there. If they are there, they will be displayed, and users can select them.

What would you think of a base tool that hides away objects that somebody considered potentially dangerous? Would you like a /bin/ls that does not display certain files? Or wouldn't you rather suspect this is very much like evil root kit technology?