Hello,

My company is running CentOS 7 on Dell R730 servers, about 600 of them. My company has been tasked with migrating from Dell to HP DL 360 Gen 9s.

The OS iso image I'm using to load onto the HP has all packages and configurations and has always worked on Dells.

The image does not work on the new HPs. Get an "opcode error" and red screen of death.

My question to the group is "What would your strategy be to fix this?" Fix meaning a working os using our image. I'm looking for a way to troubleshoot this, not a solution to the problem.

It may be helpful to note that the image has an install script that runs parted to partition drives. Also, there are no errors on install but get a red screen on first reboot.

Many thanks. Let me know if you have questions, be glad to answer.

Exactly when? What shows up onscreen before the opcode message? IOW, how far along does it proceed before the failure?

Take a photo of the monitor when it stops and post it here.

@mrmazda before opcode, install script runs on new HP server, parted's partitions, gunzips gz files representing /var, /, /boot and so forth to respective partitions. Copies an HP mbr to /dev/sda in lieu of previous Dell mbr. All completes without errors. Reboot is requested. After reboot, red screen. "....how far along does it proceed before the failure?" -- proceeds in a normal fashion without errors, followed by red screen.

@AwesomeMachine, will get screenshot Monday. Generally EAX, EBX, ECX registers reporting contents, would say contents are addresses.

Just a thought...

Do you have the same video, network and RAID hardware on both the Dell and HP? Have they the same firmware on both?

Didn't think so.

I reckon you'll have to build an HP version of Centos 7 to match what's running on the Dells as the difference will be with the hardware. You also need to ensure that the DL360s have all their firmware at current levels before building your HP release and staging.

just my

Play Bonny!

Here is red screen opcodes

EAX 00000300
EBX 00150001
ECX 00000000
EDX 00000080
EBP 00150801
ESI 0000811F
ED1 000081E8
DS 0000
ES 0820
FS 0000
CS:EIP 0080:00000087
SS: ESP 0000:00001FFE
EFLAGS 00003203

opcodes error:

https://plus.google.com/photos/photo...4226?icm=false

Opcode is a machine code instruction by it's value. The red screen dump is the register values at the time of failure. Looks like X86 registers, 64 bit registers at that. The cpu's seem to be both x86_64 and mostly the same specs.

Dell R730
----------
CPU Intel Xeon E5-2630 v4
Number of Cores 10 core / 20 threads
https://ark.intel.com/products/92981...Cache-2_20-GHz
TSX-NI = yes

HP DL 360 Gen 9s
----------
CPU Intel Xeon E5-2670 v3
Number of Cores 12-core / 24 threads
http://ark.intel.com/products/81709/...Cache-2_30-GHz
TSX-NI = no

Seems that the TSX-NI instructions are the main difference, not sure why (or if) redhat optimized to that level, but high end servers which I don't normally deal with. Otherwise x86_64 and mostly the same stuff.

As I said in post #5, it may be due to hardware/firmware issues, it's not just the processors which are different.

Dunno about Dell but HP have a product; hpsum (HP Smart Update Manager) which will check the systems firmware and update it as required(But apparently not the BIOS which is a separate deal). It will cover iLo, RAID cards, nics, HBAs, etc.

Oh! You have to have either a support contract or Warranty to download and use hpsum. If they're new servers, you should be covered.

Play Bonny!

Believe issue is twofold:

1. Have to copy a mbr from a hp server back to my build platform, which is a CentOS7 vm, and include it in the mkhybrid iso build process. Not sure at what point the GPT is updated, but I see it, so that's step 1

2. Have to copy biosboot bootloader from hp server back to my build platform and include in iso build process.

Somehow, hp formats these partitions in an hp propriety format. Originally, they were copied from our old Dells.

This all seems to be moving forward. Will let you know.

BTW, don't believe it's a hardware/cpu issue. Likely opcodes were results -- as you said -- of cpu trying to access bootloader (mbr I'm pretty sure is good, run gdisk and tables for paritions are all there), a bootloader it doesn't recognize.