Transfer Images from 0.32 to fresh 1.2.0 - 1.2.0 can't see images
-
Hey there,
i found a post labelled ‘[SIZE=3]Upgrade from .32 to 1.2.0 Problems’ that listed some of the issues we’re having, but didn’t clearly tell where to find/set the parameters of the issue.[/SIZE]
Basically we have a 0.32 server on Ubuntu Server 12.04 and have just built a brand new[SIZE=3] Ubuntu 12.04 Server with 1.2.0 installed. We transferred the Images from the 0.32 to the 1.2.0, but when we go to ‘Show Images’ on the 1.2.0, it doesn’t ‘see’ the images[/SIZE]
The other post mentioned[SIZE=3], “I[/SIZE]mage from 0.32 are not supported on 1.x unless you activate support in the FOG option and then set image type as partimage.”, but it never answered where these settings are, so if anyone can jump in and give a play-by-play on the where/how to do this, it would be MUCHO appreciated.
Thanks tons in advance
Cheers
-
There’s plenty of posts on these forums that specifically tell you where to go and what to do.
First things first,
The Images aren’t just going to populate in your fog server considering as the information (as I’m understanding it) is you created a brand new 1.2.0 FOG Server, and copied the 0.32 images over. Did you define the actual images within the server? Meaning, did you create the new images and image names? From what I can tell this is where you’re going wrong. Many others “migrate” their old images by exporting the images table from the 0.32 server and importing the images into the new images table.
To get the Format flag so you can specify if it’s partimage or partclone, you go to FOG Configuration->FOG Settings->General Settings->OG_FORMAT_FLAG_IN_GUI
This will give the gui the partimage/partclone setting on the image you’re working on so you can specify whether it is old or new. The dropdown will only be present when “editing” an image, not during creation of the image as we know nothing about the image until the image is actually created.
-
Thanks much for the insight.
I’m [B]very[/B] new to Fog, as I inherited it, so I did do many searches through the forum (and on Google), and we did find that ‘flag’ and set it, but we obviously missed the other posts that went into detail (that or just didn’t quite understand the steps, which is obvious :oops: ), so thanks much for your patient explanation.
We did indeed transfer the images from our Fog 0.32 server from the ‘images’ location directly to the same location on our new 1.2.0 server, so I guess the only step we didn’t understand was to ‘create the new images and image names’, so as we understood it (and I’m sure we’re still missing something), we thought once we set that flag then transferred them, they would show up in Fog under the ‘Image Management’, but obviously that’s not the case.
The one part we don’t quite get is if we ‘create’ an image, how do we refer/use/activate the ‘old’ image file? Do we create it on the 1.2.0 with the same name and just set the path directly to it (which would be a guess), or is there another way/step to this?
We’ll definitely start digging better in the forums, but if you feel you would be able to confirm/list the ‘after’ steps, it would be appreciated, only because we’re in a time crunch.
Truly appreciate the assist so far.
Thanks
-
To at least update this a bit - we had a ‘test’ image that we transferred (as is always a usual practice
and so we created a ‘new’ Image that we named exactly as the old one, then we saw the partimage/partclone option show up, so we set it to partimage.The only piece we’re not sure of is if this ‘new’ image is actually going to utilize the old image file, so we’ll give it a test and see what happens.
Hopefully this was the right steps, but if not, any ‘heads ups’ would be appreciated
Cheers
-
it sounds like you figured out what you need accurately. when you create an image, you’re actually creating what i call an “image profile” that contains all of the information about an image that fog needs, and where to get it. so long as the location in the profile matches the location that you put the file (and all of the other information is correct), it should work.
-
Another update - after creating the ‘new’ test image with the same name as the old one, in the headers under ‘Image size: on client’ and ‘: on server’, they both show 0.00iB as the size, so we’re thinking the system isn’t using/seeing the old image file(s)
Guessing there’s still a step missing
-
P.S. it also states ‘No data’ under the Uploaded header.
-
the “on client” info is updated when you upload an image, this will not be filled out for images that are imported from other servers.
the “on server” info is acquired by ftp and it being 0 can mean a number of different issues, including incorrect ftp credentials, or an incorrect file path (remember, it’s case sensitive) -
[quote=“Philip Boschman, post: 36735, member: 26110”]P.S. it also states ‘No data’ under the Uploaded header.[/quote]
that’s because there are no records in the database of it being uploaded. it was imported manually.
-
Okay - thanks much JunkHacker,
It sounds like we’re on the right track, but we may have either done something backwards, or we’re still missing a step, so I’ll break it down a bit so I don’t confuse anyone (mostly myself)…
[LIST=1]
[]We set up a direct SecPanel connection from the 1.2.0 to the 0.32 server
[]We copied all the image files from the 0.32 ‘images’ folder directly to the same folder on the 1.2.0
[]We then went into the 1.2.0 Web GUI and checked the ‘FOG_FORMAT_FLAG_IN_GUI’ box
[]We then (after Tom Elliot’s reply) created a ‘new’ image with the same name as the ‘test’ image that we copied
[LIST=1]
[]We named it [B]exactly[/B] the same, case and all
[]We set it to ‘partimage’
[/LIST]
[*]…and here’s where we are now
[/LIST]
…so this is where we need to know what to do next (or to correct) with our steps to allow the 1.2.0 to use/‘see’ the old copied image ‘test’ files (i.e. Do we do something on the DB side? Do we have to run a task? etc.) -
Unless of course I’m that dense and the answer was ‘Nope - you’re seeing what you’re seeing BECAUSE you imported, so you’re done - run the image’
-
the size on server should show up, so that’s a little concerning, but i think 1.2.0 may have had a bug reporting that for some systems (which will be fixed when we release 1.3.0)
try to use the image, if you have any trouble doing so, then we’ll troubleshoot further. -
Awesome.
Thanks again for all the insight, and I will ABSOLUTELY follow up on this thread with either failure OR success.
(I hate posts that get an answer that worked, but then are never replied to with the 2 minutes to at least post, ‘That worked’)
Just FYI - it may be a couple days as we’re still working with the old 0.32 for imaging as we’re under a time crunch to just get it done, but we WILL be testing the new ASA we have time.
Cheers and thanks again
-
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
-
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
-
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] -
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
-
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
-
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?
-
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
