@Obsidian reported that replication worked fine after he setup his remote servers as Storage Nodes, as recommended.

Also, this topic has gone off topic, and has been forked to here:
https://forums.fogproject.org/topic/8747/when-restoring-image-disk-not-found

@Wayne-Workman He already did, it’s how I know it was already pushed and is working.

@george1421 ,
Hi,
with Intel I5/I7 processor the system start correct,
j1900 e3826 reboot (it’s not a fog problem but ACHI driver installed ).

Hye,

I 've update to rc14 and now it’s working.

Thanks

In addition to below, on your FOG server please key in showmount -e 127.0.0.1 that will show what is exported (shared via nfs) on your FOG server.

@smazzola said in I am trying to image a lab of Dell Precision 1700's.:

@sudburr

I created the image in UEFI mode. I had to turn on the Legacy Roms in order to get the device to pxe. However, I never took the device out of UEFI mode. I used the same settings on the machine I brought the image down to.

But, the image was captured in UEFI mode. This hasn’t changed. The destination computers must be configured in exactly the way the source computer was configured - before you changed things around - in order for the image to boot as expected on the destination computers.

Please read through my previous post.

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