You are not logged in.
Pages: 1
Hi all,
I've been experimenting with some UEFI bootloaders, and was wondering if others have experienced the same outcomes / issues. This concerns a AMD-E1 Toshiba Satellite laptop (500GB GPT, secure boot disabled).
Gummiboot works like a charm, each time and every time. It seems like a pretty fantastic bootloader, especially for easy dual-booting. Really like this one.
Grub and rEFInd were completely different stories. Despite installing as per the instructions on the Arch wiki - and apparently without any errors - on /boot/efi, the result was an unbootable medium ("Reboot and Select proper Boot device or Insert Boot Media in selected Boot device and press a key").
For Grub in particular, tried to repair with efibootmgr on a few occasions (after reading some posts here about similar problems), such as:
efibootmgr --create --gpt --disk /dev/sda --part 2 --write-signature --label "Arch" --loader '\EFI\arch_grub\grubx64.efi'
/dev/sda2 was the UEFI partition (FAT32), and /dev/sda5 (ext4) was used for root and home.
An .efi entry was indeed located in the /boot/efi/EFI/arch_grub directory, but again, no bootable medium. Is this a common issue? I ask as I am curious if it may be something with the bootloaders, my hardware/firmware, my incompetence, or perhaps even the installation scripts provided; and of course if there could be potentially a lot of users out there with unbootable installations where using Grub, for example.
I'd like to try and work this out for myself, but other people's experiences would be very interesting (and helpful) to note.
Last edited by CarlD (2014-09-20 15:53:34)
Offline
You didn't mention what went wrong with rEFInd
I am using it and I like it very much, no issues so far.
GRUB for EFI ..well it seems to be a rather complicated thing so I never tried manually. I have a grub installation on my efi partition as a result from dualbooting ubuntu. Starting this grub via rEFInd works. Never tried it directly, though.
I put at button on it. Yes. I wish to press it, but I'm not sure what will happen if I do. (Gune | Titan A.E.)
Offline
You didn't mention what went wrong with rEFInd
I am using it and I like it very much, no issues so far.
GRUB for EFI ..well it seems to be a rather complicated thing so I never tried manually. I have a grub installation on my efi partition as a result from dualbooting ubuntu. Starting this grub via rEFInd works. Never tried it directly, though.
Oops - focused on Grub due to head-banging with it for a couple of hours last night! Identical outcome with rEFInd as with Grub: unbootable medium. Used the installation script:
refind-install
No errors reported.
Edit: tried with /boot and /boot/efi
Last edited by CarlD (2014-09-20 16:33:24)
Offline
Were is your efi system partition mounted? What are the contents of it?
"Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it."—Linus Torvalds
s/ftp/git/
https://iandouglasscott.com | https://github.org/ids1024 | https://keybase.io/ids1024
Offline
Well, I just tried rEFInd again. Mounted the UEFI partition to /boot:
# mkfs.vfat -F32 /dev/sda2
# mount /dev/sda2 /mnt/boot
And noticed the following error:
Installing rEFInd on Linux....
The ESP doesn't seem to be mounted! Trying to find it...
///boot doesn't seem to be on a VFAT file system. The ESP must be mounted at //boot or //boot/efi and it must be VFAT! Aborting...
How I missed that one last night I do not know. Same error when trying:
# mkfs.vfat /dev/sda2
# mount -t vfat /dev/sda2 /mnt/boot
This would explain the rEFInd issue, without poking into the re-formatted UEFI partition, it seems.
Edit: I'm not the only one: https://bbs.archlinux.org/viewtopic.php?pid=1453060
Last edited by CarlD (2014-09-20 16:57:34)
Offline
Refind-install wants the ESP mounted at /boot/efi.
sudo mkdir /boot/efi
sudo mount /dev/sda2 /boot/efi
"Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it."—Linus Torvalds
s/ftp/git/
https://iandouglasscott.com | https://github.org/ids1024 | https://keybase.io/ids1024
Offline
I will try that out, thank you, ids!
I managed to get grub working. Turns out it was indeed a firmware issue. Found this buried in the Archwiki grub article (tested and confirmed as working):
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, grub-install will claim efibootmgr has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at /boot/efi/ this will work:
mkdir /boot/efi/EFI/boot
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi
Offline
Figured out rEFInd:
1. UEFI partition MUST be mounted to /boot/efi for the script to work (rEFInd article was recently updated for this)
2. Same firmware issue on my system as with Grub: /boot/efi/EFI/refind/refind_x64.efi must be copied to /boot/efi/EFI/boot/bootx64.efi
The only issue is that there is an initial rEFInd screen that does not display the icons. It is also necessary to then select the refind_x64.efi option to go to the "proper" boot screen, where the icons are displayed correctly, and where it is actually possible to boot Arch.
Obviously some configuration is required here. I am thinking perhaps having the initial boot screen automatically go to the intended one...
edit: Copying over the refind.conf file into the /boot/efi/EFI/boot directory and setting the timeout to -1 results in the illusion that the system is going straight to the "real" rEFInd boot menu. Bit of an ugly workaround, but it works.
Would anyone object to me adding this stuff to the rEFInd wiki article?
edit 2: It is possible to edit the original refind.conf (/boot/efi/EFI/refind/) not to show the bootx64.efi stub created. Add this in the appropriate section:
dont_scan_files bootx64.efi
Last edited by CarlD (2014-09-21 18:45:13)
Offline
you could also copy the whole content of the refind folder to the folder where bootx64.efi is and not just the .efi file. Then refind should work correctly and you should see icons and be able to choose your boot entry.
EDIT: In your case this means installing refind not in /boot/efi/EFI/refind/ but in /boot/efi/EFI/boot/ and then rename refind_x64.efi to bootx64.efi
Last edited by dice (2014-09-22 14:47:50)
I put at button on it. Yes. I wish to press it, but I'm not sure what will happen if I do. (Gune | Titan A.E.)
Offline
you could also copy the whole content of the refind folder to the folder where bootx64.efi is and not just the .efi file. Then refind should work correctly and you should see icons and be able to choose your boot entry.
EDIT: In your case this means installing refind not in /boot/efi/EFI/refind/ but in /boot/efi/EFI/boot/ and then rename refind_x64.efi to bootx64.efi
Yes, another wiki contributor said much the same thing. I'm going to try this out, and once confirmed, will update the wiki entry. There is one burning question, which I do not have the hardware to test for:
Will installing to /boot/efi/EFI/boot/ also work for firmware where otherwise the default installation works? If so, then we have a potentially consistent installation method that will work on the broadest range of UEFI hardware possible. I imagine that would make life easier for a lot of Arch users!
Last edited by CarlD (2014-09-22 15:17:57)
Offline
OK, tried:
refind-install --usedefault /dev/sdxY
Which did indeed create a bootable bootx64.efi stub in the /boot/efi/EFI/boot directory. However, the result was a bootscreen with no bootable entries listed. Once the countdown ran out, it then booted into a second screen where Arch was listed. I found a mid-way workaround - suggest by dice - to get around this, which has been entered on the rEFInd Arch wiki page.
Thank you Dice - seems the UEFI bootloader experient has come to a successful conclusion. I'll make some further edits to the manual installation section of the rEFInd page to reflect this as well.
Last edited by CarlD (2014-09-22 22:10:22)
Offline
Refind-install wants the ESP mounted at /boot/efi.
sudo mkdir /boot/efi sudo mount /dev/sda2 /boot/efi
Gummiboot and maybe rEFInd should need to be mounted on /boot, else they should need to instruct which is the path to $esp/boot.
About grub, I rather drop the maintenance because of its complexity.
do it good first, it will be faster than do it twice the saint
Offline
Silverhammermba kindly came up with the solution to rEFInd, and has updated its wiki article, accordingly. So, in conclusion (at least on my hardware):
1. Gummiboot - No issues encountered
2. Grub - after a standard installation for UEFI, create a new boot directory, and copy across the efi-stub, renaming it in the process:
# mkdir $esp/EFI/boot
# cp $esp/EFI/grub/grubx64.efi $esp/EFI/boot/bootx64.efi
3. rEFInd - there is an alternative automated installation method (tested and works perfectly):
# refind-install --usedefault /dev/sdxY --alldrivers
Last edited by CarlD (2014-09-23 20:58:04)
Offline
It's my opinion that nowadays the BIOS does as boot loader and we can jump directly to kernel. About windows kernel I don't know if it is feasible.
do it good first, it will be faster than do it twice the saint
Offline
As some firmware isn't fussy about the name of the directory after $esp/EFI/ - nor apparently the name of the efi stub contained within it - then logically bootx64.efi in $esp/EFI/boot should work for them as well.
For example, the standard Grub UEFI installation command:
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug
Could possibly be changed to:
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=boot --recheck --debug
To install to $esp/EFI/boot rather than $esp/EFI/grub. All that would be required then is to rename the efi stub, which again - logically - should work for all firmware.
In respect to rEFInd, the standard automated installation method:
refind-install
Would be replaced with:
refind-install --usedefault /dev/sdxY --alldrivers
I am therefore wondering if we might have found an easier and more consistent method of installing UEFI bootloaders / managers? I've started a couple of discussions on the wiki (rEFInd and Grub discussion pages), and have asked elsewhere for those with UEFI hardware to test this theory out.
Offline
If I understand correctly this approach would make having multiple boot loaders installed much more difficult. If I installed for example refind with your method I would have the refind binary in $esp/EFI/boot named bootx64.efi. If I then install grub it would override this with grub.
Well in this case blindly following this procedure would be rather stupid, but a warning or such on the wiki would be good
I put at button on it. Yes. I wish to press it, but I'm not sure what will happen if I do. (Gune | Titan A.E.)
Offline
If I understand correctly this approach would make having multiple boot loaders installed much more difficult. If I installed for example refind with your method I would have the refind binary in $esp/EFI/boot named bootx64.efi. If I then install grub it would override this with grub.
Well in this case blindly following this procedure would be rather stupid, but a warning or such on the wiki would be good
No changes have been made yet, as this theory is yet to be tested.
MULTIPLE bootloaders?!
Offline
Yes. Some of us have multiple boot loaders. There was a time that EFI + Kernel updates would result in a non-booting system with one loader, but work fine with another. I have both Syslinux and rEFInd installed. I wouldn't make a change that would prevent multiple boot loaders, as that would eliminate choices and fallbacks.
Matt
"It is very difficult to educate the educated."
Offline
Yes. Some of us have multiple boot loaders. There was a time that EFI + Kernel updates would result in a non-booting system with one loader, but work fine with another. I have both Syslinux and rEFInd installed. I wouldn't make a change that would prevent multiple boot loaders, as that would eliminate choices and fallbacks.
Makes sense. Did a bit more research and $esp/EFI/boot/bootx64.efi is essentially recognised as the default bootloader on (apparently) most UEFI firmware, hence being most widely applicable. OK, not really my place to make recommendations on the wiki anyway, just to provide information...
Offline
bootx64.efi is the default searched, unless differently wrote onto NVRAM, I think.
do it good first, it will be faster than do it twice the saint
Offline
Pages: 1