@Tom-Elliott I’ve also learned something new today as well. I installed Windows 10 on a PC with a 500GB hard drive and uploaded it to FOG. I then deployed it to another computer with a 256GB SSD and it came up as a 15GB drive. I’ll post the contents of that image.
@Tom-Elliott That is a newer image that I posted. You know, since you asked if it was created on a 1TB drive since it is showing the 4th partition, I’ve sorta decided to rebuild that image. I thought it was odd seeing that 4th partition since none of my other images have that.
@Wayne-Workman The drive type is both spinning and solid state. The OS is Windows 10 Enterprise. The BIOS image resized without any problems.
@Tom-Elliott The size of the drives are below:
500GB HDD -> 256GB SSD
128GB SSD -> 256GB SSD (this is the older image that was created around August 2016; the drive showed up as a 128GB drive after imaging)
The older image has not had any issues in the past as far as I can tell.
Here is the contents of the files:
I ran a Deploy Debug and it said that it resized sda4, but it did not.
Thank you for your help in advance.
We just noticed today that since updating to version 1.3.4 the hard drives are not expanding to use the rest of the HDD. I saw someone else had a similar issue, so I updated to 1.3.5 RC 7 and that did not fix the issue. Once the update did not fix the issue I thought maybe it was the image since I had uploaded it after updating to 1.3.4, but I used an older image and it had the same issue. As of this evening I’ve only been able to test this out with our UEFI image. I’ll try to see if we have the same issue with our BIOS image in the morning.
@Tom-Elliott I believe everything else is working fine for now.
@Tom-Elliott Whoops… You’re right. They are forward slashes. 
@Tom-Elliott Sorry, no. I changed it from double \ to a single \ .
@Tom-Elliott I did some poking around last night and I changed a couple of things. The first thing I changed was in my .fogsettings. My default and one of my storage nodes did not have the username= entry. I added that and instead of “username” “password”, changed the quotes to apostrophes ‘username’ ‘password’. This gave me a different error this morning, which I did not expect so I did not capture the error. However, the error pointed saying that the ftp location did not exist. So I went into the Fog Settings through the web gui and saw that ftp path on all of the storage nodes was set to \images. I changed that to \images and I was able to get my capture task to clear out and the uploaded files are in the correct image folder and not sitting in dev.
@Tom-Elliott I hope this is what you were looking for. 
@Tom-Elliott This fixed the reboot/join issue. Thought I’d mention that it did not fix the upload issue as forecast.
@Tom-Elliott No, I’ve been getting the update using:
sudo -i
wget http://downloads.sourceforge.net/project/freeghost/FOG/fog_1.3.2/fog_1.3.2.tar.gz
tar xzf fog_1.3.2.tar.gz
cd fog_1.3.2/bin
./installfog.sh
@Tom-Elliott Running Version 689680
SVN Revision: 6059
@Tom-Elliott I have not updated to 1.3.3 yet, but I found another issue that we are having. I was able to image a computer, but it is not auto joining to the domain. I also inputted the domain password just to make sure it was using the right password.
@Tom-Elliott So seeing that 1.3.3 had been published, should I update to this to see if it fixes my issue?
@Doctrg I’m told by one of our other techs that even with the service off and the replicate image unchecked that it still fails.
@Tom-Elliott I stopped the Replicator service and tried uploading with replicate checked. It failed uploading.
@Tom-Elliott It would great if there were a global setting for disabling replication. I have updated one of our other storage nodes that was failing before 1.3.2 and with replication unchecked it uploaded without an issue.
