Alien Pastures

My thoughts on Slackware, life and everything

Tag: liveslak (Page 3 of 10)

liveslak 1.6.0 feature release, plus a new set of ISOs for Slackware Live Edition

August 15, 2022 / / 47 Comments

Liveslak is my favorite project, it’s fully under my control, I built it from scratch, I get good improvement ideas from its users and Patrick helps when liveslak needs something new from Slackware.
There are times that it gets less attention though, and in the first half of 2022 there was not much activity – some minor updates whenever I needed to release a fresh batch of Live ISO images. Most of that inactivity was caused by burnout.

But then someone mentioned Ventoy to me, because liveslak ISOs would not boot from a Ventoy disk and they hoped I would be able to fix that. At first I was like “I don’t care for it, why should I put effort in supporting it” but on second thought and reading through its web pages, my opinion changed in favor of Ventoy. In fact, it is a quite the unique piece of software and I am using it myself now.

So what does it do? Ventoy takes a USB stick, formats it and puts a Linux kernel, a Grub bootloader and some smart tools on it. Then you can put as many bootable images (ISOs, IMGs and so on) on its first exfat-formatted partition as there is room. Ventoy will automatically populate the Grub boot selection screen with all bootable images it could find on that partition. You can then boot any ISO straight from that menu.

Ventoy supports a lot of Operating Systems out of the box, in particular when the OS on the bootable image does not have to know it is chainloaded by Ventoy. Mostly installation ISOs work without issue.
For Live ISOs the situation is more delicate. A Live OS which starts from an ISO needs to know that it boots from an ISO, because its initrd will have to find that ISO file’s location on disk and then mount it in order to start the actual Live OS. Ventoy provides “hooks” for a lot of Live OS-es that it already knows about and validated. It is fairly trivial for a Live OS maintainer to add support for Ventoy.
And actually that’s exactly what I did between the releases of liveslak 1.5.3 and 1.5.4. The liveslak ISO images that are generated automatically after every update for Slackware-current already support booting from a Ventoy disk since a month ago.
You get these Slackware-current Live ISOs from https://download.liveslak.org/slackware64-current-live/ or from https://us.liveslak.org/slackware64-current-live/ by the way, if you are curious and want to test the latest & greatest of Slackware straight from the press.

After releasing liveslak-1.5.4 I took its Ventoy support to the next level and used the opportunity to add a whole new feature set to liveslak.

New features of liveslak 1.6.0

  • Ventoy is now fully supported. Liveslak 1.6.0 implements the “Ventoy-compatible” guideline. This means, Ventoy won’t apply any “hooks” to liveslak when it boots its ISO image, and liveslak figures out for itself how to boot. You’ll see the message “SLACKWARELIVE: (UEFI) Ventoy ISO boot detected…” (or ‘BIOS’ instead of ‘UEFI’ if you have an older computer). There is nothing you have to do, this works out of the box.
  • When you are booting from an ISO file (whether via Ventoy, or through your own hand-crafted Grub menu entry, or Windows BCD), Operating System persistence and an encrypted homedirectory are now supported, as well as the ability to load additional live modules (as ‘addons’ or ‘optional’) that are not part of the ISO. All of this is possible without the need for any modification to the ISO image.
  • A new script, “isocomp.sh” aka the ISO Companion script, has been added to liveslak. Like with all of my scripts, it accepts a “–help” parameter which will show you how to use it.
    This script manages everything mentioned in the previous bullet:

    • creation of encrypted containers for OS persistence and a persistent homedirectory (actually not just for /home but you can create as many containers as fit on the disk and mount them wherever you want)
    • size extension of existing encrypted containers if they threaten to run out of space
    • creating a secondary liveslak root on the disk partition where you can add more optional/add-on live modules that you need in the Live OS but are not contained in the ISO
  • Containerfiles managed by “isocomp.sh” have the filename extension “.icc” which is shorthand for “ISO Companion Container” 😉
    This differs from containerfiles on a persistent USB stick created with “iso2usb.sh” where the container file extension is “.img”.
  • The configuration of all these new features is stored in a file with the same name and full path as the ISO file but with a “.cfg” file extension instead of “.iso”. The “isocomp.sh” script manages this configuration file for you, but you can safely edit and modify it manually if you want to. The script will leave your customizations alone.
    Here is an example of such a configuration file; it is copied from my Ventoy disk, for a Slackware LEAN Live ISO image:
    # Liveslak ISO configuration file for SLACKWARE-CURRENT FOR X86_64 (LEAN LIVE 1.6.0)
    # Generated by isocomp.sh on 20220815_0654
    LIVESLAKROOT=/liveslak
    LUKSVOL=/liveslak/myhome.icc:/home
    ISOPERSISTENCE=/liveslak/persistence.icc
    TZ=Europe/Amsterdam
    LIVE_HOSTNAME=zelazny
    I added the variables “TZ” and “LIVE_HOSTNAME” manually by opening the configuration file in an editor.
    The following variables are also supported in this configuration file – but not managed by “isocomp.sh” – they all correspond to liveslak boot parameters by the way: BLACKLIST, KEYMAP, LIVE_HOSTNAME, LOAD, LOCALE, NOLOAD, RUNLEVEL, TWEAKS, TZ and XKB.
    The value of the “LUKSVOL” variable can hold multiple “containerfile:mountpoint” definitions, separated by commas. You can use the script to add more, or add them manually if you prefer.
    The “LIVESLAKROOT” variable points to the root of a secondary liveslak directory tree on your disk.
    And the “ISOPERSISTENCE” variable holds the path to a persistence file (also an encrypted container) as its value.

