Bug 19609

Summary:	Installer choosing server kernel when ECC memory is present
Product:	Mageia	Reporter:	Thomas Andrews <andrewsfarm>
Component:	Installer	Assignee:	Mageia tools maintainers <mageiatools>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	Normal	CC:	marja11, thierry.vignaud
Version:	5	Keywords:	NEEDINFO
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:		CVE:
Status comment:
Attachments:	output from dmesg output from dmidecode output from lspcidrake -v

Description Thomas Andrews 2016-10-17 16:46:50 CEST

Description of problem:

When installing from the classical installer media, the server kernel is selected when the motherboard has a maximum of only 2GB of RAM. Hardware is a Fujitsu D1711 motherboard(manufactured by Asus), Sempron 3100+ 64-bit capable processor, 2GB DDR2 RAM, Geforce 6200OC AGP video card.

I filed this bug against Mageia 5, but it has been true of this motherboard/processor since I bought it and installed Mandriva 2010. At first with Mandriva I changed to the desktop kernel, but after using the server kernel I couldn't perceive any difference in performance, so when I switched to Mageia I just left it as the installer put it. I have never had any problems with it. When I upgraded to newer hardware about a year ago I passed this hardware to my brother as an upgrade for his system, and he has had no problems with the server kernel, either. (He did have some problems with his system, but they disappeared after replacing the main power supply with a larger one.)

I talked about this at a recent QA meeting, and was asked to file a bug on it. So, here it is. Will be adding dmesg, dmidecode, and lscpidrake information.

Comment 1 Thomas Andrews 2016-10-17 16:47:56 CEST

Created attachment 8555 [details]
output from dmesg

Comment 2 Thomas Andrews 2016-10-17 16:48:38 CEST

Created attachment 8556 [details]
output from dmidecode

Comment 3 Thomas Andrews 2016-10-17 16:50:26 CEST

Created attachment 8557 [details]
output from lspcidrake -v

Comment 4 Thomas Andrews 2016-10-17 17:14:29 CEST

I don't see how this could be relevant, but just in case it is, the motherboard/processor combo was originally purchased used on eBay from a recycler. The RAM was purchased soon after from Newegg.

Marja Van Waes 2016-10-18 09:34:22 CEST

CC: (none) => marja11
Assignee: bugsquad => mageiatools

Comment 5 Marja Van Waes 2016-10-18 09:38:02 CEST

Hi Thomas,

I don't see report.bug(.xz)

Please attach it :-)

See https://wiki.mageia.org/en/Triage_guide#Traditional_installer

Btw, I assume this was with a pre-Mageia5.1 QA iso, correct?
Does it happen with 6sta1 (or the old pre-6RC), too?

Cheers,
Marja

Keywords: (none) => NEEDINFO

Comment 6 Thierry Vignaud 2016-10-18 11:27:52 CEST

No we choose the server flavor as your machine is using ECC memory:
http://gitweb.mageia.org/software/drakx/tree/perl-install/detect_devices.pm#n1406

Status: NEW => RESOLVED
CC: (none) => thierry.vignaud
Resolution: (none) => WONTFIX

Comment 7 David Walser 2016-10-18 12:40:41 CEST

(In reply to Thierry Vignaud from comment #6)
> No we choose the server flavor as your machine is using ECC memory:
> http://gitweb.mageia.org/software/drakx/tree/perl-install/detect_devices.
> pm#n1406

Is that because there's something special about the server kernel with regards to ECC memory, or just because we are taking that as a likely indication of it being a server?  Is it just ECC RAM in a motherboard that can't take advantage of it, or does his also have that capability?

Comment 8 Thierry Vignaud 2016-10-18 12:58:12 CEST

It's because ECC memory is expensive and thus most often found in servers.

As the chassis fields in the DMI table cannot always be trusted, we historically check for several hints:
- chassis type if filled,
- memory type,
- some storage controller models,
- having a server CPU,
- ...

Samuel Verschelde 2016-10-18 13:08:48 CEST

Summary: Installer choosing server kernel when only 2GB RAM present => Installer choosing server kernel when ECC memory is present

Comment 9 Thomas Andrews 2016-10-18 15:18:08 CEST

(In reply to Thierry Vignaud from comment #6)
> No we choose the server flavor as your machine is using ECC memory:
> http://gitweb.mageia.org/software/drakx/tree/perl-install/detect_devices.
> pm#n1406

That's odd. The downloaded motherboard manual specifically states "2 x 184-pin DDR DIMM sockets for up to 2 GB unbuffered non-ECC PC3200/PC2700 DDR SDRAM memory" and as I recall that's what I supposedly bought. I see that the files I provided disagree with that, and I don't know what to say about it. I'd have to open it up to confirm with part numbers, I suppose, but I'm not prepared to do that with a machine that's working.

This is an Asus motherboard that was modified for Fujitsu. The original motherboard could use ECC memory, according to the manual for it, but this modified one, no.

Comment 10 Thomas Andrews 2016-10-18 15:24:33 CEST

(In reply to Marja van Waes from comment #5)
> Hi Thomas,
> 
> I don't see report.bug(.xz)
> 
> Please attach it :-)
> 
> See https://wiki.mageia.org/en/Triage_guide#Traditional_installer
> 
> Btw, I assume this was with a pre-Mageia5.1 QA iso, correct?
> Does it happen with 6sta1 (or the old pre-6RC), too?
> 
> Cheers,
> Marja

Yes, this was with an old Mageia 5 Official iso. And also with every Mageia classical release that there has been, as well as with a couple of Mandriva official releases. I have not tried Mageia 6 on this machine yet, as it is my brother's and I don't want to disrupt his usage. He is not particularly computer-savvy, and would not deal with it well. However, from the other comments I have no reason to believe Mageia 6 would be any different.

Comment 11 Thierry Vignaud 2016-10-18 15:58:14 CEST

Sadly, as I said, tables filled by firmwares/vendors are often buggy (ACPI, DMI, screen info, keyboard language, ...)

Comment 12 Thomas Andrews 2016-10-18 16:52:06 CEST

I came to the same conclusion after some research. I found the Newegg receipt in my Thunderbird archives, and confirmed online in several places that the PNY memory I bought is indeed non-ECC memory. So, it must be a glitch in the BIOS firmware.

Since it's working, I'm not going to "fix" it, either.

Comment 13 Thierry Vignaud 2016-10-18 20:39:07 CEST

If you wan, you can as well:
- run "urpmi kernel-desktop-latest"
  (or install "kernel-desktop-latest" from the GUI)
- reboot to the desktop kernel
- remove all server kernels