@TThax You don’t need to actually download the client. The latest kernel, init, and client gets downloaded automatically when you run the fog installer. You just need to update to the latest FOG release candidate, run that installer, and you should be good to go.

@Sebastian-Roth I agree, after looking at a dhcp booting process all weekend I can read the pcap like code from the matrix.

The requesting system is in BIOS mode so undionly is the proper boot kernel for it. I see the target requested the file size for undionly.0 from the tftp server at 192.168.1.133 with no second response from the fog server or no request for undionly.0 to be downloaded from the tftp server. This tells me the tftp server responded with “file not found” for undionly.0.

Well then… those things happen. Marking it solved. Feel free to ask more questions if it starts happening again.

@Sebastian-Roth I have a feeling the “looping” without reboot actually “was looping with reboot” it was just a matter of “timing” between when it restarted due to failure and starting gathering the data itself.

This particularly so considering nothing in the init’s changed in the time the issue occurred and when the updates happened.

Thank you horse’s mouth!

So what should you do first. I assume today you have the proper line in your current PXE boot menu to forward the client to the FOG server, Right??

Take a test computer and collect its mac address, then get with your networking or admin group and have them insert the line from your current pxe menu into a text file and title that file the mac address of your target computer. I think you create the file name without any punctuation. So the file name should be like: 0018DC234567 Then pxe boot the target computer and see what happens.

Actually read over this page it does a lot better explaining of syslinux pxe booting than I can: http://www.syslinux.org/wiki/index.php?title=PXELINUX Plus I had the search order backwards (go figure)

Everything here works now though - including EXIT where I need it. Thanks again.

-Dustin

@Tom-Elliott from the logs: 10/7/2016 10:32 AM PowerManagement On demand shutdown requested. An on-demand shutdown is always queued and not being cleared. We need a clear on-demand tasks button.

@Tom-Elliott said in FOG Client Power Management issues:

Also, you must know that having the client on the same system within multiple boot layout can cause the invalid security token also.

Not can, will.

I have a box in the basement that I have two images for, that I go back and forth between as I need. One is Server 2012 R2, the other is Win10. Of course I have the fog client installed on both images. Every single time I swap to the other image, authentication for the client breaks, and I have to clear the encryption for that host. It’s because there are two OSs reporting in as the same machine. Of course this would cause authentication issues, I would expect it to.

But for me, I understand, and clicking a “clear encryption” button isn’t a big deal to do when I decide to swap to another OS every few weeks for my testing purposes.

@Joe-Schmitt Ok that’s great !
Tested on 40 pc, it resolves my problem, thanks 😉

I had to table these efforts, as I have been unable to successfully clone and deploy an extended linux image without having the swap drive hiccup during the cloning/imaging process. I will return to this as soon as time permits, but I have a few tentative workarounds for this milestone.

-Dustin

@pencils I think we need a lot more information to be able to help you. Please start by explaining in more detail what you are trying to do and what you think might or might not work…

@Tom-Elliott said in Fog Full registration Don't Work:

ou will likely need to remove th

I delete the entry purpose the problem was always the same. I supose it was a problem of the RC9. With the RC11 when complete inventory, if I validates restore immediately, no task is created. Yet if back in the fog menu once the item is inventoried, I created the task from the pxe menu.

@wanderbread ok… so Ubuntu 12 isn’t recommended for the new fog 1.3.0 release candidate, and upgrading Ubuntu has always ended in fog disaster. And your current installation is messed up and on a very old OS, and running a fairly old version if fog.

You need to rebuild.

I’m going to recommend to you that you make a copy of your images to somewhere, they are in /images and then backup your database with thus command and put this somewhere safe too: mysqldump fog > fogdb.sql

And then nuke this server and install something recent like CENTOS 7 or Ubuntu 16, use the same IP, and install fog 1.3.0 release candidate, and after that is done, backup the new database with tge same above command, then import the old database, and move images back over.

The files of /var/www/fog/service/ipxe are in your /var/lib/tftpboot folder and the the /tftpboot folder does not exist.

Try running the FOG installer again and hope it can fix this mess.

@Dave-Wolf If I’m not mistaken, you’re using ubuntu?

If i had to guess, mysql started before networking was ready, so you’re kind of in a “stale” state for the mysql process.

Try simply running:

sudo service mysql stop

It will most likely come back with failure to find running process…

Then run:
sudo service mysql start and all should start working from the MySQL standpoint.

RC11 solve the problem, thank you
You can close this topic

Thx Wayne, your method worked I’m now in RC11

You can close this topic

@Wayne-Workman Indeed - many thanks for your help 🙂

@mrayzies I would suggest becoming standard. You can completely separate out all of fogs pieces as you wish, but storage nodes are best as a full Linux vm and setup with the fog installer.