MX Linux Forum

Posted: **Fri Jun 05, 2020 5:34 am**

Now that Debian buster fully supports Secure Boot it is possible to also enable MX-19. Unfortunately Secure Boot does not allow for custom kernel modules so this guide should not be followed if the proprietary NVIDIA, Broadcom or VirtualBox drivers are needed, it also removes the ability to load ndiswrapper-derived drivers.

To enable Secure Boot first remove the various DKMS-related packages, as explained above:

Code: Select all

sudo apt purge dkms broadcom-sta-dkms ndiswrapper{,-dkms,-utils-1.9} virtualbox-guest-{dkms,utils{,-modified-init},x11}

Now install the required Secure Boot packages:

Code: Select all

sudo apt install shim-signed grub-efi-amd64-{signed,bin=2.02+dfsg1-20} grub{,2}-common=2.02+dfsg1-20 linux-image-amd64

You will be asked if you want to replace the maintainer script at /etc/grub.d/10_linux, say "no" (which is the default) to keep MX's modified GRUB script.

Also copy the old 30_os-prober script back if dual-booting with Manjaro:

Code: Select all

sudo cp /usr/local/share/live-files/files/etc/grub.d/30_os-prober /etc/grub.d/30_os-prober

And finally pin the grub{,2}-common & grub-efi-amd64-bin packages so that the Debian versions are preferred over the MX versions:

Code: Select all

sudo tee /etc/apt/preferences.d/secure-boot <<END
Package: grub-common grub2-common grub-efi-amd64-bin
Pin: release o=Debian
Pin-Priority: 1001
END

Secure Boot should now work in MX.

EDIT: corrected purge command and simplified procedure.
EDIT2: added fehlix's fix.

Posted: **Fri Jun 05, 2020 6:52 am**

That doesn't work with unsigned kernels, does it?

Posted: **Fri Jun 05, 2020 7:24 am**

No. But the signed kernels work just fine with the rest of the MX ecosystem, not sure why the developers use the unsigned versions.

Posted: **Fri Jun 05, 2020 8:12 am**

Head_on_a_Stick wrote: Fri Jun 05, 2020 5:34 am Secure Boot should now work in MX.

Have you tried it?

Posted: **Fri Jun 05, 2020 9:08 am**

Wouldn't this break Broadcom wifi, NDIS wrapper (if someone's using it) and VirtualBox?

Posted: **Fri Jun 05, 2020 9:10 am**

Wouldn't this break Broadcom wifi, NDIS wrapper (if someone's using it) and VirtualBox guest additions? The last two are probably expendable in most installed systems but I'm a bit hinky about removing Broadcom dkms. One could simply disable secure boot in their UEFI settings instead.

Posted: **Fri Jun 05, 2020 9:38 am**

fehlix wrote: Fri Jun 05, 2020 8:12 amHave you tried it?

Not at the time of posting

I have now though:

Code: Select all

empty@mx:~ $ grep PRETTY /etc/lsb-release                                                          
PRETTY_NAME="MX 19.2 patito feo"
empty@mx:~ $ mokutil --sb-state
SecureBoot enabled
empty@mx:~ $

JayM wrote: Fri Jun 05, 2020 9:10 amWouldn't this break Broadcom wifi, NDIS wrapper (if someone's using it) and VirtualBox guest additions?

Yes. I have explained that in the OP, sorry if it isn't very clear.

JayM wrote: Fri Jun 05, 2020 9:10 amOne could simply disable secure boot in their UEFI settings instead.

Some machines do not have that option and Microsoft is trying to make Secure Boot mandatory.

Posted: **Fri Jun 05, 2020 10:59 am**

Head_on_a_Stick wrote: Fri Jun 05, 2020 9:38 am
fehlix wrote: Fri Jun 05, 2020 8:12 amHave you tried it?
Not at the time of posting

I meant do you get a Grub-menu to boot into the MX Linux. I got a nice Grub-shell.
So something with the signed-efi. Perhaps an embedded early-grub is missing or it does not find the grub.cfg helper :
like this one:

Code: Select all

configfile /efi/mx/grub.cfg

Doing early-grub manually gives me the Grub-menu.

Posted: **Fri Jun 05, 2020 11:42 am**

Seems they have hardcoded the "early" prefix to "/EFI/debian". Despite the grub-install process creates an /EFI/mx.
So one would need to copy manually the "early" grub.cfg from /EFI/mx/grub.cfg to EFI/debian/grub.cfg.

Posted: **Fri Jun 05, 2020 12:12 pm**