Summarizing, there is now a second way to get persistence in Slackware Live Edition.

Of course you can still use ‘iso2usb.sh” to create a dedicated Live USB stick, this remains fully supported; but especially putting Ventoy on a USB stick gives you a portable media with an EXFAT-formatted partition, meaning you can not just have multiple persistent Slackware Live environments on one disk, but in addition you can store data on that partition which can also be read and written on MS Windows or Apple computers.

Get liveslak ISOs

The various variants of Slackware Live Edition can be found in the “latest” subdirectory at https://download.liveslak.org/ or its US mirror https://us.liveslak.org/ . This time, there’s no Cinnamon ISO, because its graphical user interface won’t start, perhaps due to missing packages in its repository. I already alerted the package maintainer Willy Sudiarto Raharjo, and he is looking into it.
You’ll be able to download ISO Live images of 32bit and 64bit Slackware proper, also of the small XFCE variant for (both architectures), and then DAW, LEAN and MATE ISOs that only come in 64bits. All ISOs containing a 64bit Slackware have support for SecureBoot.
Also have a look in the “bonus” subdirectory!

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/

To conclude…

Let me know if you run into bugs. I tested all the permutations I could think of on several computers here in the house, but I know that you people out there always come up with scenarios I could not dream of. The live init script has been extensively updated and re-written, and the logic flow had to be changed, but I believe it’s solid.

Have fun! Eric

Finally a new batch of Live ISOs for Slackware-current (liveslak-1.5.3)

July 10, 2022 / / 30 Comments

Updates in liveslak

Time flies. The last batch-release of Slackware Live ISO’s was almost 7 months ago.
I was burnt up by the time 2021 turned into 2022 and it took a long time for me to enjoy working on my projects again (and it’s still difficult), but I thought it might be appreciated to at least have a fresh set of ISOs for the Slackware Live Edition to play with during summer holidays.

It’s of course not entirely correct that there were no new ISOs for seven months… I have an automated process in place which re-creates a Live ISO of Slackware64-current every time there is an update to the ChangeLog.txt. It is meant to test every update and find issues to fix. There’s a European and a USA URL to download this ISO.

The various small issues that popped as a result software updates in Slackware-current, were fixed in the liveslak sources during these past months, and thanks to the people who reported to me the issues that they encountered!
These fixes went into ‘silent’ liveslak releases that were not mentioned in blog posts or other forms of communication: 1.5.1.5 to accompany the release of Slackware 15.0 (I tagged this to create the original Live ISO for Slackware 15.0) and then 1.5.2 was tagged a short while later to fix a few glaring errors in 1.5.1.5. Finally the 1.5.2 tag was meant to release a batch of ISOs in May, but I did not have the energy.

