0

I am using an ASUS N53J that is currently using MBR boot. I have enabled UEFI booting in the bios can can seem to boot USB drives that have been configured with gpt tables. Though I have not figured out how to make use of a dedicated EFI boot partition on the USB drive as yet.

Separately I have connected a second hdd to the laptop via the external SATA connection, created a gpt partition table, esp boot partition, and the filesystem and swap partitions.

When I run grub-mkconfig on the internal hdd, it finds the new linux image on the external hdd. I can boot to that external image and confirm that the esp boot partition gets mounted at /boot/efi, so it appears that I should be able to configure grub2. However, if I run grub-mkconfig when executing from the external drive, its own image does not get found, only the linux and windows images on the internal drive.

I also cannot get efibootmgr to run. The tutorials I have read either are not clear on both the how and the why so I can troubleshoot myself or use commands that I cannot find in the packages I think they are using. Does anyone have a good pointer on how to configure the disk before I install it as the primary boot disk?

Thanks.

Update 2015-12-30 I have progressed to making a USB drive that will at least boot into grub rescue. I do not know why grub won't run from this drive but it at least allows me to manually boot to my target OS. Since I have now booted via a UEFI boot efibootmgr is available.

I performed a new grub-install targeting the esp partition mounted at /boot/efi. This completed without errors. However, when I select the target system for booting the firmware loader stops at a blank screen. This occurs whether the disk is connected via ESATA or has been moved to be the primary disk in the machine.

the output of efibootmgr -v is:

BootCurrent: 0003
Timeout: 2 seconds
BootOrder: 0005,0002,0003,0004,0000,0001
Boot0000  Hard Drive    BBS(HD,,0x0)
Boot0001  CD/DVD Drive  BBS(CDROM,,0x0)P1: Slimtype BD  E  DS4E1S    .
Boot0002* ubuntu 15.10  HD(1,GPT,8b6800c2-0b24-4f00-aa66-b1378052604e,0x800,0xfa000)/File(\bootx64.efi)
Boot0003* grub  HD(2,GPT,b07e72fd-9168-4924-a17c-b75e55ed685c,0x800,0xfa000)/File(\Shellx64.efi)
Boot0004* UEFI: SanDisk Cruzer Micro 1.26   PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(2,0)/HD(2,GPT,b07e72fd-9168-4924-a17c-b75e55ed685c,0x800,0xfa000)
Boot0005* ubuntu15.10   HD(1,GPT,8b6800c2-0b24-4f00-aa66-b1378052604e,0x800,0xfa000)/File(\EFI\ubuntu15.10\grubx64.efi)

The desired target is Boot0005. Boot0002 is an experiment copying grubx64.efi to /boot/efi/bootx64.efi. Both Boot0002 and Boot0005 behave similarly.

Boot0003 (grub) is the USB drive and the only means to boot, though it only starts in grub rescue.

Any ideas where I should explore or what additional information may assist diagnosis?

More progress:

grub rescue> set  
prefix=(hd0,2)/boot/grub  ... This is the fat32-formatted esp boot partition  

grub rescue>ls (hd0,2)/  
unknown filesystem      ... or similar words to that effect

grub rescue>set prefix=(hd0,1)/boot/grub  ... ext4-formatted partition
grub rescue> insmod fat
grub rescue>ls (hd0,2)/
                    .... the directory is now read

setting the root to the target boot system and the prefix to the /boot/grub directory of that target system I can insmod linux search config file and normal. If normal does not start the boot option page the following will:

grub rescue>configfile /boot/grub/grub.cfg

I can eventually get the target to boot from the menu.

My synopsis is that grubx64.efi on the USB drive is not configured with the necessary modules for the boot method being used.

While efi-booted into my target filesystem I created a new USB drive, also with a gpt partition table, this time with esp boot as partition 1. I only mention that to assist with reading the bios boot table presented later.

mounting USB partition 2 to an appropriate node:

mkdir -p /boot/efi

mount (USB partition 1) to (USB partition 2)/boot/efi

grub-install --target=x86_64-efi --efi-directory=(USB partition 2)/boot/efi --removable

generates EFI/BOOT/BOOTx64.EFI. The UEFI: Sandisk entry in the bios boot table is the means to boot via this loader

grub-install --target=x86_64-efi --efi-directory=(USB partition2)/boot/efi --bootloader-id=USBboot

generates EFI/USBboot/grubx64.efi. The USBboot entry is also written int the bios boot table

cmp -v BOOT/BOOTx64.EFI USBboot/grubx64.efi yields no differences
either boot option now boots directly to the target filesystem without displaying any grub boot menu. Since the USB drive does not have a /boot/grub directory or a grub.cfg, grubx64.exe must be configured to search for this directory on the target rather than USB.

