|
Bugzilla – Full Text Bug Listing |
| Summary: | Installation problems on lex cv860a | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Joop Boonen <joop.boonen> |
| Component: | Installation | Assignee: | Klaus Kämpf <kkaempf> |
| Status: | RESOLVED FIXED | QA Contact: | Klaus Kämpf <kkaempf> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | RC 1 | ||
| Target Milestone: | --- | ||
| Hardware: | 32bit | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
y2logRPM whith errors
hardware info for lex CV860A Yast log after checking for software and dependancies Screendump of when the pervious yastlog was created Yast log during dependency check, a screen dump cant be created, with the warnings about glibc YaST2 logging for klamath Screen shot of klamath |
||
|
Description
Joop Boonen
2005-09-26 19:29:07 UTC
Created attachment 50854 [details]
y2logRPM whith errors
Created attachment 50855 [details]
hardware info for lex CV860A
Thanks for logs. Could you, please, also attach YaST logs if possible? http://www.opensuse.org/Bug_Reporting_FAQ#YaST Michael, there's a lot of failures in y2logRPM, looks strange to me. Take over ;-) If there are dependency errors related to glibc, and they are ignored, and thus glibc is not installed, almost nothing will work. In this case it looks as if every package, whose post install script calls ldconfig, fails. /sbin/ldconfig is provided by glibc. EXTRA_PROV is needed to create the packages metadata file, as it has to include these kind of file dependencies. If the SuSE 10.0 source was built manually, then it probabely broken (maybe due to missing EXTRA_PROV data). In this case YaST would not see, that required /sbin/ldconfig is resolved by glibc. If it's an official source it's probabely something else. If the file dependencies were missing, nobody would have been able to install a SuSE 10.0 RC1. Maybe the complete logs can reveal what went wrong. Created attachment 50973 [details]
Yast log after checking for software and dependancies
Created attachment 50974 [details]
Screendump of when the pervious yastlog was created
Created attachment 50976 [details]
Yast log during dependency check, a screen dump cant be created, with the warnings about glibc
lex CV860 does not support i686 glibc and i586 one was missing on RC1. (In reply to comment #9) > lex CV860 does not support i686 glibc and i586 one was missing on RC1. Will glibc i586 be available in the new release? If so when will it be available? Or how can i solve this myself? Can i build a glibc i586 myself? I presume i also have to add it to a list of available packages, or is placing it in the correct directory enough? Can you solve this problem on the ftp site of opensuse? I don't know if i should start this dicussion in the bug list. But i wonder about something. Why is the the VIA samuel 2 considered a i586 processor. Because it's a PII type processor. cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 399.573 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx pni 3dnow bogomips : 789.50 PII processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 3 model name : Pentium II (Klamath) stepping : 4 cpu MHz : 233.290 cache size : 512 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 pae mce cx8 sep mtrr pge mca cmov mmx bogomips : 465.30 So i'm wondering which options cause it to be a i586 and not a i686? Is a PII also considered a i586 proc? Have the packages been compiled with for instance PIII specific options? By the way the chipset that's used by this processor is a PII-PIII is a socket 370 processor. uname -a Linux worldcitizen 2.6.11.4-21.9-default #1 Fri Aug 19 11:58:59 UTC 2005 i686 i686 i386 GNU/Linux A Klamath is seen as a i686. Where is this based on? I'll attach the logging. Created attachment 51119 [details]
YaST2 logging for klamath
Created attachment 51120 [details]
Screen shot of klamath
cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 3 model name : Pentium II (Klamath) stepping : 4 cpu MHz : 231.857 cache size : 512 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 pae mce cx8 sep mtrr pge mca cmov mmx bogomips : 456.70 Looking at the logs from comment #6, the CPU is recognized as i586. The logs from comment #14 report i686. Lets ask our hwinfo expert ... Well, yast uses 'uname -m' for this, or not? Some cpus are i586 some i686. That's live. As to why that VIA cpu is not i686: IIRC the lack of cmov instructions. Thanks. So indeed the 'Klamath' is i686 since it has cx8 and cmov Thank you very much. Now i know what makes a i586 and what a i686 (cmov for the Samuel). I'm sorry for your time. I couldn't google this. I expected it was a register like that. Will i586 sill be supported in 10.0 =>? Or only i686 =>? If not than i expect there won't be any action. If it will be supported when will it be fixed? 10.0 final? Joop, please read comment #9. Of course i586 is supported. The non-support was a bug on RC1. |