I now have tagged a liveslak-1.5.3 release with the latest updates.
Most important change in liveslak is that I decided to abandon the CDROM capacity limit (703 MB) of the XFCE ISO image size. This size limitation ensured that there would always be a version of Slackware Live Edition that you could burn to a good old CDROM medium.
What was the reason for this change of mind? When I generated a XFCE ISO last week, it was significantly larger than the 703 MB physical CDROM capacity, and I realized that I could not trim the ISO back to below 703 MB. There was simply no way to keep removing packages (read: functionality) from that ISO without penalty.
I do want the XFCE ISO to be functional and useful, so I decided on a new (somewhat arbitrary) size limitation for XFCE ISO, which is 1000 MB. It allowed me to add (back) a bunch of useful programs, most prominently Seamonkey is now gone, and it has been replaced by Firefox. If you have a need for yet more useful Slackware utilities that are missing from the XFCE ISO, leave a comment below.
If there is an interest, I may consider releasing a console-only Slackware Live ISO, which will again be a lot smaller than 700 MB and therefore able to be burnt to a CDROM. Basically this will be the standalone version of “Core OS” which you can already find in the boot menus of the DAW, LEAN and XFCE variants. Let me know your thoughts in the comments section!

The new liveslak also introduces an intermediate form of trimming the ISO content (I trim some ISOs to reduce size). Where before you’d have three increasingly severe forms of trimming “doc“, “mandoc” and “bloat“, there is now an additional form “waste” and its trimming effect lies somewhere between that of “mandoc” and “bloat“. The “waste” form of trimming is now applied to XFCE ISO instead of the old “bloat” form, and this leaves alot of libraries (dynamic and static) in the ISO image, which should make it more functional even.

The new ISOs are available for download at the usual locations (see below for download URLs). You’ll find SLACKWARE (32bit/64bit), XFCE (32bit/64bit), DAW, LEAN, CINNAMON and MATE updated images. I refreshed the ‘bonus’ section with nvidia and broadcom-sta live-modules that contain kernel drivers matching the installed kernel; I also updated the multilib and wine modules and other useful stuff.

Slackware LEAN Live

A note about ISO sizes

Over time, the functionality of the Slackware distro has been expanding. More programs were added, and package sizes have been increasing (I barely know software developers that remove functionality – everybody just keeps adding stuff) . The ISO image for the full and unmodified Slackware is almost equal to the capacity of a physical DVD. The difference is only 30 Megabytes! This means, I will soon have to start trimming the Slackware Live ISO to stay below DVD capacity limit. That is unsettling and goes against what I think does justice to the distro. On the other hand, I assume that some people’s first experience with Slackware comes from burning a Live ISO to a DVD medium and booting their computer from the DVD.
Here as well, your thoughts are welcome: should I apply trim like with the XFCE ISO, or should I be selective in the package series that I add to the Live ISO?

Download Slackware Live Edition

You can find a set of new ISOs based on liveslak on my own servers: download.liveslak.org/latest/ in the Netherlands, or the US host us.liveslak.org/latest/ .
Note: all 64bit versions support Secure Boot.

Some people report that the ISO images won’t boot when copied (using ‘cp’ or ‘dd’ for instance) to a USB stick but they all boot properly if you use the ‘iso2usb.sh‘ script provided with liveslak to transfer the ISO content to a USB stick. Of course, this will give you nice persistent storage of all your modifications with optional data encryption, ideal for a secure on-the-road Slackware environment.

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/

Remember Secure Boot

All 64bit ISOs are able to boot on a computer with SecureBoot enabled. You’ll need to enroll the liveslak public key (a SSL certificate in DER encoding format with the filename ‘liveslak.der‘) into such a computer during the very first boot. That certificate file can be found in the EFI partition inside the ISO image or on the USB stick you produced. It can also be downloaded from https://download.liveslak.org/secureboot/liveslak.der if you want. This DER certificate does not change when new ISO’s are released, so an updated ISO should boot normally on your SecureBoot-enabled system using the stored version of the ‘liveslak.der’ certificate which you enrolled in the past.

Cheers, Eric

Fresh liveslak ISO images, setup2hd can now install a basic firewall

December 20, 2021 / / 14 Comments

Updates in liveslak

New ISO’s for Slackware Live Edition (based on liveslak-1.5.1) are available for download. You’ll find SLACKWARE (32bit/64bit), XFCE (32bit/64bit), DAW, LEAN, CINNAMON and MATE updated images (see below for download locations). I also refreshed the ‘bonus’ section with nvidia and broadcom-sta drivers matching the installed kernel, and other useful stuff.
All 32bit ISOs will boot a SMP kernel from now on, since the non-SMP kernels still refuse to execute the init script in the initramfs.

