Copy images from dead 1.2.0 server to new 1.4.0 server

[ECRTechZ]

Server

• FOG Version: 1.4.0
• OS: Ubuntu 16.04 LTS

Client

• Service Version: N/a
• OS: N/a

Description

I am working on a FOG server for a client. They had a Ubuntu FOG 1.2.0 (upgraded from version .35 I believe) virtual machine that has an OS problem that so far has been irreparable. Rather than continue banging my head against it, I though making a new server would be easier. I created a server with the the specs above, and it is running fine. I was able to attach the VHD file of the old server to the new one, and copy over all the images from the old server. My question is, is there a good way to make the new fog server recognize the old images by just having the image files? To be clear, the old server is not operational in any way. Theoretically I should have the old database on the VHD with the images, but I have no clue if I could export that database given that I’m not on the same server it was running on, and that I know have another database running.

All help appreciated!

[george1421]

@ECRTechZ How many images are you talking about?

Either way if you can’t access the database, exporting the image records will be not possible.

In regards to FOG and images, there are two parts. The raw disk images are stored in /images/<image_name> on the FOG server hard drive. The second bit is the image metadata stored in the database. You should be able to reconstruct the image name from the directory path on the old hard drive. If the customer was smart they would have embedded a bit about the image in the image name, i.e. Win7SP1OEM. That would tell you what OS the image was in.

The fields that are going to trip you up are Image Type and Image Manager

The image type defines how the image was captured. Raw, Single disk resizable, multiple disk resizable.

The image manager tell the FOS engine what image cloning tool to use. For images that came from 0.3x days then its PartImage. For the 1.2.0 it could be PartImage or more probably PartClone. You can disregard the zstd images because that is something new in 1.3.5 and later.

I see that you deployed FOG 1.4.0. The latest release is 1.4.2 and maybe worth the upgrade. If you had FOG 1.4.1 then I would say for sure upgrade. There was a bug in the new install version of 1.4.1 that caused a client check-in issue, that was resolved in 1.4.2.

FWIW, I think your client will be much better off with the setup you are proposing now than trying to resurrect FOG 1.2.0. The newer version of FOG are much faster and have more abilities than FOG 1.2.0 ever dreamed. Plus FOG 1.3.x and newer support Win10, GPT format, NVMe drives, UEFI firmware and much newer hardware than 1.2.0. Its a good move all the way around.

[ECRTechZ]

@george1421 We are looking at 8 images, though some may not need to be transferred. I am able to recreate their path’s in /image/ and they do have descriptive names so I know the operating system. The problem to me is that when I look at the images in the FOG web interface, they say “No valid data”. Is this a symptom of having the wrong image manager or image type?

[george1421]

@ECRTechZ Just be aware that the bit size and capture date is only populated at the time of image capture. If you migrate the files from another server this count and date will be nil. That is normal.

I think the developers were working on an agent to scan the image store and update the image size in the web gui. I’m not sure where that was in the development timeline. But for now if the byte count is zero for migrated images that is normal.

[ECRTechZ]

@george1421 Excellent! I’m glad to hear it. Saves me a couple hours of creating images. However, given I do not have the original settings for the images. Do I have to just guess what the Image Manager and the Image Type were? Or is there a good way to tell?

[Tom Elliott]

@george1421 The “image size” service has been implemented for a while now, but it only works in regards to “Size on server”, not the size the disk needs to contain.

[george1421]

@ECRTechZ AFAIK There isn’t a solid way to tell. If the original file dates are before FOG 1.2.0 was released then its probably a PartImage format. If after 1.2.0 was released then maybe a partclone as the first test.

The developers may know by looking at the names of the files in each directory. But its probably going to be a long day testing to find just the right mix.

You may be able to move the database files to the new server and mount them with mysql. I’ve never done it this way, but it may be possible to get at the image data.

[Tom Elliott]

@ECRTechZ For 1.2.0, images captured during it will be simply “partclone gzip”. The “split” file system should also work due to how it builds the data structure. That said, while knowing the image manager is important, the feature to change the manager didn’t arrive until later on in the 1.3.x series. Specifically it was including with 1.3.5. This feature is more towards telling the server how to capture the image (though is used to help with deploying the image.) If you migrate your images over, more than likely the “defaults” during the definition creation will be fine.

[george1421]

@Tom-Elliott said in Copy images from dead 1.2.0 server to new 1.4.0 server:

The “image size” service has been implemented for a while now

Well I wonder where I’ve been all this time Well done!!

[ECRTechZ]

@Tom-Elliott @george1421 Alright, I’ll just copy the images over and see if they work with the defaults (Given the technician before me, and knowledge of the company I imagine most of them are). Both of you were a great help!

[Wayne Workman]

@ECRTechZ This is probably what you’re looking for: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

[ECRTechZ]

@Wayne-Workman The problem with those articles is that they assume the old server is accessible. In my case, it’s dead. I recovered the images and manually created their image definitions in the new server. I’m just hoping they are the defaults. Looking at the files they seem to be though. The only other thing I can think to do is do what @george1421 said and try to mount the old database in the new server and export it, as I have the old servers database. I’m going to try to image a computer using my manually created definitions this week and hope it works.

Thanks for the help!

[Wayne Workman]

@ECRTechZ said in Copy images from dead 1.2.0 server to new 1.4.0 server:

The problem with those articles is that they assume the old server is accessible.

The guide only requires that ssh is accessible. The web interface can be nonfunctional. If you don’t have ssh, then yeah the only thing to do is mount the disk on another box as you’ve done and just copy the needed things from it.