Will MX-25 come with secureboot?

[m_pav]

PDF updated and uploaded - ‘Secure Boot: How to‘ updated May 24, 2025

What are your thoughts on adding a link to the pertinent location in this thread into the document? Sometimes, folk reading through step-throughs have difficulty following them because they may be overthinking stuff.

[FullScale4Me]

I agree that an expansion is needed based on your comment and the one by dolphin earlier in this thread.

Luckily for all, I kept the longer form of this document, which had a more complete set of options beyond the single option presented in the linked document. I had taken the shortening because I thought it was the best path. I generally dislike these compact forms as they all too often leave out what you are referring to.

Yesterday I had an opportunity to devote a large block of time to resurrecting the longer one and then merging dolphin's posted method into it. After printing, I went through it and did a few hours of tweaking improvement scan of it - the resulting notes looks like a toddler scribbled all over it! This is very normal for me as I'm not a software screen tweaker kinda guy.

When I return from dinner out, I'll do the comment merge, add a graphic, and post a 'preliminary' watermarked version after doing a run-through test on bare metal of how I adapted dolphin's post to see if I made an actionable documentation of his post.

[fehlix]

minor corollary to the procedure.

you can do a fresh install on a secure boot enabled system, as long as you do the install AFTER installing the grub-efi-amd64-signed mokutil shim-signed packages (say, while running live). then use a chroot (chroot-rescue scan is easy) to do install the debian efi and do the mok key stuff. on first reboot, you confirm the mok key, and then continue on to boot the SB system, with the dkms modules intact and loadable.

after an install, including grub install, in the chroot (however you get into one)

Code: Select all

sudo grub-install bootloader-id=debian --no-nvram
sudo mokutil --import /var/lib/dkms/mok.pub
sudo reboot 

The MX Installer "minstall" creates when booted with secure boot and after having installed grub-efi-amd64-signed and shim-signed
(mokutil is already installed by default - I guess since MX-21)
an entry in NVRAM like this one:

Code: Select all

Boot000B* MX Linux	HD(2,GPT,689045a6-184b-473e-8c0f-d962306d94a6,0x1000,0x100000)/File(\EFI\MX\grubx64.efi)

which points to the grubx64-efi loader. But even this is now debian's signed grub-efi loader, secure boot needs to go through shim,
b/c only shim-efi loader is signed by MS and trying to boot directly grubx64.efi will be rejected and fails.
Now why is it booting: B/c the grub-install performed by "MX Installer" will create a working fallback loader within the
fallback directory /EFI/BOOT where shim is now /EFI/BOOT/BOOTx64.efi and in addtion debian's signed
grubx64.efi also copied into /EFI/BOOT/grubx64.efi.
So when rebooting the first entry in the boot order labeled as "MX Linux" (/EFI/MX/grubx64.efi) is ignored b/c not working with SB.
And UEFI will take shim at the fallback loader position, shim will find and load grubx64.efi and this will look for /EFI/debian/grub.cfg.
which looks like this:
EFI/debian/grub.cfg

Code: Select all

search.fs_uuid eaa74c5f-435f-4791-9e6a-3236ce674524 root 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

The installer would need adjusted, and instead of this exampled line:

Code: Select all

efibootmgr -qcL "MX Linux" -d /dev/vda -p 2 -l /EFI/MX/grubx64.efi

would need to check whether installing with sb enabled and having grub-efi-amd64-signed and shim-signed installed:

Code: Select all

efibootmgr -qcL "MX Linux" -d /dev/vda -p 2 -l /EFI/MX/shimx64.efi

Also the BOOTX64.CSV entry needs adjusted to carry the MX label like "MX Linux".
The one taken by grub-install look like this:
cat EFI/MX/BOOTX64.CSV

Code: Select all

shimx64.efi,debian,,This is the boot entry for debian

which can be done directly after installing shim-signed:

Code: Select all

echo "shimx64.efi,MX Linux,,This is the boot entry for MX Linux" | iconv -t UCS-2 | sudo tee /usr/lib/shim/BOOTX64.CSV

and grub-install would take the adjusted one. Or within the installer for the currently installation with:

Code: Select all