Firewall testers needed

This newest release of liveslak brings something that was recently discussed on linuxquestions.org. What about adding a basic firewall configuration to the freshly installed Slackware system? A new Slackware Linux computer may have several ports open already and some people are paranoid about any prying from the outside.
You will find as many firewall ideas as there are people in the discussion. So I based the core of the liveslak firewall on the code of Easy Firewall Generator of which I host a slightly modified version at http://www.slackware.com/~alien/efg/ . I added ipv6 support too. I know that this is old code, it’s also still using iptables instead of nftables but I wanted something functional that I knew well.

But in particular I want people to test the dialog-based configurator and give me feedback. You’ll notice that the configurator allows you to go back and forth in the various dialog windows. I also want to know what you think of the questions and the level of simplicity. Also look at the installed rc.firewall script. Does it do what you need it to do?
Also, does the resulting firewall configuration what you expected it to do? Is there anything that does not work?

Now, how does this firewall configurator work and where do I find it anyhow?

Every liveslak ISO since liveslak 1.5.1 has this functionality included. The firewall configurator will be invoked only when you use the (also included) setup2hd script to install the content of the Live ISO to your hard drive:

Adding a firewall is an optional step! You can choose to skip it during installation. The relevant files will be installed to your computer and you can call “myfwconf” at any time in future if you change your mind.
Note that this is a simple firewall. It does not do any NAT, it is meant for a single-homed single-purpose personal computer running Slackware which you want to protect from external attacks. The rc script will add a lot of sysctl tweaks to make your system safer, this is independent of opening (or not) any TCP or UDP ports via iptables.

Do I get this firewall when I use a Live ISO to install regular Slackware?

The firewall configurator is not available during installation of regular Slackware (i.e. from a HTTP/FTP mirror or a NFS/SMB network location).
If you would like to see the option of installing a firewall also for a regular Slackware installation, let me know. I am open to suggestions.

Some screenshots…

During the installation of the Live OS to your hard drive, the firewall dialog is inserted to the pkgtools setup directory so that it will be called during Slackware’s post-install configuration. The first question you will see when going through the configuration steps of your fresh installation is whether you want a firewall at all. You can opt out at this point, by selecting “No”, and no further questions will be asked:

Next you will be asked to select the external network interface(s) that you want to have firewalled. Sometimes you’ll have more than one network interface (such as a laptop with its wired and wireless interfaces) which you want to protect with a firewall. This dialog will show you all detected interfaces and will have the one with the default gateway selected by default:

Next question to answer is whether you want a firewall to completely block all external connections (excluding DHCP traffic) or that you want to have specific ports open to the outside. Select “No” if you don’t want a completely blocking firewall:

If you selected “No” in the previous dialog, you will be presented with a choice of common network protocols that you can open up from the outside by selecting them:

The next dialog allows you to specify additional TCP/UDP ports and/or port ranges to remain open:

You will have a final opportunity to review the choices you made:

Pressing “Generate” will generate ‘ipv4’ and ‘ipv6’ configurations for iptables in the directory ‘/etc/firewall/’ and install the scripts “/etc/rc.d/rc.firewall”, “/usr/sbin/myfwconf” and “/var/lib/pkgtools/setup/setup.firewall”. The “myfwconf” script is the actual configurator shown in the screenshots. The “rc.firewall” script executes on boot and activates your firewall, whereas “setup.firewall” is a convenient script to be called from pkgtools:

Note that you can use the “Previous” button at any stage of the configuration to go to the previous dialog(s) and change your inputs. Pressing “Esc” at any time will bring you back to the very first dialog but then the default choice will become “No” instead of a “Yes”.

 

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.

Some people report that the ISO images won’t boot when copied (using ‘cp’ or ‘dd’ for instance) to a USB stick but they all boot properly if you use the ‘iso2usb.sh‘ script provided with liveslak to transfer the ISO content to a USB stick. Of course, this will give you nice persistent storage of all your modifications with optional data encryption, ideal for a secure on-the-road Slackware environment.

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/

Remember Secure Boot

