[SOLVED] Trying to chainload grub from rEFInd fails

mcloaked · 2014-05-23 14:30:25

I have a Thinkpad S540 that boots using UEFI with rEFInd and works most of the time. Occasionally a particular kernel won't boot, so I am trying to set up grub so that, in the event that rEFInd won't boot the kernel using the efistub, then I can fall back to booting the same kernel with grub instead using grub-standalone.

I have read the available wikie entry concerning grub standalone, and looked at the man page and tried to set it up as follows so that there is a rEFInd entry that will boot grub which will then boot the current arch kernel. What I did was:

# pacman -S grub
#  grub-mkconfig -o /boot/grub/grub.cfg
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "/boot/grub/grubx64_standalone.efi"  "/boot/grub/grub.cfg=/tmp/grub.cfg" -v

The ESP is at /boot/efi/EFI/ and the kernel is in /boot which is an ext4 directory within the root partition. So I wanted grub to be at /boot/grub/ and in there is now:

ls /boot/grub/
grub.cfg  grub.cfg.example  grubx64_standalone.efi

I then made a rEFInd boot stanza in refind.conf:

menuentry Grub {
    loader /boot/grub/grubx64_standalone.efi
    initrd
    options
}

When I boot the machine I get the usual rEFInd graphical boot screen and the normal efi entry for arch linux boots just fine. However if I select the Grub entry then it fails complaining that there is an invalid loader file.

Can someone guide me as to what I did wrong so that I can boot grub from the rEFInd menu?

Thanks

Last edited by mcloaked (2014-05-25 08:44:41)

WorMzy · 2014-05-23 14:41:43

I don't know if chain-loading UEFI boot managers is possible, but assuming i is, I suspect the problem is that you're using Arch-absolute paths, rather than ESP-absolute paths in your grub stanza. i.e. '/boot/grub/grubx64_standalone.efi' should probably be '/grub/grubx64_standalone.efi'.

mcloaked · 2014-05-23 14:57:16

WorMzy wrote:

I don't know if chain-loading UEFI boot managers is possible, but assuming i is, I suspect the problem is that you're using Arch-absolute paths, rather than ESP-absolute paths in your grub stanza. i.e. '/boot/grub/grubx64_standalone.efi' should probably be '/grub/grubx64_standalone.efi'.

Yes there may well be an issue with paths. I am not sure what the way forward is but the grub directory is not in the ESP which is mounted at /boot/efi/EFI/ and which does not contain the grub directory. Grub is at /boot/grub/ which is a normal directory under / so I had just thought that provided the real grub.cfg was in the same directory as the grub-standalone efi file it should work. However I am very unclear in my understanding of the ${cmdpath} variable and certainly trying to echo that variable gives a blank output! So maybe that approach needs to be modified in the command that generates the grub standalone efi file?.

Also possibly the grub.cfg and standalone file are required to be in the ESP and not in /boot since my ESP is mounted at /boot/efi/ ?

Maybe someone has already got this working and knows the secret incantation to make it work!

Last edited by mcloaked (2014-05-23 15:15:40)

mcloaked · 2014-05-23 21:38:03

I think my problem is that I am not specifying the correct disk for refind to look for the loader file.

I have tried changing the stanza in refind.conf to boot the arch kernel with:

menuentry "Arch Linux and grub" {
        icon EFI/refind/icons/os_linux.icns
        volume "a01aa42a-8ece-4584-a632-bea1f042c80a"
        loader /boot/vmlinuz-linux
        initrd /boot/initramfs-linux.img
        options "rw root=UUID=352b1b2e-575c-4757-90a8-c7d0162f5b9f PARTUUID=a01aa42a-8ece-4584-a632-bea1f042c80a quiet"
        ostype Linux
submenuentry "boot via Grub" {
        loader /boot/grub/grubx64_standalone.efi
        initrd
        options
    }
}

and the required disk and partition is from the blkid command:

/dev/sdb1: UUID="352b1b2e-575c-4757-90a8-c7d0162f5b9f" TYPE="ext4" PARTLABEL="root" PARTUUID="a01aa42a-8ece-4584-a632-bea1f042c80a"

