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

UEFI Imaging with Debian 10 on Intel NUCs

Scheduled Pinned Locked Moved
FOG Problems
3
6
844
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
    sloeckle
    last edited by Jul 28, 2020, 12:24 PM

    Hi Everyone,

    I’ve spent quite a bit of time searching about UEFI imaging. I’ve read that it works great, it doesn’t work great, it works with Windows, it does or doesn’t work with Linux. I can’t seem to find any definitive answers.

    We’ve been imaging our NUCs for a few years now with fog and BIOS boot. We must migrate to UEFI for a new large client (5000 existing NUCs) we just got. We must remove windows from these NUCs and install Linux. I’ve successfully reinstalled Debian 10 using UEFI and captured an image. When I deploy the image on other NUCs, there’s not a single error but the device can’t find an operating system after reboot. I’ve even taken successfully imaged SSD drives from the master machine that boot in the master machine and put them in other devices and that SSD doesn’t boot in another device.

    What am I missing and how do I solve this?

    Thanks,

    Stephen

    1 Reply Last reply Reply Quote 0
    • T
      Tom Elliott
      last edited by Jul 28, 2020, 12:26 PM

      UEFI booting doesn’t Magically, typically, detect the Boot partition.

      UEFI uses NVRAM space to store the boot location.

      Essentially, once you image the machine, you’ll need to tell the BIOS to look at the Hard Drive and select the boot file as appropriate.

      Once you do that, I’ll bet you’ll have success with booting the machines.

      This isn’t a FOG problem, persay.

      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
      • G
        george1421 Moderator
        last edited by Jul 28, 2020, 12:50 PM

        In my experience if the UEFI firmware can see the boot partition it will list it in the uefi boot manager.

        So if on partition 1 /efi/boot directory it finds the boot loader it will put that disk as bootable.

        So I wonder how your original disk layout is created. Did it use LVM or are the partitions standard partitions? I would recommend regular partitions with the first partition as the efi boot partition.

        On your Debian reference image, from a linux command prompt what do you get when you key in fdisk -l /dev/sda If that throws an error look for the disk name in lsblk command then run the fdisk command.

        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!

        S 1 Reply Last reply Jul 29, 2020, 2:43 AM Reply Quote 0
        • S
          sloeckle @george1421
          last edited by Jul 29, 2020, 2:43 AM

          @george1421 Here ya go plus some additional info:

          root@NUC:~# efibootmgr
          BootCurrent: 0003
          Timeout: 1 seconds
          BootOrder: 0001,0002,0003,0000
          Boot0000* Windows Boot Manager
          Boot0001* UEFI : LAN : IP6 Intel® Ethernet Connection (3) I218-LM
          Boot0002* UEFI : LAN : IP4 Intel® Ethernet Connection (3) I218-LM
          Boot0003* UEFI : Built-in EFI Shell

          root@NUC:~# fdisk -l /dev/sda
          Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
          Disk model: INTEL SSDSCKJW12
          Units: sectors of 1 * 512 = 512 bytes
          Sector size (logical/physical): 512 bytes / 512 bytes
          I/O size (minimum/optimal): 512 bytes / 512 bytes
          Disklabel type: gpt
          Disk identifier: AE7EA9CB-3ECD-429B-AA65-D73F45898212

          Device Start End Sectors Size Type
          /dev/sda1 2048 1050623 1048576 512M EFI System
          /dev/sda2 1050624 234441215 233390592 111.3G Linux filesystem
          root@NUC:~#

          Oddly, Windows has never been on this drive. It’s not detecting debian nor is it showing up in the boot order list either in the BIOS or when pressing F10 for the boot menu. However, I was able to boot this device by going into the EFI shell and running grubx64.efi from /EFI/debian on /dev/sda1.

          One note, this image was created on a nmve ssd. It has never caused a problem switching between nmve and non-nmve drives before and doesn’t change anything when imaging but I thought I’d throw that out there.

          1 Reply Last reply Reply Quote 0
          • S
            sloeckle
            last edited by Jul 29, 2020, 3:40 AM

            @Tom-Elliott @george1421

            I may have solved this. More reading, specifically on Debian’s site concerning manually adding (thanks Tom) a new boot entry (adding details for anyone else needing this) with:

            efibootmgr -c -d /dev/sda -p 1 -w -L debian -l ‘\EFI\debian\grubx64.efi’

            then I deleted the old Windows boot entry (still don’t know how it got there) with:

            efibootmgr -B -b 0000

            Any advice for automatically detecting the EFI partition path in the post.download scripts so I can dynamically set EFI entries after imaging? Querying the list and cleaning it up automatically is straight forward.

            With all this, I’m a little lost as to how I’d image a drive and move it to another computer without considerable expertise. The original plan was to image drives, ship them to remote sites and have someone less-technical swap them out. Is this even possible? I suppose we could run efibootmgr remotely before swapping out the drives. Sorry, thinking out loud.

            Thank you both for the pointers.

            Stephen

            G 1 Reply Last reply Jul 29, 2020, 11:48 AM Reply Quote 0
            • G
              george1421 Moderator @sloeckle
              last edited by george1421 Jul 29, 2020, 5:49 AM Jul 29, 2020, 11:48 AM

              @sloeckle Well I can tell you that FOG doesn’t change any settings in the uefi menu, so that windows entry is probably from a previous install on that computer.

              Now to your question about post download scripts. I have a tutorial that can be the starting point of your task.

              The starting point could be here: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

              If you start looking in this section of the post fog.custominstall

              In the code you will see that I key off the $osdi field. In this case I check to see if its one of the windows platforms. In your case you can use the same overall code flow/outline but switch case the linux code of 50. If you look a bit deeper into what is going on in the windows section we loop through the different disk partitions on the disk looking for the /Windows directory on the partition. If its found then we exit the loop with the proper partition number.

              In your case you will loop through the partitions looking for /EFI or /efi If you find that directory (you could even be a bit more specific like /efi/boot then you know what partition number the efi partition is. Yo u could also look at the partitions by the partition type but that could be a bit misleading because not every uefi partition is of type efi. Searching for the boot file path may be a bit more universal. For uefi the path don’t change. You just need to be mindful of the case.

              Once you have the identified partition then you can do the magic with the efibootmgr. You could be blindfully trusting and just replace the value in boot order 0000 or do a bit more coding to identify the values you don’t want to purge, or just insert your linux boot manager always at position 0 and set it to default. That will push all of the other entries down one position. I think that may be a messy approach especially if you reimage that target computer a number of times, but it would get the job done.

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

              158

              Online

              12.0k

              Users

              17.3k

              Topics

              155.2k

              Posts
              Copyright © 2012-2024 FOG Project