MX Linux Forum

I am new to this forum and just in the process of replacing mt tower PC. The new machine came with an SSD with Windows 10 on it which I disconnected and instead installed a brand new 500Gb SSD. The machine has SecureBoot enabled and legacy options turned off in BIOS. Windows 10 boots from and EFI partition.

First, I installed MX Linux 19.4.1 from CD. The CD booted fine and the install proceeded without incident. I kind of cheated and selected the whole disk initially to see how the installer would configure it and then cancelled the file copy process, went back into the partition tools and manually partitioned the SSD. I plan to install at least two Linux distros so the SSD has an ESP partition, an Ext4 partition and a swap partition for MX Linux and another Ext4 and swap partition for Mint. The first problem became apparent immediately after reboot upon which I got the message:
I figured I would come back to this and proceeded to install Linux Mint. There is a part during the install process where one can select to install additional codecs which requires SecureBoot to be enabled. I enabled this option. The installation proceeded just fine and on re-boot I got a different GRUB menu installed by MInt. The first time I chose to boot into Mint I got a dialog asking me whether I wanted to run something called MOKUTIL or perform a secure key operation (upload or download keys from BIOS I think?) on SecureBoot. Not being sure what the purpose of these options was, I selected the default option and proceeded with boot. Boot completed and I got the Mint desktop. I then rebooted and from GRUB opted to go back into MX Linux. This time I got:
Since this is a new clean installation, I figured I would just re-install MX Linux but after installation, I still got the Mint version of GRUB and the same error.

Having Googled these errors it would seem that the kernel needs to be signed for SecureBoot and there is a discussion of the process here, although this is for Ubuntu:

https://askubuntu.com/questions/1081472 ... -signature

The other option that is put forward by some is to simply disable SecureBoot. The problem with that option is that Windows 11 is around the corner and when it arrives, I will be installing that onto the SSD that contains the Windows 10 partition. It is my understanding that SecureBoot is mandatory for Windows 11. I therefore would like to avoid tuning it off and would rather proceed with the modern and safer way of doing things.

The question now is, will that procedure in the link work for MX Linux? Is there a recommended way of doing this for MX?
I am also curious why the DVD booted and had not problem with SecureBoot, but the installed system did not and instead reported the first error?

UPDATE: I have found that after disabling SecureBoot, the machine automatically booted into the original MX Linux themed GRUB and allowed me to boot run MX Linux. I also found that I could access the MX Linux themed GRUB by selecting MX19 from the UEFI boot menu. This did at least allow me to boot into MX and run update-grub2. I Now have access to both operating systems. Re-enabling SecureBoot and using the UEFI menu got me to the original "Incompatible with SecureBoot" error.

I did also find this thread:

viewtopic.php?t=58496

The author details how to enable SecureBoot for MX Linux. However, he does mention the incompatibility with Broadcom drivers, NDIS and VirtualBox. I don't think this Dell machine has and Broadcom hardware, but do make use of VirtualBox so that will be an issue. I will be checking out resources for VirtualBox on that matter.

We already suggest almost in every thread to turn off secure boot when there's such an option in Bios (also "Fast Boot")

There's also this one if you'd like to try: viewtopic.php?p=566375#p566375

Thank you. That is almost the same instruction including the purging of certain driver packagaes and VirtualBox.

With Microsoft using its clout to force the issue in its next OS release, this is going to prove interesting. Will we have to go into BIOS and enable/disable SecureBoot every time we want to switch between Linux and Windows? How long will it be before disabling SecureBoot is no longer supported in BIOS?

UPDATE: Just found these two links which seems to suggest that VirtualBox 6.0.10 (and presumably upwards) has support for UEFI secure boot:

https://www.linuxuprising.com/2019/07/v ... -boot.html

https://ubuntuhandbook.org/index.php/20 ... t-support/

Will have to give it some thought and maybe try and see what happens. At this stage I can still wipe the SSD and start again if necessary.

