Hi Everyone,
i've decided to install Arch on my 2010 MB Pro so I could power off the faulty nVidia card.
Everything worked fine with the boot (autodetect with the ext4 driver), however I had to patch the kernel in order to vga_switcheroo work properlly.
With this new compiled kernel - linux-custom - the auto detect is not working. It does find the kernel, however to boot I need to, everytime, change the boot options. the initrd is equals to initramfs-linux.img and not initramfs-linux-custom.img
Is there any way to fix this our should I create a stanzas? If the last option is the best, how should I do it? The img is not in the EFI parition.
Thanks :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
rEFInd's mapping of kernels to initrd images is based on version number strings, since every major distribution except Arch uses this method. If you've built a new initrd to match your kernel, the easiest way to get it working is likely to be to include a number in your kernel and initrd filenames. Even a single digit should work (although that's not been well tested). If you're using an existing initrd, you might try giving the kernel a name that includes a number and then create a link from the original initrd to a copy that includes the same number you give the kernel.
Another approach is to put your custom kernel in its own subdirectory and then having rEFInd scan that subdirectory. You might piggyback on rEFInd's normal directory scanning (say, "boot" or "EFI/mykernel") or use also_scan_dirs in refind.conf to add your directory.
Also, Arch's two-initrd approach (the standard one and a secondary one for emergencies) is unique. This is most easily handled in rEFInd by adding "initrd=" specifications in refind_linux.conf. One line can point to the regular initrd file and the other to the secondary file. If you don't do this, there's a chance that rEFInd will pick up the wrong initrd file if/when they're updated, since rEFInd simply uses the first one it finds, and there's no guarantee that the EFI will return the one you want first.
Using manual boot stanzas will also work, an is popular among Arch users. This method is similar in rEFInd to the equivalnt in ELILO, SYSLINUX, or even a manually-configured GRUB. IMHO, it's generally harder, but you do need to know the preceding tricks to get the auto-detection to work properly with Arch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Ubuntu I am having the same issue when using the lowlatency version of the kernel. The naming convention there is "(version number)-(flavour)", where flavour can be "lowlatency" or "generic" for both the initial ramdisk and the kernel image. Since refind only looks for a version number that is delimited by numbers it misses the "-lowlatency" part.
I feel like this is a common problem that could be fixed. I don't understand why the whole string after the file "type" wouldn't be used as the version string. Also, the way that refind is currently working doesn't seem to be a well known standard since Ubuntu doesn't implement it that way. Maybe some written standard could be created and popularized ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That version introduces an extension to the initrd-finding code so that, if multiple initrd files match the kernel, the one that matches the most characters from after the kernel version string in the kernel file will be used. That should work with your -lowlatency kernels.
From a rEFInd perspective, the Arch issue is entirely different and has long been easily handled by creating suitable configuration files in rEFInd.
Note that the whole string after the kernel version number cannot be used because some distributions (including Ubuntu) sometimes place extra stuff in the kernel filename that's not present in the initrd filename. When Ubuntu is used with signed kernels, for instance, the kernel filename ends in .efi.signed, which is not part of the initrd filename.
AFAIK, there is no standard for kernel naming -- at least, not in sufficient detail to uniquely map initrd files to kernel files. Getting the many different distribution maintainers to accept a new standard is like herding cats -- just look at the Freedesktop.org Boot Loader Spec, which has been languishing, largely ignored, for years.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I installed the 0.10.5 version from the Ubuntu PPA and I now have the expected functionnality. Thank you very much for your work.
The way this functionnality is implemented seems like there would be a lot more string parsing than before since refind must compare initrd names after having already parsed them and matched the version number.
Would switching to the boot directory configuration specified in the Boot Loader Specification help solve this problem of associating kernel images to initrd images ? As I understand it the proposed solution is that "It is recommended that every distribution creates a machine id and version specific subdirectory below $BOOT and places its kernels and initial RAM disk images there". Then every kernel+intird association would be under a directory that can be auto detected by refind.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The extra parsing is mainly done only if there are multiple initrd files that match a particular version string. The impact on other configurations should be relatively small.
Use of the Boot Loader Spec would reduce parsing time, at least if rEFInd were to abandon its current method (or provide an option to disable it); however, to the best of my knowledge, no major distribution is supporting the Boot Loader Spec, so there doesn't seem to be much point to adding that support to rEFInd.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Everyone,
i've decided to install Arch on my 2010 MB Pro so I could power off the faulty nVidia card.
Everything worked fine with the boot (autodetect with the ext4 driver), however I had to patch the kernel in order to vga_switcheroo work properlly.
With this new compiled kernel - linux-custom - the auto detect is not working. It does find the kernel, however to boot I need to, everytime, change the boot options. the initrd is equals to initramfs-linux.img and not initramfs-linux-custom.img
Is there any way to fix this our should I create a stanzas? If the last option is the best, how should I do it? The img is not in the EFI parition.
Thanks :)
rEFInd's mapping of kernels to initrd images is based on version number strings, since every major distribution except Arch uses this method. If you've built a new initrd to match your kernel, the easiest way to get it working is likely to be to include a number in your kernel and initrd filenames. Even a single digit should work (although that's not been well tested). If you're using an existing initrd, you might try giving the kernel a name that includes a number and then create a link from the original initrd to a copy that includes the same number you give the kernel.
Another approach is to put your custom kernel in its own subdirectory and then having rEFInd scan that subdirectory. You might piggyback on rEFInd's normal directory scanning (say, "boot" or "EFI/mykernel") or use also_scan_dirs in refind.conf to add your directory.
Also, Arch's two-initrd approach (the standard one and a secondary one for emergencies) is unique. This is most easily handled in rEFInd by adding "initrd=" specifications in refind_linux.conf. One line can point to the regular initrd file and the other to the secondary file. If you don't do this, there's a chance that rEFInd will pick up the wrong initrd file if/when they're updated, since rEFInd simply uses the first one it finds, and there's no guarantee that the EFI will return the one you want first.
Using manual boot stanzas will also work, an is popular among Arch users. This method is similar in rEFInd to the equivalnt in ELILO, SYSLINUX, or even a manually-configured GRUB. IMHO, it's generally harder, but you do need to know the preceding tricks to get the auto-detection to work properly with Arch.
On Ubuntu I am having the same issue when using the lowlatency version of the kernel. The naming convention there is "(version number)-(flavour)", where flavour can be "lowlatency" or "generic" for both the initial ramdisk and the kernel image. Since refind only looks for a version number that is delimited by numbers it misses the "-lowlatency" part.
I feel like this is a common problem that could be fixed. I don't understand why the whole string after the file "type" wouldn't be used as the version string. Also, the way that refind is currently working doesn't seem to be a well known standard since Ubuntu doesn't implement it that way. Maybe some written standard could be created and popularized ?
Could you give this version a try:
http://www.rodsbooks.com/refind-bin-0.10.4.4.zip
That version introduces an extension to the initrd-finding code so that, if multiple initrd files match the kernel, the one that matches the most characters from after the kernel version string in the kernel file will be used. That should work with your
-lowlatencykernels.From a rEFInd perspective, the Arch issue is entirely different and has long been easily handled by creating suitable configuration files in rEFInd.
Note that the whole string after the kernel version number cannot be used because some distributions (including Ubuntu) sometimes place extra stuff in the kernel filename that's not present in the initrd filename. When Ubuntu is used with signed kernels, for instance, the kernel filename ends in
.efi.signed, which is not part of the initrd filename.AFAIK, there is no standard for kernel naming -- at least, not in sufficient detail to uniquely map initrd files to kernel files. Getting the many different distribution maintainers to accept a new standard is like herding cats -- just look at the Freedesktop.org Boot Loader Spec, which has been languishing, largely ignored, for years.
I installed the 0.10.5 version from the Ubuntu PPA and I now have the expected functionnality. Thank you very much for your work.
The way this functionnality is implemented seems like there would be a lot more string parsing than before since refind must compare initrd names after having already parsed them and matched the version number.
Would switching to the boot directory configuration specified in the Boot Loader Specification help solve this problem of associating kernel images to initrd images ? As I understand it the proposed solution is that "It is recommended that every distribution creates a machine id and version specific subdirectory below $BOOT and places its kernels and initial RAM disk images there". Then every kernel+intird association would be under a directory that can be auto detected by refind.
The extra parsing is mainly done only if there are multiple initrd files that match a particular version string. The impact on other configurations should be relatively small.
Use of the Boot Loader Spec would reduce parsing time, at least if rEFInd were to abandon its current method (or provide an option to disable it); however, to the best of my knowledge, no major distribution is supporting the Boot Loader Spec, so there doesn't seem to be much point to adding that support to rEFInd.