@hancocza said in FOG update to 1.5.5 doesn't allow passphrase entry for SSL/TLS key:
It looks like it skipped the part where you can enter the password for your ssl certificate key. In the past, it would ask for the password and allow you to enter it,
Not sure if this was before my time but I have never seen the installer ask you for a SSL key password. Are you sure?
@jjacobs Please set has_usb_nic=1 as Kernel Parameter for this particular host in the FOG web UI and see if that helps.
@deckerta Please provide the fog.log from one of the clients that failed domain join.
@china-boy Can you please post a picture of disk management from the target PC before you deploy to it?
@george1421 I have read through the whole thread over and over and just had a glimps of an idea on what he’s actually trying to do. Not exactly sure but to me it sounds as if he has target PC with two or three partitions on them already. Now he’s prepared a fresh windows installation in a VM and wants to to capture and deploy only the windows 
partition of the VM out to the physical machines. Does that make sense?
@jgiovann You need to push a gateway/router to those clients in the other subnet. Add option routers 192.168.2.X; to your DHCP config. There must be a router/gateway between those two networks and you need to specify its IP from the 192.168.2.0/24 side.
Kernel option CONFIG_VMD added to the official repo. Will upload new 4.19.6 kernels soon.
@Fernando-Gietz Edit /var/www/html/fog/lib/plugins/ldap/hooks/ldappluginhook.hook.php, jump to line 175 and comment the single line in the setTypeFilter function, so it looks like this:
public function setTypeFilter($arguments)
{
// $arguments['types'] = array(990, 991);
}
Be aware this might result in unexpected behavior in other parts!
@Junkhacker I just had a look and 0.2.89 is still the latest stable version of partclone. Sure there is 0.2.90 testing and 0.3.12 unstable.
We might start testing with the unstable build before we actually let users run into it. I just build a fresh init with partclone 0.3.12 in it. No adjustments to the parameters yet. I just want to see if plain old capture and deploy run smoothly with unstable partclone. Please give it a go and let us know.
@lenels2eng said in Trouble getting first Image:
should I just start over with a larger vdisk???
No need to I reckon. You can simply merge those together. See if you still have any images left in the original directory ls -al /images. If so, move them to the other one mv /images/<image_name> /images2/. All done, then clean the old directory - not actually needed, but might prevent from further confusion rm -rf /images/.mntcheck /images/dev /images/postdownloadscripts (think before you do this). No unmount the 2nd vdisk umount /images2 and remount mount /dev/sdXY /images. Make sure you have the entry also in your /etc/fstab file correct for next reboot. Then remove the second storage node definition and simply go with the single one in /images…
Be careful with this, it’s just written down and untested. Your situation might be a bit different to what I expect. Please double check and don’t run the commands blindly!!
@lenels2eng I am sorry but from my point of view you’re not on the right track yet. Let’s see what information we have:
...storage=172.16.30.10:/images2/devPHP Warning: ftp_put(/images/dev/000c29748171): failed to open stream/images/dev and /images2/dev on the very same server.I think this might be causing the trouble. Why do you have two different directories at all?
About the file ownership: See we transfer the files from the client to the server using NFS. Mounting and file creation is done via root user as we don’t have the same fog user account (and more important same UID) on the client. Access rights might only be changed at the end when the imaging finishes properly and FOG is able to move the newly uploaded image from /images/dev/<mac_address> to /images/<image_name>.
@lschnider The “read ERROR: No such file or directory” is a bit miss-leading. What FOG does in the background is it spawns a tool that extracts the d1pX.img file on the fly through a FIFO pipe. In case the gzip extraction is failing (process dies for whatever reason) partclone failes with “No such file or directory” because the FIFO it was reading from is gone.
We have seen people reporting this in the forums every now and then (see forum search). Mostly unsolved or solved for no reason. Quite often it’s been in VM environments and I tend to believe that it might have to do with too little RAM setup for the VM causing the gzip extraction to fail and die. Just a guess in the wild. But see if you can successfully deploy the image if you add more RAM to the VM and try again.
@thegiantcat Thanks for the log but seems like my instructions were not as well though of. Didn’t have a machine to test and just made that up. So let’s do it a different way because we still miss the most important part in the debug log. Edit installfog.sh again and remove the -xv. Then start the installer like this: bash -x installfog.sh 2> debug.log. You will see some amount of debug messages go past ending with a line Choice: [1] ++ read osid. Just hit ctrl+c here and upload the new debug log. That should have the information I hope to see what’s going wrong.
@jflippen This is not a step by step manual. Make sure you read about LVM, understand it and have a backup copy of the data before you start.
So in LVM speech it seems like you have a physical volume on sda2 with one volume group (centos_fog–master) and three logical volumes. You should be able to assemble the new disk, initialize as physical volume, add to the volume group and then extend your centos_fog–master-images logical volume and the filesystem on it to span the size of the new disk.
Read man pages and articles on LVM on the web before you start.
@jjacobs There most probably is no simple “do this and that and it will work” I am afraid. Every machine is kind of different as it might come with different firmware (version). Maybe start by posting a picture of the error here.
@thegiantcat Ok, this is very strange indeed. Have no idea what could cause this at the moment. We may need to enable shell debug output to figure this out.
Edit installfog.sh and make the very first line look like this #!/bin/bash -xv. Now that will put out a lot of text. So you better tell it to write to a log file via ./installfog.sh | tee debug.log
Upload the debug.log file here.
@george1421 Well this depends on where and 
are actually located. If they are two partitions on the very same disk we need to play with the Partition setting in the image definition instead. If it’s two separate disks you are spot on.
@Junkhacker said in file format and compression option request:
fog images as they are created now do almost no duplication on supported filesystems and backup systems.
I am wondering if this is actually the case. Reading the forum topic on this (being mentioned in the release nodes an all) I get the impression that the option was added in 2014 but not much tested. lucatrv said in Add --rsyncable option for image compression:
However, I have carried out several tests and found out that unfortunately rsync or similar deduplicating algorithms do not work as expected with Clonzilla backups. It could be due to how Clonezilla stores data […]
Have you done any testing with rsync/zbackup yet?
@lschnider Ok, so client can reach the server but firewall is enabled. Disable it for now and see if the deploy is working then. This looks like a CentOS ruleset. So I may ask if you have followed our wiki article on CentOS and disabled SELinux (and the firewall)??! I wonder how you were able to capture an image if the firewall was enabled all the time. Run the following command to switch off the firewall temporarily and then try to do another deploy: systemctl stop firewalld
@lschnider said in Could not mount images folder Error:
No the target computer is 10.2.227.199
Can you please schedule a fresh deploy task. But this time tick the checkbox for debug. Start up the client and when you get to the shell run the following commands to verify:
ip a s
ping -c 3 10.2.227.200
If the two machines are surely in the same subnet I suspect the error “No route to host” might come from the firewall being enabled on the FOG server and not allowing NFS access. Run iptables -L -n -v on the FOG server and post here.