This fails the same with with "invalid loader file!" and when I hover the mouse over the auto detected entry it correctly shows it is going to boot from files on the right disk, but the entry from the above stanza is looking at the other disk where is will fail to find the partition containing the kernel. So I guess it is my lack of understanding in defining the volume for a system with more than one disk.
However I would have thought from the description of the volume from the refind web page that this would work but I must be wrong.

When I created the filesystem I didn't give it a label which would have made life easier since the stanza could have used something like "volume root" if I had called the partition filesystem "root".

The laptop has two drives - one is an ssd which just has the above partition on it and the other is the hard drive that came with the hardware and is where the ESP is located. Letting refind autodetect the linux kernel works fine, but I think that the stanza above is making refind look on the wrong hard drive. I had thought that the volume could be specified with the UUID since the help page for writing stanzas gives the explanation of the volume parameter as

Sets the volume that's used for subsequent file accesses (by icon and loader, and by implication by initrd if loader follows volume). 
You pass this token a filesystem's label, a partition's label, a partition's GUID, or a volume number. 
A filesystem or partition label is typically displayed under the volume's icon in file managers and rEFInd displays it on its menu at the end of the boot prompt string. 
If this label isn't unique, the first volume with the specified label is used. The matching is nominally case-insensitive, but on some EFIs it's case-sensitive. 
If a filesystem has no label, you can use a partition GUID number. You can also use a volume number followed by a colon, such as 0: to refer to the first filesystem or 1: to refer to the second. 
The assignment of numbers is arbitrary and may not be consistent across boots, though. It might change if you insert an optical disc or plug in a USB flash drive, for instance. 
If this option is not set, the volume defaults to the one from which rEFInd launched.

the.ridikulus.rat · 2014-05-24 03:06:38

@mcloaked: Why don't you install grubx64_standalone.efi to ESP instead of /boot?

mcloaked · 2014-05-24 07:06:09

the.ridikulus.rat wrote:

@mcloaked: Why don't you install grubx64_standalone.efi to ESP instead of /boot?

You are right - that would likely get it working with rEFInd's auto detection. However it would be really nice to know how to fix the manual stanza to make that work since it would then give the freedom to configure booting the system with customised options, so that is a challenge I would like to conquer! I think it must be the syntax of the volume command that I have wrong. The only example that I could see uses simply the volume specifier with the filesystem label but the documentation implies that the GUID and other parameters can be used instead.

With a fresh mind this morning I will try some different syntaxes for the volume line and will report back if I can make it work. If so then perhaps some examples using the different ways to specify the drive that the loader (and initrd etc) that refind will look for it might be useful either in the original page at Rod's refind documentation, or in the wiki would help others get this working must faster. I know that the line is required if the efi being loaded is not on the same drive as the ESP.

I do know that another user who has two hard drives with the ESP on a different drive to the root system containing the kernel and initrd has made this work using the filesystem label in the volume line, so if I can't make it work using the UUID or PARTUUID then I will add a filesystem label and see if that works. Maybe using a syntax like PARTUUID="xxxxxxxxxxx" is the correct way so that is what I will try first later today.

Edit: With the rEFInd graphical screen displayed during boot I moved the mouse from one icon to the next to see the text displayed for each icon. The auto-detected kernel that works fine had a volume label "59 GiB ext4 volume" whereas all the other entries had "SYSTEM_DRV", so I changed the volume line in the manual stanza to boot arch to contain "59 GiB ext4 volume" and it boots fine. The submenu entry for grub now does start grub but it just goes to the grub menu and does not run the standalone grub efi file. So I must have used the wrong procedure to generate the grub standalone file.

I also added a separate manual stanza to try to boot the grub standalone efi file. This goes to the grub prompt just as for the submenu off the arch menu. So I clearly messed up preparation of the grub standalone file.

So I have two remaining questions. One is how can I properly specify the volume line in a manual rEFInd stanza to use the UUID or PARTUUID instead of using the volume label? Secondly I would like to know what I did wrong in the preparation of the grub standalone efi file described at the start of this thread?

Last edited by mcloaked (2014-05-24 08:51:12)

the.ridikulus.rat · 2014-05-25 01:58:48

mcloaked wrote:

Occasionally a particular kernel won't boot, so I am trying to set up grub so that, in the event that rEFInd won't boot the kernel using the efistub, then I can fall back to booting the same kernel with grub instead using grub-standalone.

mcloaked wrote:

menuentry "Arch Linux and grub" {
        icon EFI/refind/icons/os_linux.icns
        volume "a01aa42a-8ece-4584-a632-bea1f042c80a"
        loader /boot/vmlinuz-linux
        initrd /boot/initramfs-linux.img
        options "rw root=UUID=352b1b2e-575c-4757-90a8-c7d0162f5b9f PARTUUID=a01aa42a-8ece-4584-a632-bea1f042c80a quiet"
        ostype Linux
submenuentry "boot via Grub" {
        loader /boot/grub/grubx64_standalone.efi
        initrd
        options
    }
}

The "loader" command in submenuentry overrides the loader file in the main menuentry. Even if rEFInd passes such info as arguments/options in the submenuentry GRUB will simply ignore it. The only way you can make GRUB to boot the kernel is to create a menuentry for the kernel in grub.cfg, and the grub.cfg should be located in the same directory as grubx64_standalone.efi .

mcloaked wrote:

and the required disk and partition is from the blkid command:
/dev/sdb1: UUID="352b1b2e-575c-4757-90a8-c7d0162f5b9f" TYPE="ext4" PARTLABEL="root" PARTUUID="a01aa42a-8ece-4584-a632-bea1f042c80a"
This fails the same with with "invalid loader file!" and when I hover the mouse over the auto detected entry it correctly shows it is going to boot from files on the right disk, but the entry from the above stanza is looking at the other disk where is will fail to find the partition containing the kernel. So I guess it is my lack of understanding in defining the volume for a system with more than one disk.
However I would have thought from the description of the volume from the refind web page that this would work but I must be wrong.

You may have to remove the quotes around the <PARTUUID> in the menuentry for it to work. You also have to make sure to enable the options in refind.conf (scan_driver_dirs) for refind to find the UEFI ext4 driver and load it, for your menu entry to work, if you have grub standalone installed in /boot/grub.

Last edited by the.ridikulus.rat (2014-05-25 02:20:34)

the.ridikulus.rat · 2014-05-25 02:20:10

mcloaked wrote:

the.ridikulus.rat wrote:
@mcloaked: Why don't you install grubx64_standalone.efi to ESP instead of /boot?
You are right - that would likely get it working with rEFInd's auto detection. However it would be really nice to know how to fix the manual stanza to make that work since it would then give the freedom to configure booting the system with customised options, so that is a challenge I would like to conquer! I think it must be the syntax of the volume command that I have wrong. The only example that I could see uses simply the volume specifier with the filesystem label but the documentation implies that the GUID and other parameters can be used instead.

An example refind menuentry with PARTUUID which works for me:

menuentry "Arch Linux Core Kernel" {
    icon /EFI/refind/icons/os_arch.icns
    volume f5e1ef99-752e-4041-855d-aca8a7cc0d03
    loader /EFI/arch/core/vmlinuz-arch-core.efi
    initrd /EFI/arch/core/initramfs-arch-core.img
    options "root=PARTUUID=6f44c56d-d5c2-41ca-8c54-873d8dc5e5e3 rootfstype=ext4 rw loglevel=6 printk.time=y pcie_aspm=force i915.i915_enable_rc6=1 nouveau.nofbaccel=1 add_efi_memmap systemd.unit=graphical.target"
    ostype Linux
    graphics off
}

mcloaked wrote:

The submenu entry for grub now does start grub but it just goes to the grub menu and does not run the standalone grub efi file. So I must have used the wrong procedure to generate the grub standalone file.

Your procedure to generate grub standalone is coirrect and runtime behavior of grub standalone file is also correct. The problem here is your confusion as to what grub standalone actually does. GRUB standalone simply removes the need for the *.mod and other related files in /boot/grub/x86_64-efi/ dir such that all those files are self contained within the standalone file (hence the name "standalone"). Normally GRUB uses the embedded grub.cfg, or if it not available fallback to grub commandline. In our case, we instruct grub standalone to use the external, same-dir grub.cfg by adding the line "configfile ${cmdpath}/grub.cfg" to the embedded grub.cfg, wherein ${cmdpath} is the path of the directory where the grub standalone file is located or launched from. The ${cmdpath} var is set by grub itself during runtime, and the "configfile ${cmdpath}/grub.cfg" command instructs grub to use the external grub.cfg as its config file.

