Error capturing to a subfolder

  • Moderator

    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>

  • Moderator

    @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.

  • Senior Developer

    1. 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.

    2. 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 bind arguments, 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.

  • Moderator

    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.

    1. Added a new vmdk to the fog server
    2. Used fdisk to create a partition
    3. Formatted the partition ext4
    4. Create a directory under /images called vol1
    5. Created an image definition that looked like this:
      0_1495740650894_VolExtnd1 _ Image Management _ FOG _ Open Source Computer Cloning Solution.png
    6. I assigned that image definition to an existing host
    7. Scheduled a capture task
    8. The image captured correctly to the directory /images/vol1/VolExtnd1 (sweet)
    9. I ran the following command mount -t ext4 /dev/sdb1 /images/vol1
    10. I schedule a new capture task
    11. Capture failed with Unable to locate image store.
    12. 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.
    13. I unmounted /dev/sdb1 from /images/vol1
    14. 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)
    0_1495741075584_mapped drives.png

    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

Log in to reply