All 64bit ISOs are able to boot on a computer with SecureBoot enabled. You’ll need to enroll the liveslak public key (a SSL certificate in DER encoding format with the filename ‘liveslak.der‘) into such a computer during the very first boot. That certificate file can be found in the EFI partition inside the ISO image or on the USB stick you produced. It can also be downloaded from https://download.liveslak.org/secureboot/liveslak.der if you want. This DER certificate does not change when new ISO’s are released, so an updated ISO should boot normally on your SecureBoot-enabled system using the stored version of the ‘liveslak.der’ certificate which you enrolled in the past.

Cheers, Eric

Secure Boot support landed in liveslak 1.5.0

November 8, 2021 / / 25 Comments

Secure Boot ???

Secure Boot is part of the UEFI specification and first appeared in the Unified Extensible Firmware Interface (UEFI) 2.3.1 specification (Errata C). It is meant to prevent the execution of unauthorized code upon boot of a computer. Most modern Personal Computers will have a way of enabling Secure Boot in UEFI, but it is common to leave it disabled if you are not running a Microsoft OS on it since Microsoft controls Secure Boot.
For dual-boot scenario’s the story is different however. Microsoft Windows 8 and 10 advise to have Secure Boot enabled but don’t enforce it, but as far as I know, for Microsoft Windows 11 enabling Secure Boot will be a requirement to get full upgrade support.

Microsoft’s own Windows OS-es fully support Secure Boot (naturally), but non-Microsoft Operating Systems that want to boot on a Secure Boot enabled computer, must have an initial bootloader which has been cryptographically signed with the ‘Microsoft UEFI CA‘ key. Getting Microsoft to sign a 3rd-party (mostly Linux) bootloader is a complex procedure which involves money (but not always) and establishment of trust. You need to realize that if a malicious bootloader gets accidentally signed by Microsoft, this bootloader could be used to deliver all kinds of nasty to every Secure Boot platform in existence. And that would defy the whole purpose of a tightly controlled ‘Secure Boot‘ environment.

It’s likely that more and more computers with MS Windows installed or with a dual-boot configuration will have Secure Boot enabled in the near future. For Slackware and its derivatives, including my liveslak based ISOs, this is a potential problem because Secure Boot is not supported yet and therefore our OS will not launch.
Additionally, one of the use-cases of liveslak ISOs is to take it along with you on a USB stick on your key-chain and boot random PC hardware with it – just for fun, or to test the Slackware compatibility of new hardware, or simply to have your Slackware desktop with you on a stick all the time.
A liveslak ISO will be a lot less useful if every PC you encounter has Secure Boot enabled.
So I set out to find a solution.

One possible way out of this dilemma is to acquire a Microsoft-signed first-stage bootloader, just like Red Hat, Fedora, Debian, Ubuntu and the other big brothers already provide. Like said before – this process is complex and I am not able to satisfy the requirements at the moment. In future, who knows? I am working on that.

Alternatively, and other small distros seem to do this too, an already signed bootloader can be ‘borrowed’ from another distro and used to boot a liveslak ISO. But that has consequences which I will elaborate further down. This is the solution I chose.

Note: In case you have doubts: the liveslak ISOs support Secure Boot from now on. But nothing changes when your computer does not have Secure Boot enabled. Slackware Live Edition will boot and work exactly like before.

Boot sequence

Let me give a quick and dirty and possibly not 100% terminology-accurate explanation of the boot procedure in a Secure Boot computer.

  • The TPM chip in the computer may be used to store a bunch of (Microsoft) security certificates which are trusted by the Secure Boot subsystem of UEFI, as well as (potentially) a list of certificates that have been revoked due to security violations. Otherwise these keys are stored in NVRAM (non-volatile RAM).
    Secure Boot will load only bootloaders that have been signed by a trusted Microsoft certificate. The most widely used Linux bootloader which Microsoft accepts for signing is the ‘shim‘, a trivial application which does not do much more than verifying the signatures of the second-stage bootloader which it is hard-coded to look for. A signed  ‘shim’ binary also contains an embedded SSL certificate of the distro that owns the shim binary.
    The shim accepts two certificates when it checks the signature of the second-stage bootloader and other binaries: one is the Microsoft certificate and the other is this embedded distro certificate. This allows such a distro to provide a nice unattended problem-free boot on every computer with Secure Boot enabled.
  • The shim loads the second-stage bootloader, this is most often the Grub2 bootloader but it could be any EFI image file (such as rEFInd). The hard-coded default filename that the shim will attempt to load is ‘grubx64.efi’ so whatever your distro bootloader, it needs to be renamed to that.
    Shim will check the signing certificate of that file and will proceed only if it recognizes the certificate as valid.
  • Grub will be informed by the shim that it loads in a Secure Boot environment and because of that, Grub will ask the shim if it is OK to load the kernel it is configured for. Shim will check the signing certificate of your kernel and will signal an ‘OK’ to Grub only if it recognizes the kernel’s signing certificate as valid.
  • Your Linux OS will now boot properly.
    But what happens if Grub or the kernel are not signed, or when they are signed with an un-recognized certificate? Well, your computer will refuse to boot.

