The previous batch of ISOs for Slackware Live Edition is already a few months old, so I decided to generate new images.
The ISO files are based on Slackware-current of “Wed Sep 8 18:07:38 UTC 2021” and using the liveslak-1.3.10 scripts, where passwordless login is a new feature.
Slackware-current has the label “15.0 Release Candidate 1” since August 16th but considering the amount of non-trivial updates since that date, I wonder whether the phrase “release candidate” has any relevance here. No sign that we are anywhere nearer to a final 15.0 release.
Let’s hope for the best, and in the meantime fresh ISOs for the Slackware Live Edition can be obtained at download.liveslak.org .
I refreshed he ‘bonus‘ section as well. There you find several squashfs modules you can use with your persistent liveslak USB stick. Copy these module into the ‘addons’ directory on the USB drive. They expand the functionality of the Live OS and allow me to keep the ISO file size within reasonable bounds.
Among these you’ll find the binary nvidia driver (already contained in the CINNAMON, DAW and MATE ISOs by the way); Wine 6.12, multilib, the DAW package collection, and a set from my own repository (chromium, libreoffice, veracrypt, vlc etc).
To end this post, I have a question for you regarding liveslak functionality.
At boot you can add any number of parameters to the kernel commandline, and some of these are used by the liveslak initialization. A subset of these parameters cause modifications of files in the live filesystem. For instance, “livepw=” will update /etc/shadow and /etc/passwd to update the password for the ‘live’ user. You can specify a domain name, custom hostname and a lot more which will cause modifications of files in the live filesystem.
Now the crux of the issue: if you have a persistent Live USB stick, do you want these parameters to make permanent changes to your Live filesystem? Or do you want them to be ignored if you are booting a persistent USB stick?
I can see good reasons for a limitation of the scope of these parameters, to just the non-persistent Slackware Live (i.e. when booting from a DVD). I also realize that it would be a functional change that can impact the way some of you work with a liveslak medium.
Let me know (in the comments section below) if you would like liveslak to ignore certain boot parameters if you boot a persistent medium.
Have fun! Eric
In my opinion live CD/DVD/USBs should have an immutable “base” system. Permanent changes then belong in a “changes” directory on top of that “base” system. And ad-hoc changes on the command line should override the “change” directory and the “base” system.
By making the command line easily accessible a “changes” directory might be superfluous in many cases.
Regards, Dick 😀
That is not completely answering my question I think. My live system does indeed have that immutable base layer (everything that’s in the squashfs modules which get layered on top of each other to build the filesystem).
But there are two implementations of the ‘changes’ directory. One is the ‘changes in RAM’ where anything you would modify will be lost on reboot. And then there is the persistent ‘changes’ where your modifications to the filesystem will still be present after you reboot. My question is only relevant for the persistent case.
Let’s take an example of my dilemma.
You have a persistent USB drive, you still use the ‘live’ account but have given it your own new password instead of the default string ‘live’. Now, you boot this stick and pass the parameter “livepw=” which will edit your passwd and shadow files to remove the password for user ‘live’. Now you reboot again and do NOT add “livepw=” as a boot parameter. Still, your ‘live’ user will have an empty password because that change during the previous boot-up was a permanent change to the filesystem. Your custom password is gone. Is that what you really want?
That was the rationale for my question: I can make the live init ignore such boot parameters if it detects a persistent ‘changes’ directory.
And no – it is NOT possible to stack a ‘volatile’ layer on top of that ‘persistent’ layer which is again stacked on top of the ‘immutable’ layer.
When reading back my post and your answer it occurs to me that I described the changes handling in my own private fork of PartedMagic …
The basic difference with your handling is the fact that changes irrespective from where they came are held in memory. One has to explicitely run a “Save Session” to make the then current situation permanent — persistent in your terminology. That “Save Session” will create/overwrite a module (a bonus for you) that will be loaded at the next boot before the command line is read. So your “livepw=” boot parameter by default would be for this session only.
You seem to assume the boot parameter to be entered at boot time via the Grub “e” command. However alternatively one can edit the grub.cfg file to make the boot parameter permanent.
So, to answer your question I would prefer a boot parameter to always override the changes and base directories.
Regards, Dick 😀
I use liveslak with encrypted home directory for my personal use.
How vulnerable is my install for case uses you exposed? (root password specially).
In liveslak use case like mine, I think security is a must.
Thanks for liveslak, Eric.
The encrypted homedirectory does not re-use the password of the live or the root user.
You define that passphrase for the LUKS encryption when that encrypted container is created (normally, that would be part of the “iso2usb.sh” process of creating a persistent USB stick).
Nobody will be able to break that encryption if they do not have that passphrase.
I’ve been using the live slack as a daily driver. It’s nice to be able to move from PC to PC and have the same apps and files.
Most of my boot options would be temporary in my mind.
EXCEPTION: Being able to save my timezone would be nice. *US/Central” or “America/Chicago” – UTC can cause some issues between PCs and when I try and fix it, I have to fix it again on the ‘native’ OS to the host hardware when I don’t boot with the Live Slack.
Perhaps I should document this better, the feature you are looking for actually exists.
liveslak can optionally load a OS config file “/@LIVEMAIN@/@DISTRO@_os.cfg” – in the case of Slackware Live Edition it is actually called “/liveslak/slackware_os.cfg” – i.e. is placed in the “liveslak” directory of your USB drive.
This file contains “VARIABLE=value” lines, where VARIABLE is one of the following variables that are used in the live init script:
BLACKLIST, KEYMAP, LIVE_HOSTNAME, LOAD, LOCALE, LUKSVOL, NOLOAD, RUNLEVEL, TWEAKS, TZ, XKB.
This configuration file will override any other values you may already have set via liveslak’s own defaults or via boot-up command-line parameters.
The liveslak init accepts a boot-time parameter called “cfg” which understands two possible argument values:
(1) “cfg=write” will write this configuration file to your USB drive, using the values for all of the above variables that are valid at that particular boot. So if your timezone is “PST” then one line in that file will read “TZ=PST”.
(2) “cfg=skip” will skip loading/processing an existing “/liveslak/slackware_os.cfg” file if it exists. If such a file does not exist at all (which is the default) then you would of course not need this boot-time parameter at all.
As an example, here is the content of /liveslak/slackware_os.cfg on my own USB stick:
*jaw drop* (I missed that information or didn’t put it together)
I will be trying that out tonight – Thank you!
In that case… I’ve reread this part of your post a few times and it seems ‘safer’ to limit the scope on a persistent medium… For a password reset it does sound nice though. I hope others have better arguments in either direction. =)
Adam, the ‘cfg’ parameter is mentioned in the documentation. Exactly what it can do for you cannot be found in the README. That information currently is only available inside the live init script as comments to the implementation.
I will have to update the README with the above text I guess…
Hi Eric, thank you for liveslak again!
I would like these parameter changes to be ignored when booting a persistent USB stick.
Pingback: Links 10/9/2021: liveslak-1.3.10 and PipeWire 0.3.35 | Techrights
Version 14.2 is now 5 years old, and if the trend continues, version 15 will not get upgraded for another 5 years or more. At the same time, most software we use get upgraded regularly in an increasing frequency. So, if we stick to the stable release of Slackware, it will be state in a short time, perhaps in a couple of years. It seems, keeping a distro up to date is an increasingly difficult job. Do you think that the one-person shop of Mr. Volkerding will be able to keep up with the demand?
I have been using Slackware current on several of my computers. It seems I’ll have to keep using the current release, and periodically update it, rather than the stable release if I don’t want to get stuck with a stale system. I would be interested to hear your thoughts on this.
I guess a sound approach would be to use the stable release for a server and the current release on a desktop.
I run Slackware 14.2 on my server at home, Slackware64-current on everything else, including my laptop, my desktop and other online servers. A lot of software simply won’t work on 14.2, even server-based software often requires PHP7 or a newer MariaDB than shipping in Slackware 14.2.
I run -current on internet-facing servers by necessity, not because I like it! It is very hard to keep these servers secure and up-to-date while at the same time not causing downtime due to breakage after a -current package update.
Also, the OpenSSL in Slackware 14.2 is obsolete. Let alone KDE4 which was already un-maintained when Slackware 14.2 was released. A Slackware 15.0 release is 3 years overdue and if it does not happen in 2021 then I expect it’s going to be a difficult story to sell.
i’m testing slackware64-live-xfce-current.iso with multilib, alien and alienrest bonus sxz. I have a problem starting Libreoffice (7.2.0): when start libreoffice or soffice command i get this stack trace:
terminate called after throwing an instance of ‘com::sun::star::uno::DeploymentException’
Fatal exception: Signal 6
My (your) java version is openjdk version “1.8.0_302”
How can i solve it?
Thanks in advance for all your work.
To solve it, simply DO NOT use the XFCE ISO file. It is a very bare Slackware image with lots of packages and files not being present to keep the ISO below 700 MB.
If you want to use add-on modules from my bonus sub-directory, it will only make sense to combine it with the full Slackware ISO (slackware64-live-current.iso) which has all the dependencies that my 3rd-party packages expect to be present.
i didn’t know that bonus are only for full iso.
I would to create a slim-de iso, so i started from xfce variant, integrating bonus for gparted, libreoffice and some other tool:(
About specific error is it possible to detect missing dependency?
If i start from full-iso and manually remove other de packages can i obtain a (like-full)slim-de viariant?
The stuff in bonus is not only for the full Slackware Live. There’s the nvidia driver which works for all ISOs for instance. But generally speaking, my own packages expect a full installation of Slackware. If you want to slim down your installation I can and will not guarantee that my own packages will still work.
You can also download the LEAN ISO which is only 1.9 GB in size, compared with the 4.3 GB of the full SLACKWARE image. Perhaps that will work with my add-on packages.
Unfortunelly libreoffce doesn’t even work with LEAN iso (same error), but with full iso did;)
Thanks for support and crossfingers for Slackware stable release:)
I downloaded slackware64-live-current.iso and iso2usb yesterday. Installed it to a usb key with:
./iso2usb -i slackware64-live-current.iso -o /dev/sdb
It completed w/o error. When I boot, after selecting slackware live in the menu, I get the following error message:
error: shim lock protocol not found
error: you need to load the kernel first
The laptop uses UEFI boot. Legacy boot is not supported.
What can I do?
Thanks in advance for your help
My ISOs do not contain the SecureBoot shim so I have no idea what causes this error. Did you use this USB stick before with another distro’s GRUB installed on it?
Slackware Live boots fine on UEFI computers, but the SecureBoot needs to be disabled.
Thanks for the quick response. I naively thought that the shim was used everywhere Linux was booted on UEFI (I am a dinosaur with a new laptop and almost no practical knowledge about UEFI)
So I disabled SecureBoot in the BIOS and the Slackware live usb key boots fine. Thanks for this great Slackware live edition!
By the way, any plan to include the shim in your ISO and/or in the regular Slackware (15?)
Slackware will eventually also incorporate a means to boot on UEFI SecureBoot-enabled computers but I have no idea whether that will happen before the 15.0 release. My guess would be: after that.
In the meantime, I am independently looking into possibilities to make my own liveslak ISOs able to boot on computers with SecureBoot enabled.
Unlike Patrick Volkerding, I have a day job which is not related to Slackware, so it may take some time to figure it out.
Ok. Thanks again for your work!
Thank you for providing these isos. Nice work! Really.
Downloaded and installed first the xfce4 version because small and fast. But unable to compile C programs.
Downloaded and installed then the current kde version in order to be able to compile. No problem to compile and run the c file (lua) I needed. Made a module and copied it in the “addon” directory of xfce4.
Get following error : “lua
-bash: /usr/local/bin/lua: No such file or directory”
How is this possible since the ‘lua’ file is present ”
find /usr/local/ -name lua
and “ls -al /usr/local/bin/
drwxr-xr-x 1 root root 80 Oct 20 13:55 ./
drwxr-xr-x 1 root root 60 Oct 20 2021 ../
-rwxr-xr-x 1 root root 252248 Oct 20 13:55 lua*
-rwxr-xr-x 1 root root 170756 Oct 20 13:55 luac*
What’s wrong? Vreemd?!?
Thank you for kind attention
As a test I installed lua from my own repository into a XFCE Live installation. Lua runs fine, it does not miss any dependencies.
There’s a possibility that you compiled lua as 32bit and are trying to run it on a 64bit XFCE Live, or the other way round? That can give that “no such file or directory” error.
Have to apologize. You are right. Thought I had installed slackware64-live-current.iso but the modules in /liveslak/system show “-current-i586.sxz”.
Will install ‘slackware64-live-current.iso’ and compile again,
Thank you very much for your comments.
Dank. Prettige dag!
Is there a way to merge multiple addons into one file? As I make changes I am adding more to the addon directory. Love your work in slackware. Thanks.
You can extract the contents of multiple squashfs files (the *.sxz files are merely squashfs containers that are compressed using ‘xz’) into one target directory, then squash the full content of that directory into a new .sxz file.
I just found this blog area for a BIG THANK YOU!!! for liveslak and KDE in
I got a shine and beautiful KDE Plasma 4K display, all environment is working perfectly for my daily use in my DELL XPS 31 (9370) 4k Display.
And a USB stick with liveslak is in my wallet :).
Again, thanks Eric!
Glad you like it 🙂
I can’t boot live slak from my sd card. The kernel modules aren’t in the intrd (I think) and so it can’t find the root filesystem. As I’ve understood, the missing modules are “rtsx_pci” and “rtsx_pci_sdmmc”. Is there a way to add them?
Thanks a lot
It would mean building a whole new initrd for the Live ISO, adding these two modules “rtsx_pci:rtsx_pci_sdmmc”. There’s no easy or scripted way to do that yourself.
I will update my liveslak scripts, adding the two modules, so that the next release should support booting from your SD card.
Thank you so much!