Question on boot file sync with uefi -[SOLVED]

cfr · 2013-02-01 22:54:30

How safe is it to automate the update given that refind.conf often changes as well? Or is any existing refind.conf likely to work with updates but maybe lack a new feature, for example?

EDIT: My understanding is that custom systemd service/path files etc. belong under /etc/systemd and not under /usr/lib/systemd/system. Also, the script given on the wiki will not work on all systems (e.g. mine) without editing. Also, it seems overly complex to me but perhaps that's just a matter of ignorance failing to understand. (What, for example, is the purpose of defining a function main () in a shell script? And why declare variables and as read only? As I say, perhaps I'm missing the dangers of doing otherwise, but I can see several places where this script doesn't check for failures so I'm a bit confused.) Am I right in thinking that the script assumes that your EFI partition is named "ESP" and that the EFI partition is mounted? I think it will also install all drivers for your architecture which, as I understand it, will slow boot down a bit. (I'm not sure what the 10% speed boost claim refers to?) It seems also to install documentation to the EFI partition which seems unnecessary. (It also assumes you are using the standard suggested layout e.g. that the refind directory is EFI/refind but I assume if you are not doing so, you can reasonably be expected to know about it.)

Last edited by cfr (2013-02-01 23:20:08)

srs5694 · 2013-02-02 00:00:44

I'm rEFInd's author, but I did not write the referenced script, so you can take the below as being authoritative on some matters but not authoritative on others....

cfr wrote:

How safe is it to automate the update given that refind.conf often changes as well? Or is any existing refind.conf likely to work with updates but maybe lack a new feature, for example?

At this point, I'm trying to avoid making any changes to rEFInd that will alter the way existing configuration files work, with the exception of bug fixes. (For instance, I've recently found that dont_scan_dirs didn't work on the Microsoft boot loader. I've fixed that locally, and the fix will go out with the next version.) I don't make promises about this, though, particularly over the long term. If I do make a change that will necessitate changing your refind.conf file, though, I hope to do it by deprecating the old way (to keep it working for a while) and then eliminate the option or change its interpretation. For the most part, though, my intent is that when I add a new option, the default behavior (when the option is commented out or not present) should work like it does in earlier versions.

the script given on the wiki will not work on all systems (e.g. mine) without editing. Also, it seems overly complex to me but perhaps that's just a matter of ignorance failing to understand.

As I've discovered in writing rEFInd's official install.sh script, the task has enough edge cases that an installation script becomes very complex very fast. If anything, the referenced script is overly simple, IMHO, and you've identified some of the reasons....

