• Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
  • Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

Legacy partimage images with FOG trunk

Scheduled Pinned Locked Moved
General
3
8
2.8k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S
    Sebastian Roth Moderator
    last edited by Sebastian Roth May 29, 2016, 2:51 PM May 29, 2016, 8:46 PM

    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.

    Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

    Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

    T 1 Reply Last reply May 30, 2016, 12:21 AM Reply Quote 2
    • T
      Tom Elliott @Sebastian Roth
      last edited by May 30, 2016, 12:21 AM

      @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.

      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

      Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

      Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

      1 Reply Last reply Reply Quote 0
      • W
        Wayne Workman
        last edited by Wayne Workman May 29, 2016, 7:53 PM May 30, 2016, 1:51 AM

        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.

        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
        Daily Clean Installation Results:
        https://fogtesting.fogproject.us/
        FOG Reporting:
        https://fog-external-reporting-results.fogproject.us/

        1 Reply Last reply Reply Quote 0
        • S
          Sebastian Roth Moderator
          last edited by May 30, 2016, 2:57 PM

          @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.

          Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

          Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

          W T 2 Replies Last reply May 30, 2016, 3:00 PM Reply Quote 1
          • W
            Wayne Workman @Sebastian Roth
            last edited by Wayne Workman May 30, 2016, 9:02 AM May 30, 2016, 3:00 PM

            @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.

            Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
            Daily Clean Installation Results:
            https://fogtesting.fogproject.us/
            FOG Reporting:
            https://fog-external-reporting-results.fogproject.us/

            1 Reply Last reply Reply Quote 0
            • T
              Tom Elliott @Sebastian Roth
              last edited by May 30, 2016, 3:02 PM

              @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.

              Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

              Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

              Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

              1 Reply Last reply Reply Quote 0
              • S
                Sebastian Roth Moderator
                last edited by May 30, 2016, 3:11 PM

                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?

                Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                W 1 Reply Last reply May 31, 2016, 12:49 PM Reply Quote 0
                • W
                  Wayne Workman @Sebastian Roth
                  last edited by May 31, 2016, 12:49 PM

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

                  Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
                  Daily Clean Installation Results:
                  https://fogtesting.fogproject.us/
                  FOG Reporting:
                  https://fog-external-reporting-results.fogproject.us/

                  1 Reply Last reply Reply Quote 0
                  • 1 / 1
                  1 / 1
                  • First post
                    6/8
                    Last post

                  199

                  Online

                  12.0k

                  Users

                  17.3k

                  Topics

                  155.2k

                  Posts
                  Copyright © 2012-2024 FOG Project