Last night I embarked on a project, I have been trying different UEFI boot methods listed on the arch wiki (under bootloaders) to attempt to get UEFI to work with Obarun. Now this is very much a work in progress and I haven't tried all options yet, this is just a general update. The install method I used was following the arch wiki (where appropriate and leaving out steps requiring systemd specific stuff) just replacing the pacstrap command with running the Obarun install script.

Grub does not work in any configuration I tried, it just loaded directly into the grub command line, I couldn't get it further, this has been where the bulk of my effort has been focused so far

rEFInd (for EFI stub) is my current project, it is showing more progress so far, however, the default configuration does not work, this is as far as I have gotten, it seems to be detecting some sort of backup or virtualization kernel image (I don't recall exactly as I'm not at my computer right now), my next step is to try manually pointing it at the kernel and see if that works

If I missed anything or you have any advice for me it is welcome

-conron
Hey conron,

when you refer to UEFI support, what do you refer to really? Booting without having legacy BIOS support enabled in your BIOS?
To start off it is recommended to format the disk with GPT instead of MBR when doing this for compatibility (or so says the Arch wiki).
UEFI boot requires a small separate partition for the EFI to boot from, also called ESP, see Arch wiki here.
The EFI spec calls for a FAT compatible formatted ESP but different systems use different formats (like Apple, see article).
(Fungal has mentioned that FAT could be a security issue, I don't know anything about this, maybe he can chime in on this).

This much I assume you have working.

Inside of that partition there has to be found any executable EFI application, which under Arch is usually called vmlinuz-linux.
On older Apple devices (way back with EFI 1.1 and 32-bit architecture) the EFI application to boot was called BOOTIA32.EFI as dictated by the EFI spec. The contemporary 64-bit variant of this would be BOOTX64.EFI.

So once you have your ESP with an EFI app inside it, ironically you would have to point your bootloader to that EFI app. The bootloader can be an application itself or the very same UEFI of your motherboard!
Usually the linux community uses GRUB. Quite some late linuxes offer SysV instead (like Obarun from the installer).
Instructions to use GRUB with UEFI can be found here and for SysV you should also refer to the Arch wiki, just that I couldn't find any direct mention of UEFI there right now. Just read it all up.

The latter, which I personally use and prefer is called EFISTUB. This uses no bootloader application at all, because guess what - your motherboard has a bootloader integrated. It's called EFI (or UEFI as of late).
You can make use of this by making direct entries to your motherboards boot menu (like when your MOBO says "Press F8 to select boot" and you get your USBs, disks and CDs all listed separately). A typcial program used for this is called efibootmgr.

The downside is that it's not dynamic, but hard coded. If you want to change a kernel parameter or some boot parameter, the root PARTUUID changed, or whatever else, you will have to rewrite the entry. You can make yourself a quick little bash script for this case though. (I could even share mine if you wanted to).

I am using this method to boot fast and reliable without issues for years. I hope this is a fine starter to get you into the right direction. Ask for anything more!
marianarlt
thanks for your insight!

yes, I am referring to booting without bios compatibility mode (since my motherboard doesn't have one). rEFInd as far as I have been able to determine is just a nifty UI and manager for doing EFISTUB (see Arch WIki ) the plan was to move on to doing efibootmgr if I couldn't get rEFInd working (thus moving from most convenient method to least from grub to rEFInd to EFISTUB). I do believe rEFInd solves the issue with it not being dynamic but I'm not sure (as I haven't gotten it working yet). If that doesn't work I'd certainly be interested in any advice you might have on booting EFISTUB.
Personally I don't see a use case for rEFInd or others unless you boot several different distros/OSes - which maybe don't support EFISTUB, because even then I'd just create different entries. You basically put a boot menu inside another boot menu.
rEFInd is able to boot legacy systems where EFISTUB is not. It's mostly used to use several operating systems alongside each other, like windows, osx and linux all together. Also I personally don't think it's most convenient to setup at all.
If we talk about convenience, every system I install, I say no to a bootloader, install efibootmgr and create an entry with a one-liner from cli. How convenient is that?!

Even right now I am running Obarun and Arch on a single disk with the same ESP and the same EFI application used (vmlinuz-linux, because Obarun is basically Arch) and just have two different boot entries in the motherboard.
(Details on this are not part of the simplicity of using EFISTUB, because I have to keep track of the kernel updates)

The only real downside of EFISTUB is that it simply cannot boot operating systems that are not EFI compatible. Like for instance Linux distributions which have the EFISTUB kernel option disabled by default. (You could still compile these with support though...)

No bootloader/manager is really dynamic. You will always have to set it up and write to config files when changing anything (like kernel parameters). That's not really dynamic to me in the first place. EFISTUB is as direct, basic and simple as it gets. No extra programs, no extra configs, no extra updates. Just your motherboard.
And really, once you have figured out your kernel parameters for your rig, you won't be changing anything anytime soon anyways. Create labels for your partitions and boot with kernel parameter root=LABEL=OBARUN (nice!). That's just for you not needing to remember or write down your root partitions PARTUUID or the like.

If you're concerned about messing something up and having an unbootable system, not even to a rescue shell, make yourself an obarun live USB with efibootmgr installed and if anything should go wrong: boot from that USB, chroot into your install and correct the EFI entry. This also makes you familiar with rescuing your system in general. Big advantage to be comfortable with chroot.
marianarlt

I guess I'm just stuck in the old way of doing things.

Anyway I did finish my experiments with refind and that didn't amount to much, so I tried your medthod of using efibootmgr, followed everything in the archwiki, (substituting my own name instead of arch linux and partUUID since I prefer UUID) and am still unable to get it to boot. As you seem to know more about efibootmgr than me I'm going to ask you for advice, I entered it exactly as in the wiki except for using the UEFI label Obarun and the partuuid of my drive (obtained using blkid) and whenever I try to boot it, it kicks me back to the UEFI menu

I'm at a loss on what to try next
I am of no help, I would never buy anything that mandates uefi, and I have only tried it on VM just to get the experience of being able to install such a thing.
The only thing I can deduce from reading and trying to learn from this experience is support for my crazy conspiracy theory of why they introduced this (hw-sw "secure boot") stupidity in the first place. I bet you can install debian, ubuntu, redhat, and manjaro and win10 in the same system easily.

Sorry for intruding
Fungal you're not intruding, I'd still like to know more about that theory of yours (probably others as well) :)
Also EFI inside of virtual machines (from my experiences which I tried several times) does not translate at all to a real UEFI experience. It's really quirky and weird and often for me just plain did not work as expected.
I actually don't really get the point. Isn't BIOS flagged as legacy anyways?! I mean, in some years from now you won't have no choice anyways when buying a new motherboard. Ain't that right?
If this was the case why not benefit from it's booting capacities. For years BIOS has been nagged upon for being outdated and whatnot. In the future if I wanted to buy a new motherboard, would you recommend to look out for then older boards which support BIOS? Or for then up to date boards that have legacy support and rather use BIOS instead of UEFI? Please explain! I wanna know! (I call for a new thread!)

