Right now, the (ahci)/(ata) variable expands to list partitions from highest (ex: achi0,msdos3) to lowest (ahci0,msdos1). The main grub menuentry script therefore tries to mount the luks partitions in that order. Most installers will put boot at the first partition, not the last. So when a user has an encrypted boot partition and a separate encrypted root partition they have to decrypt both.
The latest commit in my personal git builds reverses the order of the list and breaks the loop once a partition is successfully mounted.
https://github.com/shmalebx9/Bleeding-Libreboot/commit/5767489cadc4a9a1f2e7bffe03457e29e1c9a101
I think it's probably a fair trade off, since it will only fail to boot where the user has a separate encrypted root and boot partition AND the boot partition is after the root partition on the partition table (which is uncommon afaik).
I'm reticent to make a PR though, because the argument reversal is done with a for-loop. I imagine there must be a cleaner way to do the argument reversal.
Right now, the (ahci*)/(ata*) variable expands to list partitions from highest (ex: achi0,msdos3) to lowest (ahci0,msdos1). The main grub menuentry script therefore tries to mount the luks partitions in that order. Most installers will put boot at the first partition, not the last. So when a user has an encrypted boot partition and a separate encrypted root partition they have to decrypt both.
The latest commit in my personal git builds reverses the order of the list and breaks the loop once a partition is successfully mounted.
https://github.com/shmalebx9/Bleeding-Libreboot/commit/5767489cadc4a9a1f2e7bffe03457e29e1c9a101
I think it's probably a fair trade off, since it will only fail to boot where the user has a separate encrypted root and boot partition AND the boot partition is after the root partition on the partition table (which is uncommon afaik).
I'm reticent to make a PR though, because the argument reversal is done with a for-loop. I imagine there must be a cleaner way to do the argument reversal.
Right now, the (ahci)/(ata) variable expands to list partitions from highest (ex: achi0,msdos3) to lowest (ahci0,msdos1). The main grub menuentry script therefore tries to mount the luks partitions in that order. Most installers will put boot at the first partition, not the last. So when a user has an encrypted boot partition and a separate encrypted root partition they have to decrypt both. The latest commit in my personal git builds reverses the order of the list and breaks the loop once a partition is successfully mounted. https://github.com/shmalebx9/Bleeding-Libreboot/commit/5767489cadc4a9a1f2e7bffe03457e29e1c9a101 I think it's probably a fair trade off, since it will only fail to boot where the user has a separate encrypted root and boot partition AND the boot partition is after the root partition on the partition table (which is uncommon afaik). I'm reticent to make a PR though, because the argument reversal is done with a for-loop. I imagine there must be a cleaner way to do the argument reversal.
i've now merged this patch which you linked. the way you did it is good enough. thank you for your contribution