@rdaval3 Are you behind a proxy server? Maybe find something useful here: https://forums.fogproject.org/topic/9371/fog-1-3-3-kernel-update-unable-to-contact-server
Best posts made by Sebastian Roth
-
RE: Kernel Update FOG 1.3.4
-
RE: PXE-E53: No Boot File Received
@jamcdonald120 said:
if we assume that the DHCP setting of the router are correct (they worked before) …
I am sure I have heard phrases like this more than a hundred times and it quite often turns out …
Asking the web to see what other things could cause this issue I see that the error message you posted is not quite the same most other people report - which is:
PXE-E53: No boot Filename received
(see the difference between ‘File’ and ‘Filename’?). Your positive test of trying to load the undionly.kpxe (how do you know your server is using this file and not ipxe.kpxe which we also use sometimes?) binary file makes me believe that your TFTP and the files on it are fine. This would emphasize even more that something is wrong with the DHCP! The message essentially says: “I got an answer from a DHCP server but no information on what file to load for PXE booting”.You need to understand that DHCP is always a bit of an issue. This is because even if neither you nor any colleague changed the “original” DHCP server you can still run into problems if someone added another DHCP server answering requests in your network.
Please try this: Make one of your clients ready for turn on and PXE boot. Install and run tcpdump - a tool to capture network traffic - on your FOG server.
sudo -i apt-get install tcpdump tcpdump -w /tmp/dhcp_traffic.pcap port 67 or port 68 or port 69 or port 4111
Leave that command as is and start up the client till you see the error message on screen. Then stop the tcpdump command (Ctrl-c) and upload that packet dump file (/tmp/dhcp_traffic.pcap) from your server to the forum here.
-
RE: PXEboot with Netgear router
@gabbas Something seems to be wrong here with tcpdump on your FOG server. After starting it you should see at least one or two lines of information. Something like this:
fog@fog:~$ sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 [sudo] password for fog: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
The command sits there and waits. Leave it like this and fire up your client till you see the error message on the client. Then stop tcpdump (Ctrl+c) and upload the output.pcap file to the forums.
-
RE: Windows 10 Ent 64bit upload issues
@butch2861 Kernel oops at such an early stage sounds as it could be a hardware issue. Most probably memory? You might want to run memtest for a couple of hours and see if it is all well.
-
RE: Image drop issues after upgrade from 1.3.3 to 1.3.5
@Tim-Reynolds Seems like you have enough free space on the disk. Tom is right, this does not make much sense. Do you see anything in the install error log?
-
RE: PXE boot under Fortigate 40C
@Kpax I don’t know much about the FGT config itself but what jumps at me is that you are trying to use
pxelinux.0
instead ofundionly.kpxe
… Why that? -
RE: Client does not load after install
@captatim Would you mind telling us what the problem was and how you were able to fix it? Other users might find this information very helpful too. Thanks in advance!
-
RE: Could Not Remove Old Partition?
@dustindizzle11 Maybe I am wrong but looking at the script code and comparing those to the messages in your screenshot it seems like you’ve set OS ID for this image to 1 (WinXP) or 2 (Win Vista)… but you are talking about Win7 images…
-
RE: Search failedSyntaxError: Unexpected token < in JSON at position 0
@wanderson Maybe too many clients hitting the apache with requests? Please check your apache access and maybe error log to see what’s going on and how many requests from which hosts are coming in.
-
RE: Imaging Jobs Freezing
@atarone Reading all the things you have already tried I think we need to tackle this from a different angle to get a step forward. So I modified the most current init.xz image to spawn a second virtual terminal. Usually FOS does not spawn a second one because there is no need to. In this case I thought this might be helpful for the first time.
On your test FOG server, download init.xz here and put it in
/var/www/fog/service/ipxe
(move the original out of the way).Then schedule a deploy task for your test client and boot it up. It should boot just as it used to and while FOG sets things up for imaging you should be able to switch between virtual terminal one and two with the well known keys Ctrl+Alt+F2 and Ctrl+Alt+F1… On the second terminal hit ENTER once and you get to a shell. Here you are free to run commands while FOG is doing it’s thing on VT1.
I’d start with getting VT2 ready but then switching back to VT1 and watching partclone. After freezing, are you still able to switch back to VT2? If yes, what do you see when running
dmesg
for example? If you cannot switch back to VT2 then … (I am still thinking about what to do next then!). -
RE: Imaging Jobs Freezing
@atarone said in Imaging Jobs Freezing:
So I updated init.xz with the one created by Sebastian-Roth and now images deploy
This all sounds totally weird! Is this in your small simple test environment? The only thing I did was downloading the most current init.xz and adding this one line to /etc/inititab:
tty2::askfirst:-/bin/bash
From my point of view it’s impossible that this change is actually solving your freezing problem!
but Windows no longer boots after imaging.
Which error do you see? Please post a picture!
It did the capture but returned errors trying to update the database using the username “fog”. I tested that login and it is still the default. What password is it trying to use and could this be the root cause of my deployments freezing?
Check this wiki page about database password. Again I highly doubt that this could cause the freezing!
-
RE: Could not boot:not enough space(http://ipxe.org/31062006)
@stepryan Alright, thanks for reporting pack. Great to hear that this seems fixed with the most current initrd files. I have no idea how those old ones made it onto your server as the installer always downloads the newest ones and would fail if it cannot download those. Anyhow, marking this solved.
-
RE: PXE issuses
In case anyone is running into this same iPXE error again. Please read this thread. Old initrd files (init.gz from October 2014 instead of current init.xz) were in place and caused the problem.
Not sure if this was the case here to but I doubt that ubuntu server was the problem!!
-
RE: W7 Image: Disk read Error after imaging
@george1421 @roger-jsf Hopefully I can give some more answers… I think I was able to replicate the problem and I guess it’s within our magic-calculate-partition-resize-awk-script. I might figure this out in the next hours. Please give me a bit more time.
As well I am still trying to figure out why this issue is not more common but only seems to come up with this particular partition layout.
-
RE: Fog Client 11.12 not renaming computer/joining domain (Could not authenticate)
@gnevills Did you try “Reset encryption data” for this host in the FOG web GUI?
-
RE: W7 Image: Disk read Error after imaging
@roger-jsf Found and fixed the issue together with @Tom-Elliott! For testing you need to get the very latest initrd files. On your FOG server run those commands:
sudo -i cd /var/www/fog/service/ipxe/ mv init.xz init.xz.1.4.2 mv init_32.xz init_32.xz.1.4.2 wget https://fogproject.org/inits/init.xz wget https://fogproject.org/inits/init_32.xz chown fog:www-data init*
Then try deploying your image again.
-
RE: Fog Client 11.12 not renaming computer/joining domain (Could not authenticate)
@gnevills You need single quotes for the mysql update command:
UPDATE hosts SET hostPubKey='', hostSecToken='', hostSecTime='0000-00-00 00:00:00' WHERE hostname like 'myhostname';
If you don’t see the “Reset encryption data” button in the host settings page then neither hostPubKey nor hostSecToken are set in the DB anyway. Still give it a try but I guess we need to dig deeper. I am still looking through the stuff you posted. Maybe I missed some important detail there.
-
RE: Unable to deploy Snapins - Stuck in Que
@tyler2017 Check the
fog.log
on the client and post here. -
RE: No Login History Clients
@UWPVIOLATOR said in No Login History Clients:
Uncaught PDOException: SQLSTATE[HY000]: General error: 144 Table './fog/userTracking' is marked as crashed and last (automatic?) repair failed in ...
This error looks interesting. Never seen this before. Check out this: https://stackoverflow.com/questions/8843776/mysql-table-is-marked-as-crashed-and-last-automatic-repair-failed (good advices on trying to fix this table)