@ablohowiak Maybe play with the image settings (e.g. Image Type and Image Manager) might make those images work again. As we don’t know your settings it’s just a wild guess. But if the images worked on your 1.4.4 server they should work on 1.5.4 just as well if you get the image settings right.

@george1421 It worked the policy was disable on each scope and the secure boot on enable, just had to activate the policy and and disable secure boot

@mxc In the second video I don’t see the client PXE booting at all?!? Maybe I get you wrong?

In the first video it looks like a legacy BIOS PXE boot (not UEFI). Try different boot exit style settings for BIOS (and maybe UEFI just in case)…

Please resolved this post. we went virtual machine route to capture image and it worked.

Thank you for support.

@Wayne-Workman the 6 first of the mac are the same and fog could see somes of theese MAC.

i’m still looking for BUT you’re right @Sebastian-Roth , the forticlient have an integrated FW, maybe the problem… today i will look if I can turn off the FW part and you say after

@afaure Please provide more information. On the FOG server run the following commands and post the full output here: df -h, lsblk, showmount -s

@Cire3 said in Can't see Images in menu after manually uploading.:

The compression scale also must match huh ?

Sorry, I didn’t mean the compression scale but the compression format…

Thanks for all the help! things seem to be back in order!

In fact, i must be wrong.
What is the “*” at the end of the name of the server in the “storage node disk usage”.
It is the Master Node or the current server ?

@Sebastian-Roth I think I found it - I had to add the snapin to the group!

@andy-king said in Fedora 21 version 1.2 to 1.5.4 version update fails:

I would like to oput the large image files on an iscsi device do you think that is possible?

Sure, mount that iSCSI device on your FOG server, move the existing directory structure in /images to the mounted iSCSI device (unmount the old disk/partition in case it was seperate), remount the iSCSI under /images and off you go without much headache.

@Sebastian-Roth

FOG Configuration
FOG Version Information
Running Version: 8179

Kernel Versions
DefaultMember
bzImage Version: 4.6.2
bzImage32 Version: 4.6.2

@Raymond-Bell @Tom-Elliott You had me update to the working-1.6 branch and it fixed the issue in that it would go the next node even if it says there is a non-match file on the first node. The issue of it constantly thinking image files (usually the largest .img) don’t match still has not been fixed. I have been too busy with other issues in our school district to continue testing at the moment though and have been manually updating images using rsync if we ever upload a new version, seeing as how it doesn’t seem to delete non-matching files and /or thinks matching files don’t match. I am able to replicate the issue on VM’s at home and with multiple test machines and our servers at work. However until the work orders slow down I am unable to keep digging into the issue and the rsync has been working as a temporary solution.

@Sebastian-Roth I will give the doc a read through, but I believe it was more or less set up by IT. I plugged in my system to the network by ethernet through an VOIP phone, and gave them the system’s MAC address and then they assigned the box an IP. I do not recall messing with settings other than the systems proxy settings when getting on the network.

@jlad00 Have you searched the forum yet. There is a ton of threads about Surface devices having those kind of an issue. I am fairly sure you will find the right threads.

@Sebastian-Roth So after taking your advice on the multiple DHCP servers, I went and checked for any possible Rogue DHCP servers using Wireshark, and I found a range that is not apart of our usual subnet, was offering and broadcasting DHCP. So the issue was rogue DHCP.

@Sebastian-Roth Thanks that did the trick.

@Brenth453 said in Deploy Issues:

File was named d1 partitions. Only file with a similar name to the ones above.

Ok so this image is not set to resizable type. Should still work though.

From the information I see that the SSD is probably around 238 GB in size. What size is the HDD?

Have you made sure bitlocker is disabled before capturing the image? There is a command for that and not via the gui! manage-bde -status C: and manage-bde -off C:

@pietroaretino said in SnapinClient ERROR: Compressed size mismatch between central header and local header:

It’s not the best wiki in the world; they also do not touch on ‘templates’ in that wiki article either.

I know, you are absolutely right. We are missing quite some information in the wiki. Would be great if you find the time to help us here. I am fairly sure you can figure out that stuff. Then just write it down so we can put it into the wiki.

Hey guys we can close this I solved it.

The drivers that i had extracted with 7-zip was incomplete and with errors.
Removed the folder and extracted the .cab with pea zip and it started working as normal again.

Don’t know why that made it work, but it did. 🙂