echo "shimx64.efi,MX Linux,,This is the boot entry for MX Linux" | iconv -t UCS-2 |  tee EFI/MX//BOOTX64.CSV

Why is this usefull? In case user wants bootentry "MX Linux" always on top, or dynamical generated
incase of NVRAM entries got lost. the fallback efiloader fbx64.efi copy in the fallback postion:

Code: Select all

cp /EFI/MX/fbx64.efi   /EFI/BOOT/fbx64.efi  

will be trigged by shim and re-generation a missing "MX Linux" boot entry at 1st position is performed.
B/c when boot from "disk" the shim ar EFI/BOOT/BOOTX64.efi first looks for fbx64.efi and next for grubx64.efi
if fbx64.efi was found a missing boot entry is added and placed on first position within the efi-boot order list.
and the name "MX Linux" of the re-genrated entry is the one from BOOTX64.CSV.
It may help users to see/find the "MX Linux" entry with EFI boot options list, or in case of Windows re-occupies/takes over the first boot entry, it helps the re-gain that position again.
ttfn
++EDIT+++
Re this step performed:

Code: Select all

sudo grub-install bootloader-id=debian --no-nvram

could be simplified with just this: on the ESP (e.g within chroot "visited" just installed "MX Linux" or simply manually mounted ESP ):

Code: Select all

