Better bootloader options for a UEFI based system?
I've been using GRUB for years and it's always worked fine for what I wanted to do (dual boot one install of linux and Windows on a BIOS based system.) However, with my new computer I've run into some issues managing my bootloader. I'm dealing with some issues related to a recent kernel upgrade, so I've been compiling a lot of kernels lately and switching between 3 distros plus a Windows 10 install. Every time I install a new kernel on a distro that doesn't "own" GRUB, I have to boot into the other distro and run 'sudo update-grub' to add it to the list.
I have heard about systemd-boot/gummiboot and rEFInd but I haven't been able to find much info about how they manage this. It would be ideal if my bootloader could either a. auto detect the kernels and generate a boot list on every startup, or b. at least be able to be updated from any linux OS I'm running so I don't have to boot into my other install and reboot again. Is anyone running these bootloaders? Is it worth it? |
A lot depends on whether your UEFI gives you a nice boot menu. If it does, you don't need rEFind. You might not even need grub. Linux kernels are self-booting in UEFI if you put them on the efi system partition and have efi stubs set.
Here's something I found on the Arch wiki. |
Guess you could chain load and put each loader in with each distro.
There have been all sorts of multiboot manangers but haven't seen but a few for uefi. As I understand it you could create a special uefi setting for your system. I suspect that will be next big thing if uefi ever gets settled. |
My laptop does give a basic menu for EFI booting, but I sometimes like to mess with kernel parameters, etc. so I would really like to go with a proper bootloader that's designed for linux. If I went with rEFInd, it will only automatically find the kernels if I keep them all in the EFI system partition then? If so, would I have to add something to /etc/kernel/postinst.d/ to automatically copy them there? And, currently, that partition on my computer is only 200MB, so I assume I would have to expand it a lot. Will Windows 10 freak out if I do that?
|
who needs chainloding or customization of bootloder in a uefi-bios? you can just simply boot the partition from bios...simple as that
|
Quote:
I have a dual boot Centos 7/ Fedora 24 system. The Centos 7 grub loads the config file of the Fedora 24 installation. In /etc/grub.d/40-custom Code:
menuentry "Fedora 24 using grub2 configfile" { Your maintenance problem could be solved in an hour or so. You don't need a better bootloader at all. You just need to understand and use the power of the one you are already using. |
Quote:
chainloding -> chainloading bootloder -> bootloader uefi-bios -> UEFI firmware, if you have UEFI firmware you don't have a BIOS Who the hell would want to go into their firmware every time they wanted to boot a different OS ? Lazy but not simple as it gets quite tiring. |
Quote:
I personally tried rEFInd and configured it manually so that I can control the number of icons displayed per system and the boot options, etc. You can try it if you wish and see for yourself. This is the advantage of UEFI. You have a large enough EFI partition and you can experiment with many bootloaders and boot managers. So check these out: http://www.rodsbooks.com/refind/ https://docs.slackware.com/howtos:sl...d_on_slackware |
Quote:
I have a EFI system that has Win10 on MBR and (several) Linux on gpt. Cannot be accessed from the same menu. Period. |
I use rEFind, but as aragorn2101 posted it can get messy.
|
Quote:
If I understand the issue correctly it is in order to boot Win10 on MBR the UEFI firmware must be in CSM mode during which it can't recognize GPT partitions. Having a Linux bootloader on the same MBR disk will solve this problem. The top level menu possibly created with BCDEdit will have two options, Win 10 and Linux Grub2. Once Grub2 is loaded in memory and running it controls the hardware. It has modules for GPT partitions and extn filesystems among many other things. The capabilities of the firmware wouldn't matter at this point. You would manually create 5-6 line targets as I have shown by using the filesystem UUIDs of the /boot or / root partitions of the various Linux installations on the GPT disk and load their config files using the configfile command . You would only need to create about 50 MB of space on the MBR disk as there wouldn't be any kernels or initrds on this dedicated Grub2 partition, just the Grub2 system and the config file. I would create two partitions, one small 1 MiB and one about 50MiB. The small one may be needed for the grub2 core.img second stage. |
Thank you tofino_surfer for the detailed answers. I did end up trying rEFInd, but I'm not entirely sure I like it enough to replace GRUB. It automatically found all my kernels in their respective partitions which was nice though. I will probably keep it as #2 in efibootmgr in case I irreparably mess up GRUB, then I can still boot into rEFInd from my UEFI menu. I was able to get the custom entries working (I'll post about that shortly) but I have another question about the long term feasibility of this setup.
Originally, my Mint install was in charge of GRUB. Then I installed rEFInd and messed around with that. A few days ago I installed updates in Xubuntu and GRUB updated. Xubuntu's GRUB took over the bootloader AND put itself in front of rEFInd in the efibootmgr list. So:
|
Ok, here's what I did in case it helps anyone. This is the annotated output of sudo blkid on my system. /dev/sdb is all my operating systems and ESP, and /dev/sda is swap and data.
Code:
Data Here's what I added to /etc/grub.d/40-custom. I had to copy the various hints from the autogenerated entries from os-prober (in Xubuntu's /boot/grub/grub.cfg file) to get it to work. I don't really know why, but I'm sure the reasons will be demystified after I check out the GRUB manual. It seems weird to me that this works with "insmod ext2" when they are all ext4 partitions, but at least it works. Fedora keeps its grub.cfg in the EFI system partition instead of its /boot directory for some annoying reason. Luckily I had the example from the Windows 10 entry where it mounts the ESP, so I modeled it after that. Note that the Win10 entry is a chainloader to the actual Windows bootloader. Code:
menuentry "Linux Mint config" { |
Quote:
All GPT formatted drives have a protective MBR to prevent older tools from seeing the drive as empty. The first 440 bytes of this protective MBR can be used to point to the second stage of a legacy BIOS bootloader. This can even be done even if there is an ESP partition as well. There is no problem having both UEFI and legacy BIOS bootloaders on the same disk. In fact all newer live ISOs are dual mode. They have both an /EFI directory for UEFI systems and typically use syslinux (isolinux) for supporting legacy BIOS systems. The major difference between BIOS/GPT and BIOS/MBR is that with BIOS/GPT a 1 MiB partition called a BIOS Boot partition is required as a place for the core.img grub2 second stage. This is due to the fact that there is no "MBR gap" in which to place the core.img grub2 second stage with GPT formatting. However this requirement makes it easier to set up multi-boot systems than with MBR partitions. Therefore since you can install legacy BIOS bootloaders on GPT formatted disks if you had a Win10 installation on an MBR disk they should both be visible in legacy CSM mode. |
Quote:
Quote:
If the Mint installation was also installed in directory ubuntu this could have happened. If this is happening you may need to create unique subdirectories manually and copy files. Quote:
The original grub now called grub-legacy only supported reading ext2. Grub2 supports ext[234]. |
All times are GMT -5. The time now is 05:00 AM. |