Kernel for Xeon compiled on Core i7?

[LarryTheNoob]

Several months ago, one of our developers managed to pretty much delete most of the system drive on our development server. We have managed to recover from backups (rdiff-backup to other server, most of the important data are on unaffected software RAID volumes) and by chrooting from a "live cd" on a flash drive + some minor recompilation of stuff that didn't work.

I need to reinstall the system with a shortest possible downtime before the flash drive goes south or we suffer an extended power outage. I do have the original kernel config file, but I don't have any spare servers with Xeon CPUs, similar motherboard, etc...

* Can I compile a new kernel (and whole system) with same ".config" file on a desktop PC with Intel Core i7?
* If so, will it work on the Xeon Server? (simply pluging the drive from the desktop into the server)
* If so, does it affect compilation and setup of other packages like apache, nginx, php, MariaDB, etc...

This is a noob question stemming from my lack of understanding of kernel compilation and options. I have looked for the answer, but I might not be asking the right questions. Any advice would be appreciated.
_________________
I studied economy. I don't (really) understand anything. I know dogs smarter than me.

[Jaglover]

Unless you have enabled the experimental feature in kernel config to use -marh=native you can compile the kernel in another box and it will work.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

[LarryTheNoob]

Dear Jaglover, thank you !!!
_________________
I studied economy. I don't (really) understand anything. I know dogs smarter than me.

[NeddySeagoon]

LarryTheNoob,

The whole system is harder.

When you build the kernel for a different CPU, it works because none of that kernel code ever runs on the build host.

When you build other packages for a different system, you might use a chroot. However, when you do that the build host has to be able to execute at least some of the code for the target. Therefore you need to choose CFLAGS etc that will work on both systems.
This usually results in working buf suboptimal code. In your situation thats probably a price you are willing to pay, as it ned only be temporary.

If your Gentoo installs are out of date, there is a whole new world of pain awaiting.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[LarryTheNoob]

NeddySeagoon, thank you for the response,
I probably haven't explained correctly, I understand that I need to compile the kernel, chroot into the new system and compile the packages (as the handbook states). It is good news that I can do so on the Intel Core i7 and it will run on the Xeon.
* according to https://wiki.gentoo.org/wiki/Safe_CFLAGS both of the cpu's are in my case the same cpu architecture (I might have pointed that out sooner, sorry), therefore I can actually even use the "-march=native or specifically -march=sandybridge" switch anyway?
* Is there any chance that I could actually boot up the newly compiled system on the Core i7 to test it out? I am not that concerned about suboptimal code (even though I understand that is not the "gentoo way"), I need to test out dozens of badly/not documented custom fixes and modifications made on the original server over the years that are still important to our developers. BTW: yes - it hasn't been updated for years - I am confident I simply don't have the skills to be able to save the original system.
* If not, how similar would the hardware have to be for me to be able to boot up the newly compiled system? I suspect I would need same CPU Architecture, as for the motherboard - would same chipset work or do I need an identical motherboard? (I see similar hw is pretty much obsolete and quite cheap nowadays. On the other hand at that point I could probably just buy any similar server that will handle same RAID cards and memories (to save at least some money) and start from a clean slate..
* Is there a different approach I could take to test out the newly prepared system before i put the drive (actually 2 drives in software RAID 1) into the Xeon server? Do I make sense at all?
_________________
I studied economy. I don't (really) understand anything. I know dogs smarter than me.

[NeddySeagoon]

LarryTheNoob,

Take care with CFLAGS. Run

[Hu]

If you have a strong need to boot into a subdirectory, you could probably fake it with some clever use of an early userspace and chroot before handing control off to the regular init system. I wouldn't mess with that if avoidable, in part because it moves you away from running the exact same environment in both test and production. You want to minimize variance, especially in a case like this where you cannot quickly revert to a previous known good production environment on the first sign of trouble.

Regarding architecture, I recommend you be conservative for -march. Unless the Xeon system is routinely CPU-bound in its regular duties, you probably care more about Gentoo's flexibility in what to install than you do about building the code for optimal performance. Conservative choices here improve your changes that dissimilar x86 hardware can be used freely.

As far as hardware compatibility, it should be safe to experiment. If the kernel is configured to support exactly the hardware of the old Xeon and no other, you might not be able to bring it up as-is on whatever dissimilar hardware you have at hand. Remember though that the binary distributions (Red Hat, Debian, etc.) ship general purpose kernels that run on a variety of hardware. Your kernel can be built that way, if you know what you need (or can find someone to tell you what you need). When you think you're ready, try slotting the test drive into a spare system and bring it up. The worst case is that it panics on boot if your kernel is not able to operate the test system. Second worst is that it comes up, but is missing some functionality required to bring it up all the way and do your planned validation tests. Either way, I wouldn't expect it to damage your test install, so it shouldn't cost you more than the time required to plug/test it.

[LarryTheNoob]

Dear NeddySeagoon, Hu,
thank you guys for your kind response and explanation.

The "-native" CFLAGS on the Xeon server are

[NeddySeagoon]

LarryTheNoob,

I would go with -march=native, it will be easier to manage later.
If you want to specify --param l2-cache-size=10240 too for targeting the Xeon, its harmless. I doubt that you will notice the difference.