Lack of trust

The problem for liveslak (and for Slackware) is that neither Patrick nor I own any of the private keys corresponding to the SSL certificate that these big distros embed in the signed ‘shim’ binary they provide (naturally). Therefore I must sign the liveslak grub and kernel images using my own private key and public certificate pair.
The public certificate I use for signing is not recognized by UEFI SecureBoot, since it is not embedded in any bootloader which has been signed by the Microsoft Certificate Authority. If Secure Boot is enabled then the signing certificate of liveslak’s grub and kernel images will not be accepted by shim… and the Live OS fails to boot.

As the owner of your PC, you can clear the Microsoft certificates from the local certificate store and load your own certificate instead. Your computer will then boot without issue because your bootloader finds the certificate that it is validating in the trust store.
This is probably the best solution if you are never going to run MS Windows on it anyway. But if you do, or might, or if you want to provide a solution that works on a multitude of computers besides your own, you need to come up with something else.

You are the Machine Owner

Lucky for us poor distro developers, Secure Boot recognizes a database of Machine Owner Keys (MOK) next to the Microsoft trusted keys. And you are the Machine Owner if you have physical access to the computer and know the password to unlock the MOK database (it is empty by default).
The MOK can be populated with public keys of your own making, or of your friends… and/or with liveslak’s public key. And then the shim will accept liveslak’s signed Grub and kernel… and liveslak will boot just fine.

Managing Machine Owner Keys (MOK)

My repository contains two relevant packages: mokutil and sbsigntools. The mokutil package contains the ‘mokutil’ program which allows you to query the SecureBoot NVRAM and to manipulate MOK certificates (the latter only if Secure Boot is enabled). The sbsigntools package contains ‘sbsign’ which is used by liveslak to cryptographically sign the Grub and kernel images.

To check whether Secure Boot is enabled, run:

# mokutil --sb-state

If this returns “Secure Boot enabled” then you are probably running a commercial Linux distro :-). In this case, you can generate a MOK enroll request to the shim before rebooting:

# wget https://download.liveslak.org/secureboot/liveslak.der
# mokutil --import liveslak.der

You will be prompted for an optional password. If you enter one, this password then needs to be entered again after reboot to complete the MOK enrollment.

If Secure Boot is not enabled, don’t worry: you can still enroll this ‘liveslak.der’. Just continue reading.

Adding liveslak.der certificate to MOK database

The remainder of the article will describe in detail how to add the liveslak public key (a SSL certificate) to the MOK if you were unable to use the mokutil program as described above.

Note that adding the certificate is a one-time action. Once the MOK database contains the liveslak certificate, future liveslak ISOs will boot on your SecureBoot-enabled computer out of the box.

Enable Secure Boot in your UEFI (press F1 or whatever key your computer needs to enter setup and find the proper menu to enable SB). Then reboot your computer with a liveslak (1.5.0 or later release) medium inserted.
UEFI will look for the first-stage bootloader on the liveslak medium in the ESP partition (ESP = EFI System Partition which is a FAT partition with partition type 0xEF00). According to UEFI spec, it wants to load the file ‘/EFI/BOOT/bootx64.efi’. The Fedora ‘shim’ binary which is now contained in the liveslak ISO has been renamed to that exact filename. Shim loads, it will try to load our Grub and discovers that its SSL signature is invalid/unknown. Shim will then ask you if it should load the MokManager instead (the ‘mmmx64.efi file in the same directory) which is signed with the distro certificate embedded in the shim.

