I guess that’s a pretty reasonable approach, thanks for sharing.
Now your boot path for Endless is:
Ubuntu shim -> Ubuntu grub -> Endless shim -> Endless grub -> Endless Linux kernel
When Secure Boot is on, Endless’s grub will call into shim to verify that the Endless Linux kernel was signed and distributed by Endless. Otherwise it will not boot further.
The question is in this case, which shim receives that request? Since while Endless’s shim would be happy to verify the signature on the Endless kernel, the Ubuntu shim naturally would see it as untrusted.
If it’s not booting in that config then it seems likely that Ubuntu’s shim is the one that is “in effect” here, which would not be too surprising, seems reasonable that the first shim wouldn’t have any provisions to allow it to be replaced by another chainloaded instance. So turning off secure boot is a quick way to avoid this issue.
You may have another option that lets you leave secure boot enabled though. Search around for how to access MOK/MokManager/mokutil within Ubuntu. This tool will let you enroll further certificates or keys within the boot process. If you can find a way to enroll the Endless certificate, then hopefully Endless-signed kernels would become trusted by this boot process.
You can download the Endess certificate from https://github.com/endlessm/shim/raw/debian-master/debian/endless-ca.cer