I tried that process on my new machine (both links in #2 and #3 contain the same information) but unfortunately I can't get secure boot to work.

The first command to purge dkms related packages worked fine.

The second command to install shim-signed and other grub related packages I had trouble with because version 2.02+dfsg1-20 could not be found and was reported as a missing dependency. However I was able to install the following packages individually:

shim-signed
grub-efi-amd64-signed
linux-image-amd64

Both grub-efi-adm64-bin and grub-common were reported as already being at the latest version so I had no reason to do anything else with them. I don't know how old those instructions are but at this point I assumed that I had all of the required packages installed - although some with later versions - and proceeded to the next step.

When installing grub-efi-amd64-signed I was prompted as described to replace /etc/grub.d/10_linux. I selected 'N' as instructed. I was also prompted to replace /etc/grub.d/30_os-prober. Since the original file has to be copied back, I selected 'N' here as well to leave the current file in place. This is a new installation so the file should be original. I was not able to find the path /usr/local/share/live-files/.... but then again, this looks like maybe a path on the live DVD? I was booted into the MX partition on the SSD. In order to do this, Secure Boot was turned off in BIOS.

The last instruction to 'pin' certain files succeeded without a problem. I re-enabled secure boot, re-booted but still got the previous errors. I also tried update-grub2 but this made no difference.

Not sure where to go from here.

Incidentally I noticed that Mint 20 no longer has VirtualBox installed by default...

Fehlix has just drawn my attention on another thread to a little detail that I missed in the first link back in post #2:

viewtopic.php?p=654509#p654509

I had a look at /boot/efi/ but there is no EFI/debian directory in there, only EFI/MX19, EFI/ubuntu and EFI/BOOT. Curiously EFI/MX19 has only 1 file in it called grubx64.efi while the others have a number of files in them. Not sure whether that is of any significance.

Mirador wrote: Sun Sep 26, 2021 1:42 pm Fehlix has just drawn my attention on another thread to a little detail that I missed in the first link back in post #2:

viewtopic.php?p=654509#p654509

I had a look at /boot/efi/ but there is no EFI/debian directory in there, only EFI/MX19, EFI/ubuntu and EFI/BOOT. Curiously EFI/MX19 has only 1 file in it called grubx64.efi while the others have a number of files in them. Not sure whether that is of any significance.

Yes, I know it's a bit confusing.. as mentioned in the MX-21 beta thread, I'm rather preparing something for MX-21 at least as a manual action to enable sb. It's probably easier in MX-21, as we made sure we have already the singed kernels in place and the LiveGRUB is identical the installed grub, where the LiveGRUB includes debians signed EFI-loader. So it would only some small actions to get the installed MX booting under SB...

it is an distinct possibility that future PCs may be more difficult to convert to an Linux System.

as the Microsoft Windows System becomes the New Standard, upon which New Hardware,
is built to be used excursively by that one operating system.

one thing that I've done, on an few occasions, is to still use legacy style partitioning,
and even when Installing MX-Linux in 64bit mode .. it simply makes the whole Installation that much easier.
- - especially if I'm only likely to use less than the usual Four Primary Partitions - -

fehlix wrote: Sun Sep 26, 2021 4:42 pm Yes, I know it's a bit confusing.. as mentioned in the MX-21 beta thread, I'm rather preparing something for MX-21 at least as a manual action to enable sb. It's probably easier in MX-21, as we made sure we have already the singed kernels in place and the LiveGRUB is identical the installed grub, where the LiveGRUB includes debians signed EFI-loader. So it would only some small actions to get the installed MX booting under SB...

Wow ! Congrats. This is what I really wanted. I'm ready to help if you need that.

We can't turn off "Secure Boot" (or M$ lock-in boot ) on my sister's laptop -- managed by her school, and they say they won't turn it off due to "security reasons" .

BTW it would also be extremely useful for those who want to dual-boot Win11 .

I am also ready to help with testing or whatever.

TimothySimon wrote: Mon Sep 27, 2021 12:35 am We can't turn off "Secure Boot" (or M$ lock-in boot ) on my sister's laptop -- managed by her school, and they say they won't turn it off due to "security reasons" .

The mokutil tool can turn off secure boot even when the BIOS does not offer the option to do so but if the issue here is that the school managed laptop has its BIOS locked with an Administrator password in accordance with their security policy then I guess you are stuck with that.

My understanding fro m research so far is that secure boot is not so much about Microsoft lock-in as preventing malware from being able to gain a foothold onto a system via the BIOS and the UEFI boot mechanism:

https://wiki.debian.org/SecureBoot

I dare say that Microsoft does, at present, have something of an advantage because their encryption key is shipped with all new hardware so that it is ready to run Windows, but it is also possible to enrol additional keys in the BIOS and some Linux distros get you to do that during the installation process. It is also possible to make and enrol ones own key in the BIOS or even to remove the Microsoft key if you felt so inclined, although I'm not sure why one would want to do that.

Coming back to my original issue, one thing that I realised when running through the instructions contained in the links from #2 and #3 is that at no point did mukutil come up and ask me to enrol the Debian key in the BIOS so it might this have been what was missing? The instructions in the link above show you how to enrol one's own generated key, but where do I get the Debian public key from?

It seems I may be better off installing MX-21 beta although it does come with a warning about not using it on production systems and the machine I intend to install it on is my main workstation.

@MultipleX
I would suggest you wait for the RC. It should be coming soon.

MultipleX wrote: Mon Sep 27, 2021 8:14 am Coming back to my original issue, one thing that I realised when running through the instructions contained in the links from #2 and #3 is that at no point did mukutil come up and ask me to enrol the Debian key in the BIOS so it might this have been what was missing? The instructions in the link above show you how to enrol one's own generated key, but where do I get the Debian public key from?

B/c Debians signing key is signed by a Microsoft key, where MS's public counterpart is available already within the UEFI firmware, hence no key-enrolement using mokutil are required.

richb wrote: Mon Sep 27, 2021 8:33 am @MultipleX
I would suggest you wait for the RC. It should be coming soon.

No problem. Happy to wait. Seems reasonable.

fehlix wrote: Mon Sep 27, 2021 8:38 am

MultipleX wrote: Mon Sep 27, 2021 8:14 am Coming back to my original issue, one thing that I realised when running through the instructions contained in the links from #2 and #3 is that at no point did mukutil come up and ask me to enrol the Debian key in the BIOS so it might this have been what was missing? The instructions in the link above show you how to enrol one's own generated key, but where do I get the Debian public key from?

B/c Debians signing key is signed by a Microsoft key, where MS's public counterpart is available already within the UEFI firmware, hence no key-enrolement using mokutil are required.

Ah, that would explain it then. Thank you.

Wouldn't that presumably mean that any DKMS drivers (e.g. VirtualBox, Nvidia) would need to be signed with Microsoft's key as well?

MultipleX wrote: Tue Sep 28, 2021 4:39 am

richb wrote: Mon Sep 27, 2021 8:33 am @MultipleX
I would suggest you wait for the RC. It should be coming soon.

No problem. Happy to wait. Seems reasonable.

fehlix wrote: Mon Sep 27, 2021 8:38 am

MultipleX wrote: Mon Sep 27, 2021 8:14 am Coming back to my original issue, one thing that I realised when running through the instructions contained in the links from #2 and #3 is that at no point did mukutil come up and ask me to enrol the Debian key in the BIOS so it might this have been what was missing? The instructions in the link above show you how to enrol one's own generated key, but where do I get the Debian public key from?

B/c Debians signing key is signed by a Microsoft key, where MS's public counterpart is available already within the UEFI firmware, hence no key-enrolement using mokutil are required.

Ah, that would explain it then. Thank you.

Wouldn't that presumably mean that any DKMS drivers (e.g. VirtualBox, Nvidia) would need to be signed with Microsoft's key as well?

I think, one would generate one-time a local signing key, which would need to be put into UEFI firmware by using mokutil key-enrolement, and sign the driver with that key. I think, but I might be wrong, that's still the way Ubuntu and co. are doing it, but need to check where they are now with latest releases.

Meanwhile, these may be useful in general about what secure boot is and also what it's not :

https://wiki.debian.org/SecureBoot

https://linuxhint.com/secure-boot-linux/

@fehlix that's how they do it with the modules. upon reboot, there is a prompt to accept the self-signed modules, IIRC. this happens when you do broadcom drivers on ubuntu.

I discovered kvm and QEMU today as an alternative to VirtualBox. It seems kvm already has hooks into the kernel so doesn't need dkms drivers and Debian provides signed drivers. I tried it on Mint and it seems to works fine. The Debian VM that was created using virt-manager also seemed to run without any problems in a secure boot environment. I suspect the drivers are bundled with the package supplied on the Ubuntu repository as I didn't have to install anything else than the usually recommended packages. I have yet to test an OS that is not secure boot aware.

I have decided to go with a dual-boot setup with Mint20.2 and MX-21 when the release candidate becomes available. In the meantime the MX partition has MX-19 installed on it. MX feels a little snappier than Mint and I hope to move over to it in due course.

I had to turn off Secure Boot on my Dell 7380 laptop to get my system to boot, couldn't get it to work any other way.

MultipleX wrote: Sat Sep 25, 2021 3:59 pm With Microsoft using its clout to force the issue in its next OS release, this is going to prove interesting. Will we have to go into BIOS and enable/disable SecureBoot every time we want to switch between Linux and Windows?

As if I'm going to be caught dead using Windows 11... 10 is already bad enough. And I say all this as a big former Windows fan too.

The good news though is that you won't need to run Windows 11 any time soon for compatibility reasons. What runs on Windows 11 will run on 10 as well for the foreseeable future.

MultipleX wrote: Sat Sep 25, 2021 3:59 pm How long will it be before disabling SecureBoot is no longer supported in BIOS?

Pretty sure that won't happen. There's no reason to take it out.

richb wrote: Mon Sep 27, 2021 8:33 am @MultipleX
I would suggest you wait for the RC. It should be coming soon.

WHEN

richb wrote: Mon Sep 27, 2021 8:33 am @MultipleX
I would suggest you wait for the RC. It should be coming soon.

WHEN

When it's ready

Pierre wrote: Sun Sep 26, 2021 11:26 pm it is an distinct possibility that future PCs may be more difficult to convert to an Linux System.

as the Microsoft Windows System becomes the New Standard, upon which New Hardware,
is built to be used excursively by that one operating system.

If that happens hopefully companies like Star Labs and System 76 will still be around.

richb wrote: ↑Mon Sep 27, 2021 8:33 am
@MultipleX
I would suggest you wait for the RC. It should be coming soon.

Response
WHEN

Defintion of Soon

In a prompt manner without undue delay.

Whether I actually use Win 11 or not remains to be seen. Like many others, I stopped being a fan when W10 came out. When it becomes available I will set up a W10/W11 dual boot setup and have a look at it. This will also ensure that the machine is licenced to use it. It is supposed to be an automatic upgrade from W10 provided that the hardware supports it. I have kept Win on one SSD and Linux on another which reduces complications. Data is on a third SSD.

Nevertheless, I have only a handful of programs left that I actually need to run on Windows. I previously ran WINE and also preserved the W7 partition for that purpose. On the new one have decided to move forward and set up a Win10 VM in QEMU on Linux rather than run WINE. I am looking forward to setting up in MX once the RC is available.

richb wrote: Mon Sep 27, 2021 8:33 am @MultipleX
I would suggest you wait for the RC. It should be coming soon.

Ok, I have now got MX21 RC1 installed on my computer in place of MX19. What is the process for enabling secure boot? Is it still the same as described in the other thread here:

viewtopic.php?f=23&t=58496&sid=dc4f3ee4 ... 75fbf5b535

Or has it changed?

MultipleX wrote: Sat Oct 16, 2021 7:01 am

richb wrote: Mon Sep 27, 2021 8:33 am @MultipleX
I would suggest you wait for the RC. It should be coming soon.

Ok, I have now got MX21 RC1 installed on my computer in place of MX19. What is the process for enabling secure boot? Is it still the same as described in the other thread here:

viewtopic.php?f=23&t=58496&sid=dc4f3ee4 ... 75fbf5b535

Or has it changed?

Instructions will be different, b/c they will include to make those out-of-tree dkms modules signed with user's generated MOK and adjustments to EFI-loader installations. So I guess you might wait a bit until final release is out and tests have been made and proven that it indeed works.

fehlix, thanks. It was my impression from the previous comment that the tools would be available with the release of RC1. However, n.p. will wait.

MultipleX wrote: Sat Oct 16, 2021 7:56 am fehlix, thanks. It was my impression from the previous comment that the tools would be available with the release of RC1. However, n.p. will wait.

MX-21 will be released without official secure boot support. Those activities re making secure boot available for MX21 will be a kind of "first" attempt to make secure boot work for MX 21 installations. Main points to consider are driver signing e.g. virtualbox, nvidia, wifi etc and use of Debian signed kernel vs MX/antiX provided unsigned kernels. So there will be different steps/levels to satisfy depending on actual use case. The first attempt will probably not include unsigned kernels. This might be part of a next attempt to include automatic signing of MX/antiX kernels. My optimistic view on this it should be possible, but first test on different hardware made my automatic signed MX/antiX kernels to not "secure"-bootable.

I"m wondering/asking what is the point of this focus on secure boot? Is it to have the MX distro boot process conform to the requirements of Windows 11 so then one can more conveintly dual/multi boot os's OR is it because it is a 'better' way to boot? Or something else perhaps.

From what I understood W11 will not boot without secure boot. But I could be wrong, haven't followed that intensely.

MultipleX wrote: Sat Oct 16, 2021 7:56 am fehlix, thanks. It was my impression from the previous comment that the tools would be available with the release of RC1. However, n.p. will wait.

I've opened a new thread which starts with a post about enabling secure boot in MX21. Also the intention is to update this thread with further refinement of automatically signing modules and MX/antiX kernels and in addition allowing multiple MX21 and Debian installation with working UEFI boot options entries. Watch this place: "MX 21 Secure Boot" https://forum.mxlinux.org/viewtopic.php?t=67022

Well at least in my case secure boot and MX21 work quite well, and I even have it dual boot win 11 on my main machine.
I just had to set up an ESP boot partition.

I did a clean install of Windows 11 the other day after enabling tpm and secure boot. After installing I disabled secure boot and enabled CSM and the Windows 11 booted up no problems. Just FYI