rEFInd + softlinks = weird

[The Doctor]

Hi,

I am having a weird problem with the rEFInd boot manager. Since I want the flexibility given by specifying a config without the hassle of updating it for each kernel I have implemented a solution using soflinks. REFInd throws an error on the first boot attempt. After rebooting with a rescue media or backup kernel and then remaking the soft link it works.

Does anyone have any ideas about what is happening and how to fix it?

[khayyam]

Since I want the flexibility given by specifying a config without the hassle of updating it for each kernel I have implemented a solution using soflinks.

Doc' ... you don't need to update the config at all, rEFInd will autodetect any efi executable that has an efi suffix and offer it as a boot option (with the most recent as the first/default). It will also detect initramfs based on the continuity between the kernel name and that of the initramfs.cpio.gz (you could also, as I do, build in the intramfs into the kernel). If its a question of providing kernel parameters then a 'refind_linux.conf' in the root of /boot (or wherever you store the kernels) can be used for the same purpose ...

Code: Select all

# print -rl /boot/*
/boot/efi
/boot/refind_linux.conf
/boot/vmlinuz-3.10.29-geek.efi
/boot/vmlinuz-3.10.37-geek.efi
/boot/vmlinuz-3.13.11-ck.efi
# egrep -v '(^#|^$)' /boot/efi/refind/refind.conf
timeout 5
hideui banner
use_graphics_for linux
showtools shell, reboot, exit
dont_scan_dirs efi/grub2
# cat /boot/refind_linux.conf
"Boot softlevel default"  "ro nopat threadirqs acpi_backlight=vendor rootfstype=ext4 luks enc_root=/dev/sda2 lvm root=/dev/mapper/vg-root swsusp resume=/dev/mapper/vg-swap"
"Boot softlevel online"   "ro nopat threadirqs acpi_backlight=vendor rootfstype=ext4 luks enc_root=/dev/sda2 lvm root=/dev/mapper/vg-root swsusp resume=/dev/mapper/vg-swap softlevel=online" 
"Boot softlevel single"   "ro nopat threadirqs acpi_backlight=vendor rootfstype=ext4 luks enc_root=/dev/sda2 lvm root=/dev/mapper/vg-root swsusp resume=/dev/mapper/vg-swap softlevel=single"

I never have to edit anything on updating the kernel, just copy it to /boot and voila.

HTH & best ... khay

[The Doctor]

Doc' ... you don't need to update the config at all, rEFInd will autodetect any efi executable that has an efi suffix and offer it as a boot option (with the most recent as the first/default).

True, but the way it does it is kind of annoying. What I did was write a general Gentoo entry with a rescue option so the boot menu looks nicer. In theory it should have worked the same way, just copy the new kernel to /boot and update a few symbolic link and it would work out of the box and preserve a versioned naming scheme for the kernels.

Honestly, I am mostly curious why refined can't follow symbolic link fails the first time but works if redone after a failed boot attempted.

[GabrielYYZ]

Even better, with the option "scan_all_linux_kernels" on in refind.conf, you don't even have to add the .efi extension as long as your kernel's name is vmlinuz-* or bzImage-*.

[khayyam]

Honestly, I am mostly curious why refined can't follow symbolic link fails the first time but works if redone after a failed boot attempted.

Doc' ... yeah, that does seem a little weird. Rod Smith (the rEFInd author) is often reading here so perhaps he can offer an answer, it may be a bug.

best ... khay

[srs5694]

By design, recent versions of rEFInd should ignore symbolic links. The reason is that many distributions set them up to point to specific kernels in the same directory (say, the symlink vmlinuz points to vmlinuz-3.10.0 or vmlinuz-3.12.0), in which case the symlink adds pointless clutter; or they point to entirely different partitions, in which case the symlink doesn't work at all.

If you could provide more details about what it is you want to accomplish, perhaps I could suggest another way to do it. In my experience, people who are used to the LILO, SYSLINUX, or GRUB way of setting up boot loaders often go straight for the hardest way to do things in rEFInd.

[The Doctor]

Basically, I was doing exactly that: copying vmlinuz-3.10.0.efi to /boot and symlinking it to vmlinuz.efi, I know rEFInd's newer versions ignore symbolic links. I have changed my setup now so it does the reverse: it copies the entry and creates a version symlink, so it should work reliably now.

What got me is that I tested it to see if it would ignore a symlinked kernel if it was defined as an entry in the refined.conf. That worked fine or I would have dropped the idea. Then when I updated to a new kernel everything broke. After remaking the link it was back to working. This is with no change to rEFInd at all.

Hence the thread. The fact that it worked except in one situation repeatably worked made me want to find out why. As far as I know the two symbolic links should have been identical in every way.

[srs5694]

The symlink may have failed because of driver issues. EFI doesn't recognize symlinks. The rEFInd filesystem drivers try to present symlinks as if they were the linked-to files, but there are some quirks. For instance, there are (at least) two different ways to find a file's size in EFI. When done on a symlink, one of these methods returns the size of the symlink (which is quite small) and the other returns the size of the symlinked file. (That's how rEFInd identifies symlinks -- if these two sizes are not identical, rEFInd assumes the file is a symlink.) This issue, or some other quirk, may have caused inconsistent results when you tried to use a symlink.

You still haven't said precisely what it is you're trying to accomplish. By that, I don't mean something like "use symlinks to identify the kernel to be launched by default" -- that's the means to the end. I mean something like "reduce the number of options on the menu" or "have rEFInd boot the most recent kernel by default."

[The Doctor]

Thanks for the explanation.

What I am trying to do is simplify the boot options that rEFInd presents. Left on its own auto config finds a bunch of kernels in my /boot directory since I tend to be a bit of a pack rat in that regard. Since my laptop tends to go back and forth between using windows and linux I'm trying to simply the options to either windows or linux without extra clutter.

[srs5694]

You could try organizing the kernels. For instance:

Code: Select all

/boot
  /boot/vmlinuz-3.13.3
  /boot/vmlinuz-3.13.2
  /boot/older
    /boot/older/vmlinuz-3.11.2
    /boot/older/vmlinuz-3.12.2
    /boot/older/vmlinuz-3.12.3

rEFInd won't scan the /boot/older directory, but if you also have either a second rEFInd installation or a supplemental configuration file that's loaded by a manual rEFInd option, you could then get access to those options. For instance, a manual entry in the main refind.conf might look like this:

Code: Select all

menuentry "Additional kernels" {
        icon \EFI\refind\icons\os_refind.png
        loader \EFI\refind\refind_x64.efi
        options "-c refind_extra.conf"
}

If refind_extra.conf includes "also_scan_dirs + /boot/older", then the result will be that your main rEFInd will show just the 3.13.x kernels in /boot, whereas the secondary rEFInd will show all the kernels, including those in /boot/older. Note that your initrd files (if you use them) will have to reside in the same directory as their matched kernels.

Admittedly this does require some configuration, in the form of moving kernels and initrd files between directories, but it's reasonably low-maintenance.