Notes about commit 92df3f6f3e6b6aadd54829c923f45d5a947fbbd2

[Iavael]

Here are some notes about https://sourceforge.net/p/refind/code/ci/92df3f6f3e6b6aadd54829c923f45d5a947fbbd2/

1. Code doesn't handle raid arrays (software and hardware).
2. Instead of "mount and check FS type" behaviour, it's better to check fs type before mounting it with "blkid" coomand.
3. parted output is localized, so, for example, instead of flag "boot" there would be flag "загрузочный" in russian systems.
4. "grep and cut" could be implemented nicer and more accurate with awk for data in "delimiter-separated values" format. Like

parted $Drive print -m -s 2>/dev/null | awk -F: '$1 == "'$Drive'" { print $6 }'
LANG=C parted $Drive print -m -s 2>/dev/null | awk -F: '$7 ~ "boot" { print $1 }'

[Iavael]

Also it would be nice to be able to open tickets on SF.

[Roderick W. Smith]

Hardware RAID isn't an issue, since hardware RAID shows up under Linux pre-assumbled as regular devices (/dev/sda, /dev/sdb, and so on). Linux software RAID shouldn't be an issue, because the ESP should not be assembled in a software RAID array -- that's an error that can lead to data corruption, and not just from the rEFInd installation script. (EFI programs, including rEFInd, might write to such partitions, for instance.) Motherboard-based software RAID (aka "fake RAID") could be an issue, though, and I've added a test for that to the script; it should now skip any disk that's marked as part of such an array. Because I have no such setup myself, though, this is only tested as well as I could simulate it.

The filesystems have to be mounted, and the mounting can fail even if they're marked as being of type FAT, so testing after mounting is necessary. Doing more testing is therefore redundant. Note that any partition that's not of type FAT and that's marked with an ESP type code (that is, if it has a "boot flag" in parted) is set up incorrectly. Such partitions are rare. Thus, pre-testing might save a bit of CPU time, but only on very rare occasion.

Unfortunately, I know of only two tools in Linux that can identify ESPs by type code: parted and gdisk. Although gdisk uses hexadecimal type codes that would be more reliable than parted's localized words, gdisk is not installed on all computers, so I don't want to make the install script rely on it. If the LANG=C you used in your example fixes this problem, then that's great; I've incorporated it in the latest revision of the script. If not, then the script will simply fail to find the ESP in some cases. This is no worse than what it did before adding this feature, so it's still a net improvement.

I've replaced the grep/cut usage with your awk usage; however, I had to modify the second one because it wasn't working in all cases -- unfortunately, the string boot is used in two different flags, so it was necessary to match in a more complicated way. It was also necessary to limit the output because the code would fail if the disk had two marked ESPs with your version. (It now arbitrarily uses the first ESP.)

[Iavael]

Thanks for your fixes.

Hardware RAID isn't an issue, since hardware RAID shows up under Linux pre-assumbled as regular devices (/dev/sda, /dev/sdb, and so on).

I just remembered about cciss driver (with devices like /dev/cciss/c0t0d10), but forgot, that it's dropped in new kernels.
Also, in case of many controllers and SAS disks there may be multipath devices via device mapper with names like /dev/dm-{0..9}* , but I don't think that somebody would try to install refind on such configurations. :)

Linux software RAID shouldn't be an issue, because the ESP should not be assembled in a software RAID array -- that's an error that can lead to data corruption, and not just from the rEFInd installation script. (EFI programs, including rEFInd, might write to such partitions, for instance.)

Yep, it is so. But Linux mdraid can also handle fakeraid arrays in IMSM (actually, I have this one) or DDF formats, so it's better to iterate over /dev/md{0..9}* devices too.

The filesystems have to be mounted

The problem is that you try to mount filesystems and only then check it's filesystem. While blkid allows to check filesystem without mounting it. Like

blkid /dev/md1p2 -t PART_ENTRY_TYPE=c12a7328-f81f-11d2-ba4b-00a0c93ec93b -n vfat -p -s none && echo "It's ESP with FAT" || echo ":("

So it allows not to mount (and every mount causes write on the disk, even if it's with "ro" option) boot partitions without vfat on improperly configured disk layouts.
Also blkid is present on every linux systems with util-linux tools and as a bonus it could detect RAID-membered disks :)

Like

$ blkid /dev/sda /dev/sdc -p -t USAGE=raid
/dev/sda: VERSION="1.1.00" TYPE="isw_raid_member" USAGE="raid"
/dev/sdc: UUID="524f0468-ce00-06b0-f601-08a219beed28" UUID_SUB="4b9a632d-2b06-8c41-5707-0467dfb43693" LABEL="Data" VERSION="1.2" TYPE="linux_raid_member" USAGE="raid"

[Iavael]

I've just tried to implement a reliable way to automount ESP partition and decided, that it's impossible.
For example, if user attaches second disk with another ESP, which one should we try to mount on /boot/efi? Or does user really want always to automatically update his ESP's contents during every refind package update?

I think, that this automatics is pretty dangerous but cannot be smart enough to be reliable, so it shouldn't be done at all, or at least should be optional and definitely must not be executed in postinstall scripts.

For example, in Fedora the only time, when bootloader is installed automatically is in the end of operating system installation (and yet it still can be disabled). All updates of grub package don't cause updating bootloader in system itself and it is always done by users with explicit shell command execution by hands. And also no automagic fs mounting is performed too.