Error capturing to a subfolder
I’m currently working through another forum members issue where they are trying to augment their fog server’s storage with a second hard drive. The forum member created a directory under /images. For the sake of discussion lets call it vol1. Then the new hard drive [/dev/sdb1] was mounted to that new directory [/images/vol1]. Then an new image definition was setup to capture to that subdirectory under the /images directory. A capture was scheduled and the capture failed with unable to locate image store.
<I’ll link in the original thread here>
@Tom-Elliott Yeah I got that on the mounting.
/images/vol1 (which points to a directory on /dev/sda1) images correctly.
/images/vol1 --> /dev/sdb1 errors out
From FOS with the mount point in place if I stop the script where it errors out. I can move to /images/vol1 no problem. I can’t touch a file in /images/vol1 because /images on the fog server is shared out read only. There must be some conditional check that is failing above where it works when /images/vol1 is a directory and failing when /images/vol1 is a mountpoint. I’m just not seeing it.
You can’t unmount a disk/volume if it’s busy. For example, If you’ve mounted a filesystem to /images/vol1, then you cd to /images/vol1, you won’t be able to unmount until you are out of /images/vol1.
Capturing a file to a non-mounted directory does not make the file exist in the mounted point.
- For example: you have created directory /images/vol1. You then captured an image to /images/vol1/someimage. From the /images/vol1 point (nothing mounted) the files are all good and dandy. When you mount the filesystem on /images/vol1, files within /images/vol1 do not become automatically available to the volume you mounted on top of it. You might be able to acheive this with the
-o bindarguments, though I’m not 100% sure that would do it.
So let’s say /dev/sda1 is the current /images/vol1
Lets say you want /dev/sdb1 to mount to /images/vol1
Without /dev/sdb1 mounted, the file will exist and be happy on /dev/sda1.
Now you mount the /dev/sdb1 on /images/vol1.
The file still exists in /dev/sda1, but /images/vol1 is no longer pointing at /dev/sda1, it’s pointing at /dev/sdb1.
In my dev environment I have a dev fog server setup for another task so I decided to see if I could duplicate the OP’s issue (short answer is I can).
Here is how I setup the experiment.
- Added a new vmdk to the fog server
- Used fdisk to create a partition
- Formatted the partition ext4
- Create a directory under /images called vol1
- Created an image definition that looked like this:
- I assigned that image definition to an existing host
- Scheduled a capture task
- The image captured correctly to the directory /images/vol1/VolExtnd1 (sweet)
- I ran the following command
mount -t ext4 /dev/sdb1 /images/vol1
- I schedule a new capture task
- Capture failed with Unable to locate image store.
- I reboot the target computer (since I wasn’t able to umount /images/vol1 because of a locked file ??). Note the same capture task was still pending cause I was running in debug mode.
- I unmounted /dev/sdb1 from /images/vol1
- When the target computer rebooted it started imaging and ran to completion placing the files in /images/vol1/VolExtnd1.
So for some reason it doesn’t like a mounted hard drive in this location.
At the point of the error this is what was mapped on the FOS engine (interesting that dev wasn’t mounted yet)
from the FOG server this is what the directory structure looks like
[root@devfog images]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/centos-root 27G 8.8G 18G 34% / devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 8.6M 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/sda1 497M 172M 326M 35% /boot tmpfs 380M 0 380M 0% /run/user/0 /dev/sdb1 40G 49M 38G 1% /images/vol1
This is what the images directory looked like
[root@devfog images]# ls -la total 12 drwxrwxrwx. 7 fog root 100 May 25 14:55 . dr-xr-xr-x. 20 root root 4096 May 25 14:12 .. drwxrwxrwx. 3 fog root 44 May 25 15:07 dev drwxrwxrwx. 3 fog root 26 May 18 17:56 drivers -rwxrwxrwx. 1 fog root 0 May 16 15:32 .mntcheck drwxrwxrwx. 2 fog root 29 May 16 15:32 postdownloadscripts drwxrwxrwx. 3 fog root 4096 May 25 13:30 vol1 drwxrwxrwx. 2 fog root 4096 May 25 13:46 WIN7OEMX64
This is the point of the actual error when running on FOS. Line #76 of fog.download