Transfer Images from 0.32 to fresh 1.2.0 - 1.2.0 can't see images

[Philip Boschman]

Okay - we’re still under the gun with our other project, BUT…

I was able to setup a lab at home with VMWare Workstation 8 and did the following (I’ll add/repeat some of my steps from above)…
[LIST=1]
[]I built a new Ubuntu Server (12.04.5)
[]Installed Fog (1.2.0)
[]Checked the ‘FOG_FORMAT_FLAG_IN_GUI’ box
[]Transferred (copied) the ‘test’ image from our 0.32 Fog server to the new 1.2.0 server
[]Ran chmod 777 on ‘images’ folder
[]Created a ‘new’ image with the same [B]exact[/B] name as transferred (copied) file
[]Set it to ‘partimage’ as per this note form the other post
[LIST=1]
[]“Images made with 0.32 must be set to partimage and 1.x images set to partclone”
[/LIST]
[]Created a dummy VM (no OS)
[]Changed BIOS in dummy to boot from network (PXE)
[]Set up host ‘download’ task
[]Started up the dummy
[/LIST]
From this point everything went normally (system registered, etc.), UNTIL it came to ‘downloading’ the image onto the dummy, at which point it says it completes the task, but no image is loaded, and it just reboots back to the main Fog menu with ‘Quick Image’ as one of the choices, so looks like there is something more needed to get the transferred (copied) image to be ‘seen’/work (i.e. change something in the database???)

If anyone has any info on what to do at this point, please let us know, as we really need to get this to work.

Thanks in advance

[Philip Boschman]

P.S. We just built another Fog server, but this time with Fog 0.32, transferred (copied) the ‘test’ image, and we can’t get it to work either, so there’s something we’re missing somewhere

[Tom Elliott]

Have you verified that the permissions are proper so things can actually see your images?

[code]sudo touch /images/.mntcheck
sudo touch /images/dev/.mntcheck
sudo chown -R root:root /images
sudo chmod -R 777 /images[/code]

[Philip Boschman]

Sorry for the late reply.

Just got back to the office today, so just ran those commands. Testing now to see what we get, so will report back when done

[Philip Boschman]

Okay,

This update is from building n EXACT duplicate of the current Ubuntu FOG server (same OS - 12.04.2, same Fog version - 0.32), as well as creating a blank ‘dummy’ system with no OS on it (BTW - we’re doing all this in VMWare Workstation with the ‘Test’ image transferred over to it in the ‘Images’ folder (ad ran the permissions commands from Tom above), so…

Right out of the gate we were able to register the ‘dummy’ VM (shows up in the Hosts), and we were able to create a task, however, now when we get to the Fog GUI on the ‘dummy’ and choose the ‘Quick Image’ option, it prompts for the password (which is the default ‘password’) and…nothing happens.

Not sure what the issue is here, but again, any help would be appreciated

[Junkhacker]

the vm that you’re trying to quick image, does it have an image assigned to it? does it have any partitions on the drive?

[Philip Boschman]

We just created a blank VM (no OS - no nothing), ran the registration (it registered), assigned the ‘Test’ image to it as a task (succeeded), rebooted the system and got the Fog GUI with the ‘Quick Image’ option, which we chose, it asked for the password (we used the default), then…nothing happens…the GUI screen just sits there and we can move up and down the list, choose ‘Quick Image’ again, asks for password - again, put in password - again, then …nothing - again.

We did get some sort of ‘can’t have partition outside the disk’ at one point, but then we changed a parameter that we saw in the old Fog settings to the new, and that error hasn’t returned, so we figured that one out.

Still no go on the imaging though

[Philip Boschman]

P.S. Just for FYI - the parameter we changed was for the image. The old Fog had it set to MPI - All Disks (Not resizable), and we had set it on the new Fog to MPI - Single Disk (NR), so now when it gets to ‘Checking Hard Disk’, we get ‘Done’ instead of that error

[Philip Boschman]

This post is deleted!

[Philip Boschman]

Just a quick FYI update - we set the VM to PXE boot, create the task in Fog to deploy to the ‘seen’ VM, it boots up, goes through the initial Fog cmd screen, then at the end - reboots - and it’s at THIS point it reboots into the Fog GUI with the ‘Quick Image’ listed as a choice, so from what we know, the imaging should have happened during the initial boot and NOT reboot (if we have this right), so that kind of suggests that it’s not seeing the image on the initial boot up.

BTW - we made the drive 5GB’s bigger than the actual system (a laptop) that this ‘test’ image was created for, and we set it as IDE, so don’t know if any of that info matters

[Philip Boschman]

This post is deleted!

[Philip Boschman]

Still trying to see if we’ve missed something, so going through the settings - again

[Philip Boschman]

Haven’t updated in a while, but after digging on the web a bit more these past few weeks, found a note that it may be due to the old image ID’s still being in play somewhere, so you need to reset them. We’re rebuilding the current server from scratch and going to see what the DB shows when we transfer the ‘Test’ image across. Will update again.

[cassie_280]

I’m having issues using images that I transferred from my previous 0.32 server, to my 1.2 server. So far I have copied the image to the /images folder, and created the"image profile" in the FOG GUI and named it exactly like the file I transferred. I went into the settings and turned on the FLAG_IN_GUI option and set that image to partimage. I’m still receiving this error when I try to deploy this image to a host.

I also created a new image directly from the server and uploaded an image to it, and strangely i’m not seeing the file that should have been added to the /images folder with that images name.

I’m running FOG on Ubuntu 14. I’m not sure if this is a permissions error for the /images folder?

[Wayne Workman]

@cassie_280 FOG 1.2.0 is notorious for FTP Credentials issues… I’d suspect that it’s either a credentials problem, or the path is not exactly how it should be. the pathnames are case sensitive. Also you need to ensure the right permissions exist on time image you moved in. Look at this:

https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP

and make sure the image you moved has 777 permissions recursively like this: chmod -R 777 /images

[george1421]

FWIW: On my centos system the permissions are 755 and owned by fog.fog for all files and folders in /images

[cassie_280]

@Wayne-Workman It’s weird. I realized that I can do a full host registration and image from the machines and it works fine. It only fails when I try to deploy the image from the server.

[Wayne Workman]

@cassie_280 What version of FOG are you using? What is the number in the cloud, top left?

Is it possible that there are two fog servers in your environment, and you’re just using the wrong/old one?

[cassie_280]

@Wayne-Workman I do have two FOG servers, but the old one is shut down, so I’m positive that’s not the one I’m using. I’m using FOG version 1.2.0

[Wayne Workman]

@cassie_280 have you gone through the credentials section of the below article, “Troubleshoot FTP” ?