Thanks fehlix, I missed that. I've added the step to the OP.

That problem was actually reported by p.H over at forums.debian.net but it hasn't been fixed yet: https://bugs.debian.org/cgi-bin/bugrepo ... bug=925309

Posted: **Fri Jun 05, 2020 12:26 pm**

Perhaps, you "still" might not know, we have a nice Chroot-Rescue-Scan available from the Whisker menu.
Suggest, to provide MX-Recipes with using MX Tools, no need to extra install tools, which are already available.

In addition, for anyone who just wants to try secure boot out, the procedure provided might create non-bootable menu entries, for other installed systems. Mainly due to the fact that the os-prober used by MX was adjusted to allow the generation of valid Manjaro Grub-menu-entries. So you would either need also to "downgrade" os-prober, which would give you unbootable manjaro entries - or manual adjust the generated invalid menu-entries.

Posted: **Fri Jun 05, 2020 12:54 pm**

fehlix wrote: Fri Jun 05, 2020 12:26 pmSuggest, to provide MX-Recipes with using MX Tools, no need to extra install tools, which are already available.

I'm not sure how the Chroot-Rescue-Scan tool would be useful for enabling Secure Boot

The guide originally advised using arch-chroot(1) from the live system but that was only because I copy&pasted it from a thread wherein the user could not boot their system at all. I've since modified it to work without that step.

fehlix wrote: Fri Jun 05, 2020 12:26 pmfor anyone who just wants to try secure boot out, the procedure provided might create non-bootable menu entries, for other installed systems. Mainly due to the fact that the os-prober used by MX was adjusted to allow the generation of valid Manjaro Grub-menu-entries.

My guide does not change the installed version of the os-prober package so workable Arch-based menu entries should still be present (AFAICT).

That problem is currently being worked on upstream: https://bugs.debian.org/cgi-bin/bugrepo ... bug=820838

Posted: **Fri Jun 05, 2020 1:05 pm**

Head_on_a_Stick wrote: Fri Jun 05, 2020 12:54 pm
fehlix wrote: Fri Jun 05, 2020 12:26 pmfor anyone who just wants to try secure boot out, the procedure provided might create non-bootable menu entries, for other installed systems. Mainly due to the fact that the os-prober used by MX was adjusted to allow the generation of valid Manjaro Grub-menu-entries.
My guide does not change the installed version of the os-prober package so workable Arch-based menu entries should still be present (AFAICT).
[/code]

I have only tested with manjaro, and our mx-osprober works closely with mx-grub.

Head_on_a_Stick wrote: Fri Jun 05, 2020 12:54 pm That problem is currently being worked on upstream: https://bugs.debian.org/cgi-bin/bugrepo ... bug=820838

Well, early-initrd's are already officially supported by grub2.04, but only debian seems not to have it adjusted, accordingly, yet.
It works with MX-grub/os-prober already.

Posted: **Fri Jun 05, 2020 11:17 pm**

The virtualbox in the repo is fully open source, not proprietary, so is it just that its modules don't get signed anyway after building? What about other open DKMS drivers, such as ZFS?

Posted: **Sat Jun 06, 2020 6:36 am**

Stevo wrote: Fri Jun 05, 2020 11:17 pmThe virtualbox in the repo is fully open source, not proprietary, so is it just that its modules don't get signed anyway after building?

Yes, that is correct.

Stevo wrote: Fri Jun 05, 2020 11:17 pm What about other open DKMS drivers, such as ZFS?

No, ZFS won't work in Debian with Secure Boot enabled. I tried it already

fehlix wrote: Fri Jun 05, 2020 12:26 pmthe os-prober used by MX was adjusted to allow the generation of valid Manjaro Grub-menu-entries

I have some good news and some bad news about that...

On the up side my suggested changes do not break MX's os-prober modifications and the system will still generate bootable entries for Arch-based systems with the CPU µcode package installed.

The bad news is that MX's os-prober modifications *do not* create a boot entry that actually loads the CPU µcode and so any Arch-based systems booted from MX's GRUB will not be loading the µcode.

A correct Arch-based boot entry would look like this (example shows an AMD system):

Code: Select all

echo 'Loading initial ramdisk'
initrd /boot/amd-ucode.img /boot/initramfs-linux.img

https://wiki.archlinux.org/index.php/Microcode#GRUB

But MX generates an entry like this:

Code: Select all

echo 'Loading initial ramdisk'
initrd /boot/initramfs-linux.img

^ That is wrong.

