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

VMware 6.7 VM not able to capture image using UEFI

Scheduled Pinned Locked Moved Solved
FOG Problems
3
6
773
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.
  • Q
    quinniedid
    last edited by Oct 9, 2018, 4:43 PM

    @george1421 @Sebastian-Roth I just wanted to see about tackling this issue again. Using the SATA controller for the VM hard disk is costing us a lot of time as it takes roughly 2 hours to capture an image. Where as the SCSI controller takes less then 20 minutes.

    This is in reference to an issue I posted about 10 months ago: https://forums.fogproject.org/topic/11179/vmware-6-5-vm-not-able-to-capture-image-using-efi-uefi

    FOG Version: 1.5.4
    bzImage: 4.18.3

    This is what I am seeing:

    0_1539103353660_d0a7f4a4-4933-4a38-b9b8-a409540635b4-image.png

    1 Reply Last reply Reply Quote 0
    • Q
      quinniedid
      last edited by quinniedid Nov 8, 2018, 4:12 PM Nov 8, 2018, 10:11 PM

      @george1421 @Sebastian-Roth I just discovered the solution to this issue.

      Back a while ago we had HP Z400 workstations that required us to put a global kernel argument of “ahci = off” as they would fail to deploy an image without it. The reason we made this global as it did not have an impact on any other devices and I would not have to specify it specifically on every workstation. The oddness of this all, when the VM was running in BIOS this was not an issue with capturing the image with the SCSI controller. When the VM was UEFI it would fail and would require us using the SATA controller which slowed capturing to be almost a 2 hour process. Removing this kernel argument now allows us to capture an image at full speed again using teh SCSI controller and it fixed a hang issue that occurred in the beginning that was also previously reported with the “can’t find IRQ”.

      All in all this is now fixed removing that kernel argument. I am just shocked that it would be affected differently between BIOS and UEFI specifically on a VM.

      Thanks for all your help.

      1 Reply Last reply Reply Quote 2
      • G
        george1421 Moderator
        last edited by Oct 9, 2018, 7:54 PM

        While this might sound counter intuitive, what happens if you roll the FOS kernel back to 4.15.2? Do you get similar results? I don’t have vmware 6.7 in my environment yet so I can’t compare results easily. But is your 6.7 release been updated since the GA release? It looks like a fully patched build base # should be 10176752.

        6.7 GA build base is 8169922.

        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!

        1 Reply Last reply Reply Quote 0
        • Q
          quinniedid
          last edited by Oct 9, 2018, 8:46 PM

          @george1421 I tried that kernel and it is doing the same thing. We are on Build 9433931. They have an update U1 out but our hardware vendor does not support it yet.

          1 Reply Last reply Reply Quote 0
          • S
            Sebastian Roth Moderator
            last edited by Oct 9, 2018, 9:40 PM

            @quinniedid In the picture we see a note about using kernel parameter pci=biosirq. Have you tried this yet? You can set kernel parameters for particular hosts in the host settings in the web UI.

            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
            • Q
              quinniedid
              last edited by Oct 10, 2018, 2:25 PM

              @Sebastian-Roth I have tried specifying that setting for the host in the kernel arguments and still continues to show the same message.

              1 Reply Last reply Reply Quote 0
              • Q
                quinniedid
                last edited by quinniedid Nov 8, 2018, 4:12 PM Nov 8, 2018, 10:11 PM

                @george1421 @Sebastian-Roth I just discovered the solution to this issue.

                Back a while ago we had HP Z400 workstations that required us to put a global kernel argument of “ahci = off” as they would fail to deploy an image without it. The reason we made this global as it did not have an impact on any other devices and I would not have to specify it specifically on every workstation. The oddness of this all, when the VM was running in BIOS this was not an issue with capturing the image with the SCSI controller. When the VM was UEFI it would fail and would require us using the SATA controller which slowed capturing to be almost a 2 hour process. Removing this kernel argument now allows us to capture an image at full speed again using teh SCSI controller and it fixed a hang issue that occurred in the beginning that was also previously reported with the “can’t find IRQ”.

                All in all this is now fixed removing that kernel argument. I am just shocked that it would be affected differently between BIOS and UEFI specifically on a VM.

                Thanks for all your help.

                1 Reply Last reply Reply Quote 2
                • 1 / 1
                • First post
                  Last post

                145

                Online

                12.0k

                Users

                17.3k

                Topics

                155.2k

                Posts
                Copyright © 2012-2024 FOG Project