(What, for example, is the purpose of defining a function main () in a shell script?

Using functions in scripts can be as useful as using functions in other types of programs. Defining a main() function is not strictly necessary, but it does at least clarify the entry point.

That said, the referenced script is only 47 lines long, so I'm not sure functions are really necessary in it. OTOH, it's really a judgment call one way or the other. I don't want to criticize it on this score.

And why declare variables and as read only?

I can only guess, and my guess would be to ensure that the variable isn't accidentally changed elsewhere.

Am I right in thinking that the script assumes that your EFI partition is named "ESP" and that the EFI partition is mounted?

It looks like it to me, but I may have overlooked something. (I've not tried running the script to test it.)

Unfortunately, identifying the ESP is rather tricky, particularly if it's not currently mounted. A script could use tools like gdisk or parted to try to search for an ESP, but some computers have multiple ESPs, and in such cases, there's no telling which one should be used. For this reason, my own install.sh requires that the ESP be mounted at /boot or /boot/efi, at least in Linux. (It goes out on a limb and mounts the first available ESP in OS X, but only if that's requested by the user.)

I think it will also install all drivers for your architecture which, as I understand it, will slow boot down a bit.

I'd want to do a test run of the script before commenting on what it does -- the cp command it uses is pushing the limits of my comfort level with bash semantics!

That said, if rEFInd loads drivers unnecessarily, they can slow down the launch process. Sometimes the effect is negligible, but I've received reports of it causing delays of at least ten seconds. My own install.sh script installs just one driver -- the one used for the /boot directory -- by default, for this very reason.

(I'm not sure what the 10% speed boost claim refers to?)

Given the context, I'd guess it's a performance improvement for the script itself, but that's just a guess.

It seems also to install documentation to the EFI partition which seems unnecessary.

My own practice is to keep the documentation out of the ESP; however, there is a case to be made for storing it on the ESP instead of or in addition to storing it elsewhere: Putting it on the ESP makes the documentation accessible under all OSes. If you put it in, say, an ext4fs Arch partition, then it probably won't be accessible when you boot Windows or OS X.

cfr · 2013-02-02 00:39:42

srs5694 wrote:

At this point, I'm trying to avoid making any changes to rEFInd that will alter the way existing configuration files work, with the exception of bug fixes. (For instance, I've recently found that dont_scan_dirs didn't work on the Microsoft boot loader. I've fixed that locally, and the fix will go out with the next version.) I don't make promises about this, though, particularly over the long term. If I do make a change that will necessitate changing your refind.conf file, though, I hope to do it by deprecating the old way (to keep it working for a while) and then eliminate the option or change its interpretation. For the most part, though, my intent is that when I add a new option, the default behavior (when the option is commented out or not present) should work like it does in earlier versions.

This is very useful - thanks. It sounds as though it would be unlikely to break boot if, say, I just forgot to check for changes after a particular update.

the script given on the wiki will not work on all systems (e.g. mine) without editing. Also, it seems overly complex to me but perhaps that's just a matter of ignorance failing to understand.
As I've discovered in writing rEFInd's official install.sh script, the task has enough edge cases that an installation script becomes very complex very fast. If anything, the referenced script is overly simple, IMHO, and you've identified some of the reasons....

I should have said that it seemed complicated in unnecessary ways but not sophisticated enough (i.e. complicated) in several others. Thanks for clarifying this for me - I wasn't very clear.

(What, for example, is the purpose of defining a function main () in a shell script?
Using functions in scripts can be as useful as using functions in other types of programs. Defining a main() function is not strictly necessary, but it does at least clarify the entry point.
That said, the referenced script is only 47 lines long, so I'm not sure functions are really necessary in it. OTOH, it's really a judgment call one way or the other. I don't want to criticize it on this score.

Fair enough. I like functions and use them in my own scripts. I just thought it made this one less rather than more transparent. But I can see that it might make it more obvious for some - especially maybe people used to reading code of the non-shell sort. (That is an alien language to me so anything with main () looks unintelligible. Then I realised it was just a function.)

Am I right in thinking that the script assumes that your EFI partition is named "ESP" and that the EFI partition is mounted?
It looks like it to me, but I may have overlooked something. (I've not tried running the script to test it.)
Unfortunately, identifying the ESP is rather tricky, particularly if it's not currently mounted.

What alarmed me was that it looks to me as if the script will try to make the rEFInd directory and report success even if the EFI partition is not mounted.

I think it will also install all drivers for your architecture which, as I understand it, will slow boot down a bit.
I'd want to do a test run of the script before commenting on what it does -- the cp command it uses is pushing the limits of my comfort level with bash semantics!

$ mkdir /tmp/b
$ cp -r /usr/{share/refind/*,lib/refind/*x64*} /tmp/b/
$ ls -R /tmp/b
/tmp/b:
docs/  drivers_x64/  icons/  refind_x64.efi

/tmp/b/docs:
NEWS  README  Styles/  html/

/tmp/b/docs/Styles:
styles.css

/tmp/b/docs/html:
FDL-1.3.txt            configfile.html  getting.html     manual-submenu.png     refind.gif       submenu.png  windows-gpt.png
MokManager1.png        drivers.html     index.html       os_legacy.png          refind.png       themes.html  windows8-on-mac-efi.txt
automatic-submenu.png  editor.png       installing.html  refind-background.png  revisions.html   todo.html
bootmode.html          features.html    linux.html       refind-orig.png        secureboot.html  using.html

/tmp/b/drivers_x64:
ext2_x64.efi  ext4_x64.efi  hfs_x64.efi  iso9660_x64.efi  reiserfs_x64.efi

/tmp/b/icons:
arrow_left.icns   func_shutdown.icns   os_fedora.icns     os_legacy.icns     os_redhat.icns     tool_apple_rescue.icns  vol_optical.icns
arrow_right.icns  os_altlinux.icns     os_freebsd.icns    os_linux.icns      os_refit.icns      tool_mok_tool.icns
boot_linux.icns   os_arch.icns         os_freedos.icns    os_linuxmint.icns  os_slackware.icns  tool_part.icns
boot_win.icns     os_centos.icns       os_gentoo.icns     os_mac.icns        os_suse.icns       tool_shell.icns
func_about.icns   os_debian.icns       os_gummiboot.icns  os_mandriva.icns   os_ubuntu.icns     transparent.icns
func_exit.icns    os_ecomstation.icns  os_haiku.icns      os_netbsd.icns     os_unknown.icns    vol_external.icns
func_reset.icns   os_fatdog.icns       os_hwtest.icns     os_openbsd.icns    os_win.icns        vol_internal.icns

It seems also to install documentation to the EFI partition which seems unnecessary.
My own practice is to keep the documentation out of the ESP; however, there is a case to be made for storing it on the ESP instead of or in addition to storing it elsewhere: Putting it on the ESP makes the documentation accessible under all OSes. If you put it in, say, an ext4fs Arch partition, then it probably won't be accessible when you boot Windows or OS X.

I hadn't thought of that but I can see why that might be useful.

I also note that the script is copyrighted with no indication of any licence allowing its use or distribution.

@srs5694,
Incidentally, I never thought for a moment that you wrote the script on the wiki. If I did, I would be looking for a new boot manager...

the.ridikulus.rat · 2013-02-02 03:41:07

cfr wrote:

How safe is it to automate the update given that refind.conf often changes as well? Or is any existing refind.conf likely to work with updates but maybe lack a new feature, for example?
EDIT: My understanding is that custom systemd service/path files etc. belong under /etc/systemd and not under /usr/lib/systemd/system. Also, the script given on the wiki will not work on all systems (e.g. mine) without editing. Also, it seems overly complex to me but perhaps that's just a matter of ignorance failing to understand. (What, for example, is the purpose of defining a function main () in a shell script? And why declare variables and as read only? As I say, perhaps I'm missing the dangers of doing otherwise, but I can see several places where this script doesn't check for failures so I'm a bit confused.) Am I right in thinking that the script assumes that your EFI partition is named "ESP" and that the EFI partition is mounted? I think it will also install all drivers for your architecture which, as I understand it, will slow boot down a bit. (I'm not sure what the 10% speed boost claim refers to?) It seems also to install documentation to the EFI partition which seems unnecessary. (It also assumes you are using the standard suggested layout e.g. that the refind directory is EFI/refind but I assume if you are not doing so, you can reasonably be expected to know about it.)

Those are exactly my thoughts too. You are also right in saying that user created scripts should go into /etc/systemd/system and not into /usr/lib/systemd/system, the latter path is for pkg installed services files.

In case anyone need to know I sync rEFInd in my system -

/etc/systemd/system/refind-efi_copy.path

[Unit]
Description=Copy rEFInd files to UEFISYS Partition

[Path]
PathChanged=/usr/lib/refind/refind_x64.efi

PathChanged=/mnt/Source_Codes_Partition/Source_Codes/My_Files/Bootloader_Config_Files/refind_uefi/refind_uefi.conf
PathChanged=/mnt/Source_Codes_Partition/Source_Codes/My_Files/Bootloader_Config_Files/refind_uefi/refind_uefi_linux.conf

PathChanged=/usr/lib/refind/drivers_x64/ext4_x64.efi
PathChanged=/usr/lib/refind/drivers_x64/iso9660_x64.efi

Unit=refind-efi_copy.service

[Install]
WantedBy=multi-user.target

/etc/systemd/system/refind-efi_copy.service

[Unit]
Description=Copy rEFInd files to UEFISYS Partition
# Requires=boot-efi.mount

[Service]
Type=oneshot

ExecStart=/usr/bin/cp -f /usr/lib/refind/refind_x64.efi /boot/efi/EFI/refind/refindx64.efi

ExecStart=/usr/bin/cp -f /mnt/Source_Codes_Partition/Source_Codes/My_Files/Bootloader_Config_Files/refind_uefi/refind_uefi.conf /boot/efi/EFI/refind/refind.conf
ExecStart=/usr/bin/cp -f /mnt/Source_Codes_Partition/Source_Codes/My_Files/Bootloader_Config_Files/refind_uefi/refind_uefi.conf /boot/efi/EFI/boot/refind.conf

ExecStart=/usr/bin/cp -f /mnt/Source_Codes_Partition/Source_Codes/My_Files/Bootloader_Config_Files/refind_uefi/refind_uefi_linux.conf /boot/efi/EFI/arch/arch_linux_core/refind_linux.conf
ExecStart=/usr/bin/cp -f /mnt/Source_Codes_Partition/Source_Codes/My_Files/Bootloader_Config_Files/refind_uefi/refind_uefi_linux.conf /boot/efi/EFI/arch/arch_linux_mainline/refind_linux.conf

ExecStart=/usr/bin/rm -rf /boot/efi/EFI/tools/drivers_x64/
ExecStart=/usr/bin/cp -rf /usr/lib/refind/drivers_x64 /boot/efi/EFI/tools/drivers_x64
ExecStart=/usr/bin/rm -f /boot/efi/EFI/tools/drivers_x64/ext2_x64.efi

and then do

# systemctl enable refind-efi_copy.path
# systemctl start refind-efi_copy.path

Just make sure ESP is always mounted (in /etc/fstab) if you enable refind-efi_copy.path .

I have similar .path and service files for all UEFI bootloaders I have installed in ESP (currently rEFInd, Gummiboot, GRUB and Syslinux 6.00-preX, and of course the kernels).

srs5694 · 2013-02-02 03:44:43

cfr wrote:

srs5694 wrote:
At this point, I'm trying to avoid making any changes to rEFInd that will alter the way existing configuration files work, with the exception of bug fixes.
This is very useful - thanks. It sounds as though it would be unlikely to break boot if, say, I just forgot to check for changes after a particular update.

Yes, that's the idea. Partly I want to be nice, but it's also partly defensive -- if I were to make changes that necessitated alterations to users' configuration files, I'm sure I'd be flooded with bug reports!

mcloaked · 2013-02-02 15:20:57

I thought I would add an update to my attempts at a uefi based install last night on my system. I thought I had the uefi details sorted out but after completing the main install, and exiting the chroot - when I tried to reboot the machine it would not boot to any uefi initial screen - so I booted back into the archiso from the same usbkey that I used to install and I picked up the following issues:

1) I found that although during the install process my usbkey had been labelled as /dev/sda and the two ssd's in my system /dev/sdb and /dev/sdc which I used with the correct disk partition designations for efibootmgr, and also for the refind_linux.conf after I booted back in with the usbkey as a rescue system the disk labelling was now that the two ssd's were sda and sdb and the usbkey was sdc - which means that the labelling I used within the chroot during the initial install was now wrong - so presumably led to the system being unbootable! Since the disk labelling changed between the initial install and reboot it would be nice to be able to make all partition references refer to PARTUUID and not to the disk labels.

2) The refind_linux.conf file in the beginners' guide was suggested to use a format:

 "Boot to X"          "root=/dev/sdaX ro rootfstype=ext4 systemd.unit=graphical.target"

Whereas in the UEFI Bootloader wiki page it suggests:

 "Boot with defaults" "root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap systemd.unit=graphical.target"

I intend to change the /dev/sdXY designation to using PARTUUID which will then not be dependent on the labelling of disks.

2) I am also unsure comparing the two forms from the beginners' guide and the UEFI bootloader wiki whether having the phrase "add_efi_memmap" is critically important to include or not?

3) Also when using efibootmgr the ESP partition is referred to with /dev/sdX -p Y and it would be much better to be able to use the PARTUUID if the efibootmgr would accept it - I will have to look up whether it is possible to change to the PARTUUID form or not?

So I will now have to go back and try to correct those problems and hopefully get a bootable system! I'll report again once I have had a chance to fix these config issues.

mcloaked · 2013-02-02 19:19:52

I am completely frustrated as whatever I do I can't get a uefi boot for my newly installed arch system.

I have /boot/efi mounted as a FAT32 partition with the following structure:

 sh-4.2# ls /boot/efi/EFI/
boot  icons  refind  tools
sh-4.2# ls /boot/efi/EFI/boot/
boot_x64.efi  refind.conf
sh-4.2# ls /boot/efi/EFI/refind/
refind.conf  refind_x64.efi
sh-4.2# ls /boot/efi/EFI/tools/
drivers_x64

I made the driver scan line in the refind.conf as scan_driver_dirs EFI/tools/drivers_x64 which does contain the ext4 driver file copied in from the /usr/lib/refind/drivers_x64/ext4_x64.efi file.

I have /boot as a subdir in the / partition which is ext4. Both the ext4 / partition, and the FAT32 ESP are the only two partitions on a GPT partition table for an SSD mSATA drive. There is a second SSD which later will holds an ext4 /opt on a GPT partition. I can't seem to get consistent disk device naming but of course UUID and PARTUUID are fine - there is a normal looking fstab which references partitions by UUID.

 sh-4.2# ls /boot
efi  initramfs-linux-fallback.img  initramfs-linux.img  refind_linux.conf  vmlinuz-linux

The content of the refind_linux.conf is:

 sh-4.2# cat /boot/refind_linux.conf 
"Boot to X" "root=PARTUUID=f4b79029-10cc-4272-8d57-7e491ccd28a1 ro rootfstype=ext4 add_efi_memmap systemd.unit=graphical.target"
"Boot to console" "root=PARTUUID=f4b79029-10cc-4272-8d57-7e491ccd28a1 ro rootfstype=ext4 add_efi_memmap systemd.unit=multi-user.target"

I created the uefi entry with efibootmr and checked as:

sh-4.2# efibootmgr --verbose
BootCurrent: 0009
Timeout: 1 seconds
BootOrder: 0002,0001,0008,0003,0004,0009,0007
Boot0001* SATA : PORT 6G 0 : M4-CT256M4SSD2 : PART 0 : Boot Drive       BIOS(2,0,00)AMBO
Boot0002* SATA : PORT 5 : M4-CT032M4SSD3 : PART 0 : Boot Drive  BIOS(2,0,00)AMBO
Boot0003* LAN : IBA GE Slot 00C8 v1376  BIOS(6,0,00)AMBO
Boot0004* LAN : IBA GE Slot 0200 v1376  BIOS(6,0,00)AMBO
Boot0007* rEFInd        Vendor(99e275e7-75a0-4b37-a2e6-c5385e6c00cb,)
Boot0008* USB : JetFlashTranscend 4GB 8.07 : PART 0 : Boot Drive        BIOS(2,0,00)AMBO
Boot0009* UEFI : USB : JetFlashTranscend 4GB 8.07 : PART 0 : OS Bootloader      ACPI(a0341d0,0)PCI(1d,0)USB(1,0)USB(3,0)HD(1,800,77a800,0000e60c)AMBO

When I boot the system it immediately tries to boot off the LAN and from the ethernet port which is a live connection starts dhcp and it does not boot to the refind graphical menu as expected.

I tried using efibootmgr to move the refind entry to the top -which is did - but when I reboot then the entry does not seem to boot and the same symptoms as the line above happen - booting back into the usbkey (and doing modprobe efivars gets me booted which is how I can see the entries above from the chrooted shell - the rEFInd entry has been moved back to position 7 as happens even if I have moved it to 0000 using efibootmgr!

I did add fallback entries as suggested in the wiki - however I did expect it to boot using uefi with these files/directories/entries.

The usbkey prepared as per the guidance for preparing a uefi usbkey in https://wiki.archlinux.org/index.php/UEFI does boot to uefi just fine! So I am puzzled. I am getting close to the point of frustration where abandonning further attempts to get a uefi boot and starting again with bios legacy instead is looking more appealing!

Can anyone point me to where to look for what I am doing wrong so that I can boot the new system with uefi?

Thanks

swordfish · 2013-02-02 19:44:46

mcloaked wrote:

I am completely frustrated as whatever I do I can't get a uefi boot for my newly installed arch system.
I have /boot/efi mounted as a FAT32 partition with the following structure:
 sh-4.2# ls /boot/efi/EFI/
boot  icons  refind  tools
sh-4.2# ls /boot/efi/EFI/boot/
boot_x64.efi  refind.conf
sh-4.2# ls /boot/efi/EFI/refind/
refind.conf  refind_x64.efi
sh-4.2# ls /boot/efi/EFI/tools/
drivers_x64

Please explain: Why the double structure of /boot/efi/EFI/boot and /boot/efi/EFI/refind ? What is "boot_x64.efi" (where does it come from)?

mcloaked wrote:

I made the driver scan line in the refind.conf as scan_driver_dirs EFI/tools/drivers_x64 which does contain the ext4 driver file copied in from the /usr/lib/refind/drivers_x64/ext4_x64.efi file.
I have /boot as a subdir in the / partition which is ext4. Both the ext4 / partition, and the FAT32 ESP are the only two partitions on a GPT partition table for an SSD mSATA drive. There is a second SSD which later will holds an ext4 /opt on a GPT partition. I can't seem to get consistent disk device naming but of course UUID and PARTUUID are fine - there is a normal looking fstab which references partitions by UUID.

Please post your /etc/fstab

mcloaked wrote:

 sh-4.2# ls /boot
efi  initramfs-linux-fallback.img  initramfs-linux.img  refind_linux.conf  vmlinuz-linux

The content of the refind_linux.conf is:

 sh-4.2# cat /boot/refind_linux.conf 
"Boot to X" "root=PARTUUID=f4b79029-10cc-4272-8d57-7e491ccd28a1 ro rootfstype=ext4 add_efi_memmap systemd.unit=graphical.target"
"Boot to console" "root=PARTUUID=f4b79029-10cc-4272-8d57-7e491ccd28a1 ro rootfstype=ext4 add_efi_memmap systemd.unit=multi-user.target"

I created the uefi entry with efibootmr and checked as:

sh-4.2# efibootmgr --verbose
BootCurrent: 0009
Timeout: 1 seconds
BootOrder: 0002,0001,0008,0003,0004,0009,0007
Boot0001* SATA : PORT 6G 0 : M4-CT256M4SSD2 : PART 0 : Boot Drive       BIOS(2,0,00)AMBO
Boot0002* SATA : PORT 5 : M4-CT032M4SSD3 : PART 0 : Boot Drive  BIOS(2,0,00)AMBO
Boot0003* LAN : IBA GE Slot 00C8 v1376  BIOS(6,0,00)AMBO
Boot0004* LAN : IBA GE Slot 0200 v1376  BIOS(6,0,00)AMBO
Boot0007* rEFInd        Vendor(99e275e7-75a0-4b37-a2e6-c5385e6c00cb,)
Boot0008* USB : JetFlashTranscend 4GB 8.07 : PART 0 : Boot Drive        BIOS(2,0,00)AMBO
Boot0009* UEFI : USB : JetFlashTranscend 4GB 8.07 : PART 0 : OS Bootloader      ACPI(a0341d0,0)PCI(1d,0)USB(1,0)USB(3,0)HD(1,800,77a800,0000e60c)AMBO

How did you create the entry?

This

Boot0007* rEFInd        Vendor(99e275e7-75a0-4b37-a2e6-c5385e6c00cb,)

looks a little bit strange to me. On my desktop it looks like this:

Boot0001* rEFInd 0.6.6-1	HD(1,800,100000,0c483db9-c73b-48a5-ace9-f4cf4dfa78a9)File(\EFI\refind\refind_x64.efi)

mcloaked wrote:

When I boot the system it immediately tries to boot off the LAN and from the ethernet port which is a live connection starts dhcp and it does not boot to the refind graphical menu as expected.
I tried using efibootmgr to move the refind entry to the top -which is did - but when I reboot then the entry does not seem to boot and the same symptoms as the line above happen - booting back into the usbkey (and doing modprobe efivars gets me booted which is how I can see the entries above from the chrooted shell - the rEFInd entry has been moved back to position 7 as happens even if I have moved it to 0000 using efibootmgr!
I did add fallback entries as suggested in the wiki - however I did expect it to boot using uefi with these files/directories/entries.
The usbkey prepared as per the guidance for preparing a uefi usbkey in https://wiki.archlinux.org/index.php/UEFI does boot to uefi just fine! So I am puzzled. I am getting close to the point of frustration where abandonning further attempts to get a uefi boot and starting again with bios legacy instead is looking more appealing!
Can anyone point me to where to look for what I am doing wrong so that I can boot the new system with uefi?
Thanks

Can you get to the boot selection menu that should be available by pressing F12 while the BIOS starts (well, it's F12 on my laptop and on my desktop, maybe it's different on your system)?

mcloaked · 2013-02-02 20:25:54

swordfish wrote:

mcloaked wrote:
I am completely frustrated as whatever I do I can't get a uefi boot for my newly installed arch system.
I have /boot/efi mounted as a FAT32 partition with the following structure:
 sh-4.2# ls /boot/efi/EFI/
boot  icons  refind  tools
sh-4.2# ls /boot/efi/EFI/boot/
boot_x64.efi  refind.conf
sh-4.2# ls /boot/efi/EFI/refind/
refind.conf  refind_x64.efi
sh-4.2# ls /boot/efi/EFI/tools/
drivers_x64
Please explain: Why the double structure of /boot/efi/EFI/boot and /boot/efi/EFI/refind ? What is "boot_x64.efi" (where does it come from)?
I followed paragraph 7 of https://wiki.archlinux.org/index.php/Beginners'_Guide#EFISTUB to make a fallback entry.
mcloaked wrote:
I made the driver scan line in the refind.conf as scan_driver_dirs EFI/tools/drivers_x64 which does contain the ext4 driver file copied in from the /usr/lib/refind/drivers_x64/ext4_x64.efi file.
I have /boot as a subdir in the / partition which is ext4. Both the ext4 / partition, and the FAT32 ESP are the only two partitions on a GPT partition table for an SSD mSATA drive. There is a second SSD which later will holds an ext4 /opt on a GPT partition. I can't seem to get consistent disk device naming but of course UUID and PARTUUID are fine - there is a normal looking fstab which references partitions by UUID.
Please post your /etc/fstab
# 
# /etc/fstab: static file system information
#
# <file system> <dir>   <type>  <options>       <dump>  <pass>
# /dev/sdc2
UUID=87d59fd7-646d-4604-a5a5-395d7e0495a7       /               ext4            defaults,relatime       0 1

# /dev/sdc1
UUID=D8B9-6A05                                  /boot/efi       vfat            noatime 0 2

# /dev/sdb2
UUID=64de551d-87e3-408f-928b-8f1470d9c073       /opt            ext4            defaults,relatime       0 2

# /dev/sdb1
UUID=a3113712-5fe4-4a3d-accb-f1296c883e4c       none            swap            defaults        0 0
mcloaked wrote:
 sh-4.2# ls /boot
efi  initramfs-linux-fallback.img  initramfs-linux.img  refind_linux.conf  vmlinuz-linux
The content of the refind_linux.conf is:
 sh-4.2# cat /boot/refind_linux.conf 
"Boot to X" "root=PARTUUID=f4b79029-10cc-4272-8d57-7e491ccd28a1 ro rootfstype=ext4 add_efi_memmap systemd.unit=graphical.target"
"Boot to console" "root=PARTUUID=f4b79029-10cc-4272-8d57-7e491ccd28a1 ro rootfstype=ext4 add_efi_memmap systemd.unit=multi-user.target"
I created the uefi entry with efibootmr and checked as:
sh-4.2# efibootmgr --verbose
BootCurrent: 0009
Timeout: 1 seconds
BootOrder: 0002,0001,0008,0003,0004,0009,0007
Boot0001* SATA : PORT 6G 0 : M4-CT256M4SSD2 : PART 0 : Boot Drive       BIOS(2,0,00)AMBO
Boot0002* SATA : PORT 5 : M4-CT032M4SSD3 : PART 0 : Boot Drive  BIOS(2,0,00)AMBO
Boot0003* LAN : IBA GE Slot 00C8 v1376  BIOS(6,0,00)AMBO
Boot0004* LAN : IBA GE Slot 0200 v1376  BIOS(6,0,00)AMBO
Boot0007* rEFInd        Vendor(99e275e7-75a0-4b37-a2e6-c5385e6c00cb,)
Boot0008* USB : JetFlashTranscend 4GB 8.07 : PART 0 : Boot Drive        BIOS(2,0,00)AMBO
Boot0009* UEFI : USB : JetFlashTranscend 4GB 8.07 : PART 0 : OS Bootloader      ACPI(a0341d0,0)PCI(1d,0)USB(1,0)USB(3,0)HD(1,800,77a800,0000e60c)AMBO
How did you create the entry?
As per the paragraph 6 of the link to the Efistub section of the Beginner's Guide:
efibootmgr -c -g -d /dev/sdc -p 1 -w -L "rEFInd" -l '\EFI\refind\refind_x64.efi'
Though I do have a question about this - if I reboot the machine then the partition that was sdc1 changes - and might be sdb1 next boot when booting back to the usbkey for the archiso - so I am puzzled as to how to make the disk naming consistent - or does it not matter once the file is written?

This
Boot0007* rEFInd        Vendor(99e275e7-75a0-4b37-a2e6-c5385e6c00cb,)
looks a little bit strange to me. On my desktop it looks like this:
Boot0001* rEFInd 0.6.6-1	HD(1,800,100000,0c483db9-c73b-48a5-ace9-f4cf4dfa78a9)File(\EFI\refind\refind_x64.efi)
Yes I don't know why mine does not look like what you quoted which is more like how I expected mine to look!
mcloaked wrote:
When I boot the system it immediately tries to boot off the LAN and from the ethernet port which is a live connection starts dhcp and it does not boot to the refind graphical menu as expected.
I tried using efibootmgr to move the refind entry to the top -which is did - but when I reboot then the entry does not seem to boot and the same symptoms as the line above happen - booting back into the usbkey (and doing modprobe efivars gets me booted which is how I can see the entries above from the chrooted shell - the rEFInd entry has been moved back to position 7 as happens even if I have moved it to 0000 using efibootmgr!
I did add fallback entries as suggested in the wiki - however I did expect it to boot using uefi with these files/directories/entries.
The usbkey prepared as per the guidance for preparing a uefi usbkey in https://wiki.archlinux.org/index.php/UEFI does boot to uefi just fine! So I am puzzled. I am getting close to the point of frustration where abandonning further attempts to get a uefi boot and starting again with bios legacy instead is looking more appealing!
Can anyone point me to where to look for what I am doing wrong so that I can boot the new system with uefi?
Thanks
Can you get to the boot selection menu that should be available by pressing F12 while the BIOS starts (well, it's F12 on my laptop and on my desktop, maybe it's different on your system)?

Yes (it's F10 on mine as it is an Intel mATX board.) and I tried going to the refind entry - but it just goes to the network entry and tries to dhcp - with a whirring spinning "-" "/" "\" etc moving along from left to right....

Last edited by mcloaked (2013-02-02 20:30:42)

swordfish · 2013-02-02 20:49:23

Hm, strange, indeed. But you can start your usb drive in uefi mode without problems, right? (Otherwise I would say, try if you could start an Ubuntu live system from the usb drive in uefi mode - just to check if the uefi implementation of your board is ok)

Just an idea: In the refind.conf file you can set the default menu selection. Maybe it helps.

Or you could try to erase the LAN entries using efibootmgr? Like

$ sudo efibootmgr -b 0003 -B

And a point to investigate is the strange uefi entry for rEFInd.

One last point: How about installing all the uefi stuff as it is advised in the wiki? I mean, without trying to use the default /boot/vmlinuz-linux but copying it to /boot/efi/EFI/arch ( and so on).

Last edited by swordfish (2013-02-02 20:52:10)

mcloaked · 2013-02-02 20:54:59

swordfish wrote:

Hm, strange, indeed. But you can start your usb drive in uefi mode without problems, right? (Otherwise I would say, try if you could start an Ubuntu live system from the usb drive in uefi mode - just to check if the uefi implementation of your board is ok)
Just an idea: In the refind.conf file you can set the default menu selection. Maybe it helps.
And a point to investigate is the strange uefi entry for rEFInd.
One last point: How about installing all the uefi stuff as it is advised in the wiki? I mean, without trying to use the default /boot/vmlinuz-linux but copying it to /boot/efi/EFI/arch ( and so on).

Yes it is worth a shot.... I'll try that... but the main problem seems to be the rEFInd entry that looks peculiar but I have no idea how to proceed with diagnosing it? I am still suspicious about the device naming - does anyone else have a working system with two hard drives? Any similar issues and work arounds? And yes I can start the usbkey in uefi mode and confirmed by checking the contents of /sys/firmware/efi/vars/ are populated.

Last edited by mcloaked (2013-02-02 20:55:52)

srs5694 · 2013-02-03 00:44:51

mcloaked wrote:

I am completely frustrated as whatever I do I can't get a uefi boot for my newly installed arch system.

I have a few suggestions for getting it working. Try these in any order until something works:

Use an EFI shell (version 2) and its bcfg command rather than efibootmgr. The latter doesn't always work right; bcfg from an EFI shell is sometimes more reliable. There are some basic instructions on using bcfg in the Arch wiki.
Create a fallback (EFI/BOOT/bootx64.efi) entry. Note that the one you've got now is incorrect (see below).
Try eliminating all the NVRAM boot entries (using efibootmgr and/or bcfg), then add just one new entry for rEFInd.
Check your firmware for boot order options. Some include the ability to adjust the boot order (similar to "efibootmgr -o {boot list}").

I have /boot/efi mounted as a FAT32 partition with the following structure:
 sh-4.2# ls /boot/efi/EFI/
boot  icons  refind  tools
sh-4.2# ls /boot/efi/EFI/boot/
boot_x64.efi  refind.conf

The correct filename for a fallback boot loader on x86-64 is bootx64.efi, not boot_x64.efi. Thus, if this is an accurate representation of what you've got, this entry won't work as you expect.

Also, if this file is a rEFInd binary, you should have an "icons" subdirectory that holds the icon files. (The same comment applies to your EFI/refind directory.) The lack of an "icons" subdirectory won't cause rEFInd to fail completely, but most of its icons will be replaced with ugly black-and-yellow patterns.

mcloaked · 2013-02-03 09:19:28

srs5694 wrote:

mcloaked wrote:
I am completely frustrated as whatever I do I can't get a uefi boot for my newly installed arch system.
I have a few suggestions for getting it working. Try these in any order until something works:
Use an EFI shell (version 2) and its bcfg command rather than efibootmgr. The latter doesn't always work right; bcfg from an EFI shell is sometimes more reliable. There are some basic instructions on using bcfg in the Arch wiki.
Create a fallback (EFI/BOOT/bootx64.efi) entry. Note that the one you've got now is incorrect (see below).
Try eliminating all the NVRAM boot entries (using efibootmgr and/or bcfg), then add just one new entry for rEFInd.
Check your firmware for boot order options. Some include the ability to adjust the boot order (similar to "efibootmgr -o {boot list}").
I have /boot/efi mounted as a FAT32 partition with the following structure:
 sh-4.2# ls /boot/efi/EFI/
boot  icons  refind  tools
sh-4.2# ls /boot/efi/EFI/boot/
boot_x64.efi  refind.conf
The correct filename for a fallback boot loader on x86-64 is bootx64.efi, not boot_x64.efi. Thus, if this is an accurate representation of what you've got, this entry won't work as you expect.
Also, if this file is a rEFInd binary, you should have an "icons" subdirectory that holds the icon files. (The same comment applies to your EFI/refind directory.) The lack of an "icons" subdirectory won't cause rEFInd to fail completely, but most of its icons will be replaced with ugly black-and-yellow patterns.

Thank you for these suggestions which I will take up. By the way I did try to change the boot order with efibootmgr -o which looked as I had set them immediately after execution but after rebooting the order had been put back to the way they were before executing the efibootmgr -o command presumably by the bios! i.e. it was not persistent! I don't know whether some bioses such as mine take control of that?

Yes I seem to have the fallback entry with lower case instead of upper case for the "BOOT" and also got the filename wrong so I will correct that - but also try the shell as you suggest - and I will edit this post later when I have tried these things.

Added comment: Booting the archiso to a rescue system, I corrected the fallback entry as you suggested, and added in the icons directory to both the /boot/efi/EFI/boot/ and /boot/efi/EFI/refind/ directrories, and for good measure added the drivers_x64 directory also to both. I then removed the existing refind entry in the nvram using efibootmgr, and then booted the archiso usbkey to the uefi shell v2. Then using

 bcfg boot add 0 fs1:\EFI\arch\refind\refindx64.efi "Arch Linux (rEFInd)"

to create a new nvram boot entry, I had to check the contents of fs0 and fs1, and saw that fs0 was the usbkey boot files, but listing the directories in fs1 confirmed that this was the ESP on the hard drive (SSD). I then rebooted without the usbkey in - and was very quickly presented with a nice rEFInd graphical screen with 6 icon options including the correct entry for the newly installed arch system! I did have to select the central top icon with the linux penguin to boot the installed arch system on the SSD.

The nvram entries now look like the following with efibootmgr:

 BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0001,0003,0004,000A
Boot0000* Arch Linux (rEFInd)   ACPI(a0341d0,0)PCI(1f,2)03120a000500ffff0000HD(1,1000,3e8000,08d86b83-7c6d-4e74-b45d-ce436f4fdced)File(\EFI\refind\refind_x64.efi)
Boot0001* SATA : PORT 6G 0 : M4-CT256M4SSD2 : PART 0 : Boot Drive       BIOS(2,0,00)AMBO
Boot0002* SATA : PORT 5 : M4-CT032M4SSD3 : PART 0 : Boot Drive  BIOS(2,0,00)AMBO
Boot0003* LAN : IBA GE Slot 00C8 v1376  BIOS(6,0,00)AMBO
Boot0004* LAN : IBA GE Slot 0200 v1376  BIOS(6,0,00)AMBO
Boot000A* UEFI : SATA : PORT 5 : M4-CT032M4SSD3 : PART 0 : OS Bootloader        ACPI(a0341d0,0)PCI(1f,2)03120a000500ffff0000HD(1,1000,3e8000,08d86b83-7c6d-4e74-b45d-ce436f4fdced)AMBO

So thank you so much for bearing with me on this issue in this thread - it does seem that possibly efibootmgr did not work with my system but adding the entry using the uefi shell v2 did work! What I would like to know now is how to make the arch normal system the default - on the rEFInd graphical menu the arch normal system is in the middle of three icons on the top line with the other two being fallback entries - I will read more but would like to have the normal arch system the default entry. I am delighted to have reached this stage as I was on the verge of giving up - thank you for the help, particularly from Rod. I now have what seems to be a working uefi booted system - and can now go ahead and configure the rest of the system.

Last edited by mcloaked (2013-02-03 15:43:18)

srs5694 · 2013-02-03 16:23:38

mcloaked wrote:

Yes I seem to have the fallback entry with lower case instead of upper case for the "BOOT" and also got the filename wrong so I will correct that

It's a moot point for now, but FYI, the case of the directory name and of the filenames on the ESP shouldn't matter, since FAT is case-insensitive. It was the stray "_" in the filename that was the issue.

it does seem that possibly efibootmgr did not work with my system but adding the entry using the uefi shell v2 did work!

That's what it sounds like to me, although it's possible that some of the file-juggling you did had some subtle positive effect.

What I would like to know now is how to make the arch normal system the default - on the rEFInd graphical menu the arch normal system is in the middle of three icons on the top line with the other two being fallback entries

Look at the default_selection option in refind.conf. I recommend setting it to a unique substring of the identifier for your boot selection. Something like "arch" or "vmlinuz" is likely to work, but without knowing the text of all the available options, along with which one you want to be the default, I can't tell you with certainty what will work.

mcloaked · 2013-02-03 17:45:25

srs5694 wrote:

mcloaked wrote:
Yes I seem to have the fallback entry with lower case instead of upper case for the "BOOT" and also got the filename wrong so I will correct that
It's a moot point for now, but FYI, the case of the directory name and of the filenames on the ESP shouldn't matter, since FAT is case-insensitive. It was the stray "_" in the filename that was the issue.
it does seem that possibly efibootmgr did not work with my system but adding the entry using the uefi shell v2 did work!
That's what it sounds like to me, although it's possible that some of the file-juggling you did had some subtle positive effect.
What I would like to know now is how to make the arch normal system the default - on the rEFInd graphical menu the arch normal system is in the middle of three icons on the top line with the other two being fallback entries
Look at the default_selection option in refind.conf. I recommend setting it to a unique substring of the identifier for your boot selection. Something like "arch" or "vmlinuz" is likely to work, but without knowing the text of all the available options, along with which one you want to be the default, I can't tell you with certainty what will work.

Thank you for all your advice and help without which I am sure I would not have got this far.... I will look at the default_selection option and it should be relatively easy if all it needs is a substring of the entry identifier. I will post back with how it works... I think maybe some editing of the wiki might help others so once my system is fully configured I will try to add some useful extra info to the wiki - specifically concerning watchpoints to look out for - such as the incorrectly included "_" in the fallback binary name.

Update 4th February: Once I looked at the "name" of the entry that appears on the refind initial screen, which in my case does contain "vmlinuz" then adding that to the default_selection string makes that entry the default and it works beautifully. Also that is described in rodsbooks at http://www.rodsbooks.com/refind/configfile.html. So I will now mark this thread as closed. Thank you all for your help.

Last edited by mcloaked (2013-02-04 15:15:20)

mcloaked · 2013-02-11 14:06:04

I am posting this note as a "postscript" to the uefi story - the one thing I still needed to check was what the system would do following both a kernel update, and secondly after a BIOS update.

Since getting my system working there has been both a new arch kernel, and a BIOS update.

1) Doing pacman -Syu giving a kernel update placed new files in /boot for the kernel and inittramfs - the system booted without the need for any other intervention following the kernel update which is fab.

2) A new firmware BIOS update was released for my DQ77KB motherboard - so I installed it and rebooted - the previously stored NVRAM entries remained intact and the system rebooted with the new BIOS firmware without any need for additional manual changes.

So installing refind for uefi booting with the recommendations given earlier in this thread has led to a system that is resilient to new kernels and BIOS updates. Of course I have only tested my own single system and other users with different systems may have possibly a different experience. However I am really pleased that I went through the learning curve to get uefi boot working with rEFInd.

Arch Linux

#26 2013-02-01 22:54:30

Re: Question on boot file sync with uefi -[SOLVED]

#27 2013-02-02 00:00:44

Re: Question on boot file sync with uefi -[SOLVED]

#28 2013-02-02 00:39:42

Re: Question on boot file sync with uefi -[SOLVED]

#29 2013-02-02 03:41:07

Re: Question on boot file sync with uefi -[SOLVED]

#30 2013-02-02 03:44:43

Re: Question on boot file sync with uefi -[SOLVED]

#31 2013-02-02 15:20:57

Re: Question on boot file sync with uefi -[SOLVED]

#32 2013-02-02 19:19:52

Re: Question on boot file sync with uefi -[SOLVED]

#33 2013-02-02 19:44:46

Re: Question on boot file sync with uefi -[SOLVED]

#34 2013-02-02 20:25:54

Re: Question on boot file sync with uefi -[SOLVED]

#35 2013-02-02 20:49:23

Re: Question on boot file sync with uefi -[SOLVED]

#36 2013-02-02 20:54:59

Re: Question on boot file sync with uefi -[SOLVED]

#37 2013-02-03 00:44:51

Re: Question on boot file sync with uefi -[SOLVED]

#38 2013-02-03 09:19:28

Re: Question on boot file sync with uefi -[SOLVED]

#39 2013-02-03 16:23:38

Re: Question on boot file sync with uefi -[SOLVED]

#40 2013-02-03 17:45:25

Re: Question on boot file sync with uefi -[SOLVED]

#41 2013-02-11 14:06:04

Re: Question on boot file sync with uefi -[SOLVED]

Board footer