I’ve set the image to Single Disk - Resizable and removed the custom entries in the Host’s Primary Disk field.
It all looks good when recognizing the disk… however it appears to be stuck at the following…
I’ve tried repairing the MBR just in case but still seems to be stuck at this point when attempting to capture an image.
@Sebastian-Roth Thanks for that! I will download and test and let you know how it goes.
@Arrowhead-IT ok cool… well the image on the server came to 20GB. That’s from a 256GB SSD and the Image Compression setting set to 6. Still not too bad actually considering a captured Windows 10 image from the previous model XPS 13 with a 256GB SATA disk using Single Disk - Resizable is about 17GB.
Now I guess the big test is to restore the Image on to the same machine and see if it boots. 
@Arrowhead-IT The notebook and FOG server are on a Gigabit connections and at the moment, the upload rate is displaying 5.14GB/min
What’s the implications of using RAW when restoring to drives larger than what its currently being imaged? Will it just be a matter of manually expanding the partition to take up the remainder of the space?
@Arrowhead-IT Thanks for the suggestion! I modified the Host Primary Disk value as you suggested and I then got the error saying “No resizable partitions found”.
So I then went to the Image properties and changed the Image Type from Single Disk - Resizable to Multiple Partition Image - Single Disk (Resizable), but it just hung after…
* Using Hard Disk: /dev/nvme0n1
I then changed it to Raw Image and it is now currently uploading.
@Sebastian-Roth said:
lsblk -pno KNAME,MAJ:MIN -x KNAME
I tried excuting the above command but I got…
[root@fog bin]# lsblk -pno KNAME,MAJ:MIN -x KNAME
lsblk: invalid option -- 'p'
Usage:
lsblk [options] [<device> ...]
Options:
-a, --all print all devices
-b, --bytes print SIZE in bytes rather than in human readable format
-d, --nodeps don't print slaves or holders
-D, --discard print discard capabilities
-e, --exclude <list> exclude devices by major number (default: RAM disks)
-I, --include <list> show only devices with specified major numbers
-f, --fs output info about filesystems
-h, --help usage information (this)
-i, --ascii use ascii characters only
-m, --perms output info about permissions
-l, --list use list format ouput
-n, --noheadings don't print headings
-o, --output <list> output columns
-P, --pairs use key="value" output format
-r, --raw use raw output format
-s, --inverse inverse dependencies
-t, --topology output info about topology
-V, --version output version information and exit
Running CentOS 6.7
Thanks for the response. I’m running FOG 5602.
Not quite sure whether it is AHCI or NVMe. From searching on google it may possibly be NVMe as it is the top range model.
I will try your suggestions tomorrow and post the output here.
Hi guys,
Have an interesting one here.
Has anyone tried or been able to image to/from an m.2 PCIe SSD?
I’ve got a new DELL XPS 13 9350 which is an upgrade from the previous model that uses a regular SSD. I’ve been able to image the DELL XPS 13 9343 without any problems (with the setting in BIOS set to Legacy).
Anyways, I’ve not been able to get FOG to capture an image from the PCIe SSD.
What I’ve done to the XPS is…
Set BIOS to Legacy
Updated to the latest BIOS from the DELL Support site.
Installed Windows 10 from scratch wiping all existing partitions and allowing the installer to create its own partitions (2 were created).
When it comes to PXE booting off the DELL USB NIC (Realtek RTL8153)… if I try using undionly.kkpxe, it gets stuck at loading bzImage at 0%.
If I try to use any of the .efi pxe images, it goes through the motions until it tried to detect for a HDD but fails and says…
Looking for Hard Disk....
An error has been detected!
Cannot find HDD on system
Computer will reboot in 1 minute.
So just seeing if anyone has had any experience with PCIe SSDs?
Cheers
David
Hi Devs,
Just a feature that may be a ‘nice thing to have’ would be to be able to set time of day replication.
Eg, Be able to set time schedules for when image replication occurs between storage nodes.
This is so that replication can occur during quieter times when there is less network traffic. Especially useful for replication to remote sites that go out via the WAN.
@Wayne-Workman Thanks Wayne… understood.
I do use the Location plugin for this very reason. I guess because it had worked in a previous trunk, I just assumed that the way I had it set up originally was how it worked. In any case, I can easily change this and put all the storage nodes in to the one storage group, making Sydney the Master node.
You can set this one as resolved.
@Tom-Elliott Thanks for that explanation. I think I’ve grasped the concept.
Yes your assumption is correct. Our Melbourne office is a small office actually with no I.T at all. So there would never be a need for them to update/upload an image.
Yes I do have several images set to be in both the Sydney & Melbourne Storage Groups, however I thought that since only the Sydney Storage Node is set to Master, only images from the Sydney node would be pushed through to the other nodes. Then there’s the issue you mentioned if one was to upload a fresh image to Melbourne Storage Node, then it would be wiped by replication from Sydney since it is set as the Master (which I was aware of from the warning next to the checkbox 
).
So correct me if I’m wrong, in my case, I would just simply tick Is Master Node checkbox in the Melbourne Storage Node since it is in its own Melbourne Storage Group. Then as long as the Primary Group is set to Sydney Storage Group in each of the Images, then replication should kick in and copy the image to the Melbourne Storage Node that’s inside the Melbourne Storage Group?
If say a Host location was set to Melbourne and was in Melbourne, and the Image’s Primary Group set to Sydney, Would the same thing happen then if for eg an image was uploaded to FOG in Melbourne, because the Primary Group for the Image is still set to Sydney, would that still also wipe the local Melbourne image with the one from the Sydney node?
Edit: Or is FOG smart enough to know that the Primary Storage Group for the image being uploaded is in Sydney, and so will then replace the Image in Sydney, then once done, replicate it back to the Melbourne Storage Node?
Apologies for the long write up. Hopefully this will be the last. 
ah right… i think i understand you.
So at the moment, I have a Sydney Storage Group and a Melbourne Storage Group, in which each Storage Node is in their respective Storage Group.
What I should be doing is scrapping that and having just 1 Storage Group called, Australia (for eg). And then putting the Sydney & Melbourne Storage Nodes in to that Australia Storage Group with Sydney being set as the Master?
Was this changed or has it always been like that?
Just strange that it worked in its current form at trunk 3594 but is different with the latest trunk.
@george1421
The Sydney Storage Node points to itself. The main fog server 192.168.20.10
The Melbourne Storage Node points to 192.168.20.8
So in Location Management. I have Sydney and Melbourne.
In each of these, Sydney has Sydney Storage Group and Sydney Storage Node. Melbourne has Melbourne Storage Group and Melbourne Storage Node.
In Storage Management, there are the 2 Storage Nodes. One for Sydney and one for Melbourne, each pointing to their respective IP’s and each with their credentials, and each point to their respective Storage Group. Only the Sydney Storage Node is set as the master.
Hi all,
I seem to have a Storage Node replication problem from the main FOG server after upgrading it from 3594 to 5566.
The main FOG server (in Sydney with IP 192.168.23.10), the Storage Node (in Melbourne with IP 192.168.20.8). Are both running on CentOS 6.7.
When I am running trunk 3594 on the main server, image replication works.
[12-01-15 11:21:17 am] * Found image to transfer to 1 group(s)
[12-01-15 11:21:17 am] | Image name: Dell XPS 13 [Win 10]
[12-01-15 11:21:17 am] * Melbourne Storage Node - SubProcess -> Transferring file `d1.fixed_size_partitions'
[12-01-15 11:21:18 am] * Melbourne Storage Node - SubProcess -> Transferring file `d1.mbr'
[12-01-15 11:21:19 am] * Melbourne Storage Node - SubProcess -> Transferring file `d1.minimum.partitions'
[12-01-15 11:21:19 am] * Melbourne Storage Node - SubProcess -> Transferring file `d1.original.fstypes'
[12-01-15 11:21:19 am] * Melbourne Storage Node - SubProcess -> Transferring file `d1.original.partitions'
and I can see that the files are being created on the Storage node’s /image folder.
If I then upgrade the main server to 5566, then all that appears in the image replicator logs are…
[12-02-15 8:41:28 am] * Starting Image Replication.
[12-02-15 8:41:28 am] * We are group ID: #1
[12-02-15 8:41:28 am] | We are group name: Sydney Storage Group
[12-02-15 8:41:28 am] * We have node ID: #1
[12-02-15 8:41:28 am] | We are node name: Sydney Storage Node
[12-02-15 8:41:28 am] * Not syncing Image between group(s)
[12-02-15 8:41:28 am] | Image Name: Dell Latitude E7x40 - Base
[12-02-15 8:41:28 am] | I am the only member
[12-02-15 8:41:28 am] * Not syncing Image between group(s)
[12-02-15 8:41:28 am] | Image Name: Dell Optiplex 9010 - Base
[12-02-15 8:41:28 am] | I am the only member
[12-02-15 8:41:28 am] * Not syncing Image between group(s)
I’m able to FTP from main server to storage node with the FOG user/pass that’s in .fogsettings on the storage node.
No bind options in /etc/my.cnf on both hosts.
From the Storage node, I am able to perform the command and make a successful connection to the database…
mysql -u fogstorage fog -pXXXXXXXXX -h192.168.23.10
If I downgrade to 3594, Image Replication works again.
All the credentials seem to be correct in all the areas that I should be looking at.
Just not sure why it’s broken when I upgrade to the latest trunk.
At the time of writing, I have left the Storage Node running at 5566 with the main server now downgraded to 3594 where Image Replication is currently working.
Hopefully you guys can provide me with some clues as to what else I should be checking.
Ok I managed to solve this based on a previous post where Tom had deleted files in /opt/fog/{service,etc}
I tried doing the above but still didn’t seem to resolve the problem. So I moved the existing fog folder in /opt to fog.backup. Then created the /opt/fog folder and copied the .fogsettings to it.
Performed a reinstall to pick up the existing settings and it now seems to be all ok without any errors.
Hi,
I upgraded to FOG 5566 from 3594 but for some reason, the services are displaying errors.
In /opt/fog/log/servicemaster.log
[11-30-15 7:04:47 pm] FOGImageReplicator child process (11066) exited with code 255.
[11-30-15 7:04:47 pm] FOGImageReplicator child process (11095) exited with code 255.
[11-30-15 7:04:47 pm] FOGMulticastManager child process (11094) exited with code 255.
[11-30-15 7:04:47 pm] FOGPingHosts child process (11096) exited with code 255.
[11-30-15 7:04:47 pm] FOGTaskScheduler child process (11097) exited with code 255.
When I stop and then start the service manually, I get…
Fatal error: Call to undefined method ImageReplicator::getBanner() in /opt/fog/service/FOGImageReplicator/FOGImageReplicator on line 10
PHP Fatal error: Call to undefined method ImageReplicator::getBanner() in /opt/fog/service/FOGImageReplicator/FOGImageReplicator on line 10
Also in the WebUI Log Viewer, the drop down box only shows Service Master, Apache Error Log, and Apache Access Log. It doesn’t display the services logs.
Any ideas?
Thanks @Wayne-Workman
I am currently running a trunk version so will test it out.
Hi all…
I’m about to attempt to image a Surface Pro 3 that’s been upgraded to Windows 10 from Windows 8.1. It has multiple partitions (5 in total) on the drive and the Disk format in Disk Management is showing as Basic.
Do I set the Image type in FOG to be Single Disk - Resizable? Or Multiple Partition Image - Disk Disk (Not Resizable)?
Hi @Tom-Elliott
Yup all good to close this one as resolved.
Thanks for your awesome work!