If you press ‘any key’ within 10 seconds, the MokManager will load and you will have your opportunity to enroll the ‘liveslak.der’ certificate. If you wait instead, the computer reboots and if you had already made an enrollment request as described in the previous paragraph, that request will then be erased and you’ll have to try again.
If MokManager loads, it will show the below screen if you created an enrollment request before the reboot. Select the “Enroll MOK” to complete that enrollment request.


If you entered a password during the “mokutil –import” command you will have to enter that same password next:

 

If you did not create an enrollment request prior to reboot, then this particular menu item will not be present and you should use the “Enroll key from disk” menu instead.
A simple and spartan file browser will be your guide towards the ‘/EFI/BOOT/’ directory on the liveslak medium; select ‘liveslak.der’ file and confirm.
After enrollment of the ‘liveslak.der’ certificate, you must reboot.

After the reboot, your Slackware Live Edition should boot as usual. If you watch closely you will see a flash right before Grub loads – that is the shim loading right before it.

Now, you can check that Secure Boot is actually enabled:

root@darkstar:~# dmesg |grep -i secure
[ 0.016864] Secure boot enabled

Cool!

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.
I tried also generating 32bit ISOs but they refuse to load the init script. The kernel loads, it unpacks the initrd image, but then the boot process stalls right before control is handed over to the initrd. I have no idea why. I tried generating ISOs with an older release of liveslak (1.4.0) that had proven to produce working 32bit ISOs but no luck. Something in the new 5.15 kernel perhaps which liveslak fails to add to the ISO? Suggestions are welcome.

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 apparently this will allow it to boot on a lot more computers.

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

liveslak-1.4.0 and new ISO images are available

October 26, 2021 / / 32 Comments

It’s that time again for a fresh batch of ISOs for Slackware Live Edition.
The ISO files are based on Slackware-current of “Sat Oct 23 18:57:30 UTC 2021” and using the liveslak-1.4.0 scripts.

The Slackware-current snapshot on which the Live ISOs are based contains a Linux 5.14.14 kernel.
This is not yet the pre-emptive variant of 5.14.14 which you can find in “./testing” inside today’s Slackware-current mirrors. However, you can use liveslak’s “upslak.sh” script to easily upgrade the kernel on your persistent USB Live if you want.
It’ll be interesting to see how it improves real-time performance on the DAW Live platform.

The new ISOs for the Slackware Live Edition can be obtained at download.liveslak.org .

Note that a new “DAW” ISO variant is missing for the moment.

Update 28-Oct:
I have uploaded a DAW ISO to the ‘latest‘ folder. It is based on liveslak-1.4.0.1 using kernel 5.14.15 and with full preemption enabled out of the box.

The upgrade in Slackware of Python to version 3.10 forces me to do a lot of re-compilations or upgrades of the software that has a Python3 dependency and unfortunately in the DAW package set, that’s quite many of them.
Give me a couple of days and the new DAW ISO will appear on the above URL. I’ll try and make a liveslak-1.4.0.1 release that supports the preemptive kernel in ‘testing’ and enables the full preemption model on boot of the DAW Live.
In the meantime, you can still obtain a DAW ISO from a month or so ago in the “1.3.10” directory.

I refreshed he ‘bonus‘ section as well with updated live modules for the binary Nvidia driver (already contained in the CINNAMON, DAW and MATE ISOs by the way), the Broadcom STA driver (wl) and an uptodate multilib package collection.

Hghlight for liveslak-1.4.0 is the extended syntax for the ‘persistence’ boot parameter. You can now point your Live OS to a persistence directory or container which is located in a subdirectory below the filesystem root.
Additionally, you can specify the partition containing the filesystem on which the persistence is located, or simply specify ‘scandev’, to request that liveslak tries to find the partition for you:

persistence=/dev/sdX:/path/to/mypersistence
persistence=scandev:/path/to/mypersistence

In addition, a UUID or LABEL value of the filesystem is accepted:

persistence=cd68b6f5-5b5a-4d27-9649-7827489f94a5:/path/to/mypersistence

This creates opportunities for PXE boot where persistence was not possible; the live modules will get mounted from a NFS export and the overlay filesystem does not support writing to a NFS layer. Storing your persistent data on a local hard drive or even a USB stick that you plug into the PXE client computer will solve that predicament.

Have fun! Eric

« Older posts Newer posts »

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