@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.

@Don-Winters Great you have it worked out.

Happy cloning.

@Tom-Elliott said in UEFI won boot tools via fog menu.:

hink

I see!! that’s great to know!!!

@Wayne-Workman Hell, whenever I try to upgrade Ubuntu even Ubuntu gets messed up and I need to spend time to fix it.

Already known about and fixed for RC 12.

@Tom-Elliott All nodes at RC-11, It back to assigning recently used snapin associations from recent image deployments

0_1475507131758_upload-32d5e685-9979-44a5-844e-e07b3c6cd59b

Nothing has changed here. Just going about day-to-day operation. Tried with same host name, and never before used host name, same result.

I update and it worked
0_1475505744994_fog.jpg

@Polii123 That’s what I would suspect, yes.