Cant PXE boot to fog server
-
Looks like a problem with the kernel.
Try mine:
[url]https://mastacontrola.com/fogboot/kernel/bzImage32[/url] -
okay thank you would the kernel effect how it boots through a switch and why some devices work and others don’t?
-
No it shouldn’t, but we never know what could be causing an issue. If removing the switch fixes the problem, it would seem likely there was a problem with the switch in the first place.
-
okay im going to try the kernel ill update shortly with the findings thanks guys for all the help so far
-
Okay sorry to ask this but how do i upload that kernel though the web interface, or do i have to do it on the server ?
-
You will need to copy it over to the server and then set that kernel for that one host or all hosts(default kernel).
It goes in the directory /tftpboot/fog/kernel.
-
does the kernel update have to be updated through the server or can it be done through the gui
-
okay thank you
-
through the server for Tom’s custom kernel.
There are lots of defaults that can be done through the GUI but Tom’s requires you to add it without the GUI unless you go to FOG 33b.
-
okay thank you
-
how do i set it for the host or as the default kerenal for all hosts , sorry this is the first time Ive ever done any thing with the kerenals
-
You just copy it to the /tftpboot/fog/kernel/ directory as bzImage
A sample of commands you could perform this with would be:
[code]cd /tftpboot/fog/kernel/
mv bzImage bzImage.orig.2014MAR11
wget --no-check-certificate -O bzImage https://mastacontrola.com/fogboot/kernel/bzImage32
[/code]That should do the trick for you.
-
thank you so much
-
i found this thread while searching for my hardware. I’m not sure if my problem would be fixed by this kernel or not?
I have Lenovo M72z and it PXE boots ok, but if I choose (or it times out on the pxe menu) to the first option: “boot from local disk”… well, it doesn’t happen.
I get a black screen that says “Booting from local disk…” in the upper left corner, then it hangs there forever.
As far as I can tell, everything else seems to be ok. I can upload and deploy images. Sometimes when I multicast, one computer in the group (of five computers) won’t wake (for unknown reasons) and then the multicast will be stuck at “Please Wait” (blue screen) until I go power up the offending hardware. Then it takes off fine.
After I deploy an image, it tries to reboot and I get to the black screen “booting from local disk” hang (as noted above) again. When I hit ESC to skip the pxe menu, I can get in just fine… but then it will reboot once the first time after a deploy after a minute or so… I think this must be a delayed reboot command from FOG left over from the image deploy (because the black screen hang didnt ever complete successfully).
I did the hardware inventory option and I noticed a message fly by about unknown/unrecognized BIOS “please report”. Though I am not sure where to report this?
Here are the results from the hardware inventory of a typical machine:
System Manufacturer
LENOVOSystem Product
3554CTOSystem Version
ThinkCentre M72zSystem Serial Number
PBG8GDGSystem Type
DesktopBIOS Vendor
LENOVOBIOS Version
F6KT32AUSBIOS Date
09/03/2013Motherboard Manufacturer
LENOVOMotherboard Product Name
MAHOBAYMotherboard Version
NOKMotherboard Serial Number
Motherboard Asset Tag
CPU Manufacturer
Intel
CorporationCPU Version
Intel Core
i5-3470S CPU @ 2.90GHzCPU Normal Speed
2900 MHzCPU Max Speed
2900 MHzMemory
3433056 kBHard Disk Model
WDC WD10EZEX-08RKKA0Hard Disk Firmware
80.00A80Hard Disk Serial Number
WD-WCC1S6883074 -
[quote=“mkstreet, post: 27254, member: 24215”]i found this thread while searching for my hardware. I’m not sure if my problem would be fixed by this kernel or not?
I have Lenovo M72z and it PXE boots ok, but if I choose (or it times out on the pxe menu) to the first option: “boot from local disk”… well, it doesn’t happen.
I get a black screen that says “Booting from local disk…” in the upper left corner, then it hangs there forever.[/quote]
Change the exit type within the GUI. There are two types, exit and sanboot. For your setup, try with exit. It’s defaulted to sanboot.
Location is: FOG Configuration->FOG Settings->FOG Boot Settings->FOG_BOOT_EXIT_TYPE
-
[quote=“Tom Elliott, post: 27259, member: 7271”]Change the exit type within the GUI. There are two types, exit and sanboot. For your setup, try with exit. It’s defaulted to sanboot.
Location is: FOG Configuration->FOG Settings->FOG Boot Settings->FOG_BOOT_EXIT_TYPE[/quote]
Hi Tom,
Thanks for the reply. I will try that on Monday. Would this FOG_BOOT_EXIT_TYPE affect all exits to the local disk boot – and not just boots-after-deploy? I have this same get-stuck “Booting from local disk…” when I choose “1” from the PXE menu.
Do I need to be concerned about that message during FOG Hardware Inventory about unknown BIOS ?
Sorry about not including the version info. I’m using… Fog Vers: 0.32 O/S: Ubuntu 12.04.04 LTS (Pangolin)
-
FOG_BOOT_EXIT_TYPE is only relevant for .33+ versions of Fog.
does the computer boot properly when not connected to the network? -
[quote=“mkstreet, post: 27353, member: 24215”]Hi Tom,
Thanks for the reply. I will try that on Monday. Would this FOG_BOOT_EXIT_TYPE affect all exits to the local disk boot – and not just boots-after-deploy? I have this same get-stuck “Booting from local disk…” when I choose “1” from the PXE menu.
Do I need to be concerned about that message during FOG Hardware Inventory about unknown BIOS ?
Sorry about not including the version info. I’m using… Fog Vers: 0.32 O/S: Ubuntu 12.04.04 LTS (Pangolin)[/quote]
As you’re using 0.32. There are two options to fix this issue for you.
First is, if you’re able to, upgrade to 1.x.x FOG. The reason being is related to what I’ll ask you to try secondly. You will have to make a change on the DHCP Option 67 to be looking for file: undionly.kpxe as opposed to pxelinux.0 as was done in the past. 1.x.x does chainloading natively and should help with your issue. With it, you’ll be able to change the exit type of FOG as well, so if one doesn’t work, try the other and you should be good to go.
Second, look up chainloading howto on the wiki. This should help you out if you can’t upgrade.
-
[quote=“Junkhacker, post: 27364, member: 21583”]FOG_BOOT_EXIT_TYPE is only relevant for .33+ versions of Fog.
does the computer boot properly when not connected to the network?[/quote]If its not connected to the network, yes it will boot properly.
It tries the network for about 40 seconds because PXE is our first boot device, then it gives up and goes on normally to the local HDD.
If I press escape, it will exit trying PXE and go on normally as if it had given up on PXE too. -
[quote=“Tom Elliott, post: 27365, member: 7271”]As you’re using 0.32. There are two options to fix this issue for you.
First is, if you’re able to, upgrade to 1.x.x FOG. The reason being is related to what I’ll ask you to try secondly. You will have to make a change on the DHCP Option 67 to be looking for file: undionly.kpxe as opposed to pxelinux.0 as was done in the past. 1.x.x does chainloading natively and should help with your issue. With it, you’ll be able to change the exit type of FOG as well, so if one doesn’t work, try the other and you should be good to go.
Second, look up chainloading howto on the wiki. This should help you out if you can’t upgrade.[/quote]
We’ve been using FOG a grand total of about two weeks.
In the first week, we tried getting 1.0.0 FOG from SVN (this was just prior to 13-May-2014) and installing it (on Ubuntu 14.04). Since we are using static IP in this computer lab, we did try setting up FOG as ProxyDHCP with dnsmasq (btw, those are what the wiki chainloading links redirect to). We had trouble getting any of that to work. Though offhand all the things we encountered are a blur now.
Our solution attempt was to go back to FOG 0.32 and Ubuntu 12.04.04. We did this and upload/deploy started working right away and so easily that our days/hours of earlier effort with 1.0.0 FOG and dnsmasq config seem like wasted hours of head-pounding-wall.
Right now, it’s really only this issue of BOOT LOCAL DISK remaining and this Com Lab goes live in under 24 hours. If changing that FOG_EXIT_BOOT_TYPE is not an option, then I will have to wait until there is time to “play” with this again.
