[Solved] Migrated /images folder

[Fimlore]

The disk is shared with different methods of imageing (WDS, FOG etc) so it’s mainly for clarity.
this setup worked in the old machine, in fact, the disk was detached from the old machine and attached.
FOG was already installed at that point however, i’ve overwritten the /images folder with the mounted disk

[Quazz]

@Fimlore You have to change the path in a couple of places

The storage node image path has to be adjusted on the WebGUI of the server.

Then on the server itself:

/opt/fog/.fogsettings : storageLocation

If you let FOG build exports automatically, then just rerun the installer after that change.

If not, you have to edit /etc/exports

Do be careful of ownership and permissions in a shared image location.

[Fimlore]

Thank you, this was indeed the issue.
I did have to reinstall FOG, I don’t quite know what you meant by

“If you let FOG build exports automatically, then just rerun the installer after that change.
If not, you have to edit /etc/exports”

I had no /etc/exports, so tried reinstaller anyway, problem solved. Thank you!

[Fimlore]

@Quazz
I am facing another issue,
exported and imported images work without issue, new images give me the error as can be seen in the picture:

If I rename the folder to be like one of the working images, than it works like a charm. It’s just that somehow the Image GUI doesnt seem to store the correct location?

p.s. the Args passed is something that I also see on the working images… it’s a bit confusing but I guess it’s a mount or something?

[Quazz]

@Fimlore Yes, the FOS environment mounts your image location to /images on the client.

You can actually see your image location in the kernel arguments, which seems to be correct.

If I rename the folder to be like one of the working images

What do you mean by that?

What do the image settings look like? Are they different from the old ones?

[Fimlore]

@Quazz
The ‘old’ images (which were on the older server) do work. So if I rename the folder of the image that doesn’t work, to one of the folders that do work, the image deploys.

it appears to me that newly created images do not receive the correct file path; I’ve checked the database / Images table and it doesn’t store that path with the images, as far as I can see. So I tried reconfiguring the StorageNode (defaultMember) by just removing the /FOGImages and adding it again, but to no avail.

[Fimlore]

@Quazz said in Migrated /images folder:

@Fimlore Yes, the FOS environment mounts your image location to /images on the client.

Does the FOSenv have some sort of shell so that I can troubleshoot while the folder is mounted?

[Quazz]

@Fimlore I don’t think the path is wrong. First one is the nfs path to the FOG server and second is the image name (you can see this in the kernel variables in your screenshot)

192.168.68.14:/images/FOGImages/
QAD-Teamwork

You can schedule a deploy (debug) for a registered host (type fog then enter to start deployment process)

Is this image non-resizable per chance?

[Fimlore]

@Quazz

(image is disabled because the team had to finish an order today, so am deploying using the ‘cheat’ I described earlier)

I’ll try the debug option to see what I can find.

[Fimlore]

@Fimlore said in Migrated /images folder:

I’ll try the debug option to see what I can find.

the files are clearly there… what does Exit RC 4 mean?

[Quazz]

@Fimlore From the man pages of sgdisk: Non-GPT disk detected and no -g option

Which doesn’t really make any sense since the g option is present…

[Fimlore]

@Quazz
I’m confused.
Ok, so I tried to perform the command myself, it complains that the disk isn’t big enough;
so, I expanded the disk of the VM, and suddenly the image ís able to deploy, in both Debug and non-debug VM’s…

will have to check on the actual devices, since they gave the same issues as the VM

[Quazz]

@Fimlore Makes sense, even with resizable image type, a certain size is required for it to work.

I think it’s not possible to deploy a partition table that refers to a partition starting/ending outside of the range of the hard drive itself.

[Fimlore]

@Quazz
I thinks that I fixed the issue somewhere along the way and kept on having a different issue on my debug VM, then when I went to check out that issue, I recognized the fact that I already solved it somewhere… The Physical devices also deploy without issue now;

I’ll still need to confirm that the exact issue is solved, so i’ll be creating a few images and see if they restore out of the box.

Thanks again for the quick support, I’ll mark this thread as solved

edit;
(…if I knew how… )