Kernel for Hyper-V
-
[quote=“kpourmand, post: 33649, member: 172”]Also, I fired up my old FOG box and confirmed it does still work. It does not work with the new kernels under the old FOG box either. I get the same errors.
Is there any way to determine which kernel the bzImage file is on my old FOG install?[/quote]
What version of FOG is installed on your old server? You can always copy the bzImage form that machine and put it on the new FOG server.
-
…why the hell didn’t I think of copying the file?
The new server is the newest version. The old is .33b, iirc.
-
Your new server is out of date already
-
Indeed it is.
-
So, I upgraded and now things still don’t work, but are a bit different.
First, I tried copying the old bzImage file from the old install, but it will not work with the new install (I confirmed it worked on the old install earlier today). It has the error “kernel panic – not syncing, no init found.”
Second, I tried the default kernel from the upgrade. It doesn’t work, but I get a different error than before. It says “BUG: using smp_processor_id() in preemptible [00000000] code:ntfsresize/”
Any thoughts?
-
[quote=“kpourmand, post: 33693, member: 172”]So, I upgraded and now things still don’t work, but are a bit different.
First, I tried copying the old bzImage file from the old install, but it will not work with the new install (I confirmed it worked on the old install earlier today). It has the error “kernel panic – not syncing, no init found.”
Second, I tried the default kernel from the upgrade. It doesn’t work, but I get a different error than before. It says “BUG: using smp_processor_id() in preemptible [00000000] code:ntfsresize/”
Any thoughts?[/quote]
The reason you got kernel panic – not syncing, no init found is because the kernel you installed in place of the original bzImage is 32 bit, where FOG now separates between 64bit and 32bit. The natural bzImage is now a 64bit image and loads with a 64bit init.xz file. If you copied your old kernel, chances are it is 32bit kernel trying to boot a 64bit init which will panic as the init doesn’t exist for that kernel to load. The same works in reverse (meaning 64bit kernel and 32bit init).
I still have a theory as to the “smp_process_id()” error though I can’t do anything until later today.
-
Very interesting. Is there a way to change the init file to 32 bit to match the kernel? How does that work if you download one of the 32 bit kernels available? Or are those only meant for 32 bit servers?
-
The kernels that you use are simple designed to run on the clients. You can run both bit’s on your server as your server is not booting to those kernels, they’re simply for the clients.
You should never need to use a 32 bit kernel in place of a 64 bit kernel. You actually lose support for things jumping down from 64 to 32. That said, if you’re mindset on trying 32 bit only, simply rename the init_32.xz file to init.xz and rename the bzImage32 to bzImage.
-
Gotcha. I would prefer to keep the 64 bit to retain the extra features, but if it turns out that dropping to 32 bit would enable the old bzImage to work with Hyper V, then I’ll take that.
-
Also, am I correct in assuming the 32 bit kernel is required for 32 bit clients? Because I still have a small collection of 32 bit machines.
-
It autodetects
-
Oh wow…that’s pretty cool.
-
Yeah, that’s why I hesitate to have people change the kernel and init file names.
-
I understand. FWIW, switching to the old bzImage and 32bit init file appears to make my Hyper-V server work again. I’m uploading a new image right now.
