I have released an update of the ‘liveslak‘ scripts. I needed the tag for a batch of new ISO images for the Slackware Live Edition. These are based on the latest Slackware-current dated “Wed Nov 22 05:27:06 UTC 2017“) i.e. yesterday and that means, the ISOs are going to boot into the new 4.14.1 kernel.
The new liveslak version 1.1.9.3 has a few updates. Most are not worth mentioning but these are:
- CACert root certificates are added to the OS so that you can visit the upcoming blog.alienbase.nl securely without nasty warnings about untrusted certificates.
- The PLASMA5 ISO image features Wayland support. You can login to a regular X.Org Plasma5 session but you can also choose the “Plasma – Wayland” session from the SDDM dropdown menu. In order to keep the ISO size below the DVD medium maximum size, I had to leave the optional ‘wine’ module out of the ISO. You can still download the wine module from the ‘bonus‘ location.
FYI, this was the command to generate that PLASMA5 ISO:# ./make_slackware_live.sh -d PLASMA5 -m plasma5wayland -M -X
If you already use a Slackware Live USB stick that you do not want to re-format, you should use the “-r” parameter to the “iso2usb.sh” script. The “-r” or refresh parameter allows you to refresh the liveslak files on your USB stick without touching your custom content. If you want to modify other parameters of your USB stick, use the script “upslak.sh“. It’s main feature is that it can update the kernel on the USB stick, but it also can replace the Live init script. As with most (if not all) of my scripts, use the “-h” parameter to get help on its functionality.
More detail about the features of Slackware Live Edition can be found in previous posts here on the blog.
Have fun!
As always: a big THANKS!
Alas this time the 698M slackware-live-xfce.current.iso has some problems:
— during boot sbin/ip complains about libmnl.so.0 not found;
— starting the terminal emulator fails with an “Input/output error”.
😀
burdi01 the recent updates in -current must have wreaked havoc on dependencies. I’ll have to rebuild both the 32bit and 64bit XFCE ISOs from scratch, adding new packages to satisfy new dependencies.
Eric: Take your time, I can use the “full” live-current for the time being.
Regards, Dick
The fixed XFCE ISOs have already been uploaded burdi01…
Eric: Thanks. All is well now.
😀
Eric: Thanks. All is well now.
????
I have tested plasma5 iso on dvd and usb key, no proplem 😉
Anyone try the live USB with a Chromebook or the new Pixelbook? I have one of the new Pixelbooks coming this week and plan on using the Plasma5 version. Just wondering if anyone had any experience, tips or tricks.
I have a Chromebook but it’s an ARM version so the Slackware Live is not going to work there. A Pixel2 costs a lot of money. But, I assume it should work fine with this Live USB.
Hi Eric, thanks for the .iso, I’m running in an annoying issue, I installed the system on disk with the setup2hd script, created a new user and logged in. After connecting to wifi I’m unable to launch any graphical application (“no protocol specified” error). For now I added a script to the startup applications to do “xhost +local:” as suggested in a post I found in LQ, but I was wondering if there’s a proper fix to this issue and if you know what exactly is going wrong.
Just before rebooting after the installation to disk I noticed a couple of errors printed in the console, something like “AUTHORITY add … bad command”, could it be related to the messed up permissions I’m facing?
matteo you don’t tell which of the ISOs you downloaded and installed, but I am guessing that it was the PLASMA5 ISO?
Are you running a Wayland session? You are running the graphical session as the non-root user?
Are you booting into runlevel 3 or 4?
And how are you attempting to start your graphical applications?
It’s a pity that you do not remember the exact errors you saw right before rebooting.
You are right I forgot to add a lot of info.
I’m running the plasma5 iso, x11 session as normal user and I think I’m booting into runlevel 4 because I get the sddm prompt.
Attempting to start applications from the start menu silently fails, while in the terminal I get the “protocol” error. This issue happens as soon as I connect to the WiFi network, that I thought was automatically picked up after the first connection but actually isn’t.
The errors I mentioned briefly flashed before the reboot, I didn’t have enough time to properly document them, I can try to replicate them again in a virtual machine when I have some time, meanwhile the workaround script on startup seems to work fine, I’m good for now.
Btw impressive job with the setup, all the latest and greatest and zero issues so far (apart this permission thing).
Hi Eric,
I’ve created an USB stick with your scripts, but if I try to boot from a laptop with linux already intalled, it stucks on bootloader with only a “GRUB” up left on the screen. If I boot it form another laptop without linux, it works (both laptop with UEFI).
Can you help me?
Mario laptops with UEFI usually support “legacy mode” where a BIOS-based boot is performed. The Slackware Live Edition will use syslinux to boot in BIOS mode. Perhaps that way it will boot on that laptop of yours.
The GRUB is what’s used on a UEFI boot. Why it displays only the word GRUB and does not show the boot menu I can not answer.
FYI, have you see this?:
https://lizards.opensuse.org/2017/11/17/encrypted-installation-media/
Totally irrelevant. Slackware Live Edition is already capable of encrypting the sensitive bits. No need to slow down the USB-based OS even further by fully encrypting it. Waste of time.
I have Slackware Current on my laptop with your repositories so am running Plasma5 (not that this really matters). I have a USB installation of Liveslak that I used with my work laptop last month while on the road. I save a few files on it and would like to mount the ‘slhome.img’ file on the laptop running Current without rebooting.
Most everything I can find talks about mounting a Luks partition, but not just an image file.
Nate, the “slhome.img” file is a container. You have to loop-mount it first, then use cryptsetup to unlock the LUKS partition inside and then mount the mapped device to access the data.
Something like this should work (untested):
LOOPDEV=$(losetup –find)
losetup –find /path/to/slhome.img
cryptsetup luksOpen $LOOPDEV homeluks
mount /dev/mapper/homeluks /mnt/tmp
< ... access your data below /mnt/tmp ...>
umount /mnt/tmp
cryptsetup luksClose homeluks
losetup –detach $LOOPDEV
Those commands worked exactly as you’d written them. Thanks so much, Eric!