According to T62 it sounds like @tsimonq2 is definitively saying we need to set this to Ubuntu, or not change the behavior from the way Ubuntu sets it, which is to say we need to go with option #1. This may require doing some shell work ahead of time to set bootloaderEntryName programmatically.

This really depends on the functionality of Secureboot. If Secureboot is fine with the human-readable name saying "Lubuntu" and the machine-readable name saying "ubuntu", then we're fine here.

Well if you look, Darin Miller tested Secureboot when we did 19.04, and we had Lubuntu in it then, no?

Yeah, as far as I can tell, we had "ubuntu" as the machine-readable bootloader ID and "Lubuntu" as the human-readable.

@apt-ghetto Do you want to test the above while running it through sed "s/Ubuntu/Lubuntu/"?

The efibootloaderId from https://phab.lubuntu.me/source/calamares-settings-ubuntu/browse/master/lubuntu/modules/bootloader.conf$33 is something else and is used only when installed in the UEFI mode.
This value is taken for the name of the bootloader entry in the NVRAM (where UEFI is looking for the bootloader to choose) and the name of the folder on the EFI-System-Partition (ESP). Most users don't see these entries very often, because they don't change the UEFI boot order settings often and don't search in the folders on the ESP.
I don't know, if Secure Boot takes into account the path on the ESP. I don't think so.
Changing the efibootloaderId to lubuntu could create another "problem", especially when other *buntus are installed. If there are updates for Grub, it will execute a grub-install. I don't know, where the value for the option --bootloader-id comes from during the installation of the new Grub package. Maybe we have then an older Grub in $ESP\EFI\lubuntu and a newer Grub in $ESP\EFI\ubuntu and for each bootloader two entries in the NVRAM (shimx64.efi and grubx64.efi).
The other flavours use, as far as I know, ubuntu and I think it is a good idea to have a common base, so I don't recommend to change the efibootloaderId.

The variable GRUB_DISTRIBUTOR on the other hand is used both in UEFI and BIOS mode. There are several scripts in /etc/grub.d/ where the value is used. For example:

set_default_theme(){
        case $GRUB_DISTRIBUTOR in
                Tanglu|Ubuntu|Kubuntu)  # <======= Lubuntu doesn't match

This variable is used to create the boot entry in the Grub menu, which is visible to the user, if he has a dual/multi boot or if he has enabled the Grub menu. Changing it would require changes also in the scripts (which seems to be possible, see Kubuntu).

I guess, the result of T30 should be a separate package (something like grub-theme-lubuntu*.deb). Depending on this discussion, the theme will work only for Lubuntu (in case of "Lubuntu") or also for other users (in case of "Ubuntu") or the package contains also stuff explicitly for other flavours.

Please see also bug 1833490.

I think, the best (and easiest) solution is

GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`

Consider also, that if there is a Grub update, you can accept the version of the package maintainer.

It seems to me that this is a thorny issue that we're not going to easily fix. We should revert back to the canonical Ubuntu implementation. Until we completely understand the effects this will have, I don't think we should do some special magic especially if Kubuntu isn't doing it. The benefit is way too small relative to the potential detriment, as seen in that bug.

We should add a script at the end of installation, after it sets bootentries and makes directories under ESP, which will set

GRUB_DISTRIBUTOR=lsb_release -i -s 2> /dev/null || echo Debian

but the problem we will have, as @apt-ghetto said in the task description, is that lubuntu-grub-theme will not use the hummingbird logo, I will lookup what can I do about that.

Opened a feature request upstream. In the worst case, we can patch it ourselves, I guess.