I am using debootstrap to create a custom Xenial-based distro which can then be written to a secondary bootable drive from a host machine. (Target is an Intel NUC.) When I put the drive in the target PC and power on, the EFI recognizes the bootable drive but cannot boot it (it immediately returns to the EFI boot menu.)

So I don't believe I'm actually getting as far as grub launching. I'm guessing this is a grub install/config issue.

Relevant portion of my script:

local DISK=$1 # e.g. /dev/sdc
local ROOT_MOUNT=$(mktemp -d)

# create partitions and format
parted -s --align=minimal $DISK \
       mklabel gpt \
       mkpart ESP fat32 0% 513MiB \
       mkpart primary ext4 513MiB 100% \
       set 1 boot on
partprobe $DISK
sleep 1
mkfs.fat -F32 $EFI_PARTITION

# copy rootfs

# enter chroot and install grub
for dir in /dev /proc /sys /run; do
  mount --bind $dir $ROOT_MOUNT/$dir
mkdir $ROOT_MOUNT/boot/efi

chroot $ROOT_MOUNT <<EOF
/usr/sbin/grub-install --bootloader-id=ubuntu ${DISK}
/usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg

# generate fstab and additional customizations

# sync, unmount eject

I do see the correct partition UUID in the resulting grub.cfg.

Here's my partition details:

$ sudo parted /dev/sdb print
Model: ASMT 2115 (scsi)
Disk /dev/sdb: 64.0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name     Flags
 1      17.4kB  538MB   538MB   fat32        ESP      boot, esp
 2      538MB   64.0GB  63.5GB  ext4         primary

After I added shim-singed to my debootsrap includes, here's what I see in /boot/efi:

$ sudo tree efi
└── EFI
    └── ubuntu
        ├── grub.cfg
        ├── grubx64.efi
        ├── MokManager.efi
        └── shimx64.efi

After renaming EFI/ubuntu to EFI/BOOT and shimx64.efi to bootx64.efi I can boot from the drive! However I get a grub prompt... Guessing I'm down to grub config issues now.

I've been using these docs as my primary sources:

To be clear, I'm attempting to install a linux kernel/rootfs/bootloader to a drive connected to a host machine. That bootable drive is then put into a target machine and booted. This is not a dual-boot scenario.

Do I need to do something with efibootmgr on the target?

1 Answer 1


I suspect the issue is one of boot loader naming. Under EFI, a computer can boot in any number of ways:

  • From a hard disk -- In a normal OS installation, the boot loader resides on the hard disk's EFI System Partition (ESP), which is a FAT32 partition with a particular type code (C12A7328-F81F-11D2-BA4B-00A0C93EC93B; EF00 in gdisk; "boot flag" and "esp flag" set in parted, GParted, or related tools). The boot loader can be named anything, but is conventionally placed in a subdirectory of EFI named after the OS or boot loader. For Ubuntu, it's EFI/ubuntu/shimx64.efi, although this is actually a shim program that calls GRUB at EFI/ubuntu/grubx64.efi, and GRUB can be set to launch directly if Secure Boot is disabled. The computer knows which program to launch because that information is stored in NVRAM.
  • From a removable disk -- On a removable disk, including an OS installer or anything you want to move from one computer to another (as in your case), the rules are similar to a hard disk installation; however, because the NVRAM cannot be relied upon to hold the boot loader information, the boot loader is stored using a standardized filename, which is EFI/BOOT/bootx64.efi for x86-64/AMD64/X64 computers. This is often called the fallback filename. You'd put Shim in this filename and keep GRUB named grubx64.efi, but in the EFI/BOOT directory.
  • In miscellaneous other ways -- There are other boot methods, such as booting from a network or in BIOS/CSM/legacy mode. These aren't relevant to your question.

The Ubuntu installer is designed to install to a hard disk. If you want to install to a removable disk, you must either move/rename the boot loader files after the installation or install GRUB (or another boot loader) manually. You can do this by renaming EFI/ubuntu to EFI/BOOT and then renaming shimx64.efi within that directory to bootx64.efi, or by copying the files to achieve a similar effect. Alternatively, you can install another boot loader entirely, although this is likely to be a more tedious proposition, and it may create complications, particularly if you want to boot on computers with Secure Boot enabled.

  • Rod - thanks so much! I added to the OP what my /boot/efi/ dir tree looks like and it turns out I am missing the shimx64.efi - I may need to install the shim-signed package. I think I may also need to rename files to use the fallback bootloader as you described for a removable disk. Although the drive is not intended to be "removable," nothing in the UEFI NVRAM will have been set the first time the target device is powered on. Will report back once I try this.
    – thom_nic
    Oct 6, 2017 at 16:12
  • After installing shim-signed on the target and renaming EFI/ubuntu to EFI/BOOT and renaming shimx64 to bootx64 I can now boot to a grub prompt! Now to figure out grub config issues I guess...
    – thom_nic
    Oct 6, 2017 at 17:08
  • I see at least one issue... grub var $prefix is still using EFI/ubuntu - I probably need to grub-install --bootloader-id=BOOT
    – thom_nic
    Oct 6, 2017 at 17:24
  • re: my last comment, I realized that grub-install --removable creates the correct files without having to rename any files or dirs. In fact there was a set prefix=$(root)/EFI/ubuntu embedded in the grubx64.efi binary (visible when I called set from the grub cmdline) when I used --bootloader-id=BOOT. So it seems --removable is indeed the correct option to use in this case. I no longer get a grub console - I think grub/grub.cfg is being executed but now I no longer get a grub cmdline - I just get a blank screen! I think I'm further down to some root mount or kernel init issue?
    – thom_nic
    Oct 6, 2017 at 19:24
  • Actually it looks like I can get the grub menu, I can boot linux in recovery mode (it is painfully slow for some reason) but choosing the normal boot gives me nothing. So there must be some linux boot params that I have not gotten right. But my core question of "how to grub" is answered! Thank you!
    – thom_nic
    Oct 6, 2017 at 20:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.