Disappearing images/Updating database... failed
-
I have set up a fog server on CentOS 8 running FOG version 1.5.8. When capturing an image, it will get to 100% and then I receive the “Updating database… failed” error. I also notice that the temp folder for the image created in the /images/dev directory disappears at that point. I read on the wiki this is usually a permission or credential issue and double-checked that my FTP path was set correctly and that the username and password under storage management match the ownership of the /images directory. I have also verified the TFTP, .fogsettings, and local fogproject user credentials match.
In one instance I was able to manually rename and move the temp folder to /images and that is the only time I have gotten the image to stay.
Any suggestions would be much appreciated
-
@jserowoky said in Disappearing images/Updating database... failed:
I also notice that the temp folder for the image created in the /images/dev directory disappears at that point.
It should be moved to
/images/IMAGENAME/. Do you see this? Or does it just disapear? I kind of doubt it does. -
can you provide the output of these two commands
ls -la /images/dev
ls -la /images
lsblkIf these uploaded images are gone we’ll go through the ftp debugging steps. But lets see the output of those commands first.
-
@Sebastian-Roth I just ran it again watching both folders. In /images/dev the temp folder appears using a random alphanumeric name, which I’m assuming is normal (not super familiar with Linux yet.) It then moved to /images using the actual name of the image, while still receiving the same “updating database… failed” error. Then the client machine displays a new error stating “Could not complete tasking (/bin/fog.upload)” and it is at this point the /images/IMAGENAME directory disappears.
-
@george1421 Here are the outputs for those commands:
[root@fogserver2 ~]# ls -la /images/dev
total 0
drwxr-xr-x. 3 fogproject root 46 Mar 11 14:17 .
drwxr-xr-x. 5 fogproject root 79 Mar 11 14:18 …
-rwxrwxrwx. 1 fogproject root 0 Mar 5 17:58 .mntcheck
drwxr-xr-x. 2 fogproject root 26 Mar 5 17:58 postinitscripts[root@fogserver2 ~]# ls -la /images
total 0
drwxr-xr-x. 5 fogproject root 79 Mar 11 14:18 .
dr-xr-xr-x. 20 root root 275 Mar 5 17:59 …
drwxr-xr-x. 3 fogproject root 46 Mar 11 14:17 dev
-rwxrwxrwx. 1 fogproject root 0 Mar 5 17:58 .mntcheck
drwxr-xr-x. 2 fogproject root 30 Mar 5 17:58 postdownloadscripts
drwxr-xr-x. 2 root root 222 Mar 10 16:18 Win10_04.5[root@fogserver2 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 1G 0 part /boot
└─sda2 8:2 0 930.5G 0 part
├─cl_fogserver2-root 253:0 0 50G 0 lvm /
├─cl_fogserver2-swap 253:1 0 16G 0 lvm [SWAP]
├─cl_fogserver2-home 253:2 0 10G 0 lvm /home
└─cl_fogserver2-images 253:3 0 854.5G 0 lvm /images
sr0 11:0 1 1024M 0 rom -
@jserowoky ok your directories sure do look empty. I have to say I haven’t seen fog delete everything at this point.
So where we are in the process is that when fog captures the image it uploads the image to /images/dev/<mac_address> when the capture is done the target computer logs into the FOG server using ftp and moves the directory from
/images/dev/<mac_address>to/images/<image_Name>FOG uses the ftp mv command because on linux the move command just updates the directory pointers and never moves any files themselves. So the risk of deleting them is almost 0.The unable to update the database is a bit of an incorrect error since the ftp mv command happens just before the database is updated .
So how to test this. We’ll use a windows computer with the cmd line ftp client.
- On the fog server review the hidden file /opt/fog/.fogsettings for a password field.
- On a windows computer using the ftp program log into the fog server using the user ID of fogproject and the password you collected from the .fogsettings file.
- If you can get logged in then execute these commands in the ftp client program.
cd /images/dev
mkdir bob
mv /images/dev/bob /images/sam
rm /images/sam - With the exception of the
rmcommand that is the process that FOG uses to create an image (more or less).
Lets see where that fails.
-
@jserowoky Is SELinux enabled or disabled? Run
getenforceand post output here.Change access rights on the folders (
chmod 775 /images /images/dev) and try capturing again.In /images/dev the temp folder appears using a random alphanumeric name, which I’m assuming is normal.
Yes, we use the MAC address (without colon or hyphen notation) as temporary folder name in /images/dev.
