db_root: cannot open: /etc/target
-
Thanks, I’ll give you all that I have.
Current FOG server version: 1.5.5
Fog is installed on Ubuntu Server 16.04.5 LTSI’ve had this installation up and running for about 3 months. I’ve been able to capture and deploy images, as well as other tasks. Inventory, registration, disk wipe. Everything was working.
The system I’m trying to deploy to is a Dell 3020 with identical hardware to other systems that I’ve captured from and deployed to. Please let me know what else you would like to see/know.
Here are images from the client as it was in the process of deploying an image:
-
@kboutelle Please run
cat /etc/exportsandls -al /images/ /images2/on your FOG server. Post output here. -
root@STF-IMGSVR01:/# cat /etc/exports /images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0) /images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1) root@STF-IMGSVR01:/# ls -al /images total 20 drwxrwxrwx 5 fog root 4096 Oct 29 15:40 . drwxr-xr-x 28 root root 4096 Jan 23 08:39 .. drwxrwxrwx 3 fog root 4096 Oct 22 15:18 dev drwxrwxrwx 6 fog root 4096 Oct 29 15:40 drivers -rwxrwxrwx 1 fog root 0 Oct 22 15:18 .mntcheck drwxrwxrwx 2 fog root 4096 Oct 22 15:18 postdownloadscripts root@STF-IMGSVR01:/# ls -al /images2 total 48 drwxrwxr-x 9 fog root 4096 Dec 4 13:45 . drwxr-xr-x 28 root root 4096 Jan 23 08:39 .. drwxrwxrwx 2 root root 4096 Oct 23 09:28 ConferencePC drwxr-xr-x 3 fog root 4096 Dec 4 13:45 dev drwxr-xr-x 6 fog fog 4096 Oct 29 15:55 drivers drwx------ 2 fog root 16384 Oct 23 08:32 lost+found -rw-r--r-- 1 fog root 0 Oct 23 08:36 .mntcheck drwxr-xr-x 2 fog root 4096 Oct 23 08:35 postdownloadscripts drwxrwxrwx 2 root root 4096 Dec 4 13:45 Win7-3020-Gold drwxrwxrwx 2 root root 4096 Oct 30 14:32 Win7_Pro_3020[MOD EDIT]: Put into Code block for easier reading.
-
@kboutelle Seems like you have moved your images to another directory/disk but gave up half way. Edit
/etc/exportsto have/images2and/images2/devas paths in there. Then runexportfs -raand try booting the client into the task again. -
Thanks. Believe it or not, the server has been set up this way since initial install. All images were captured to the images2 directory and deployed from there. I’m not sure what happened or why but here I am.
I completed the steps that you pointed out and I’m still not able to image. The issue I’m seeing now is Unable to open image store ( /bin/fog.download). The file is actually missing. This is preventing the imaging process from continuing. I’m looking at my vm backup now seeing if I can recover that file as I have no idea what it contains.
Edit: I’ve looked through the files contained in my backup and it’s not there. If this file is necessary, I could use a primer on how to recreate it.
Edit 2: I see that this file is supposed to end up on the client. I’m testing the hdd now to see if there is an issue with it.
Thanks again.
-
@kboutelle said in db_root: cannot open: /etc/target:
/bin/fog.download
This files is with in the FOG Linux system (we call it FOS) that is booted via PXE and runs on the client. I am sure the file exists! Don’t worry about it. Please take a picture of the error you see on the client now and post here.
-
This is what I saw on the client.
-
@kboutelle Well we are definitely a couple of steps bejond the error you posted in the first picture! So fixing /etc/exports definitely seemed to help. Now I see the image is called
Win7-3020-Goldand from the directory listings you posted it seems like this image folder does exist as well. Please runls -al /images2/Win7-3020-Goldand post output here. -
root@STF-IMGSVR01:/# ls -al /images2/Win7-3020-Gold total 8312928 drwxrwxrwx 2 root root 4096 Dec 4 13:45 . drwxrwxr-x 9 fog root 4096 Dec 4 13:45 .. -rwxrwxrwx 1 root root 3 Dec 4 13:35 d1.fixed_size_partitions -rwxrwxrwx 1 root root 1048576 Dec 4 13:40 d1.mbr -rwxrwxrwx 1 root root 190 Dec 4 13:40 d1.minimum.partitions -rwxrwxrwx 1 root root 15 Dec 4 13:38 d1.original.fstypes -rwxrwxrwx 1 root root 0 Dec 4 13:38 d1.original.swapuuids -rwxrwxrwx 1 root root 8551038 Dec 4 13:40 d1p1.img -rwxrwxrwx 1 root root 8502808087 Dec 4 13:45 d1p2.img -rwxrwxrwx 1 root root 190 Dec 4 13:38 d1.partitions -
@kboutelle From the information we have so far I cannot see why it fails this way. Can you please cancel the task in the web UI and schedule a new deploy job but this time tick the checkbox for debug. Boot up the client machine again and when you get to the shell (after hitting ENTER) you type
fogto start the process. Now step through the steps till you hit the error. It will bring you back to the shell. Then runmount ; ls -al /images, take a picture and post here. This time it really is/imageswithout2at the end because this is the directory used on the client to mount the NFS share from the server. -
OK, the error was that same in the last image I posted. This is the result of the debug process as you’ve instructed:
-
@kboutelle Well the first thing I noticed is that you don’t have any files in the /images2 directory (on the fog server across the nfs mount) according to the pxe booting client. Its also interesting to see that it IS a fog images directory because it has the FOG expected structure.
Is 10.0.0.138 your FOG server?
On your fog server you did a
ls -la /images2command that surely showed files.What is the output of the following commands
showmount -e 127.0.0.1
and
cat /etc/exports -
Yes, 10.0.0.138 is my FOG server.
root@STF-IMGSVR01:/# showmount -e 127.0.0.1 Export list for 127.0.0.1: /images2/dev * /images2 * /images/dev * /images * root@STF-IMGSVR01:/# cat /etc/exports /images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0) /images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1) /images2 *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0) /images2/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)Could I have an issue with the database? I’ve been reading as much as I can while you’ve been trying to help me. Some others have had issues with databases after updates. Sorry I didn’t save the links.
-
@kboutelle There’s the problem.
You have /images and /images2 mounting to the same File system ID. I believe nfs will use the 1st instance (in your case it’s mounting /images rather than your new share /images2.
Edit the /etc/exports file.
For your /images and /images/dev lines, prepend them with a
#symbol. This will comment those lines.That, or change the fsid of the /images2 and /images2/dev to have 2 and 3 respectively.
Then restart the nfs service,
systemctl restart nfsd -
@Tom-Elliott said in db_root: cannot open: /etc/target:
@kboutelle There’s the problem.
You have /images and /images2 mounting to the same File system ID. I believe nfs will use the 1st instance (in your case it’s mounting /images rather than your new share /images2.
Edit the /etc/exports file.
For your /images and /images/dev lines, prepend them with a
#symbol. This will comment those lines.That, or change the fsid of the /images2 and /images2/dev to have 2 and 3 respectively.
Then restart the nfs service,
systemctl restart nfsdI can’t believe I missed that. Edited, going to try again.
Deployment is proceeding as it should.
Thank you all for taking the time to help.
