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
Hello Eric,
it is what I have been waiting for, the new parameters to specify where is Persistence Folder is useful for me.
Muchas gracias!
I’m looking forward to trying the new DAW iso when you release it. I’m guessing the sudden change of moving the pre-emptive kernel into the main branch and other kde and qt upgrades threw a wrench into those plans.
I was running a jamulus session with a friend who uses a windows machine. The latency and lack of ability to route audio on his end made it really difficult to play together. I was routed through jack with ardour, eq, guitarx effects, and minimal latency so everything sounded great from my end. I’m planning on setting up a liveslak daw iso for him try out, which should make a big improvement.
Thanks for putting these out there!
Hi Bob.
I’ve updated Jamulus and will push the new packages out into my repository today. Thanks for the reminder. Then it can also be part of the DAW Live ISO which I’ll generate today.
The ISO will have full preemptive behavior enabled out of the box.
The only regression I could see in the DAW environment is the new Plasma Application Launcher. Since Plasma 5.21, the old Kickoff has been replaced by a “re-design” called “Application Launcher” with “lots of bugs fixed”. However, this new menu system does not adhere to the XDG Desktop Menu standard for merging menus (https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html#merge-algorithm) and as a result, my nice “Slackware DAW” submenu is gone. That submenu is where I combine all the DAW tools in order to un-clutter the higher-level Plasma Multimedia menu.
There’s an alternative menu system for Plasma but it is not enabled by default. The “Application Menus” does a correct implementation of the XDG specifications so there you’ll have a proper “Slackware DAW” menu structure.
I could not find a scripted way to make this alternative menu launcher the default. I am not a star in KDE Desktop scripting (https://develop.kde.org/docs/plasma/scripting/) but I am sure that this should be possible. Open to suggestions here, but first, wait for the new DAW ISO.
Normally I just use the alt-spacebar ‘krunner’ shortcut to launch what I need, but thats just my habit and I know whats already included in the DAW. I just got the DAW iso downloaded and booted up for testing so I’ll look at that application launcher set up also. First I wanted to see how this preemptive kernel works with the boot options and debugfs interface. If it helps with performance I’ll probably make it default for the DAW stick.
A little hiccup on my first run though: Ardour is looking for ‘libicuuc.so.68’. I added the relevant ‘compat’ package from your repo to get it working but Ardour will need a rebuild against the latest version.
I’ll let you know how the rest of my testing goes.
Guess I misread that preemptive was already enabled and thought that just meant that the option to use it was enabled. I just checked /proc/cmdline and see that ‘preempt=full’.
Bah, I missed that Ardour library dependency failure.
After Chromium and its un-googled sibling, I will set my build box to work on Ardour.
Everything else I’ve tried is working great with the latest DAW iso here. I didn’t really notice a difference with the new “Application Menu”, v.s. the older “Application Launcher”. The “Slackware Live DAW” submenu keeps all those programs and plugins organized nicely. I’m not familiar with KDE scripting so I cant suggest anything to improve on it.
I also tried recompiling pipewire against jack and adding that along with the ‘daemon’ program to the DAW iso. After configuring pipewire to lower latency settings (can be done without rtkit now), it nicely ran an ardour session with effects on my guitar. There is nothing wrong with pulseaudio + jack but I like testing the latest pipewire capabilities with the DAW environment on the live USB and it doesnt take much to set up these days.
I’ll keep a lookout for that Ardour update but everything else is running great. Nice work!
Hi Bob
If you have some good info on better pipewire configuration including the ‘daemon’ package, I can add that plus the pipewire-jack package which I never published and then people can have a go at it in the DAW environment. Seems like a relevant improvement.
By the way, you still see the “Slackware Live DAW ” menu because I got rid of the new “Application Launcher” aka Kickoff and replaced it (only for the DAW ISO) with the more XDG compliant Kicker menu system.
I think that guitarix also is linked against ‘libicuuc.so.68’. I just didnt notice because I installed the compat package after the first run with ardour. I guess there could be others. I dont have an automatic ldd checking script on the stick yet.
RE Pipewire: I have been documenting my latest work with pipewire over on a thread at linuxquestions.org. See this post and the following post about using pipewire for jack, and management with daemon: https://www.linuxquestions.org/questions/slackware-14/using-pipewire-instead-of-pulseaudio-in-slackware-15-a-4175693980/page11.html#post6297256
Note that the ldconfig steps there only apply for pipewire compiled with jack support, which is what I’m using in the DAW case. It’s unfortunate that it requires the linking step because that requires root privileges, and its not a switchable change. I.e. if one were to include that ld.so.conf file, then pipewire-jack becomes the default and reverting to original jack would require deleting the conf file and re-running ldconfig.
I did try using a tmpfs to make a temporary ld.so.conf change based on a boot time parameter. This isn’t ideal for full installs in the case where one were wanting to use this directory for more config changes, but it would add a toggleable feature to the DAW iso if you think it would fit. I used the following in my /etc/rc.d/rc.local script to make the boot option ‘pipewire-jack’ recognized:
# Check if pipewire-jack is on the cmdline, and set up as needed:
if ( grep -q ‘pipewire-jack’ /proc/cmdline ); then
if [ -x /sbin/ldconfig ]; then
echo “Linking pipewire-jack”
# Mount a tmpfs over /etc/ld.so.conf.d so changes revert after reboot
mount -t tmpfs -o size=1M tmpfs /etc/ld.so.conf.d
echo “/usr/lib64/pipewire-0.3/jack” > /etc/ld.so.conf.d/pipewire-jack-ld.so.conf
/sbin/ldconfig &
fi
fi
In addition (or perhaps it fixes the issues) raptor2 needs to be rebuilt against icu4c and faust needs to be rebuilt against llvm libraries. I’ll rebuild ardour and guitarix anyway, for good measure.
I’ll look at what’s still missing in the DAW ISO to be able to play with pipewire. A pipewire-jack package needs to be created and I’d have to add the ‘daemon’ package to the list.
A fresh DAW ISO has been uploaded with some programs compiled to deal with the newer icu4c and llvm libraries. I also added the daemon package from Slackware.
Excerpt from my repository ChangeLog.txt:
+--------------------------+Mon Nov 1 12:06:54 UTC 2021
ardour: rebuilt against new icu4c in -current (perhaps not needed because
it's actually its dependency raptor2 which needed the recompile).
faust: updated to 2.37.3 (-current only).
guitarix: rebuilt against new icu4c in -current (perhaps not needed because
it's actually its dependency faust which needed the recompile).
pipewire-jack: added v0.3.39 - JACK sound server support for pipewire.
raptor2: rebuilt against new icu4c in -current.
+--------------------------+
Thanks for the updates Eric, I will download it and refresh my USB drive with the latest version to continue testing.
On the topic of pipewire:
While I have found that the stability and increased, and usage of pipewire has been simplified over the last year, it still seems to be a fast moving target. E.g. Just the latest 0.3.39 version of pipewire started including an option to use pipewire without rtkit in its config file. The config file template seems to change with each version release, to the point where older config files actually prevent newer versions of pipewire from starting.
I fear that setting up a configuration that works with pipewire-jack “out of the box” will probably break several versions later, so it may not be worth effort to set up completely for now. I hope that in the future the pipewire devs simplify the jack setup.
What would be nice is to include pipewire rebuilt against jack, and the daemon tool to allow it to be properly managed. If that is whats in the new ‘pipewire-jack’ package you added then I will be happy to use that. Just having those two packages included simplifies most of the work to get pipewire running jack on the DAW. At that point a user can get everything to run through pipewire, with a little command line work.
DAW Live ISO based on liveslak-1.4.0.1 has been uploaded. It comes with full preemption enabled out of the box, and uses the Plasma Kicker instead of Kickoff as the application launcher, so that you will have a working menu structure containing ‘Slackware DAW’ below the ‘Multimedia’ menu.
Will the existing bonus/0060-daw-current-x86_64.sxz from 2021-09-09 work with the newer 2021-10-25 slackware64-live-current.iso that has the newer python 3.10? I have a new laptop to install Slackware on and like to have the extra programs to play around with, but don’t need a specialized DAW installation. Video transcoding yes, Audio not so much.
On a side note, as you go to update packages, the 1.4.1 and 1.4.2 releases of Handbrake have a bug in the Linux GUI that causes the filterlist of an existing Queue entry to not be updated correctly upon subsequent additions to the Queue. (Most noticeably, if you try to edit an existing entry to turn off a filter, it will appear to be off but the previous settings will still be used in the encode job) It’s been fixed in the master git branch for the upcoming 1.4.3 release.
Hi SouLShadow,
I still had to update bonus/0060-daw-current-x86_64.sxz, thanks for the reminder. A new version of the file is now available on the mirrorsite, which contains the updated packages that needed a recompile or upgrade for Python 3.10.
I guess I will update Handbrake as usual, when the new release is ready.
I’m liking having the preemptable kernel that I didn’t have to compile myself. I hadn’t considered the gaming aspects of one, either. Normally I just do my music in the preemptable one, then reboot for the normal kernel. I suddenly discovered that I don’t merely suck at Guild wars 2 jumping puzzles.
Hi Eric.
Just came to thank you for this release. New blood for my liveslak. Many thanks again!.
Francisco.
It’s as good a place as any to ask.
Who has (access to) a computer with Secure Boot enabled? I do not own such stuff.
And who wants to test a DAW ISO that hopefully boots on that Secure Boot computer?
The liveslak signing certificate would have to be enrolled via MokManager (part of the ISO) or using mokutil (I have this in my repository for -current) because I use the Debian ‘shim’ which is signed by Microsoft and contains a Debian certificate, not a liveslak cert.
The liveslak certificate to be enrolled in MOK is in /EFI/BOOT/liveslak.der on the ESP partition of the ISO.
Let me know, if there is at least one ‘yes’ I will upload a testing ISO and expect feedback of course.
I can not get it to boot in QEMU with the OVMF tianocore secureboot firmware and VMWare refuses to emulate SecureBoot on my AMD CPU. And I really need to know if my theories work.
I have both free time right now and a laptop with secure boot that can be enabled/disabled in the bios. Might need a little direction as I’ve never played with secureboot or shims or certs before.
I have a DAW Live ISO on https://download.liveslak.org/sb/ (or rync://download.liveslak.org/mirrors/slackware-live/sb/ if you prefer rsync) which will hopefully boot on a SecureBoot enabled computer.
The idea is that my ISO boots the Debian secureboot shim (I could also use Fedora’s but this ISO has the Debian one) and since that one is signed by Microsoft, it boots without issue. The shim is the first-stage bootloader and it will attempt to load ‘grubx64.efi’ next. When it detects that liveslak’s grubx64.efi is not signed by Debian nor by MS, it will instead load ‘mmx64.efi’ which is the ‘MokManager’. What you will see on your screen is a console-based application which will ask you to point to the certificate which was used to sign ‘grubx64.efi’. That certificate is the ‘liveslak.der’ file which you will find on the ESP partition (the FAT partition containing all the UEFI files) in the directory /EFI/BOOT/ . Click through the directory tree, select ‘liveslak.der’ and MokManager will store that certificate in the NVRAM of your computer as a “Machine Owner Key” aka MOK. The result will be that your computer’s SecureBoot will then accept any binary which was signed with that key.
So the next time your boot liveslak, shim will validate grubx64.efi, finds that it was signed by a certificate which is in your NVRAM’s MOK store, and will load Grub without complaining. It means that you only have to ‘enroll’ that liveslak.der certificate once. It will remain in your computer’s NVRAM until you would intentionally erase it.
I hope you will get past the above stage. Then the next question will be: does Grub behave and load your kernel, or will it fail? I modified grub.cfg but I am not certain whether I made the correct changes for the SecureBoot case.
Any feedback is welcome.
Sorry for the delay, I had a transcode to finish up on my test machine.
No luck.
First off I made a USB stick simply with:
iso2usb -i daw.iso -o /dev/sdd
booted into bios and enabled secureboot
tried booting and got a blue screen with the text title “Boot Option Restoration” with “Press any key to stop system reset”
doing nothing reboots. pressing any key brings up a small menu:
Reset system
Continue Boot
Always continue boot
first 2 options both result in immediate reboot, didn’t try the 3rd option.
next, my bios has an option to manually select an EFI boot file. Of all the files on the USB (mmk, grub, something I forget and bootx) only bootx64.efi would load without a signature error. And of course that just brings up the lovely blue screen above.
Finally I disabled secureboot and tried booting the USB and encountered the exact same blue screen and resulting outcomes.
I did not try manually selecting a boot file at this point.
May I suggest that future test images be bare bones iso’s with only the essentials to boot to a command prompt. While I have a sufficiently fast fiber connection, it would greatly speed up the testing process. Once the boot process is successful then a full ISO could be tried for completeness. Any changes that can be made directly to the USB without needing to download files would also speed up testing.
went back and tried manually selecting an EFI boot file with secureboot OFF and here are the results (in the order they appeared):
mmx64.efi: brought up the mokmanager blue screen to install a key
grubx64.efi: booted up the live OS
fbx64.efi: “Boot Option Restoration” screen as above
bootx64.efi: “Boot Option Restoration” screen as above
——
didn’t try installing any keys while secureboot was disabled as that seems counterproductive to the testing
Yes, future testing ISOs need to be smaller, I concur.
In the meantime I found a laptop which can enable SecureBoot. I did not get that far yet because I tried booting the ISO first without SecureBoot. Indeed the shim starts and presents the MokManager (blue screen) asking me to enroll a key. I did that, because then I do not have to once I enable secureboot (the keys in NVRAM are accessible also without SecureBoot enabled, just install my mokutil package and run “mokutil –list”).
But I do not get past the sim. It should load Grub (the grubx64.efi file) but all I get is a black screen and all I can do is press the reset button.
The ISO needs to work on non-SecureBoot systems too, which is why I want to look into that first.
It’s a little off topic from secure boot, but I was trying to build a minimal test iso with ‘make_slackware_live.sh’ for the purpose of just being able to boot to a command line. Basically the purpose was to just test booting the iso.
I used a ‘make_slackware_live.conf’ file with the package list: ‘SEC_CUSTOM=”min,noxbase,x_base”. I would have preferred to not include ‘x_base’ because I had no need for ‘X’ on the stick but the make_slackware_live.sh script will fail if it can’t find ‘fontconfig’, which is only in the ‘x_base’ list. I know I could have added it to ‘noxbase’ instead but I didnt feel like messing about with the stock pkglists.
Anyway, the resulting .iso file was 956M in size. I found that surprising since the XFCE iso is only 703M, and it also includes XFCE packages.
So whats the secret sauce behind the XFCE iso size being so low? And any suggestions for a config that would build a truly minimal iso? Sorry if this is noise, I just figured a liveslak post would be most appropriate and you guys mentioned a minimal size test iso.
The XFCE ISO is trimmed, meaning all kinds of non-essential stuff is removed. Try adding “TRIM=bloat” to your config file.
I should check for the existence of the X binary really and disable X related stuff, if I am going to support a console-only variant. I’ll think about it.
Edit: I updated the script and it should hopefully now not fail if x_base is not used. I did not actually build a test ISO but the offending command is now inside an ‘if’ block.
Well, best of luck. I’ll be around if/when you need a test subject.
As for the keys, I purposefully did not enroll a key with secureboot disabled because, as I understand it, doing so on a secureboot enabled system is a critical part of the testing process and ultimate goal.
I took the down time yesterday to update -current. Was waiting to see if/when python would roll back and it did. While sorting through the 587 changed packages I noticed there were also a bunch of multilib packages with lower versions then their counterparts. Between that, python related recompilation and any other packages in the works, I assume you’ll be pretty busy. I really appreciate what you do and. after 24 years of exclusively running Slackware, any time I have an opportunity to help out, I will. If there is some configuration(s) that I could apply and test on my end which will lower your burden, then feel free to contact me. If it’s easier I can be reached directly at my name dot net at chromium’s corporate overlord’s domain.
Updates for packages in my repository that needed recompiling as a result from the downgrade to Python 3.9 will be available real soon.
I will also update the multilib set.
SouLShadow, I have succeeded:
root@darkstar:~# dmesg |grep -i secure[ 0.016864] Secure boot enabled
I will now wrap up my liveslak script changes and reboot a couple of times and also create some more ISOS (this is typed in a login session on the XFCE ISO with SecureBoot enabled).
The MOK key enrollment was one of my issues: I had tried to enroll the key using mokutil while SecureBoot was disabled but that enrolled MOK key resulted in ‘invalid parameter’ errors when I enabled SecureBoot. After I had reset the MOK database and re-enrolled using the SHIM on boot, everything proceeded just dandy.
Awesome. I look forward to testing it out. Perhaps it’s a start toward secureboot support in the main Slackware distribution. Not that I plan
to use it personally, but it would help open Slackware up to new users that need to dual boot with secureboot enabled.
Looks like there’s more progress being made with Frescobaldi now that Fedora 35 shipped with python 3.10.
https://github.com/paopre/Spontini There’s also this. It’s browser-based, I think. I haven’t really used it, but it’s been discussed on the lilypond mailing list.