@ conron
Let's see. What's your motherboard anyways? I find it strange that there already are boards without BIOS support.
Anyways: First thing I would suggest is do yourself a favor and not use IDs of any sort. IDs are usually recommended because the common practice for years was to go with /dev/sdx which is error prone for it refers to the ports on your motherboard. Apparently you can switch disks around between those. So root may suddenly become your backup drive when you upgrade your rig in the future or something similar which in return would fool around with your entries (may it be UEFI or /etc/fstab or whatever else).
I personally recommend to label your partitions and use those labels instead. This is human readable and you will never forget it, because it'll just literally translate to what your partition is used for... Also they will persist as long as you change them or reformat your disk. So no confusion when switching around your hardware. I find this true not for UEFI but for partitioning in general!

The flag to use when formatting depends a little on the format used:
# ext2/ext3/ext4 & jfs & XFS:
sudo mkfs.ext4 -L ROOT /dev/sda3

# ReiserFS:
sudo mkfs.reiserfs -l ROOT /dev/sda3

# exfat/vfat:
sudo mkfs.vfat -n ROOT /dev/sda3

# The label can be uppercase, lowercase or mixed. Choose one, stick with one.
Now for the actual EFI entry. I have read threads and posts about efibootmgr not working well with certain boards. I personally have not had any bad experiences. There are alternatives though. What matters is the resulting entry.

