aboutsummaryrefslogtreecommitdiffstats
path: root/README.txt
diff options
context:
space:
mode:
Diffstat (limited to 'README.txt')
-rw-r--r--README.txt142
1 files changed, 111 insertions, 31 deletions
diff --git a/README.txt b/README.txt
index 79ae1f8..95bbf7b 100644
--- a/README.txt
+++ b/README.txt
@@ -33,12 +33,12 @@ The reasons I had for creating the Slackware Live Edition are as follows:
The "liveslak" scripts can generate a variety of Slackware flavors:
- - a complete 64bit Slackware-current Live Edition (in a 4.4 GB ISO);
- - a slimmed-down XFCE ISO (1000 MB) with XDM as the graphical login manager. It fits on a 1 GB USB stick;
- - a LEAN ISO (2.2 GB) of Slackware-current with reduced package set and based on Plasma5 Desktop;
+ - a complete 64bit Slackware-current Live Edition (in a 4.5 GB ISO);
+ - a slimmed-down XFCE ISO (1100 MB) with XDM as the graphical login manager. It fits on a 1 GB USB stick;
+ - a LEAN ISO (2.5 GB) of Slackware-current with reduced package set and based on Plasma5 Desktop;
- A Digital Audio Workstation (DAW) based on a custom Slackware package set plus a basic Plasma5, containing a rich software collection for musicians, producers and live performance artists (3.6 GB).
- - a Mate variant (3.8 GB) where KDE has been replaced by Mate (a Gnome 2 fork);
- - a Cinnamon flavour (a fork of the Gnome 3 Shell replacing Slackware's KDE) in an ISO file of 3.7 GB;
+ - a Mate variant (4.2 GB) where KDE has been replaced by Mate (a Gnome 2 fork);
+ - a Cinnamon flavour (a fork of the Gnome 3 Shell replacing Slackware's KDE) in an ISO file of 4.2 GB;
- a Dlackware variant, which is Gnome3 + PAM + systemd on top of Slackware and stripped of KDE (no longer developed after Slackware 14.2);
- a StudioWare edition containing all the project's audio, video and photo editing software packages (no longer developed after Slackware 14.2);
- a "Custom" variant which you can give your own name, its own package list and custom post-install configuration.
@@ -73,13 +73,14 @@ Slackware Live Edition deviates as little as possible from a regular Slackware b
=== BIOS boot ===
-Slackware Live Edition uses syslinux to boot the Linux kernel on BIOS computers. To be precise, the "isolinux" variant is installed to the ISO image and the "extlinux" variant is installed into the Linux partition of the USB Live version.
+Slackware Live Edition uses syslinux to boot the Linux kernel on BIOS computers. To be precise, the "isolinux" variant is installed to the ISO image and the "extlinux" variant is installed into the ext4-formatted Linux partition of the USB Live version.
Syslinux shows a graphical boot menu with a nice Slackware-themed background and several options:
* Start (SLACKWARE | XFCE | MATE | CINNAMON | DAW | LEAN) Live (depending on which of the ISOs you boot)
* Non-US Keyboard selection
* Non-US Language selection
* Memory test with memtest86+
+ * Console OS in RAM
You can select a keyboard mapping that matches your computer's. Also you can boot Slackware in another language than US English.
If you stick to US English interface language you will probably still want to change the timezone because it will default to UTC. You have to specify a custom timezone manually by adding "tz=YourGeography/YourLocation" because the syslinux bootmenu does not offer you a selection of timezones. Syslinux allows you to edit the boot commandline by pressing <TAB>. Press <ENTER> to boot after you made your changes or <ESC> to discard your edit and return to the menu.
@@ -96,8 +97,9 @@ On UEFI computers, Grub2 handles the boot and it will show a menu similar (and s
* Non-US Timezone selection
* Memory test with memtest86+
* Help on boot parameters
+ * Console OS in RAM
-Editing a Grub menu before booting it is possible by pressing the "e" key. After making your changes to the boot commandline, press <F10> to boot. To discard your changes, press <ESC>.
+Editing a Grub menu before booting it is possible by pressing the "e" key. After making your changes to the boot commandline, press <F10> or <Ctrl>-<x> to boot. To discard your changes, press <ESC>.
Another difference between Syslinux and Grub2 menus: in Grub2 you can select a non-US keyboard, language and/or timezone and you will return to the main menu every time. You still have to select "Start SLACKWARE Live" to boot the computer. In the Syslinux menu, only the keyboard selection menu will return you to the main menu. Any non-US *language* selection on the other hand will boot you into Slackware Live immediately; without returning to the main menu. This is a limitation of syslinux which would require exponentially more menu files to construct a menu with more choices. Grub2 supports variables which make it easy to modify a menu entry's characteristics.
@@ -134,7 +136,7 @@ Note that you can create your own SSL certificate plus private key and use those
=== Boot from an ISO file on disk ===
-If you downloaded a liveslak ISO file and want to boot that ISO directly from its location on your computer's hard drive, you can use the following Grub configuration block and add it to your ''/boot/grub/grub.cfg'':<code>
+If you downloaded a liveslak ISO file and want to boot that ISO directly from its location on your computer's hard drive, you can use the following Grub configuration block and add it to your ''/boot/grub/grub.cfg'' (the example code assumes you downloaded the XFCE ISO and stored it as ''/data/ISOS/slackware64-live-xfce-current.iso''):<code>
menuentry " LIVESLAK ISO" --class gnu-linux --class os --class icon-linux {
set iso='/data/ISOS/slackware64-live-xfce-current.iso'
set bootparms='load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0 kbd=us tz=Europe/Amsterdam lang=nl'
@@ -144,7 +146,7 @@ menuentry " LIVESLAK ISO" --class gnu-linux --class os --class icon-linux {
linux (loop)/boot/generic livemedia=scandev:$iso $bootparms
initrd (loop)/boot/initrd.img
}</code>
-This example will add a 'LIVESLAK ISO' menu entry to your local computer's boot menu, through which you can start a XFCE Live ISO which you previously downloaded to directory ''/data/ISOS/'', pre-configured for a US keyboard, Dutch language and Amsterdam timezone.
+This example will add a 'LIVESLAK ISO' menu entry to your local computer's boot menu, through which you can start a XFCE Live ISO which you previously downloaded to directory ''/data/ISOS/'', pre-configured for a US keyboard, Dutch language and Amsterdam timezone. You should of course change the ''bootparms'' string so that it matches your requirements.
Alternatively you could look into Ventoy, which is a tool to create a bootable USB drive containing multiple ISO files. Ventoy allows you to boot from any of these ISOs by automatically generating on every boot a Grub menu containing all the images found on disk. Liveslak is fully Ventoy-compatible. Website: https://www.ventoy.net/ .
@@ -166,23 +168,40 @@ This script, called 'iso2usb.sh', accepts the following parameters: <code>
-f|--force Ignore most warnings (except the back-out).
-h|--help This help.
-i|--infile <filename> Full path to the ISO image file.
+ -l|--lukshome <name> Custom path to the containerfile for your LUKS
+ encrypted /home (slhome by default).
-o|--outdev <filename> The device name of your USB drive.
- -p|--persistence <name> Custom name of the 'persistence' directory/file.
- If it does not exist yet, create it manually.
+ -p|--persistence <name> Custom path to the 'persistence' directory
+ or containerfile (persistence by default).
-r|--refresh Refresh the USB stick with the ISO content.
No formatting, do not touch user content.
-s|--scan Scan for insertion of new USB device instead of
providing a devicename (using option '-o').
-u|--unattended Do not ask any questions.
-v|--verbose Show verbose messages.
- -w|--wait<number> Add <number> seconds wait time to initialize USB.
+ -w|--wait <number> Add <number> seconds wait time to initialize USB.
+ -y|--layout <x,x,x,x> Specify partition layout and sizes (in MB).
+ Default values: '1,100,-1,' for 3 partitions,
+ the '-1' value for partition 3 meaning
+ 'use all remaining space',
+ and an empty 4th value means 'do not reserve
+ free space for a custom 4th partition'.
-C|--cryptpersistfile size|perc
Use a LUKS-encrypted 'persistence' file instead
of a directory (for use on FAT filesystem).
Format for size/percentage is the same
as for the '-c' parameter.
+ -F|--filesystem <fs> Specify filesystem to create when formatting
+ devices/containers. Defaults to 'ext4',
+ Choices are btrfs,ext2,ext4,f2fs,jfs,xfs.
+ Note that the linux partition will always be
+ formatted as 'ext4' because extlinux is used
+ as the BIOS bootloader.
-P|--persistfile Use an unencrypted 'persistence' file instead
of a directory (for use on FAT filesystem).
+ Persistent data will not be migrated
+ when switching from directory to container file.
+
</code>
Examples:
@@ -192,8 +211,10 @@ Examples:
# ./iso2usb.sh -i slackware64-live-current.iso -o /dev/sdX -c 750M -w 15
* Create a USB Live with an encrypted /home (allocating 30% of the stick's free space for /home) and where the persistent data will be stored in a container file instead of a directory:
# ./iso2usb.sh -i slackware64-live-current.iso -o /dev/sdX -c 30% -P
- * Create a USB Live with both the /home and the persistent data encrypted (the persistence filesystem will be 300 MB in size):
- # ./iso2usb.sh -i slackware64-live-current.iso -o /dev/sdX -c 30% -C 300M
+ * Create a USB Live with both the /home and the persistent data encrypted (the persistence filesystem will be 300 MB in size) using a btrfs filesystem:
+ # ./iso2usb.sh -i slackware64-live-current.iso -o /dev/sdX -F btrfs -c 30% -C 300M
+ * Create a 32bit USB Live but use a custom partition layout: create a 1 MB BIOS boot partition and a 200 MB EFI partition, add a 4th un-used $ GB partition at the end, and allocate all remaining disk space to the main Linux partition:
+ # iso2usb.sh -i slackware-live-current.iso -o /dev/sdX -y 1,200,-1,4096
* Refresh the system modules on a USB Live using a Live ISO as the source. Let the script scan for insertion of a USB stick instead of specifying the device name on the commandline. Note that the addons and optional modules will not be touched by this action:
# ./iso2usb.sh -i slackware64-live-current.iso -r -s
@@ -205,7 +226,7 @@ You might have noticed that the "-P" parameter does not accept a size parameter.
An ISO companion script is available which enables you to add functionality in cases where you want to boot directly from an ISO file. For instance, when having added the ISO file as a selection in your Grub menu, or when using a 3rd-party boot manager like Ventoy. Typically, a Live ISO is immutable (its ISO-9660 filesystem is read-only) and when you boot off it, the Live OS does not have persistence. The system starts in a virgin state, every boot.
-The ISO companion script can add encrypted persistence and homedirectory container files to the disk partition which can be VFAT or EXFAT if you want. It also can create a directory structure on-disk from which liveslak can load additional live modules that are not present inside the ISO (both 'addons' and 'optional').
+The ISO companion script can create encrypted containers for persistence and your homedirectory on the disk partition; that partition can be formatted as VFAT or EXFAT if you want. It also can create a directory structure on-disk from which liveslak can load additional live modules that are not present inside the ISO (both 'addons' and 'optional').
The script is called 'isocomp.sh', and it accepts the following parameters: <code>
-d|--directory <path> Create a liveslak directory structure to store
@@ -227,11 +248,15 @@ The script is called 'isocomp.sh', and it accepts the following parameters: <cod
file to be created in the filesystem
(filename extension must be '.icc'!).
-x|--extend <fullpath> Full path to existing (encrypted) container
- file that you want to extend in size
- (filename needs to end in '.icc'!).
+ file that you want to extend in size.
Limitations:
- - container needs to be LUKS encrypted, and
- - internal filesystem needs to be ext{2,3,4}.
+ - container needs to be LUKS encrypted.
+ - filename needs to end in '.icc'.
+ Supported filesystems inside container:
+ - btrfs,ext2,ext4,f2fs,jfs,xfs.
+ -F|--filesystem <fs> Specify filesystem to create when formatting
+ devices/containers. Defaults to 'ext4',
+ Choices are btrfs,ext2,ext4,f2fs,jfs,xfs.
-L|--lcsize <size|perc> Size of LUKS encrypted /home ; value is the
requested size of the container in kB, MB, GB,
or as a percentage of free space
@@ -252,7 +277,7 @@ Some examples of what the script can do, are given when you run the script with
* Create a 1GB encrypted persistence container:
# ./isocomp.sh -p /run/media/<user>/Ventoy/myfiles/persistence.icc -P 1G
- * Create a 4GB encrypted home:
+ * Create a 4GB encrypted home with btrfs filesystem:
# ./isocomp.sh -l /run/media/<user>/Ventoy/somedir/lukscontainers.icc -L 4000M -i /run/media/<user>/Ventoy/slackware64-live-current.iso
* Increase the size of that encrypted home container with another 2GB:
# ./isocomp.sh -x /run/media/<user>/Ventoy/somedir/lukscontainers.icc -X 2G -i /run/media/<user>/Ventoy/slackware64-live-current.iso
@@ -282,6 +307,7 @@ The "setup2hd" script supports regular Slackware network installations. In addit
The 'setup2hd' program has some capabilities that the original Slackware 'setup' lacks:
* It will launch fdisk/gdisk if you forgot to create Linux partitions in advance;
+ * It will optionally install a firewall for which the configuration is based on your answers to a few questions;
* It will allow you to create a regular user account and set its password;
* It will prompt you to set the root password in a graphical dialog.
@@ -296,6 +322,7 @@ Specifically, the script is able to:
* Restore the backed-up kernel and modules if the new kernel is not working.
* Add network support modules for PXE boot (if missing).
* Increase (or decrease) USB wait time during boot.
+ * Extend the size of any of the encrypted containers on the USB Live stick, in case such a container is running out of storage space and there's still room on the USB disk partition for the expansion.
* Replace the Live init script inside the initrd image with a new script that you supply.
* Move current persistence data to a new squashfs module in 'addons' afther which the persistence store will be re-initialized. The new module's name is time-stamped (/liveslak/addons/0099-slackware__customchanges-yymmddHHMMSS.sxz) so that this action can be repeated many times.
@@ -306,6 +333,7 @@ Before making any modifications, the script will show you a prompt at which poin
This script, called 'upslak.sh', accepts the following parameters: <code>
-b|--nobackup Do not try to backup original kernel and modules.
-d|--devices List removable devices on this computer.
+ -e|--examples Show some common usage examples.
-h|--help This help.
-i|--init <filename> Replacement init script.
-k|--kernel <filename> The kernel file (or package).
@@ -318,6 +346,26 @@ This script, called 'upslak.sh', accepts the following parameters: <code>
providing a devicename (using option '-o').
-v|--verbose Show verbose messages.
-w|--wait<number> Add <number> seconds wait time to initialize USB.
+ -x|--extend <fullpath> Full path (either in your filesystem or else
+ relative to the USB partition root)
+ to an existing (encrypted) container file,
+ whose size you want to extend.
+ Limitations:
+ - container needs to be LUKS encrypted.
+ - filename extension needs to be '.img'.
+ Supported filesystems inside container:
+ - btrfs,ext2,ext4,f2fs,jfs,xfs.
+ -N|--nolivemods Don't create an addon live module containing
+ the new kernelmodules. Normally you *will* need
+ this addon module, *unless* you have already
+ installed these kernel-modules in the Live OS.
+ FYI: the kernel and module upgrade applies only
+ to the USB boot kernel and its initrd.
+ -X|--extendsize <size|perc> Extend size of existing container; value
+ is the requested extension of the container
+ in kB, MB, GB, or as percentage of free space
+ (integer numbers only).
+ Examples: '-X 125M', '-X 2G', '-X 20%'.
</code>
Examples:
@@ -328,7 +376,10 @@ Examples:
* Restore the previous kernel and modules after a failed update, and let the script scan your computer for the insertion of your USB stick:
# ./upslak.sh -s -r
* Replace the Live init script with the latest template taken from the git repository:
- # ./upslak.sh -o /dev/sdX -i liveslak/liveinit.tpl
+ # wget https://git.liveslak.org/liveslak/plain/liveinit.tpl
+ # ./upslak.sh -o /dev/sdX -i liveinit.tpl
+ * Extend the size of the pre-existing LUKS container for your homedirectory with 3 GB, and let the script scan for the insertion of your USB stick:
+ # ./upslak.sh -s -x /slhome.img -X 3G
==== PXE booting the Live OS ====
@@ -373,7 +424,7 @@ How to start the PXE server?
When you boot the Live OS you can then start a script "pxeserver" from the console in runlevel 3 or from an X terminal in runlevel 4. The script will gather all required information and if it is unable to figure something out by itself it will ask you. If it is unable to figure out the wired network interface that it should use, you can add the name of your interface (for instance, eth1) as a single parameter to the script when you start it.
-The PXE server uses dnsmasq to offer DNS to the PXE clients. The dnsmasq program will enable its internal DHCP server capabilities if your LAN does not have its own DHCP server. Dnsmasq will also start a TFTP server which the PXE clients will connect to in order to retrieve the boot files (kernel and initrd). The ''pxeserver'' script also starts a NFS server which will be used by the Live initrd to obtain the squashfs modules and boot the Live OS. If your PXE server has multiple network interfaces, for instance a wireless interface which is connected to the outside world and a wired interface connected to another computer which will become a PXE client (or indeed connected to a switch with a whole bunch of prospective PXE clients behind that) then the PXE server will setup packet forwarding so that the PXE clients will be able to access the outside world through the wired interface and out to that other interface.
+The PXE server uses dnsmasq to offer DNS to the PXE clients. The dnsmasq program will enable its internal DHCP server capabilities if your LAN does not have its own DHCP server. Dnsmasq will also start a TFTP server which the PXE clients will connect to in order to retrieve the boot files (kernel and initrd). The ''pxeserver'' script also starts a NFS server which will be used by the Live initrd to obtain the squashfs modules and boot the Live OS. If your PXE server has multiple network interfaces, for instance a wireless interface which is connected to the outside world and a wired interface connected to another computer which will become a PXE client (or indeed connected to a switch with a whole bunch of prospective PXE clients behind that) then the PXE server will setup packet forwarding so that the PXE clients will be able to access the outside world through the wired interface and out to that other interface. If the PXE clients are unable to access the Internet using this default IP packet forwarding configuration, you may want to answer with 'YES' to the question during pxeserver's configuration when it asks you if you want to hide the PXE clients behind a NAT router.
If you have multiple network interfaces, it is important to know that dnsmasq will only bind to the interface where you want PXE clients to connect to. In a multi-NIC situation where a second NIC is connected to the outside world (your local network), this means that the DHCP/DNS server started by dnsmasq will not interfere with an existing DHCP server in your local network.
@@ -583,7 +634,7 @@ The USB variant with persistence may have an additional directory in the root:
The first script:
The script "make_slackware_live.sh" creates an ISO file as its output which contains the Live OS.
-Thanks to Linux kernel 4.x and the squashfs-tools package in Slackware, the process of creating a Slackware Live ISO requires **no** (re)compilation of Slackware content or installing 3rd party packages.
+Thanks to Linux kernel >= 4.x and the squashfs-tools package in Slackware, the process of creating a Slackware Live ISO requires **no** (re)compilation of Slackware content or installing 3rd party packages.
The script's inner workings can be subdivided into several distinct stages. For the full Slackware ISO the process stages are as follows:
@@ -613,7 +664,7 @@ Stage two:
* 'root' and 'live' user accounts are created,
* an initial environment for the accounts is configured,
* the desktop environment is pre-configured for first use,
- * the liveslak scripts "makemod", "iso2usb.sh", "isocomp.sh" and "upslak.sh" are copied to "/usr/local/sbin/" in the ISO for your convenience,
+ * the liveslak scripts "makemod", "iso2usb.sh", "isocomp.sh", "upslak.sh" and "pxeserver" are copied to "/usr/local/sbin/" in the ISO for your convenience,
* The "setup2hd" script and the Slackware installer files are copied to "/usr/local/sbin" and "/usr/share/liveslak" respectively.
* slackpkg is configured,
* a locate database is created,
@@ -635,7 +686,7 @@ Stage three:
Stage four:
- * a bootable ISO file is created using mkisofs.
+ * a bootable ISO file is created using mkisofs or xorriso.
* the "isohybrid" command is run on the ISO so that you can "dd" or "cp" the ISO to a USB stick and thus create a bootable USB media.
Done! You can find the ISO file and its MD5 checksum in the /tmp directory.
@@ -656,9 +707,10 @@ The "iso2usb.sh" script wipes and re-partitions the USB stick unless the "-r" or
* First partition: a small (1 MB in size) FAT partition which is not used for Slackware Live Edition. It can be used by an alternative bootloader if needed. You can also store your LUKS keyfile on it to unlock a LUKS-encrypted Slackware Linux computer (see the README_CRYPT.TXT file on your Slackware DVD for more information on LUKS keyfiles).
* Second partition: a 100 MB VFAT partition containing the kernel, initrd and all the other stuff required by syslinux and grub2 to boot Slackware Live Edition.
- * Third partition: a Linux partition taking up all of the remaining space. It contains the actual liveslak modules, the persistent live storage and optionally your encrypted homedirectory. You can use the remainder of this Linux ext4 filesystem's free space to store anything you like.
+ * Third partition: a Linux partition which by default takes up all of the remaining space. It contains the actual liveslak modules, the persistent live storage and optionally your encrypted homedirectory. You can use the remainder of this Linux ext4 filesystem's free space to store anything you like.
+ * Fourth partition is optional: using the ''-y|--layout'' commandline parameter you can create a un-used partition at the end of the USB disk which is all yours to format and use. This layout parameter allows you to specify partition sizes.
-Note that this script is the only supported method of transfering the liveslak ISO content to a USB stick and make that USB stick into a persistent live OS. Several 3rd party tools (like multibootusb, rufus, unetbootin) that claim to be able to mix several Live OS'es on a single USB stick and make them all work in a multi-boot setup, are not currently supporting liveslak.
+Note that this script extracts the ISO contents to transform a USB stick into into a persistent live OS. This is a destructive process, erasing all previously available content on that stick. Several 3rd party tools (like multibootusb, rufus, unetbootin) that claim to be able to mix several Live OS'es on a single USB stick and make them all work in a multi-boot setup, are not currently supporting liveslak. Ventoy on the other hand, is fully supported by liveslak and therefore your best bet if you don't want to wipe your data off your USB stick. As a bonus, the ''isocomp.sh'' script is able to add persistence to a liveslak ISO on a Ventoy boot disk.
== Mounting a filesystem in an encrypted container ==
@@ -713,7 +765,7 @@ If the container is used for an encrypted /home, the script will copy the existi
== Extending the size of an existing container file ==
-The 'isocomp.sh' script is able to extend your encrypted containers if you are running out of space on their enclosed filesystems. It does this by appending random bytes to the end of the file, unlocking and mounting the filesystem inside, and then resizing that filesystem so it grows to the new size of the container. Note that only containers with an internal ''ext4'' filesystem are supported.
+The 'isocomp.sh' script is able to extend your encrypted containers if you are running out of space on their enclosed filesystems. It does this by appending random bytes to the end of the file, unlocking and mounting the filesystem inside, and then resizing that filesystem so it grows to the new size of the container.
=== makemod ===
@@ -728,7 +780,7 @@ Usage:
* The first parameter is either the full path to a Slackware package, or else a directory.
* If a packagename is supplied as first parameter, it will be installed into a temporary directory using Slackware's "installpkg". The content of the temporary directory will be squashed into a module by the "squashfs" program.
- * If a directoryname is supplied, its content will be squashed into a module by the "squashfs" program..
+ * If a directoryname is supplied, its content will be squashed into a module by the "squashfs" program.
* The second parameter is the full pathname of the output module which will be created.
You can copy the module you just created (minding the filename conventions for a Slackware Live module, see paragraph "Slackware Live module format") to either the optional/ or to the addon/ directory of your Live OS. If you copy it to the optional/ or addon/ directory of the liveslak sources then "make_slackware_live.sh" will use the module when creating the ISO image.
@@ -760,6 +812,7 @@ The ''pxeserver'' script works as follows:
* dnsmasq providing DNS, DHCP and BOOTP;
* NFS and RPC daemons;
* The script will detect if you have an outside network connection on another interface and will enable IP forwarding if needed, so that the PXE clients will also have network access.
+ * The script can optionally setup NAT routing - masquerading the PXE clients from the outside world - if regular IP packet forwarding is not making the outside network accessible to PXE clients.
* The Live OS booted via pxelinux is configured with additional boot parameters: <code>
nfsroot=<server_ip_address>:/mnt/livemedia
luksvol=
@@ -792,9 +845,13 @@ Depending on the parameters passed to the script, it will then perform one or mo
You can provide a new kernel and its modules in two ways. The '-k' option accepts a kernel image file or else a Slackware package contaning a kernel. The '-m' option accepts a directory tree of modules below "/lib/modules/, or else a Slackware package containing kernel modules.
If there is sufficient space on the Linux and EFI partitions, the script will make a backup of the current kernel and modules by renaming the kernel and the module directory with a ".prev" suffix. Sufficient space means that at least 10 MB of free space must remain on the partition(s) after making the backup and installing the new kernel plus modules. If space is an issue, you can skip making a backup by providing the '-b' parameter to the script (a possibly unsafe choice).
+Note that these new kernel-modules will be added to the initrd image (they are needed when booting the new kernel). In order for the Live OS to keep working with the new kernel however, these new kernel-modules must also be made available to the Live OS. The script achieves this by creating a '''kernelmodules''' squashfs module and copying the module into the '''addons''' directory of the liveslak installation on your USB stick. When the Live OS boots, the kernelmodules will then automatically be merged into the live filesystem.
+It is possible to skip the creation of this squashfs module via the '-N' switch to the script.
+
== Restore backed-up kernel and modules ==
If a backup was made of kernel and modules, the upslak.sh script is able to restore these using the '-r' option, thereby removing the replacements. This comes in handy when the replacement kernel turns out to be non-functional.
+Note that restoring the old kernel and its modules will leave an orphaned squashfs kernelmodule in liveslak's '''addons''' directory. You can safely delete that file.
== Add network support modules ==
@@ -808,6 +865,10 @@ Similar to the functionality of the "iso2usb.sh" script, the "upslak.sh" script
The init script inside the initrd image is the core of liveslak. The init script prepares the Live filesystem and configures several run-time OS parameters. If you have made modifications to this init script you can easily replace the default init script with your own script using the '-i' option. The "upslak.sh" script is smart enough to recognize a iveslak template as input. The ".tpl" extension of some liveslak files means that these are templates. They are not usable as-is, because they contain placeholder strings like "@VERSION@" or "@DISTRO@" that first need to be replaced with real values. The "upslak.sh" script will take care of these substitutions.
+== Extend the size of an existing LUKS container ==
+
+Your Slackware Live USB stick will probably have two LUKS containers: one for your ''/home'' directory and the other to store persistent data. If space is running out inside such a container, you can use the '-x' and '-X' parameters to the script to indicate the relevant container and provide a size increase for it. Your data inside the container is safe; the filesystem inside it will be extended and this does not touch existing file data.
+
== Wrap persistence data into a new squashfs module ==
Persistence data will accumulate over time on the USB stick. That is perfectly OK, and you can wipe it on boot if that is needed. But sometimes you want to capture the packages you installed into the persistent storage, and create a new squashfs module out of them. The "upslak.sh" script is able to move your persistence data into a new squashfs module using the '-p' option. The new module will be created in the "/liveslak/addons/" directory so that it will be loaded into the Live OS everytime your USB Live boots up. After creating the new module, the persistence store will be re-initialized (i.e. its content will be erased on the next boot). The new module's name is time-stamped (/liveslak/addons/0099-slackware__customchanges-yyyymmddHHMMSS.sxz where yyyymmddHHMMSS is the timestamp) so that this action can be repeated as many times as you want.
@@ -879,7 +940,8 @@ The script's parameters are:
DAW (Digital Audio Workstation), XFCE (basic XFCE,
stripped), KTOWN (ktown Plasma5 replacement), MATE
(Gnome2 fork replaces KDE), CINNAMON (fork of Gnome3 Shell
- replaces KDE), DLACK (Gnome3 replaces KDE).
+ replaces KDE), DLACK (Gnome3 replaces KDE),
+ STUDIOWARE (Multimedia Studio).
-e Use ISO boot-load-size of 32 for computers
where the ISO won't boot otherwise (default: 4).
-f Forced re-generation of all squashfs modules,
@@ -894,7 +956,7 @@ The script's parameters are:
-v Show debug/error output.
-z version Define your Slackware version (default: current).
-C Add RAM-based Console OS to boot menu.
- -G Generate ISO file from existing directory tree
+ -G Generate ISO file from existing directory tree.
-H hostname Hostname of the Live OS (default: darkstar).
-M Add multilib (x86_64 only).
-O outfile Custom filename for the ISO.
@@ -984,6 +1046,23 @@ This is the section in ''make_slackware_live.conf'' which deals with these custo
#}
</code>
+=== Customizing the list of used packages ===
+
+Any liveslak ISO variant contains a specific set of Slackware packages, as defined in the various ''SEQ_*'' variables used in the ''make_slackware_live.sh'' script. Your customized Live OS will be using variable "''SEQ_CUSTOM''".
+
+Let's breakdown the definition of such a variable to explain how to customize the package set for your own live ISO.
+
+The list of packages in the MATE ISO for instance, is defined by the ''SEQ_MSB'' variable (//MSB// stands for //Mate Slack Build//). Its value is as follows: <code>
+# grep ^SEQ_MSB make_slackware_live.sh
+SEQ_MSB="tagfile:a,ap,d,e,f,k,l,n,t,tcl,x,xap,xfce,y pkglist:slackextra,mate local:slackpkg+"</code>
+
+Three keywords can be identified in the value of a ''SEQ_*'' variable, and these determine where the packages to be installed are going to be searched for:
+ * tagfile - this is an Slackware tagfile for a complete package series. For instance, using "tagfile:ap" means: install all packages in the **AP** series.
+ * pkglist - this is a list of packages to be installed from the Slackware distro itself or from a Slackware-compatible 3rd-party repository. The file containing that package list is searched in the ''./pkglists/'' subdirectory of the liveslak toplevel directory. For instance, using "pkglist:mate" means: install all packages mentioned in the file ''./pkglists/mate.lst''. If there is no matching ''./pkglists/mate.conf'' file then the packages are assumed to be present in the Slackware distro directory. Else the ".conf" file is parsed and the variables that are defined in the ".conf" file will be used while generating the ISO. Most importantly, "''SL_REPO_URL''" will contain the rsync URI pointing to the 3rd-party repository where the requested packages can be downloaded.
+ * local - some packages can not be found in Slackware-compatible repositories. The "local" keyword alows you to install packages from a subdirectory of the liveslak toplevel directory. For instance, using "local:slackpkg+" means: install all packages found in subdirectory ''./local/slackpkg+/'' or if you are generating a 64bit live ISO, install all packages found in directory ''./local64/slackpkg+/''.
+
+For the value of a ''SEQ_*'' variable, any combination of these keywords can be used. Every keyword is followed by a colon, and that is followed by a comma-separated list of relevant package definitions. They are all separated by spaces.
+
=== Custom background images ===
The Plasma5 based Live variants allow customization of the background image used for the login greeter, the desktop wallpaper and the lock screen. The image you want to use for this purpose, must have a 16:9 aspect ratio and its dimensions should at least be 1920x1080 pixels. You must store the custom image inside the liveslak source tree: in the subdirectory ''./media/<variant>/bg/'' where "<variant>" is the lower-case name of the Live variant (variant 'KTOWN' equals directory 'ktown', 'DAW' becomes 'daw', etc).
@@ -1072,6 +1151,7 @@ Slackware Live Edition expects its modules to adhere to a particularly loose fil
* Anything may be part of the '*' but most commonly used is "${VERSION}-${ARCH}". The core modules in Slackware Live use the Slackware release as ${VERSION} and the Slackware architecture as ${ARCH}. For the modules in addons/ and optional/ subdirectories, ${VERSION} would commonly be the version of the program that is being made available in the module.
* The four digits of a modulename have a meaning. Some ranges are claimed by the core OS, so please do not use them. Their prefixes are based on the package source: <code>
0000 = contains the Slackware /boot directory
+ 0005 = Console OS modules when explicitly enabled for a regular ISO installed otherwise from Slackware tagfiles
0010-0019 = packages installed from a Slackware tagfile (a,ap,d, ... , y series)
0020-0029 = packages installed from a package list as found in the ./pkglists subdirectory of the liveslak sources (min, noxbase, x_base, xapbase, xfcebase etc)
0030-0039 = a 'local' package, i.e. a package found in subdirectory ./local or ./local64 (depending on architecture)