Posted: **Sat Jun 06, 2020 7:47 am**

Head_on_a_Stick wrote: Sat Jun 06, 2020 6:36 am But MX generates an entry like this:
Code: Select all
echo 'Loading initial ramdisk'
initrd /boot/initramfs-linux.img
^ That is wrong.

Yes, with having installed buster's grub-common, it will have overwritten

Code: Select all

/etc/grub.d/30_os-prober

So you might adjust your receipt by adding this post-install procedure, after having installed
buster secure-boot enabled grub's:

Code: Select all

cp /usr/local/share/live-files/files/etc/grub.d/30_os-prober /etc/grub.d/30_os-prober

And in case os-prober have been also "downgraded" to buster's version one would need restore this file:

Code: Select all

/usr/lib/linux-boot-probes/mounted/40grub2

from MX provided os-prober version ( 1.77mx19+1)
which shall then generate proper grub entry for arch special early-initrd handling.
Or alternatively, as a pre-procedure, backup-both files and restore after secure-boot installation.
HTH

Posted: **Sat Jun 06, 2020 8:10 am**

fehlix wrote: Sat Jun 06, 2020 7:47 amwith having installed buster's grub-common, it will have overwritten

No, you misunderstand.

I have tested MX-19's os-prober by installing both MX-19 and Arch on the same (virtual) disk, the quoted incorrect menuentry was generated by the stock MX-19 system. I had not made any changes to that system at all.

Posted: **Sat Jun 06, 2020 8:24 am**

Head_on_a_Stick wrote: Sat Jun 06, 2020 8:10 am
fehlix wrote: Sat Jun 06, 2020 7:47 amwith having installed buster's grub-common, it will have overwritten
No, you misunderstand.

I have tested MX-19's os-prober by installing both MX-19 and Arch on the same (virtual) disk, the quoted incorrect menuentry was generated by the stock MX-19 system. I had not made any changes to that system at all.

Oh, that would be another thread

. I have tested with Manjaro. Will check what arch does differently.

Posted: **Sat Jun 06, 2020 10:08 am**

I don't know if this is relevant, but Manjaro itself has modified its grub package, so that it's not using the same grub that Arch does.

https://forum.manjaro.org/t/call-for-te ... lla/100190

Users who don't want Manjaro's grub package and prefer the "normal" one that Arch uses, have to replace it with grub-vanilla package.

Posted: **Sat Jun 06, 2020 10:18 am**

asqwerth wrote: Sat Jun 06, 2020 10:08 am I don't know if this is relevant, but Manjaro itself has modified its grub package, so that it's not using the same grub that Arch does.

https://forum.manjaro.org/t/call-for-te ... lla/100190

Users who don't want Manjaro's grub package and prefer the "normal" one that Arch uses, have to replace it with grub-vanilla package.

Thanks. That's probably easier to test using manjaro with vanilla grub.

Posted: **Sat Jun 06, 2020 10:34 am**

It may not be 100% Arch grub, according to the first post in that thread. Still has some minimal patching, apparently.

Posted: **Sat Jun 06, 2020 1:24 pm**

fehlix wrote: Sat Jun 06, 2020 8:24 amthat would be another thread

Yes, sorry. Probably nothing to worry about though — in the unlikely event that any Archers try to dual-boot with MX I'm sure they will be able to figure it out for themselves.

Posted: **Sat Jun 06, 2020 4:33 pm**

OK, I just tested with having a Manjaro's vanilla grub installed. The intel-µcode line in the generated grub.cfg get nicely generated from normal installed MX Linux and also with the secure-boot enabled MX-Linux (with having applied the receipt from post #1 and the os_prober corrections mentioned in my post above ( EDIT: and now also in post #1). I'm currently don't have another arch-based system to further investigate the mentioned µcode-issue in the grub-entries for arch-systems.

Posted: **Sat Jun 06, 2020 5:24 pm**

Head_on_a_Stick wrote: Fri Jun 05, 2020 5:34 am Now that Debian buster fully supports Secure Boot it is possible to also enable MX-19. Unfortunately Secure Boot does not allow for custom kernel modules so this guide should not be followed if the proprietary NVIDIA, Broadcom or VirtualBox drivers are needed, it also removes the ability to load ndiswrapper-derived drivers.
...

Thanks for the tuto.
Good news for the secure boot ... but bad new for me for one machine, I use VirtualBox.

MX Linux Forum

Enabling Secure Boot in MX Linux

Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux

Re: Enabling Secure Boot in MX Linux