Install Issue - Supermicro X9SCM & ESXi

[Adam Goldberg]

The bios seems to have strings which tell software what hardware there is. In my case, when I go to install ESXi v6.5, the install fails on some sort of strings hiccup. Anyone ever seen this before?

For 6.5, I select the drive to install on, and then it fails completely with a stack traceback which seems to indicate to me that it had trouble parsing a string that included X9SCL.

For 6.0 (update 2), it had the same first symptom (see picture), but it was able to install.

Anyone seen this? Any idea how I can get 6.5 to install?

 

[Adam Goldberg]

Something might be screwy on the (apparently) successful 6.0 install. Clearly ESXi isn't reading the manufacturer and model correctly.

(Existing machine on the left -- works fine; new machine on the right, see what I mean?)

 

[Adam Goldberg]

I also get this trying to use vCenter converter:

A general system error occurred: Error returned by expat parser: not well-formed (invalid token) while parsing serialized value of type string at line 7, column 201 while parsing property "model" of static type string while parsing serialized DataObject of type vim.host.Summary.HardwareSummary at line 7, column 109 while parsing property "hardware" of static type HostHardwareSummary while parsing serialized DataObject of type vim.host.Summary error parsing Any with xsiType HostListSummary at line 7, column 33 while parsing return value of type vim.host.Summary, version vim.version.version10 at line 7, column 0 while parsing SOAP body at line 6, column 0 while parsing SOAP envelope at line 2, column 0 while parsing HTTP response for method GetSummary on object of type vim.HostSystem at line 1, column 0​

 

[Rand__]

Have you done CMOS reset/Bios/IPMI flash ?
One of these enables you to set manufacturer & similar settings.
Easiest would be to contact SM support on how to fix that if you can't find it

 

[Adam Goldberg]

Have you done CMOS reset/Bios/IPMI flash ?
One of these enables you to set manufacturer & similar settings.
Easiest would be to contact SM support on how to fix that if you can't find it

Yes, I've done a CMOS reset, updated the BIOS, and reset the IPMI (ipmitool -fde).

The problem seems to be corrupted DMI information. It's a complete mess. I have a DMI tool, but it fails/aborts often. Some of the DMI information is correct, but the Supermicro-configured info seems to be crap.

I'm going to contact SM, but ... sigh. I hope that they have a file to send me something like "dmitool -eraseAndRewrite factorydefault.txt".

 

[Rand__]

I'd think so - they sent me a tool to reprogram my nic's mac addresses which I'd call same level patch up

 

[Adam Goldberg]

I sure hope so. Any idea how responsive to email they are?

By the way, this is a pretty close description of what my issue with ESXi is -- ESXi reads a nonsense Product Name (and model name).

 

[Rand__]

Well I only contact the Europe support, they usually respond within a business day.

 

[Adam Goldberg]

I was able (I think) to get around the ESXi problem by editing the DMI using SMBCFG.EXE ... other tools hiccuped too badly on the corrupted fields.

 

[farhan741]

You must easily install esxi 6.5.0 on this server confrigration

Intel(R) Xeon(R) CPU D-1567 9 2.10Ghz
128 GiB Memory

 

[Adam Goldberg]

You must easily install esxi 6.5.0 on this server confrigration

Intel(R) Xeon(R) CPU D-1567 9 2.10Ghz
128 GiB Memory

Must I?

I'm not sure what you're saying. Yes, ESXi should install on this system. It didn't/wouldn't. I speculated as to why, and with some prodding, was able to fix my hardware so I could get it to install.

In follow-up to the earlier conversation, SuperMicro was responsive ... but at the end of they day, neither SM /not/ AMI was able to provide a tool to fix my problem. (Well, AMI suggested a $6500 tool, I don't think that counts.)

 

[Rand__]

And they didnt offer replacement?

 

[Adam Goldberg]

And they didnt offer replacement?

Nope. Let me ping them again.

 

[Rand__]

Well you'll need to do that via your vendor o/c but if they say thats a replacement reason ...

 

[Adam Goldberg]

Nope. Let me ping them again.

Well, I had a pleasant conversation with AMI. Their solution was $1,500 professional services contract, where I'd be able to send them up to 5 boards and they'd fix them. (This is better than the $7,500 previous idea.) AMI sales guy agreed with me that it doesn't make sense to spend $1500 to repair a board that can be replaced for $100.

I'm trying again with SM, but I'm not hopeful. Apparently DMI is something which shouldn't ever get messed with, it's "saved deep in the bios", and ... who knows how it got corrupted.

 

[Adam Goldberg]

Well you'll need to do that via your vendor o/c but if they say thats a replacement reason ...

There's no vendor. I bought these second-hand. No idea who broke'em.

 

[Rand__]

ah darn, that means no SM replacement
(unless you find a vendor who sends in boards which they didn't sell, which most won't, but it's not a SM limitation to have the board sent in by the actual sales vendor)

 

[sfbayzfs]

This is caused by an improper upgrade of the BIOS from 1.x to 2.x for any X9SCL or X9SCM board - you are supposed to run AMI_1 first, and it will change the DMI data structures to be compatible with the 2.x BIOS, then reboot and run AMI_2 (those names might not be exactly correct)

If you just run the step 2 bios update batch file, it will happily update the BIOS, but your DMI info will be messed up, and once the BIOS is updated to 2.x, the first step thing which was supposed to convert the data structures refuses to run.

It seems that ESX is the only thing that cares about this - I didn't realize that a spare board I had sold someone locally had been upgraded incorrectly (I think before I got it) and he eventually fixed it with a tool to manipulate the DMI strings, which I believe came from Supermicro or AMI - it was some sort of DOS menu system for viewing pages of info, and I believe command line invocation to set strings. I don't know how he did it, but he managed to get it changed enough for ESX to like the board.

 

[Adam Goldberg]

This is caused by an improper upgrade of the BIOS from 1.x to 2.x for any X9SCL or X9SCM board
...
... he eventually fixed it with a tool to manipulate the DMI strings

Ah, thanks. That may be the root cause of this mess.

I fixed it the same way -- a utility to manually fix it enough to get ESXi happy enough. Thanks.