Legacy partimage images with FOG trunk

[Sebastian Roth]

Back in the old days FOG did not capture the MBR (now in d1.mbr) and partition table (d1.partitions) information when uploading an image from a client. So even today FOG trunk needs to do assumptions on start sector, partition size and layout. This is mostly working if people have a standard windows setup but can also fail which is very hard and time consuming to debug. Read through this if you are interested. And I am sure there are other posts on failing legacy images.

Trying to improve legacy partimage compatibility my first attempt was to extract the start sector from the rec.img.000 file and patch the MBR on the fly after deploying the default MBR file (e.g. win7.mbr), which we ship with FOG.
After playing with this for a bit and trying it out it seemed rather sketchy to me. Plus this would be something we need to do on every deploy with those legacy images. So I had the idea to extract the information and build the MBR and partition layout files via a script that people can run on their server. It would search through all the images and simply add d1.mbr and d1.partitions in case those files are missing.

This idea has been around for a good week and I talked to Tom about it already. So today I got myself together and started working on it. Extracting the information from rec.img.000 is not too hard. But as I was digging through this file I discovered that partimage includes the original MBR into rec.img.000 on capture. Surprise! I am sure the old FOG gang knew this long before I stumbled upon it. Nevermind.

So what does this mean? I found partimage to have a restmbr (restore MBR) mode/command. Using this we should be able to write the original MBR from the partimage file and don’t need to do any assumptions on start sectors and partition layout. But wait - there are two issues with that:

• partimage restmbr command seems to not want to accept destination device as command line parameter yet (I was only able to restore via ncurses GUI) - guess we can come up with a patch for that
• resizable image type is another story if we take this route - I am sure we can figure this out but I haven’t had enough time to think it all through yet

Just wanted to get this out to you guys before I spent more time on this. Possibly you think this is all crap and that we shouldn’t bother about all that legacy stuff anyway. Open for discussion! Please let me know what you think of it.

[Tom Elliott]

@Sebastian-Roth I like it. I didn’t know about the restmbr or that partimage maintained a portion of the original MBR in the boot file. If this is relatively simple to get (I imagine we could do a stdin to enact on the ncurses side if needed) it would, I think, help all those with old/old images.

[Wayne Workman]

I don’t think it’s worth the time.

People should plan to deploy all their legacy images to machines, update their server, then recapture.

Or - we can build a custom task for fog to Convert images. Use source from .32 and fog trunk to restore and capture again all at once. On a computer or even a secondary HDD on the fog server itself to keep it all fast and local. Not one at a time either. All of the old images back to back. Convert all of them at once.

[Sebastian Roth]

@Wayne-Workman said:

I don’t think it’s worth the time.

While I like your idea of converting all the legacy images on the server (deploy on a local disk and re-capture) I think this would be a lot more work to setup properly and integrate into FOG trunk! AFAIK it’s way easier to take what’s already there (the MBR in rec.img.000) and make those legacy image work as if they were normal ones.

Sure the best would be that all the people re-capture all those old images but if we want to be nice to all those people using FOG since a long time we better try to make it as comfortable for them as possible I reckon.

[Wayne Workman]

@Sebastian-Roth I’m not sure how much harder it would be. If using an internal secondary HDD on the server, you’re already in a full Linux OS. There is no need for the inits at that point, just the upload and download scripts I think. Even those could be greatly simplified since NFS wouldn’t be needed.

I have some spare drives laying around I could mess with.

[Tom Elliott]

@Sebastian-Roth I second this as well. I do recommend everybody update their images for the best experience but I know this is not always feasible. One of the things I think make fog so great is it doesn’t,typically, require a severe change on the users part to maintain and work with newer versions of fog with older files.

FOG 2.0 when it comes may lose some of the compatibility due to extreme nature and amount of changes, but this will be more due to how the system is changing. The 1.0.0 release was a major rewrite but it also kept methods of compatibility due to the init structure not really changing overly much. 2.0 is essentially a rewrite from scratch thing so some of the compatibility will be lost.

[Sebastian Roth]

What I was actually trying to say with my last post is that I think it’d be wise to make moving from FOG 0.32 to trunk as easy as possible so people don’t have a lot of work to do when moving to trunk. This way old 0.32 installations might die out a little faster, making support live a bit easier…

@Wayne-Workman I might see this from a wrong perspective but to me this looks way more complicated than extracting the MBR from the image file. Could you please post a list of commands and descriptions (all untested!) of what needs to be done to achieve what you have in mind?

[Wayne Workman]

@Sebastian-Roth Sure. Marking this un-read so I can come back later.