Problem Connecting to Fog With Atom Board
First I have to say I Love Fog and the abilities that it has outweight the things you cannot do with it that other softwares can.
I am trying to hook a Atom D945G board with a realtek Network card. When it goes to try to connect to the server it comes up with :
PXE-T01: File not found
PXE-E3B: TFTP Error - File Not Found
PXE-M0F: Exiting PXE ROM.
So then the system continues to boot into windows. I know that someone had to run into this and hoping there is a simple fix for this error.
Please if anyone can help I would appreciate it. We are fighting a virus a small one but still a pain in the but and these machines use a software in our kindergarten and the server is rebuilt and new but the machines are infected. So to save time we were going to image them until we came up with this error.
I hope someone can give some advice on this and can help with a easy fix. Thanks to all for the great software and site.
OK got it. Will give it a try today or tomorrow and see what happens. Need to do some scanning on some systems for this damn bug. Thanks for the help. I’ll be back…
Negative, DNSMasq is a service you install on your FOG server.
And the DNSmasq is in Novell, correct?
Alright, in that case the issue is specific to your new machines, or their hardware. I would install the DNSmasq service and give it a go. Since the TFTP service is currently working we can rule it out as a possibility that is did not get started.
Something to note: In my Novell environment we are using IP helper addresses to get the information where i needs to be, unfortunately I can NOT shed light on this as I am still new to the corporation and I don’t fully understand any of it, or where I would edit those settings.
When I started working with FOG I had very little knowledge of the infrastructure we used. I set up the “Next-Server” option the “boot file” option and installed DNSmasq. I spoke with one of my other colleagues to update the “ip helper”
And yes I did not only boot the machine with the problems with a different cable, I also boot the machine right next to it that I just created a image on yesterday with the cable from the machine with the Realtek card and it worked fine got me to the FOG menu without a hitch.
OK, ran it and this is what I got
Transfer Succesful 16967 bytes in 1 second 16967 byte/s
Sound about right?
FIRST… I would see if the tftp service is working… From a windows box open a command prompt and issue the following command
[code] tftp x.x.x.x get pxelinux.0 [/code] I would do it form a machine that was able to image before.
What was the output?
Earlier chad asked you to boot a machine known to work with FOG, instead you used the cable. I want to make sure the service is running on the server for the machines to talk to. You can run the command, or pxe boot an old machine known to work.
Use the DNSmasq service for your server, not a proxy dhcp.
DNSMasq IS the proxyDHCP this way and ti will ONLY be used during pxe.
I even went to go check on INTEL’s site for a new BIOS and there was one and it mentioned the card, but I installed it and still the same error.
Nope no proxy DNS that I can see. Should I set that up for the Realtek nics?
I don’t believe I do have that setup, but I will check it out. Give me a few and I will check the ProxyDHCP. Also yes that is the switch address. It is hard set just like the servers. Our range is a large one. When we set it up we made it for expansion. The DHCP is set to
We are running in the 172.16 range so we should be ok.
I will be back have to log out and log into the DHCP server and see what I have.
[quote=“chad-bisd, post: 21390, member: 18”]Are you running proxy DHCP server on the novell system? I remember our old Novell Configuration Management server had a proxy process that helped machines connect with PXE. I had to modify our FOG setup to use ProxyDHCP so that come clients would pxe-boot because they failed to download the initial file over TFTP (bad chunk error). Some of the systems are running realtek nics, the others are using ASIX usb-to-ethernet adapters.[/quote]
I second the notion for ProxyDHCP I run an old Novell Environment and it was the only way to get my pxeboot file to it’s destination. Everything we have is Realtek NIC.
Are you running proxy DHCP server on the novell system? I remember our old Novell Configuration Management server had a proxy process that helped machines connect with PXE. I had to modify our FOG setup to use ProxyDHCP so that come clients would pxe-boot because they failed to download the initial file over TFTP (bad chunk error). Some of the systems are running realtek nics, the others are using ASIX usb-to-ethernet adapters.
So is 172.16.41.180 the Switch address, or the DHCP’d address (is this within range of your network?)
Nope made sure of that when I set it up. Our DHCP server is a older Novell 6.5 SP8 box and it is the only one in the district. I will check though in the meantime to make sure no one set one up I do not know about.
Is your FOG Server setup as a DHCP Server?
Nope our DHCP server is set to dole out the IP address and once that system has it, that is basicaly it the lease doesn’t expire. As for having it hard set to the MAC which I believe is what you are talking about when you say DHCP reservations, no we do not. Just our servers are set that way. They are reserved to the MAC of the machine.
Do you guys have DHCP-Reservations? Is this/these box(es) not on DHCP Reservation and getting a totally redirected DHCP Server?
OK I did it and it still did the same thing with a cable I know works because I have been using it to create new images for a few systems.
When it comes up it shows the IP of the GATEWAY and the odd part is one is of a HP Switch we have in our system that is 172.16.41.180 and then our regular GATEWAY posted after it 172.16.1.1.
Shouldn’t there only be one? Anyway why would it work on the other systems but not this one. It does work on a INTEL DG33BU board and the other was a DQ45CB Board.
This help any?
OK give me a few and I will test it. I know it is working with the systems I had there and imaged before but who knows maybe the cable went south the last time I used it.