mcloaked · 2014-05-25 07:25:25

the.ridikulus.rat wrote:

The "loader" command in submenuentry overrides the loader file in the main menuentry. Even if rEFInd passes such info as arguments/options in the submenuentry GRUB will simply ignore it. The only way you can make GRUB to boot the kernel is to create a menuentry for the kernel in grub.cfg, and the grub.cfg should be located in the same directory as grubx64_standalone.efi .
You may have to remove the quotes around the <PARTUUID> in the menuentry for it to work. You also have to make sure to enable the options in refind.conf (scan_driver_dirs) for refind to find the UEFI ext4 driver and load it, for your menu entry to work, if you have grub standalone installed in /boot/grub.

Thank you for the additional useful info. I had thought that my grub.cfg did have the appropriate menu entry for the kernel and I will check the file (it was created with the command

#  grub-mkconfig -o /boot/grub/grub.cfg

), and I did have the grub.cfg in the same directory (/boot/grub/) as the standalone file. However your additional comments about my misunderstanding how grub standalone works are right and I will re-work how I created the standalone file and see if I can get it to load and use the grub.cfg file that is in the same directory.

Thank you for suggestion about using the PARTUUID value without quotes - I will certainly try that and report back on its success. I guess that in any future partitioning scheme I should add a filesystem label as well to make things perhaps easier.

mcloaked · 2014-05-25 07:30:21

the.ridikulus.rat wrote:

An example refind menuentry with PARTUUID which works for me:

menuentry "Arch Linux Core Kernel" {
    icon /EFI/refind/icons/os_arch.icns
    volume f5e1ef99-752e-4041-855d-aca8a7cc0d03
    loader /EFI/arch/core/vmlinuz-arch-core.efi
    initrd /EFI/arch/core/initramfs-arch-core.img
    options "root=PARTUUID=6f44c56d-d5c2-41ca-8c54-873d8dc5e5e3 rootfstype=ext4 rw loglevel=6 printk.time=y pcie_aspm=force i915.i915_enable_rc6=1 nouveau.nofbaccel=1 add_efi_memmap systemd.unit=graphical.target"
    ostype Linux
    graphics off
}

Your procedure to generate grub standalone is coirrect and runtime behavior of grub standalone file is also correct. The problem here is your confusion as to what grub standalone actually does. GRUB standalone simply removes the need for the *.mod and other related files in /boot/grub/x86_64-efi/ dir such that all those files are self contained within the standalone file (hence the name "standalone"). Normally GRUB uses the embedded grub.cfg, or if it not available fallback to grub commandline. In our case, we instruct grub standalone to use the external, same-dir grub.cfg by adding the line "configfile ${cmdpath}/grub.cfg" to the embedded grub.cfg, wherein ${cmdpath} is the path of the directory where the grub standalone file is located or launched from. The ${cmdpath} var is set by grub itself during runtime, and the "configfile ${cmdpath}/grub.cfg" command instructs grub to use the external grub.cfg as its config file.

I have grub working fine now. The use of the PARTUUID without quotes in the rEFInd manual stanza for the volume line still does not work though. I found that there was a crucial error in the creation process of the grub standalone efi file which I took from the arch wiki grub page. The creation line in the arch wiki is

grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi"  "/boot/grub/grub.cfg=/tmp/grub.cfg" -v

and the critical error is the inclusion of the / in the last part in quotes so the correct line should be

grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi"  "boot/grub/grub.cfg=/tmp/grub.cfg" -v

i.e. the section

"/boot/grub/grub.cfg=/tmp/grub.cfg"

should be

"boot/grub/grub.cfg=/tmp/grub.cfg"

So the set of commands that I use on my system to create the grub standalone and grub.cfg files is now:

# pacman -S grub
#  grub-mkconfig -o /boot/grub/grub.cfg
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "/boot/grub/grubx64_standalone.efi"  "boot/grub/grub.cfg=/tmp/grub.cfg"

