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

    FOG fails to handle odd-sized Windows 7 boot partitions properly

    Scheduled Pinned Locked Moved Solved
    Bug Reports
    2
    4
    2.3k
    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.
    • D
      Dave_A
      last edited by

      [B]Background:[/B]

      The organization I work for has a standard image, but deploys it manually in most locations (by taking PCs to an ‘Imaging Center’ within the .org). My project-team set up FOG for use with our systems, and uploaded a PC with the existing master up-and-running on it…

      The machine we are uploading from is configured as follows:
      Windows 7 Enterprise
      350MB B[/B] Windows 7 Boot Partition
      250GB Windows System partition.

      Collected via [B]‘Single Disk, Resizable (NTFS Only)’[/B]

      FOG collected the image properly but fails to restore it. On boot we see ‘Missing Operating System’

      An analysis of the restore errors indicates that the ‘size’ of the boot partition appears to be hard-coded in the FOG restore process. On restore, there is a ‘partition to be restored is larger than on disk’ error…

      Specifically, it seems that no matter what the size of the original boot partition, FOG always tries to cram it into 105MB.

      I don’t know if no one considered that some Windows installs would use different sizes, but it is-what-it-is…

      [B]Suggested fix:[/B]
      Get rid of the hard-coding, and save the original size of the boot partition in the image data - then restore it at the exact same size that it originally was.

      1 Reply Last reply Reply Quote 0
      • Tom ElliottT
        Tom Elliott
        last edited by

        [quote=“Dave_A, post: 30250, member: 24638”][B]Background:[/B]

        The organization I work for has a standard image, but deploys it manually in most locations (by taking PCs to an ‘Imaging Center’ within the .org). My project-team set up FOG for use with our systems, and uploaded a PC with the existing master up-and-running on it…

        The machine we are uploading from is configured as follows:
        Windows 7 Enterprise
        350MB B[/B] Windows 7 Boot Partition
        250GB Windows System partition.

        Collected via [B]‘Single Disk, Resizable (NTFS Only)’[/B]

        FOG collected the image properly but fails to restore it. On boot we see ‘Missing Operating System’

        An analysis of the restore errors indicates that the ‘size’ of the boot partition appears to be hard-coded in the FOG restore process. On restore, there is a ‘partition to be restored is larger than on disk’ error…

        Specifically, it seems that no matter what the size of the original boot partition, FOG always tries to cram it into 105MB.

        I don’t know if no one considered that some Windows installs would use different sizes, but it is-what-it-is…

        [B]Suggested fix:[/B]
        Get rid of the hard-coding, and save the original size of the boot partition in the image data - then restore it at the exact same size that it originally was.[/quote]

        While I understand your problem, there is no real nice way to make this a fix. The reason you’re having issues is pretty much as you suspect. We are hardcoding the partitions on resizable images.

        That being said, this is exactly what the Multi-part imaging types are designed for.

        While they’re not resizable, persay, so long as the hdd the image is created on is smaller or exactly the same size as the prospective receiving system there should be no issues.

        EDIT:

        To add to this, the hardcoded information is based on a fresh base install from windows. It doesn’t take considerations of custom boot partitions and the like.

        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
        • D
          Dave_A
          last edited by

          Wouldn’t it be possible to add a step to the image-collection process, that grabs the partition map of the source via Linux fdisk or parted, and pushes it up as a text file with sys & rec images - then pull down and parse that file in the restore part of the script, to recreate the original map??

          1 Reply Last reply Reply Quote 0
          • Tom ElliottT
            Tom Elliott
            last edited by

            [quote=“Dave_A, post: 30281, member: 24638”]Wouldn’t it be possible to add a step to the image-collection process, that grabs the partition map of the source via Linux fdisk or parted, and pushes it up as a text file with sys & rec images - then pull down and parse that file in the restore part of the script, to recreate the original map??[/quote]

            Yes, that’s very possible. The problem is, the mbr is what determines the size of the disk, so after “re-mapping” the drive with the MBR data, it would be limited to the size of the original disk, which leads to the same thing you have with multi-part 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
            • 1 / 1
            • First post
              Last post

            174

            Online

            12.0k

            Users

            17.3k

            Topics

            155.2k

            Posts
            Copyright © 2012-2024 FOG Project