When Slackware-current upgraded the Grub package to 2.12, liveslak lost the ability to boot on a computer with Secure Boot enabled.
Grub 2.12 is a lot stricter than the previous 2.06 release when it comes to trusting the files it loads and executes. The way it works now is as follows (step 1 and 2 are unchanged):
- The Secure Boot computer will only load the primary bootloader when that has been signed with a SSL certificate which is stored in NVRAM (the Database key). Unless you have deleted the original Db, the Dbx, the KEK and the Platform Key in order to install your own self-generated keys, this will be a Microsoft certificate.
Linux distributions nowadays mostly use a UEFI bootloader called “shim” for Secure Boot. The bigger distros have one in their repository which has been signed by Microsoft. Because this Microsoft certificate is already stored in your computer’s NVRAM, the “shim” trusts it and proceeds with booting.
Slackware does not have a “shim” which is signed by Microsoft, and nor do I. For liveslak I simply re-use one of the signed “shim” packages from either Fedora, OpenSuSE or else Debian. - The “shim” bootloader will only load a secondary bootloader (Grub for example) if it recognizes and trusts the SSL certificate with which that one has been signed.
The big distros have embedded their own certificate inside their Microsoft-signed “shim” and for that reason, the “shim” implicitly trusts the distro certificate. This “shim” will then accept and load any secondary bootloader which has been signed by that same distro certificate. It allows a distro to have a transparent boot process (Secure Boot or normal boot) without any specific user actions that need to be performed.
In our case since I signed our Slackware Grub bootloader with my own SSL key and certificate, the “shim” must be taught to accept this certificate as trustworthy. We do this by enrolling the certificate into the MOK – another piece of storage space in the Secure Boot computer’s NVRAM. MOK stands for Machine Owner Key… and you are the Machine Owner. Since you have to be physically present at your computer when you tell the MOK-manager to enroll the liveslak SSL certificate, that makes the certificate trusted.
How that is done? I wrote an article about that, three years ago: Secure Boot support landed in liveslak 1.5.0 and I invite you to re-read it.
The “shim” will load our liveslak Grub bootloader after you enrolled the “liveslak.der” certificate in the MOK. - Now it gets “interesting”. Grub 2.06 would happily continue loading the kernel, the initrd and then boot Slackware Live. But Grub 2.12 requires that every file it loads when Secure Boot is enabled, must be signed by a private GPG key for which Grub stores a copy of its public key. Ehh?
I called that new requirement for the boot process “interesting” but actually it was something to tear your hear out over. Debugging the boot of a computer before the stage where the Linux kernel takes over from the bootloader, is extremely difficult.
I had a good look at the Grub documentation and my liveslak sources back in July and August and actually did most of the changes that were needed during that time.
Most of the work back then went into a big rewrite of the iso2usb.sh script. When Grub needs to check a GPG signature for every file it loads from disk, the initrd must be GPG-signed as well. That means, iso2usb.sh is no longer allowed to un-pack, update and re-pack the initrd image file because that will invalidate the GPG signature.
What I did was: re-use the logic that was already implemented in isocomp.sh, a companion script to enable persistence for the Live ISO when that is used on a Ventoy USB disk.
From now on, all customizations of your Live USB stick are stored in the file ‘/liveslak/slackware_os.cfg‘ in the Linux partition. The initrd remains unchanged.
You need to use the latest version of
iso2usb.shthough! Delete older versions please. They are incompatible with the new liveslak.
When that rewrite was finished, I needed to find out what the requirements were for the GPG signing process and I needed to find a way to actually use a GPG private key in my scripts without exposing Alien’s own GPG keys. I learned about ephemeral GPG keys: the liveslak ‘make_slackware_live.sh‘ script creates a GPG private/public key pair, does all the signing, stores copies of the GPG public key inside the Grub bootloader image and on the EFI partition, and then erases the private key (it will no longer be used).
Alas, even with all the requirements apparently having been satisfied I kept running into “security violation” messages on boot.
In August, I simply gave up trying to fix this, because it was so frustrating and also because real-life was too demanding.
But during the Christmas holiday, after I had completed much of my AFFiNE cloud server article, I decided to give it another shot. Actually, I had intended to work on a ‘reboot’ of the Live DAW project but the feedback I am getting on my recent blog post is luke-warm and it did not inspire the confidence that more than a few people would actually use a refreshed DAW environment. Not to worry – that DAW refresh is still on my TODO list.
Looking at the liveslak code with a fresh perspective was really helpful and I managed to deal with the missing pieces. The final hurdle was taken when I realized that I needed to update the SBAT file which gets embedded into the Grub boot image, precisely because I am now using a newer Grub version. As I said, hair-tearing.
With good results: the liveslak-1.8.2 is again supporting Secure Boot.
Note: Secure Boot is supported only on 64-bit computers and only after you transferred the ISO Live content to a USB stick using the iso2usb.sh script.
Anything else that’s new?
Most of what happened between releases 1.8.1 and 1.8.2 is small stuff, a lot of these small changes were necessitated by the evolution of Slackware-current and to keep the Live ISOs working.
One thing worth mentioning is this. The liveslak scripts changed a lot internally, but their usage is un-changed with a single exception. The “-w” or “–wait” parameter to the “iso2usb.sh” script has been removed. It was meant for slow USB sticks where it takes more time for the USB subsystem to settle in the kernel. Using this parameter allowed you to increase the wait time for your USB stick to boot into the Operating System. But I solved that by using a loop in the live init, and the script parameter is no longer needed.
Download Slackware Live Edition
You can find a set of new ISOs based on liveslak on download.liveslak.org/latest/, the 64bit versions of them support Secure Boot.
It will probably work best if you use the ‘iso2usb.sh‘ script provided with liveslak to transfer the ISO content to a USB stick, it will give you a persistent environment with optional data encryption and this will allow it to boot on a lot more computers.
Alternatively, create a Ventoy disk and copy the un-changed ISO on it. You can then use liveslak’s ISO companion script ‘isocomp.sh‘ to add data persistence for that ISO on the Ventoy disk.
Get liveslak sources
The liveslak project is hosted in git. Its browsable cgit interface is here: https://git.liveslak.org/liveslak/
A set of the liveslak scripts can also be downloaded from http://www.slackware.com/~alien/liveslak/ or https://slackware.nl/people/alien/liveslak/
The liveslak public key (SSL certificate in DER encoding) that you need to enroll can be downloaded from https://download.liveslak.org/secureboot/liveslak.der
Let me know your experiences!
Cheers, Eric
Eric, I always enjoy reading your articles, thank you for all you do!
Hope you and those you love are well.
I am glad to read about the liveslak advances. This project has been giving me good times with my Slackware experience for many years.
Cheers!!!
Thanks Eric! Have a wonderful New Year?
Thanks, but why the questionmark?
Thanks! Very useful.
Eric, Thank You so much for giving us Liveslak.
Eric, super huge kudos and total respect for all your hard work and wonderful efforts!
hi eric, would it be feasible to add a feature to disable docs (/usr/man, /usr/doc, /usr/info) to save space due to memory constraints in slackware default build?
Use ‘make_slackware_live.sh -t mandoc’ to trim all manpages and documentation (including info pages) so that the resulting ISO will be smaller.
Use ‘make_slackware_live.sh -h” to see what else the script can do.
just to clarify, was looking to disable the docs squashfs module for any regular squashfs module and enable it as needed by user. it can be per tagfile in each directory (a,ap, …) or combined into one but it is best to have it per each tagfile in each directory which is my need.
i am currently combining all packages into one single lst file as much as possible and trying to create a docs squashfs module out of it to figure out how to disable that module.
this is to support systems with less than 2gb? of memory but still can use regular slackware build as much as possible.
Ah. I am not going to implement this.
i was able to figure out a more cleaner approach within liveslak where i am moving the files that may not be necessary to a separate squashfs image with a different extension only so users can still load them if needed by extension which makes it slightly easy.
sxz and zxz.
will share the liveslak code base once it is fully done.
doc and examples is a good approach you have used. trying to find more.
i gave two options for example:
slackware
slackware (full)
my idea is not to drop any slackware package as much as possible however had to rely on users preferences.
Hello Eric,
thank you for this, great job!
I’ve a problem with liveslak because it seems that UEFI is not secured. I’ve even rebuilt the USB key using the new scripts (1.8.5) but the mok management tool is not showed after the enroll request and reboot. Another thing, is that before I had 2 certificates enrolled (the one from levslak and from Fedora), but now the Fedora’s one disappeared completely and the liveslak’s one is always showed in “–list-new” command of mokutil, but never enrolled. I really don’t know what happens: this is my company laptop and I’d really like to have my own OS for my purposes, instead of using the company OS (windows).
If I disable the security mode, liveslak is loaded without any problem (now I’m writing from liveslak), but I cannot load Windows. If I enabled the security mode, Windows is loaded, but liveslak show a Dell bios screen, with this message: “Operating System Loader has no signature. Incompatible with SecureBoot.”
What am I missing?
Thank you very much!!
Could be broken again.
If you find out what’s wrong let me know.
I have a 2TB usb disc that I’d like to use as a fully functional portable backup Slackware Current system.
Which options for iso2usb.sh would be optimal for this purpose?
I’d like to have an encrypted and persistent /home and possibly other system dirs, as I’ll be upgrading packages from Slackware’s current branch and also install self-compiled SBo software.
Cheers, Aleksander
OK, I used this:
./iso2usb.sh -i slackware64-live-current.iso -o /dev/sdb -c 90% -P
I am testing it now, seems to work well, I got extra free (10%) 160GB unencrypted part, nice for exchanging files from/to my primary everyday slackware machine.
How can I permanently change the default KDE into XFCE?
Why didn’t you use slackware64-live-xfce-current.iso then?
Because the slackware64-live-current.iso I used contains both Kde and Xfce.