So Eric asked me the other day if I had ideas about how to integrate options to the installer to provide auto install for UEFI.

Things the installer cannot provide:
- The user having fully understood the requirements and prepared a partitioning layout and table necessary to boot this way.

Things the installer could provide:
- Either an option somewhere whether to install for UEFI or BIOS which in return would influence the options of bootloaders when prompted - or when prompted for the bootloader the option to install either for BIOS or UEFI. I personally think that the first approach is less invasive to users who don't care.
- The choice between either GRUB or EFISTUB.
- The automatic execution of the necessary commands (GRUB x 2; EFISTUB x 1)

It would be a nice user experience if the script could automatically detect the setup and decide, but due to mixed layouts this is not possible. People can prepare a MBR table but use UEFI or make a GPT table and boot with BIOS. Also unexperienced users may mix up things to begin with. So if this was to be implemented it would have to be an option as described above. Probably an "expert option"?
It could/should be a verbose option. Something along the lines: "Firmware interface to use: BIOS/UEFI" where it defaults to BIOS (according to the instructions in the Wiki).
Also when thinking about it a lot of people possibly wouldn't know if they wanted to install UEFI or BIOS. They just "know" somehow that their computer uses a "BIOS" to get into their operating system. Even when todays motherboards don't even have a real BIOS anymore, rather a legacy emulation module for BIOS boot. So anything called different possibly ain't an option for them. As a consequence I think for now it actually should be an expert option indeed.
(Personally I'd promote default UEFI on any modern equipment for any OS, but that's just me ;)

So let's say the user prepared a GPT disk and an ESP as outlined in the manual, formatted and mounted everything accordingly.
What would the script need to do?

  1. efibootmgr is already part of the script (no effort)
  2. Have the grub package included (very little effort)
  3. Offer the option to use UEFI (very little effort)
  4. For advanced user experience do a post-check on the layout after choosing this option to warn the user of possible misconfigurations (some effort)
    (store the variables globally for later access):
    • Check for the partition table type (store and compare to string):
      DISK=`lsblk -o MOUNTPOINT,NAME | grep "/mnt" | tail -c 5 | sed s/.$//` && TABLE=`sfdisk -l /dev/$DISK | grep "Disklabel" | sed 's/Disklabel\ type:\ //'`
    • And throw a warning if its not GPT (Cannot simply evaluate true to msdos as there are many others [script must not exit here, user might wanna run UEFI on MBR]):
      [[ $TABLE != "gpt" ]] && echo "Warning: Your disk was not formatted with a GUID Partition Table! \nTo boot with UEFI it is highly recommended to use a GPT table."
    • Check for the ESP (store and compare to false):
      ESP=`lsblk -p -o PARTTYPE /dev/$DISK | grep 'c12a7328-f81f-11d2-ba4b-00a0c93ec93b'`
    • Throw an error if it doesn't exist (optionally exit out of the script, need to evaluate the user experience at this point [Thinking about it rather make it a prompt whether to exit out of the script since the user might decide to uncheck the option/use default BIOS instead]):
      [[ ! $ESP ]] && echo "Error: No EFI system partition found! \nManually check your disk layout before continuing." && echo -n "Exit the script to review partitions? "; read CHOICE
    • Else just keep going