--disk /dev/sdx — Shorthand: -d — Has to point to the disk containing your ESP
--part x — Shorthand: -p — Has to point to the ESP partition on the containing disk
--create — Shorthand: -c — Literally creates the entry
--label "anything" — Shorthand: -L — This is what you will actually see in your motherboards boot menu as the entry
--loader /vmlinuz-linux — Shorthand: -l — Has to point to the EFI application to execute by the motherboards boot loader.
Notice: This is ESP root! Make sure that your EFI application can be found!
My recommendation is this when installing:
  • Make sure you booted your installation live system with UEFI (check for efivars)
  • Partition your disk as described in the obarun wiki
  • Format /dev/sda1 to be your ESP with something like: 'sudo mkfs.fat -F32 -n ESP /dev/sda1'.
  • After mounting your root partition (possibly /dev/sda3) to /mnt create /mnt/boot as described in the obarun wiki.
  • Mount the formatted ESP to /mnt/boot: 'sudo mount /dev/sda1 /mnt/boot'
  • Mount anything else as necessary and continue the install.
  • After the script finishes when it asks for a bootloader to install choose not to do so.
  • Finish the installation script and exit out of it
  • Temporarily install efibootmgr to the installation media if it's not on there yet
  • Do not chroot into your new install. Chroot has issues with recognizing efivarfs (even though you can get around that)
  • Create the EFI boot entry with efibootmgr from your running live system
--unicode "..." — Shorthand: -u — Anything inside of the brackets will be your kernel parameters.
Notice: The absolute minimum requirement for your system to boot are the following kernel parameters:
  • root — Points to your root partition. My tip if you already have the partition: 'sudo e2label /dev/sda3 ROOT'
  • rw/ro — Whether to mount your root partition read-write or read-only. Read-only is recommended for obarun
  • initrd — Points to your initial ramdisk image (use backslashes if you want to be EFI spec)
Make sure to get these three right. You can add more parameters according to your hardware needs. For testing purposes it may be a good idea to start with the minimum and add from there if all goes well. Easier to debug.


OMG SO COMPLICATED! [NOT]
Let's make a one liner out of all this:
sudo efibootmgr -d /dev/sda -p 1 -c -L "Obarun" -l /vmlinuz-linux -u "root=LABEL=ROOT ro initrd=\initramfs-linux.img"
This one line is all you ever need to create a new EFI boot menu entry!

After creation you may want to verify your entry with 'sudo efibootmgr -v' and also check that the BootOrder lists your entry number as the first; If it doesn't you can change the boot order with 'sudo efibootmgr -o 0000,0001,0002' etc; If you got anything wrong you can delete the entry with 'sudo efibootmgr -b 0000 -B' where lowercase b is the bootnumber containing your entry.

This I have to say: From here it can go quirky. My motherboard will not let me change the boot order with efibootmgr. I have to delete and create entries to order things (which I never do once it's set up...). But your entry will show up in your motherboards settings (what we actually know as BIOS) from now on. You can usually set boot priorities from there. Be aware that the settings menu and the boot menu is not the same (mine accesses the settings with DEL and the boot menu with F11).

Once everything is set up you won't have to actually go into your motherboards boot menu, it will always boot into the first boot entry or the one set from the settings. Which is your job to get done right ;)
From here on the boot menu F-Key will be your GRUB-panic-button. (You can even access a shell from there!)

Please don't hesitate to ask for more!
Marianarlt

I did just as your guide said the other night (I even formatted and started with a new partition table) and can report that it works on my motherboard, having compared your method to the one I was using two things become apparent that I was probably doing wrong.

A. I was indeed attempting to setup using a chroot, so I'll be investigating why that happens further in the future (but not now, and certainly not in this thread)

B. I wasn't mounting partition 1 to /boot as your guide stated but rather /boot/efi which I am 99.9% sure was the problem

Thanks for the help!
(also as you seem to be an expert at it have you considered asking for a portion of the wiki where you could outline how to install for UEFI? that was sort of the whole reason I even started this thread was to start working on getting a UEFI setup method reliable enough to be put into the wiki)
By no means am I an expert :P but I have my fair share of EFI experience. Lot of time invested; ask my wife >_>"
Actually the Wiki is open to everyone. If you wanted to, you could go ahead and write something in respect. That then could be redacted later maybe. I'm currently involved in several real life projects and don't have too much time on my hands. But I could start to write a guide like a few lines every day maybe. Let's see :D

Powered by Obarun