I noticed a problem with rEFInd detecting the OS icon. When using a root partition with partition type GUID 4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709 and partition name "Linux x86-64 root (/)", it shows the generic Linux icon.
If I change the partition name to "Linux filesystem" it shows the the correct icon. I think because of IGNORE_PARTITION_NAMES in refind/lib.h.
I tried various partition types and names and it looks like the partition name (PARTLABEL) is the issue, if it contains "Linux" it uses the generic icon.
The partition name overrides the chosen icon even if the OS was detected correctly from /etc/os-release, I don't think this should happen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's working as designed. "Linux filesystem" is the default partition name for Linux filesystems in gdisk, so lots of partitions have that partition name, and rEFInd ignores the name "Linux filesystem" because it's too generic. Instead, rEFInd uses other partition icon hints in this case. A partition name of "Linux x86-64 root (/)", however, is not a standard/default partition name in gdisk or, AFAIK, in any other partitioning tool, so rEFInd assumes the user set that name and uses the partition name as a hint for what icon to use. There are cases in which the "Linux" in such a partition name might be the only hint of the OS -- say, if the partition were an ESP with nothing but the fallback boot loader (EFI/BOOT/bootx64.efi), which in fact held GRUB that boots Linux, so picking up on "Linux" in this context would produce the generic Linux icon, which would be correct.
OS tag icon selection is necessarily complex, given the number of ways to set an icon and the number of potentially conflicting icons. If there are conflicting hints -- say, if rEFInd detects references to Ubuntu, Bionic Beaver, and Linux -- the choice of which to use will be arbitrary on some level. The options for OS tag icon selection are laid out in the documentation:
I've just added some elaboration to this to note that certain partition names are ignored, since that information was absent. This change is not yet released, but is now in the git repository. It should be possible to override other options by setting a .VolumeIcon.png file in the partition's root directory.
More broadly speaking, the rules for icon selection have evolved over time, and so the prioritization of one method over another is admittedly confusing, even to me. I'd like to clean this up, but as potential icons are collected at various points in the code, this will require more work than it's worth to clarify this one issue. OTOH, this is a symptom of code that's grown dynamically and chaotically, and it does need to be cleaned up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're right; I'd forgotten about that. I may update IGNORE_PARTITION_NAMES in rEFInd appropriately; or I may completely re-do the partition icon assignment, since the haphazard way it's done is bugging me, now that you've raised the issue. ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed a problem with rEFInd detecting the OS icon. When using a root partition with partition type GUID
4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709and partition name "Linux x86-64 root (/)", it shows the generic Linux icon.If I change the partition name to "Linux filesystem" it shows the the correct icon. I think because of
IGNORE_PARTITION_NAMESinrefind/lib.h.I tried various partition types and names and it looks like the partition name (PARTLABEL) is the issue, if it contains "Linux" it uses the generic icon.
The partition name overrides the chosen icon even if the OS was detected correctly from
/etc/os-release, I don't think this should happen.That's working as designed. "Linux filesystem" is the default partition name for Linux filesystems in
gdisk, so lots of partitions have that partition name, and rEFInd ignores the name "Linux filesystem" because it's too generic. Instead, rEFInd uses other partition icon hints in this case. A partition name of "Linux x86-64 root (/)", however, is not a standard/default partition name ingdiskor, AFAIK, in any other partitioning tool, so rEFInd assumes the user set that name and uses the partition name as a hint for what icon to use. There are cases in which the "Linux" in such a partition name might be the only hint of the OS -- say, if the partition were an ESP with nothing but the fallback boot loader (EFI/BOOT/bootx64.efi), which in fact held GRUB that boots Linux, so picking up on "Linux" in this context would produce the generic Linux icon, which would be correct.OS tag icon selection is necessarily complex, given the number of ways to set an icon and the number of potentially conflicting icons. If there are conflicting hints -- say, if rEFInd detects references to Ubuntu, Bionic Beaver, and Linux -- the choice of which to use will be arbitrary on some level. The options for OS tag icon selection are laid out in the documentation:
http://www.rodsbooks.com/refind/configfile.html#icons
I've just added some elaboration to this to note that certain partition names are ignored, since that information was absent. This change is not yet released, but is now in the git repository. It should be possible to override other options by setting a
.VolumeIcon.pngfile in the partition's root directory.More broadly speaking, the rules for icon selection have evolved over time, and so the prioritization of one method over another is admittedly confusing, even to me. I'd like to clean this up, but as potential icons are collected at various points in the code, this will require more work than it's worth to clarify this one issue. OTOH, this is a symptom of code that's grown dynamically and chaotically, and it does need to be cleaned up.
Really?
https://sourceforge.net/p/gptfdisk/code/ci/master/tree/parttypes.cc#l132
You're right; I'd forgotten about that. I may update
IGNORE_PARTITION_NAMESin rEFInd appropriately; or I may completely re-do the partition icon assignment, since the haphazard way it's done is bugging me, now that you've raised the issue. ;)