Tutorial on switching or updating kernels using fog .32
-
Hello,
Fog .32 has faithfully worked for my now-ex-IT admin who has left for greener pastures. In the few months before his departure I have gotten used to the easiest part of using fog which was simply deploying the images to our three different models of PCs we use across the campus (Dell Optiplex 990s, Dell 9010 All-in-Ones, and Delll 790s.
The issues we are now coming across however is that my boss has given me new Dell this time the model is the Dell Optiplex 9020.
The issues, it seems is that upon trying to deploy our current image to the new model is giving us this current screen:
[ATTACH=full]1842[/ATTACH]Obviously this is the result of driver issues that our old and current version of Fog (.32) is not used to.
After reading up as much as I can on this forum regarding the 9020s, I believe I understand the issue to be that our current kernel set used in in our Fog server needs to be updated. I I did just that. Downloaded what I believe to be the latest kernel for fog and tried to run deployment again, but to no avail, we still get the same issue. I downloaded the kernel “bzimage” thinking it might fix it but I have a sneaking suspicion I need to do more. Perhaps some additional configuration and possibly I downloaded the wrong kernel? It appears Fog can image Dell 9020s for other users.
What I need to know is, can someone point me to the wiki page or tutorial that walks one step-by-step in changing the kernels for Fog to be able to work with certain Pcs that are new to it.
Also could I have updated my fog server with the same exact kernel it always had and therefore that was the reason why I got the same crash as before? Which Tom Elliot kernel is best to down load for the Dell 9020?
Thank you.
[url=“/_imported_xf_attachments/1/1842_20150312_135805.jpg?:”]20150312_135805.jpg[/url]
-
I would suggest building a new FOG server, using FOG 1.2.0, or (what you probably need) the latest developmental revision. This will more than likely fix your problem.
You don’t need to dismantle you’re old server - just turn it off while you do this (and forever if it works.)
Go get one each of those three machine models you have, image them, and sit them next to your desk (clean).
Then work on building a new FOG server, get that working, and then upload your three images you have for your three models.
We’re here to help you at every bump and snag - but it should be really straight forward.
See here: [url]http://fogproject.org/wiki/index.php/FOGUserGuide#Installing_FOG[/url]Do you know if you’re current .32 FOG server is using DNSmasq, ProxyDHCP, or is handling DHCP itself? Is it the only FOG server in your organization, or just a node among many?
-
Well thank you so much for answering. I did purposely leave out a little history so as not to cloud the issue. I did install fog 1.2 on another server and to handle dhcp for itself on an isolated network JUST for the Dell 9020s when we first encountered the issue with our main fog .32 server. Now the Fog .32 is set up on our dhcp server with the 66 entry, and so I figured if I use fog 1.2 on isolated network via a switch to client situation, it should be fine. Issues we encountered with 1.2:
- With the Dell 9020, Fog 1.2 just simply would not deploy the image at all after pxe boot.
- I connected one of our Optiplex 790s, one of our older machines that we have successfuklly deployed to using fog .32 to fog 1.2 loaded with our current working image and we got WOL, the image deployed “successfully” (completed deployment with no errors, BUT upon booting the client , I get a “No NTLDR file” error. Maybe an issue with .32-made images vs. 1.2?
-
Yes it is exactly what you described being a ptoblem with images and specifically with 1.2.0. I’ve fixed this problem in the dev version but understand hesitation of going to an “in the works version”. You could try 1.1.2 but I’d highly recommend the development version as there’s many fixes and improvements over the other versions of fog. I’m sure there may be issues but if you tell us what the issue is and potentially what steps are needed for us to replicate the problem I’m generally get quick on getting a fox.
-
For the record,
If it wasn’t for the developmental versions, FOG wouldn’t work in my environment at all.
And, from what I’ve seen, it’s really stable.
Tom primarily focuses on the imaging features in FOG (who would have guessed??) and makes sure that it works for all sorts of hardware. This is understandable, because he is only one man, and fog has a lot of razzle dazzle plugins and other features that aren’t specific to Imaging -> Naming -> Joining to domain
And, of course, all I do with fog is: Image -> Name -> Join to domain… and FOG is really good at that.
