FOG Imaging Not Saving

[george1421]

@dpotesta50 If you look at your very first post it mentions /var/log/partclone.log. You can key in tail /var/log/partclone.log to view the last few lines of that log file. If you need a few more lines you can do tail -30 /var/log/partclone.log to show the last 30 lines.

[george1421]

@george1421 I will tell you a trick so you can remotely interact with FOS.

1. Give root a password with this command passwd. Just give it an easy password like hello. Do this from the FOS debug console.
2. Get the IP address of FOS target computer. ip addr show
3. Connect to FOS using Putty from a windows computer. Login with root and hello as the password.

Now with putty you can cut and paste commands to the FOS engine. FOS runs in memory, so when you reboot FOS all settings or changes are gone. So this password reset is only temporary.

[dpotesta50]

@george1421 Well…that log file is not there. I sorted the directory by name, no log file.

[Sebastian Roth]

@dpotesta50 Where did you check for that partclone.log file? On your server (wrong) or on the client itself? Although you can get access to the client via SSH there is a much easier route of just taking a video/picture of the error message when it is right on screen in that blue window. Post here and I am sure we’ll figure things out.

[dpotesta50]

@sebastian-roth Okay so if I look for the log file on the laptop I’m imaging FROM, how do I do command line navigation? I CTRL-C’d to the command prompt which is blue and says "[Thu Nov 9 root@fogclient /]#

[Sebastian Roth]

@dpotesta50 Trying chat for faster turnover… see the speech bubble in the right top corner of the forum.

[dpotesta50]

@sebastian-roth

[Sebastian Roth]

@dpotesta50 Alright, got that. See here: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit

[dpotesta50]

@sebastian-roth I went ahead and rebuilt the image. Ran checkdisk and disabled FAST STARTUP as instructed. So far, the image is still uploading. Before it was done in less then a minute. Now it’s been going for about four or five minutes and it’s only at 13% so something is definitely different.

[george1421]

@dpotesta50 It should have told you right away that the disk was dirty and not started at all. So this surprises me a bit. But we see this common with Win10 (not being shutdown properly). We are glad you got it uploading now.

[dpotesta50]

@george1421 Well crud!

[JGallo]

@dpotesta50

looks like your FTP credentials are not matching properly. The error is not on the Windows 10 machine but on the fog server ftp credentials.

[dpotesta50]

@jgallo It shows the image was uploading though. The file size is 19.5Gb. Before when I was getting all the errors it was 615Mb.

[george1421]

@jgallo I agree.

@dpotesta50 did someone muck about with the linux user called fog? Understand this is not the web gui administrator account that is also called fog, I’m talking about the linux user fog. We quite often see IT admins attempt to use or change the password on this FOG managed service account. If you have then there is a process to fix it.

[dpotesta50]

@george1421 Not that I’m aware of. I’m sitting right in front of the computer, nobodies on it but me. It’s running on Ubuntu. The login for the O.S. AND the FOG admin are both “FOG”.

[george1421]

@dpotesta50 ok what I want you to do is this.

inspect the following hidden file: /opt/fog/.fogsettings (yes the dot belongs in there).

Review that file and look for a setting called password= (hint its easier to do this test if you are remoted into the computer using putty).

Record the password, then from a windows computer, use a ftp client and connect from your windows pc to the FOG server. Login with fog and the password you gleaned from the .fogsettings file.

See if that works. If it does then we need to look back in the webgui for the problem.

[dpotesta50]

@george1421 Once I stopped the CAPTURE task, the image deleted itself.

[george1421]

@dpotesta50 Well you need to get this FTP part to work, or your images will stay in /images/dev/<mac_address> and not move to their proper location.

[dpotesta50]

@george1421 So the image is here??

[george1421]

@dpotesta50 If that is the mac address of the image you were uploading then yes.

FOG uses NFS to move the image from the target computer to the FOG server. For security reasons, only the /images/dev directory on the FOG server is writable via NFS. Once the upload is done, the target computer connects to the FOG server using a ftp and instructs the FOG server to move the uploaded image from /images/dev/<mac_name> to /images/<image_name>. Since this is all done on the FOG server with file pointers the fog server only updates the directory listing and doesn’t need to move the physical files. This happens very quickly on the fog server.

Now what has happened here. The upload went as planned, but because the fog linux user couldn’t login because of a bad password. The target computer couldn’t move the file to complete the upload process.

You need to fix the linux user fog’s settings to get things back in sync.