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

EFI Chainloading Failure - Venue 11 x86

Scheduled Pinned Locked Moved Unsolved FOG Problems
uefi
6 Posts 3 Posters 2.9k Views
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.
  • A
    amo862
    last edited by Feb 11, 2017, 7:59 PM

    Server
    • FOG Version: 1.3.4 (SVN Revision 6066)
    • OS: Ubuntu Server 14.04.5 x64
    Client
    • Service Version: N/A
    • OS: Win 8.1 x86
    Description

    Hi all,

    I’m having difficulty with getting my Venue 11 tablet to do any actions after loading the FOG iPXE menu.
    The boot process is fine and the menu loads up, but no matter what option I choose, or what action I schedule, I get a chainloading failure.

    I think the issue may be that this is a Dell Venue 11 5130 32-bit, but I’m finding that the bzimage32 and init_32.xz are not pulling down. I have all the Vendor Classes for x64 and x86 setup in my DHCP Server (Win Server 2012) as per the Wiki article.
    However I don’t really know what will tell the process to push the 32bit versions of the bzImage and init.xz files.

    I have tried using i386-efi/ipxe.efi and the i386-efi/snponly.efi, but saw no difference. I also tried using EXIT and REFIND_EFI exit options with no difference.

    I feel like I’m missing something simple.

    alt text

    W 1 Reply Last reply Feb 12, 2017, 2:40 PM Reply Quote 0
    • W
      Wayne Workman @amo862
      last edited by Feb 12, 2017, 2:40 PM

      @amo862 Try these files:
      ipxe7156.efi and i386-7156/ipxe.efi

      Which kernel that gets used is dynamic. If you look here in your web browser, replacing the Xs with your FOG Server’s IP address: x.x.x.x/fog/service/ipxe/boot.php You’ll see a line that looks like this near the top:

      cpuid --ext 29 && set arch x86_64 || set arch i386
      

      That’s what sets the arch parameter inside of the iPXE environment, it is what determines which kernel arch gets used - this is all automatic.

      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/

      A 1 Reply Last reply Feb 13, 2017, 6:17 PM Reply Quote 2
      • J
        JJ Fullmer Testers
        last edited by Feb 13, 2017, 5:29 PM

        you can also manually specify the kernel and init in the fog gui for that host

        Have you tried the FogApi powershell module? It's pretty cool IMHO
        https://github.com/darksidemilk/FogApi
        https://fogapi.readthedocs.io/en/latest/
        https://www.powershellgallery.com/packages/FogApi
        https://forums.fogproject.org/topic/12026/powershell-api-module

        1 Reply Last reply Reply Quote 0
        • A
          amo862 @Wayne Workman
          last edited by Feb 13, 2017, 6:17 PM

          @Wayne-Workman Thanks Wayne.
          Switching the path to i386-7156-efi/ipxe.efi or snponly.efi did not make a difference in the behavior.

          Understanding the way it decides to send the 32bit or 64bit boot files did help though. It continued to send the 64 bit files, which led to the chainloading failure. However, from within the ipxe shell, I manually loaded the bzImage32 and init_32.xz files and was able to get it to boot.
          (I used this command from the ipxe shell:)

          kernel http://[FOGServer]/fog/service/ipxe/bzImage32 loglevel=4 initrd=http://[FOGServer]/fog/service/ipxe/init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=[FOGServer]/fog/ consoleblank=0 rootfstype=ext4 loglevel=4
          imgfetch http://[FOGServer]/fog/service/ipxe/init_32.xz
          

          Following this, I specified the Host Kernel and Host Init options for that Host’s config, and I’ve now been able to start capturing an image.

          I think it boils down to the cpuid command, ultimately. This tablet is a Dell Venue 11 5130 (32bit), but has a 64bit processor. So only the 32bit boot files work, but cpuid determines its an x86_64 processor and loads the 64bit bzImage and init.xz.
          Since this is clearly an exception to the norm, I’m not too worried about it.

          However, is there a way that I could write a separate boot.php file that only called i386 boot files and specify it in the TFTP x86 efi files or DHCP boot options or something?

          J W 2 Replies Last reply Feb 13, 2017, 9:32 PM Reply Quote 0
          • J
            JJ Fullmer Testers @amo862
            last edited by Feb 13, 2017, 9:32 PM

            @amo862 While I’m sure it would be fun to make such custom code changes, I think you can just make a group for the venue tablets and similar devices that sets all devices in that group to load the 32bit kernel and inits. That’s what I would do personally.

            Have you tried the FogApi powershell module? It's pretty cool IMHO
            https://github.com/darksidemilk/FogApi
            https://fogapi.readthedocs.io/en/latest/
            https://www.powershellgallery.com/packages/FogApi
            https://forums.fogproject.org/topic/12026/powershell-api-module

            1 Reply Last reply Reply Quote 2
            • W
              Wayne Workman @amo862
              last edited by Feb 14, 2017, 12:40 AM

              @amo862 said in EFI Chainloading Failure - Venue 11 x86:

              However, is there a way that I could write a separate boot.php file that only called i386 boot files and specify it in the TFTP x86 efi files or DHCP boot options or something?

              Do what JJ Fulmer below said, that’s the best advice.

              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 1
              • 1 / 1
              1 / 1
              • First post
                3/6
                Last post

              170

              Online

              12.4k

              Users

              17.5k

              Topics

              156.0k

              Posts
              Copyright © 2012-2025 FOG Project