$ efibootmgr -v
BootOrder: 0007,0004,0005,0002,0003,0008,0000,0001
Boot0000  Hard Drive    BBS(HD,,0x0)
Boot0001  CD/DVD Drive  BBS(CDROM,,0x0)P1: Slimtype BD  E  DS4E1S    .
Boot0002* ubuntu 15.10  HD(1,GPT,8b6800c2-0b24-4f00-aa66-b1378052604e,0x800,0xfa000)/File(\bootx64.efi)
Boot0003* grub  HD(2,GPT,b07e72fd-9168-4924-a17c-b75e55ed685c,0x800,0xfa000)/File(\Shellx64.efi)
Boot0004* ubuntu_15_10  HD(1,GPT,8b6800c2-0b24-4f00-aa66-b1378052604e,0x800,0xfa000)/File(\EFI\ubuntu_15_10\grubx64.efi)
Boot0005* ubuntu15.10   HD(1,GPT,8b6800c2-0b24-4f00-aa66-b1378052604e,0x800,0xfa000)/File(\EFI\ubuntu15.10\grubx64.efi)
Boot0007* USBboot   HD(1,GPT,f887bf87-18a9-40e1-9bca-6c4bfd1cbb4a,0x800,0xc8000)/File(\EFI\USBboot\grubx64.efi)
Boot0008* UEFI: SanDisk PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(4,0)/HD(1,GPT,f887bf87-18a9-40e1-9bca-6c4bfd1cbb4a,0x800,0xc8000)

I still have not figured out how to even get to grub rescue without booting from the external USB drive. Is seems as though I have two problems:

  1. I don't fully understand how to configure grub for its intended use, how to make sure necessary modules are built in and the prefix is properly set.
  2. I either do not have the bios on the ASUS N53J properly configured or it is not accepting the hard disk configuration as a valid boot configuration.

Any other ideas? I now this is getting rather long. How can I document this to be more readable?

Status Update

Browsing on the web I have discovered grub-mkimage. I have not started working with this and will report progress once I have done so and can either understand the results or can pose a new question about it.

  • What errors do you get from running sudo efibootmgr? – ubfan1 Dec 29 '15 at 4:09
  • Grub only wants to install to sda. But if sda is a MBR(msdos) drive it has issues. And external drives in UEFI only boot from /EFI/Boot/bootx64.efi. So you have to make/rename grub to bootx64.efi. If grub not installed you may need to just directly install it from live installer. – oldfred Dec 29 '15 at 5:23
  • error is "EFI variables are not supported on this system". I gather that this means that the bootloader on /dev/sda loaded from the MBR and not an esp, which I'm pretty confident is what is happening. – mrh53 Dec 29 '15 at 12:29
  • I take renaming grub to mean the grub executable. Is this "grub.efi", which I currently find at /boot/efi/EFI/grub? For clarity, how is a drive connected to an ESATA port distinguished from the drive connected internally to SATA, other than the SATA port number? – mrh53 Dec 29 '15 at 12:38
  • Usually the signed grub executable is found in /boot/efi/EFI/ubuntu/grubx63.efi, but check its size against the "source" in /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed. Blank screen may be a video problem, if you have Nvidia then lots of things like nomodeset on the grub kernel line to try. – ubfan1 Dec 30 '15 at 22:25
0

After experimenting with other hdd's I have determined my problems appear to be related to the esp,boot partition on the original hdd. When I originally made the esp,boot partition I had accepted the default offset of 1 MB suggested by gparted. Through exploring why I could boot from USB drives and another hard drive connected via ESATA the common attribute on the successful media was the esp,boot partition being 1st on the drive and with 0 offset.

My attempt at moving the esp,boot partition was not successful. However, I did not check to make sure the UUID and PARTUUID were not modified so I do not know if this failure was due to the move not configuring the disk so the BIOS could figure out how to read it or if I failed by not re-configuring grub.

In any case, I learned how to: properly move the filesystem to new hdd configure the problem hdd from scratch. move the filesystem back modify /etc/fstab to reflect the new UUID's for mounted partitions the esp,boot partition had a copy of Shellx64.efi in its root directory

I then: reinstalled the hdd into the internal drive bay started the system in BIOS setup mode initiated Shellx64.efi from BIOS typed "c" to get to the grub prompt

grub> linux /vmlinuz root=/dev/sda2
grub> initrd /initrd.img
grub> boot

This started the filesystem (as it always would previously if I had a means to get to grub). This time when I grub-install and grub-mkconfig and reboot, the BIOS can read grubx64.efi from the proper location on esp,boot partition. Success!

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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