So the option was set to UEFI and both checks were false/skipped:
Once the the script is free to go, the option should trigger a choice of the two outlined bootloaders in the Wiki when the user chooses to "install a bootloader?"
Use a simple if condition (kinda verbose notation, I didn't look into the actual obarun-install script yet):
if [[ $FIRMWARE = "UEFI" ]]; then
  echo "You can choose one of these bootloaders: " 
  Create your recent up/down selection menu (PS3 select?) with GRUB/EFISTUB instead of Yes/No
  if [[ $GRUB ]]; then
    install GRUB (see below)
  else
    install EFISTUB (see below)
else
  install syslinux
fi

As for the GRUB installation:
Should be pretty straight forward (two lines inside of the corresponding conditional from above):
  • Get the ESPs mount point (This should be /efi for GRUB as outlined in the Wiki but the user might not care and use the deprecated /boot instead):
    EFIMOUNT=`lsblk -p -o PARTTYPE,MOUNTPOINT /dev/$DISK | grep 'c12a7328-f81f-11d2-ba4b-00a0c93ec93b' | sed 's/c12a7328-f81f-11d2-ba4b-00a0c93ec93b //'`
  • Chroot into /mnt (Use `arch-chroot`!!!!!) to install and configure Grub. Other chroots do NOT work without bugs/nuisances/errors at this point (Unsure whether the call to the variable would work in this context, might become local to the chroot environment?)!
    arch-chroot /mnt grub-install --target=x86_64-efi --efi-directory=$EFIMOUNT --bootloader-id=grub && grub-mkconfig -o /boot/grub/grub.cfg
  • Done. Continue script

As for EFISTUB:
(Needs a few more lines to make it fool proof)
Although I outline microcode and the resume kernel parameter in the manual, it is not a hard requirement for the system to be able to boot. Still it should be mentioned during the install that the script does not cover those and needs manual recreation of the NVRAM entry.
  • Check the ESPs mount point (This should be /boot for the script to work. Need to error out if it's not [because it's possible but needs customization of the --loader option]):
    EFIMOUNT=`lsblk -p -o PARTTYPE,MOUNTPOINT /dev/$DISK | grep 'c12a7328-f81f-11d2-ba4b-00a0c93ec93b' | sed 's/c12a7328-f81f-11d2-ba4b-00a0c93ec93b //'`
    [[ ! $EFIMOUNT = "/boot" ]] && echo "Error: Your EFI system partition is not mounted at /boot! \nThis script needs it to be mounted at that location. \nExit the script now?"; read CHOICE
  • Get several more system details and store as variable (only locally as they'll not be need elsewhere):
    PARTITION=`lsblk -p -o PARTTYPE,NAME $DISK | grep 'c12a7328-f81f-11d2-ba4b-00a0c93ec93b' | tail -c 2`
    ROOT=`lsblk -p -o MOUNTPOINT,PARTUUID $DISK | grep "/mnt" | tail -c 37`
    (the tail command counts line breaks so we need to cut off what we want + 1)
  • Make the NVRAM entry:
    efibootmgr -c -d $DISK -p $PARTITION -L 'Obarun' -l \vmlinuz-linux -u 'root=PARTUUID='$ROOT' ro initrd=\initramfs-linux.img'
    (Make sure the single quotes are correct! the --unicode option is a string, so it needs to be escaped right for variables to be used)
  • Inform the user about manual intervention:
    echo "Notice: Microcode and custom kernel parameters require manual reconstruction of the NVRAM entry. \nRefer to https://wiki.archlinux.org/index.php/EFISTUB# efibootmgr and efibootmgr(8)"
  • Done. Continue script
I could also try to incorporate this if you wanted me to. As I said, I didn't check the install script yet.

In short it's rather simple really:
Create the option
> If option is changed from "BIOS": Run the checks and make a conditional select in bootloader prompt
> Install based on choice

I'd also be ready to test this on VMs once it's in some dev branch.
> So if this was to be implemented it would have to be an option as described above. Probably an "expert option"? It could/should be a verbose option. Something along the lines: "Firmware interface to use: BIOS/UEFI" where it defaults to BIOS (according to the instructions in the Wiki).

The # 1 assumption on the obarun-install script is that partitioning is done, mounted, and ready for the installation to begin, so this can not change easily (I think) unless the installer is split into two, (i) obarun-install-bios and (ii) obarun-install-uefi. Is done so, then obarun-install can be a short script with two options at the first screen for (i) or (ii) from which the one script or the other begins. (ii) should have 2 lines for mounted volumes /mnt/root and /mnt/boot where the two volumes will be mounted.

My coding inexperienced head doesn't see a simpler way around this, but for sure uefi based installations are of growing demand.
Actually this:
fungalnet wrote The # 1 assumption on the obarun-install script is that partitioning is done, mounted, and ready for the installation to begin
is the same reason why there's absolutely no need to split anything.
You're making this more complicated than it is :D
Let me try to elaborate:

The number one assumption is that partitioning is done, mounted and ready to begin the installation.
The default installation guide further assumes a BIOS based setup.

If somebody wanted to install on UEFI he'd either know how to partition or read some wiki and then partition accordingly. (This is why it should be an expert option, to not raise any doubt in the mind of a less experienced user when he'd be asked about this. He wouldn't even know.)
The checks make sure that even the informed user didn't make any mistake by accident and that:
(a) The EFI system partition really exists (The Partition type GUID of the ESP will always be c12a7328-f81f-11d2-ba4b-00a0c93ec93b as it has to be set to be recognized by the firmware)
(b) If using EFISTUB the ESP is mounted at /mnt/boot (really this is not a spec requirement, but it's such an awesome commodity that there's no reason why not to point the NVRAM entry to the default Arch application path; and the script does use this location so it is a requirement for the installer)
As for Grub the ESP could be mounted almost anywhere and the script would still work as Grub internally sets the pointers.

There is no need to mount a /mnt/root. What makes you think that? The EFI system partition should get mounted by the user before hand to /mnt/efi for GRUB and to /mnt/boot for EFISTUB.
The installation of either of these is in reality only one single line of code, is nested in the usual /mnt directory and does not need any special installation scripts. It does assume that the user has the partition done right, mounted and ready for the installation though ;)

I hope this makes it more understandable.
Now, there might be users who:
(a) don't know the difference between UEFI and BIOS to begin with
(b) know the difference and might want to try it from the installer without having read the installation guides
(c) might want to try a mixed legacy setup like UEFI/MBR

These cases are easily accounted for:
(a) should just use the script as always and not change the according expert option. He's not an expert for this option.
(b) this might seem tricky first, but the checks would inform the user exactly of the necessary steps to take. He could then exit out of the script and redo his partitioning and mounting.
(c) UEFI won't mind. It's backwards compatible with MBR. The script will inform that GPT is recommended though. Correct partitioning and mounting still applies.

I think it's pretty solid. I think programming scripts is mostly about: "Where could the user f**k up? Can I prevent this from happening?" Apparently not everything can be covered by code and some things (few really) have to be done manually, generally speaking. So if a user would like some super exotic installation boot mechanism he'd just choose not to install a bootloader, chroot into his install and go do some wizardry. (That's how I usually set up Obarun on EFISTUB to begin with)

What do you think?

Powered by Obarun