And in rEFInd I have two manual stanzas. The first that will boot the arch kernel and has a submenu entry that works to boot the kernel via grub whilst the second boots grub and gives the normal grub boot options with the default going to the arch stock kernel.

menuentry "Arch Linux and grub" {
        icon EFI/refind/icons/os_linux.icns
        volume "59 GiB ext4 volume"
        loader /boot/vmlinuz-linux
        initrd /boot/initramfs-linux.img
        options "rw root=UUID=352b1b2e-575c-4757-90a8-c7d0162f5b9f PARTUUID=a01aa42a-8ece-4584-a632-bea1f042c80a quiet"
        ostype Linux
        submenuentry "boot via Grub" {
        loader /boot/grub/grubx64_standalone.efi
        initrd
        options
        }
}
menuentry Grub {
    volume "59 GiB ext4 volume"
    loader /boot/grub/grubx64_standalone.efi
    initrd
    options
}

So the information at the arch wiki page at https://wiki.archlinux.org/index.php/GR … Standalone is now correct.

I hope that this will help anybody else get rEFInd working to boot grub either via a submenu entry or booting grub directly. The main problem was the critical additional / in the grub-mkstandalone command. I have edited the wiki grub entry to fix that error and mark this thread as solved.

However the use of the PARTUUID for the volume line in my case does not work - it may be because I have the kernel in /boot/ which is an ext4 directory and not in the EFI which is mounted at /boot/efi but I am taking this up with the refind discussion at sourceforge where the rEFInd author usually responds directly to posts as an upstream rEFInd discussion as I think that this is not an arch-specific issue but a more general upstream rEFInd issue. I know that if the kernel was in the ESP then clearly the sample manual stanza given in a previous post in this thread shows that in that case the use of the PARTUUID to specify the volume does work but I don't know if this extends to the case where the kernel resides in a different partition to the ESP, and also on a different drive, is accommodated within rEFInd's capabilities.

So that remains a puzzle for the moment.

Last edited by mcloaked (2014-05-25 13:58:17)

mcloaked · 2014-05-25 17:04:14

It seems that the issue with using GUID values to specify the volume in manual rEFInd stanzas was due to this only being a supported feature of rEFInd from version 0.8.0 onwards, but the arch version is still at 0.7.9. I have had a valuable reply from the rEFInd author at https://sourceforge.net/p/refind/discus … c79a/#5e4d

I will need to download the upstream version of rEFInd and copy in the binary to replace that from the stock arch repo until the rEFInd package in arch gets updated.

Edit: I have just downloaded the gnu-efi build zipped package for version 0.8.1 of rEFInd from the author's web page and overwritten the refind_x64.efi file in my ESP so that the upstream binary is used instead of the stock arch one. The use of the partuuid to specify the partition containing the arch kernel and grub in the volume token of the manual stanza works perfectly now, so this is fuly resolved.

Last edited by mcloaked (2014-05-25 17:48:53)

Arch Linux

#1 2014-05-23 14:30:25

[SOLVED] Trying to chainload grub from rEFInd fails

#2 2014-05-23 14:41:43

Re: [SOLVED] Trying to chainload grub from rEFInd fails

#3 2014-05-23 14:57:16

Re: [SOLVED] Trying to chainload grub from rEFInd fails

#4 2014-05-23 21:38:03

Re: [SOLVED] Trying to chainload grub from rEFInd fails

#5 2014-05-24 03:06:38

Re: [SOLVED] Trying to chainload grub from rEFInd fails

#6 2014-05-24 07:06:09

Re: [SOLVED] Trying to chainload grub from rEFInd fails

#7 2014-05-25 01:58:48

Re: [SOLVED] Trying to chainload grub from rEFInd fails

#8 2014-05-25 02:20:10

Re: [SOLVED] Trying to chainload grub from rEFInd fails

#9 2014-05-25 07:25:25

Re: [SOLVED] Trying to chainload grub from rEFInd fails

#10 2014-05-25 07:30:21

Re: [SOLVED] Trying to chainload grub from rEFInd fails

#11 2014-05-25 17:04:14

Re: [SOLVED] Trying to chainload grub from rEFInd fails

Board footer