mkdir /EFI/debian
# or
rm /EFI/debian/*
# and
cp /EFI/MX/grub.cfg  /EFI/debian/grub.cfg 

b/c only grub.cfg is needed, not the full installed debian directory.

[dolphin_oracle]

good point. I didn't get to the fallback, I manually selected the entry with "shim64.efi" in it. interestingly, this shows up in nvram as a lowercase mx where by the usual grub-install shows up with a capital MX. the actual files in the fat32 ESP are all in the same MX folder though.

**edit*** just saw your edit with the simplification. will try that next go around.

[fehlix]

good point. I didn't get to the fallback, I manually selected the entry with "shim64.efi" in it. interestingly, this shows up in nvram as a lowercase mx where by the usual grub-install shows up with a capital MX. the actual files in the fat32 ESP are all in the same MX folder though.

**edit*** just saw your edit with the simplification. will try that next go around.

* booting from disks will make efi look for the first ESP on that drive and try to boot /EFI/BOOT/BOOTx64.efi.
* It would be safer sticking with lowercase only, to avoid any efi-fat-driver issue with lower/upper case, at least that's why ubuntu and debian always use lowercase,
and grub-install will always convert to lower case the string found in DISTRIB_ID of /etc/lsb-release for both the bootloader-id and the directory, if not manually specified with --bootloader-id=

[fehlix]

2add: another issue with the MX Installer
when the nvram entry get generated as shown this example line::

Code: Select all

efibootmgr -qcL "MX Linux" -d /dev/vda -p 2 -l /EFI/MX/grubx64.efi

which would be adjusted to installing shim, ( maybe we use longer form for better readability):

Code: Select all

efibootmgr --quiet --create --label  "MX Linux" --disk /dev/vda --part 2 --loader '\EFI\MX\shimx64.efi'

This for sometime now always trigger a warning, b/c any existing "MX Linux" entry will not be replaced,
but an additional entry will be added.

Code: Select all

efibootmgr: ** Warning ** : Boot0001 has same label MX Linux

If you reinstall a further entry will be added, instead of replaced.
And the issue is: If the existing entry was made with a non-secureboot install , like this entry:

Code: Select all

Boot0001* MX Linux	HD(2,GPT,689045a6-184b-473e-8c0f-d962306d94a6,0x1000,0x100000)/File(\EFI\MX\grubx64.efi)

the user would now have two or more entries one which would not work with secureboot and identical labeled "MX Linux" one which would work:

Code: Select all

Boot000B* MX Linux	HD(2,GPT,689045a6-184b-473e-8c0f-d962306d94a6,0x1000,0x100000)/File(\EFI\MX\shimx64.efi)

So the logic with the installer seems to be broken to "replace" an existing entry, but of course only an entry related to that one ESP involved.
We could avoid this simply be going back what we had and keep bootloader-id and directory identical eg. just to "MX",
or just lowercase "mx" and let grub-install do this, b/c grub-install will replace an existing entry and would not create an additional one.

[dolphin_oracle]

the shim entry would work whether secure boot enabled or not?

@fehlix

so something like this:

Code: Select all

 // Add a new NVRAM boot variable.
            if (fitesp != partman.mounts.end()) {
                const PartMan::NameParts &bs = PartMan::splitName(fitesp->second->name);
                
                //efi size & secureboot
                //if 32, don't bother with secure boot
                //if 64, check for secure boot shimx64.efi
                QString efitype;
                if (efisize==32){
                    efitype="/grubia32.efi";
                } else {
                    efitype="/grubx64.efi";
                    if (QFile("/usr/lib/shim/shimx64.efi").exists()){
                        efitype="/shimx64.efi";
                    }
                }
                proc.exec("efibootmgr", {"-qcL", loaderLabel, "-d", "/dev/"+bs.drive, "-p", bs.partition,
                    "-l", "/EFI/" + loaderID + efitype});

in this case, loaderLabel and loaderID are both lowercase (set earlier).

[fehlix]

the shim entry would work whether secure boot enabled or not?

yes! There is also an identical but unsigned shim, which would have the benefit to introduce
the dynamical fallback re-generation. The shim functionality
to look for fbx64.efi or for grubx64.efi within the same /EFI/BOOT directory,
is not dependent of signed or not. So having always shim involved may help not only with secure boot.
Also on LiveBoot it is using idetical way for non-secureboot , BOOTX64.efi is shimx64.efi
on the LiveESP, and it loads grubx64.efi found with the same directory, which further looks for grub.cfg under /boot/grub.
That's also the reason why in LiveBoot we have a fallback.efi, b/c on some older Dell liveboot efi-system always tried
to load fallback.efi instead of grubx64.efi. fallback.efi was an early name used by fedora not longer used and now only fbx64.efi is used.
BitJam found and fixed that historical bug for some of the older EFI-systems by introducing fallback.efi as a copy of grubx64.efi.

[fehlix]

so something like this:

Code: Select all

 // Add a new NVRAM boot variable.
            if (fitesp != partman.mounts.end()) {
                const PartMan::NameParts &bs = PartMan::splitName(fitesp->second->name);
                
                //efi size & secureboot
                //if 32, don't bother with secure boot
                //if 64, check for secure boot shimx64.efi
                QString efitype;
                if (efisize==32){
                    efitype="/grubia32.efi";
                } else {
                    efitype="/grubx64.efi";
                    if (QFile("/usr/lib/shim/shimx64.efi").exists()){
                        efitype="/shimx64.efi";
                    }
                }
                proc.exec("efibootmgr", {"-qcL", loaderLabel, "-d", "/dev/"+bs.drive, "-p", bs.partition,
                    "-l", "/EFI/" + loaderID + efitype});

in this case, loaderLabel and loaderID are both lowercase (set earlier).

Havn't seen you'r additon until just now..

* generation of an NVRAM boot variable with the current implementation fails to remove (or better update) an exsiting one
which makes whith every install attempt another boot-entry into the nvram.

* we have two shim's unsigned and signed:

Code: Select all

/usr/lib/shim/shimx64.efi
/usr/lib/shim/shimx64.efi.signed

where grub-install if secure-boot detected will use /usr/lib/shim/shimx64.efi.signed
So, as this is currently run after "grub-install --no-nvram ...",
we might check an existing shim at /EFI/loaderID/shimx64.efi, which was added by grub-install.
and use this , otherwise use grubx64.efi

[dolphin_oracle]

Havn't seen you'r additon until just now..

* generation of an NVRAM boot variable with the current implementation fails to remove (or better update) an exsiting one
which makes whith every install attempt another boot-entry into the nvram.

yep, that will be the next thing. just trying to make something work now.

* we have two shim's unsigned and signed:

Code: Select all

/usr/lib/shim/shimx64.efi
/usr/lib/shim/shimx64.efi.signed

where grub-install if secure-boot detected will use /usr/lib/shim/shimx64.efi.signed
So, as this is currently run after "grub-install --no-nvram ...",
we might check an existing shim at /EFI/loaderID/shimx64.efi, which was added by grub-install.
and use this , otherwise use grubx64.efi

ah, gotcha.