Well, as long as you apply custom non-mainline patches, I can sort things out transparently for Legacy boot in Rufus, if you set a custom version string for the GRUB used for ISO boot, such as what is currently the case with
grub-2.03.5 (since there is no such thing as mainline
grub-2.03.5 or even a
grub-2.03, though I would advise to perhaps use a more specific suffix to indicate that it's a Manjaro version, such as
grub-2.04-manjaro, in case other distros produce a custom version and decide to add a
That's actually the whole point of the lookup+fallback mechanism used by Rufus to deal with Legacy GRUB
core.img (since that's one critical component we need for GRUB installation, and that we can't derive it from the files on the ISO), as, if we find a custom version string, we check if there exists a repository for that custom version on the Rufus server and use the
core.img from that folder if that is the case. If not, then we try to fall back to the nearest version from the server or use the
core.img embedded in Rufus (currently 2.02 since there is no official 2.03 and the next version is going to be 2.04).
Therefore, if you apply patches that are not yet in mainline, then as long as you also apply a custom-enough suffix to your version, I can sort things out through the GRUB lookup mechanism in Rufus, which is designed precisely for this kind of thing.
Of course, nothing beats using mainline wherever possible. As a matter of fact, I asked Fedora's Hans de Goede, who is the person behind the
grub-accept-esc-f8-and-holding-shift-as-user-interrupt-key.patch and other Fedora stuff, and who I worked with on libusb in the past, to see if he could re-submit that patchset to mainline, as it appears the set was submitted last year, but didn't get applied due to a v2 being requested by the GRUB maintainers. At the time, Hans said he would carry out that work and resubmit but, from what I can see, never got around to do so.