diff options
Diffstat (limited to 'README.txt')
| -rw-r--r-- | README.txt | 362 |
1 files changed, 319 insertions, 43 deletions
@@ -5,7 +5,7 @@ ===== Preface ===== -Welcome to the Slackware Live Edition! This is a version of Slackware 14.2 (and newer), that can be run from a DVD or a USB stick. It is an ISO image meant to be a showcase of what Slackware is about. You get the default install, no custom packages or kernel, but with all the power of Slackware. The ISO is created from scratch using a Slackware package mirror, by the "liveslak" scripts. +Welcome to the Slackware Live Edition! All Slackware releases since 14.2, including the development version ''-current'', are supported versions for the ''liveslak'' project. The Live OS which liveslak creates from the Slackware Distro can be run from a DVD or a USB stick. It is an ISO image meant to be a showcase of what Slackware is about. You get the default install, no custom packages or kernel, but with all the power of Slackware. The ISO is created from scratch using a Slackware package mirror, by the "liveslak" scripts. Slackware Live Edition does not have to be installed to a computer hard drive (however you do have that choice if you want to: using the setup2hd script). You can carry the USB stick version with you in your pocket. You'll have a pre-configured Slackware OS up & running in a minute wherever you can get your hands on a computer with a USB port. @@ -13,6 +13,8 @@ The USB version is "persistent" - meaning that the OS stores your updates on the In order to protect your sensitive private data in case you lose your USB stick (or in case it gets stolen) you can enhance your persistent USB Live OS with an encrypted homedirectory and/or an encrypted persistence file, to be unlocked on boot with a passphrase that only you know. +And even booting directly from the ISO file (see chapter ''Boot from an ISO file on disk'') you can use persistence and enjoy an encrypted homedirectory, without the need for any modification to the ISO file. + ===== Why yet another Slackware Live ===== @@ -31,14 +33,14 @@ 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.0 GB ISO); - - a slimmed-down XFCE ISO (700 MB) with XDM as the graphical login manager. It fits on a CDROM medium or a 1 GB USB stick; - - a ISO image (4.3 GB) of Slackware64-current containing 'ktown' Plasma 5 instead of Slackware's KDE. - - 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. - - a Mate variant (3.2 GB) where KDE 4 has been replaced by Mate (a Gnome 2 fork); - - a Cinnamon flavour (a fork of the Gnome 3 Shell replacing Slackware's KDE 4). - - a Dlackware variant, which is Gnome3 + PAM + systemd on top of Slackware and stripped of KDE4. - - a StudioWare edition containing all the project's audio, video and photo editing software packages. + - 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 (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. @@ -46,11 +48,10 @@ The "liveslak" scripts can generate a variety of Slackware flavors: Common download locations are: - * Primary site: http://download.liveslak.org/ (%%rsync://liveslak.org/liveslak/%%) - * Darren's http://slackware.uk/people/alien-slacklive/ (%%rsync://slackware.uk/people/alien-slacklive/%%) + * Primary site: https://download.liveslak.org/ (%%rsync://liveslak.org/liveslak/%%) + * My US mirror: https://us.liveslak.org/ (%%rsync://us.liveslak.org/liveslak/%%) + * Darren's https://slackware.uk/liveslak/ (%%rsync://slackware.uk/liveslak/%%) * Willy's http://repo.ukdw.ac.id/slackware-live/ - * Ryan's https://seattleslack.ryanpcmcquen.org/mirrors/slackware-live/ - * Shasta's http://ftp.slackware.pl/pub/slackware-live/ (%%rsync://ftp.slackware.pl/slackware-live/%%) ===== Enduser Documentation ===== @@ -61,7 +62,7 @@ Common download locations are: The ISO images are hybrid, which means you can either burn them to DVD, or use 'dd' or 'cp' to copy the ISO to a USB stick. Both methods will give you a live environment which will allow you to make changes and seemingly "write them to disk". The changes will actually be kept in a RAM disk, so a reboot will "reset" the live OS to its original default state. In other words, there is no persistence of data. -Slackware Live Edition knows two user accounts: "root" and "live". They have passwords, and by default these are... you guessed: "root" and "live". Also by default, the ISOs will boot into runlevel 4, i.e. you will get a graphical login. The bootloader allows you to pick a non-US language and/or keyboard layout and (on boot of an UEFI system) a custom timezone. +Slackware Live Edition knows two user accounts: "root" and "live". They have passwords, and by default these are... you guessed: "root" and "live". Also by default, the ISOs will boot into runlevel 4, i.e. you will get a graphical login. The bootloader allows you to pick a non-US language and/or keyboard layout and (on boot of an UEFI system) a custom timezone. Slackware Live Edition deviates as little as possible from a regular Slackware boot. Once you have passed the initial Liveboot stage and brought up the actual OS, you login as user "live". From that moment onwards, you are in a regular Slackware environment. @@ -72,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 | KTOWN | XFCE | MATE | DAW) Live (depending on which of the ISOs you boot) + * 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. @@ -89,18 +91,66 @@ If you stick to US English interface language you will probably still want to ch On UEFI computers, Grub2 handles the boot and it will show a menu similar (and similarly themed) to the Syslinux menu: - * Start (SLACKWARE | KTOWN | XFCE | MATE | DAW) Live (depending on which of the ISOs you boot) + * Start (SLACKWARE | XFCE | MATE | CINNAMON | DAW | LEAN) Live (depending on which of the ISOs you boot) * Non-US Keyboard selection * Non-US Language selection * 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. +=== UEFI Secure Boot === + + +On computers with Secure Boot enabled, extra measures may be required to boot an Operating System. Slackware for instance, is unable to boot on a computer that has Secure Boot enabled. Historic liveslak based ISOs are also not able to boot there. From liveslak-1.5.0 and onwards, Secure Boot is supported for the 64-bit ISO images. + +Secure Boot enforces that the first-stage bootloader is signed with an encryption key known to Microsoft. For Linux based Operating Systems, the most widely used solution is to place an small single-purpose bootloader before the regular Linux bootloader. This EFI bootloader is called 'shim'. Shim must be cryptographically signed by Microsoft for it to successfully boot a computer. This is not a trivial process, Microsoft is very strict about the signing process because in essence your signed bootloader will boot anything on a Secure Boot enabled computer, including malware if that was signed by your 'distro key'. That would create a huge security hole and defy the purpose of Secure Boot. + +Signing your Grub bootloader and your kernel also becomes mandatory, because the 'shim' refuses to load un-signed binaries. This complicates the process of upgrading to a new kernel further. + +The Slackware Live OS boots on a Secure Boot enabled computer if created with liveslak-1.5.0 or newer, and only for the 64-bit liveslak ISO images. The Slackware Linux distro does not ship a 'shim' which is signed by Microsoft, so how to get around the dilemma of requiring a signed 'shim'? + +To realize this, the Slackware Live ISO 'borrows' a 3rd-party 'shim'. The binaryis actually called ''bootx64.efi'' in the ''/EFI/BOOT/'' directory and has been extracted from another distro's officially signed 'shim' package; Fedora by default but the Debian and openSUSE shim are also supported by the ''make_slackware_live.sh'' script. This 3rd-party 'shim' binary has been signed by 'Microsoft UEFI CA' which will allow it to boot on any computer. We just need to tell it that is OK to load Slackware's Grub and kernel into memory. + +A distro 'shim' like Fedora's contains an embedded distro SSL certificate and 'shim' will trust the signature of any binary (grub, kernel, etc) which has been signed using that certificate. Of course, 3rd-party 'shim' binaries do not embed a Slackware SSL certificate. Therefore, another means must be used to establish trust. Secure Boot recognizes additional SSL certificates in the computer's MOK (Machine Owner Key) database as valid. The 'shim' trusts custom SSL vertificates of signed binaries, if they are present in the MOK database. It is up to the user (the Machine Owner) to enroll a custom SSL certificate into that database. + +The Grub and kernel images of Slackware Live Edition are signed with an 'Alien BOB' SSL certificate and private key. This SSL certificate needs to be added to the MOK database of your Secure Boot enabled computer. All liveslak ISOs use this specific certificate plus its associated private key. The private key will of course never be distributed but a 'DER-encoded' version of the public certificate is distributed as part of the ISO. You can find it as ''/EFI/BOOT/liveslak.der'' inside the ISO. On a persistent USB stick which you created from the ISO, this will be on the second partition (the ESP). + +== Add the ''liveslak.der'' certificate to the MOK database == + +There are two ways to add or enroll this certificate. + * When you boot a Secure Boot enabled liveslak ISO for the first time, the 'shim' will fail to validate the certificate of liveslak's Grub. It will then start the 'MokManager' showing you a nice blue screen with a dialog requesting you to enroll a public key (aka the SSL certificate) from disk. You can use the file selector to browse to the 'efi' partition and there to the ''./EFI/BOOT/'' directory. Select the ''liveslak.der'' and confirm that this is the correct certificate. The computer will then reboot and after reboot, you will automatically end up in the Grub boot menu without any further intervention. + * If you already have a Linux OS up and running on that computer, you can use the program ''mokutil'' to enroll the key before you boot a liveslak ISO:<code> +# mokutil --import liveslak.der</code>. This command will schedule a request to shim, and the first time you boot a liveslak ISO the MokManager will ask confirmation to enroll the scheduled key. In other words, you won't have to 'enroll from disk'. + +Note that MOK key enrollment is a one-time action for the official liveslak based ISOs. All future liveslak ISOs will also be signed using this ''liveslak.der'' certificate and as long as it stays in your computer's MOK database, the 'shim' will load Grub and the kernel without complaint. + +Note that you can create your own SSL certificate plus private key and use those to generate custom liveslak ISO images with Secure Boot support. All you need to do is to enroll the public key (the DER-encoded version of your SSL certificate) into the MOK database of your computer. The MOK database has room for multiple keys so yours as well as liveslak's keys (and more) will fit there. + + +=== 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'' (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' + + search -f $iso --set=root + loopback loop $iso + 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. 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/ . + + ==== Transfering ISO content to USB stick ==== @@ -118,22 +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. + -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: @@ -143,14 +211,94 @@ 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 You might have noticed that the "-P" parameter does not accept a size parameter. This is because the unencrypted container file is created as a 'sparse' file that starts at zero size and is allowed to grow dynmically to a maximum of 90% of the initial free space on the Linux partition of the USB stick. +==== Adding functionality when booting directly off an ISO on disk ==== + + +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 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 + additional modules. The parameter value is + used as the root path below which the + liveslak/{addons,optional} subdirectories + will be created. + -e|--examples Show some common usage examples. + -f|--force Force execution in some cases where the script + reports an issue. + -h|--help This help text. + -i|--iso <fullpath> Full path to your liveslak ISO image. + -l|--lukscontainer <fullpath> Full path to encrypted container file to be + created by this script, and to be mounted + in the live OS under /home + (or any other mountpoint you supply). + (filename needs to end in '.icc'!). + -p|--persistence <fullpath > Full path to encrypted persistence container + 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. + Limitations: + - 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 + (integer numbers only). + Examples: '-L 125M', '-L 2G', '-L 20%'. + -P|--perssize <size|perc> Size of persistence container ; value is the + requested size of the container in kB, MB, GB, + or as a percentage of free space + (integer numbers only). + Examples: '-P 125M', '-P 2G', '-P 20%'. + -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> +Some examples of what the script can do, are given when you run the script with the '-e' or '--examples' parameter. Here is an overview of those example commands. First, mount your USB partition, for instance a Ventoy disk will be mounted for you at /run/media/<user>/Ventoy/. Then: + + * Create a 1GB encrypted persistence container: + # ./isocomp.sh -p /run/media/<user>/Ventoy/myfiles/persistence.icc -P 1G + * 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 + * Create a 10GB encrypted container to be mounted on /data in the Live OS: + # ./isocomp.sh -l /run/media/<user>/Ventoy/somedir/mydata.icc:/data -L 10G -i /run/media/<user>/Ventoy/slackware64-live-current.iso + * Create a liveslak directory structure for adding extra live modules: + # ./isocomp.sh -d /run/media/<user>/Ventoy/myliveslak -i /run/media/<user>/Ventoy/slackware64-live-current.iso + +These enhancements are recorded in a configuration file next to the ISO, with the exact same name as that ISO but with extension '.cfg' instead of '.iso'. You can manually edit this configuration file if you want; the script will not change, remove or overwrite your customizations. + +Here is an example configuration file content: <code> +# Liveslak ISO configuration file for SLACKWARE-CURRENT FOR X86_64 (LEAN LIVE 1.5.4) +# Generated by isocomp.sh on 20220814_1554 +LIVESLAKROOT=/liveslak +LUKSVOL=/liveslak/myhome.icc:/home +ISOPERSISTENCE=/liveslak/persistence.icc +TZ=Europe/Amsterdam +</code> +Note that this configuration file example is not complete; you can manually add custom values for the following additional liveslak parameters which avoids having to enter the corresponding boot parameters manually every time: BLACKLIST, KEYMAP, LIVE_HOSTNAME, LIVESLAKROOT, LOAD, LOCALE, LUKSVOL, NOLOAD, ISOPERSISTENCE, RUNLEVEL, TWEAKS, TZ and XKB. + + ==== Using the Live OS to install Slackware to hard disk ==== @@ -159,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. @@ -173,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. @@ -183,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). @@ -195,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: @@ -205,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 ==== @@ -250,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. @@ -391,6 +565,12 @@ nop=wipe => Wipe all data from persistence directory or container. persistence=name => Use this if you are using a different directory/file than "persistence" for storing persistent data. +persistence=/dev/sdX:/path/to/mypersistence +persistence=scandev:/path/to/mypersistence => Use this if + the persistence directory or container is not located on the USB stick, + but on a local hard disk partition. Useful for network (PXE) boot + where you still want to offer users persistence. + toram => copy the OS from the media to to RAM before running it. You can remove the boot media after booting. @@ -411,9 +591,12 @@ blacklist=mod1[,mod2[...]] => Add one or more kernel modules debug => During init, pause at strategic locations while assembling the overlay filesystem and show mount information. + Equivalent to 'debug=1'. -debug=<number> => '2' enables verbose script execution; - '4' dumps you into a debug shell right before the switch_root. +debug=<number> => '2' and higher enable verbose script execution; + '3' adds pauses like '1' or '2' but won't show blkid/mount info; + '4' dumps you into a debug shell right before the switch_root; + '5' saves verbose init execution output to 'debug_init.log' rescue => After initialization, you will be dropped in a rescue shell to perform lowlevel maintenance. @@ -451,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: @@ -481,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" 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, @@ -503,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. @@ -524,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 == @@ -547,11 +731,48 @@ A second type of encrypted container exists, which can be used for storing your For slow USB media, the default 5 seconds wait time during boot are sometimes insufficient to allow the kernel to detect the partitions on your USB device. The script can optionally add more wait time. It does this by editing the file "wait-for-root" in the initrd and updating the value which is stored there (by default "5" is written there by the "make_slackware_live.sh" script). -=== makemod === +=== isocomp.sh === The third script: +The "isocomp.sh" script's runtime usage is explained in detail in a previous paragraph "Adding functionality when booting directly off an ISO on disk". + +This section explains the inner workings of the script to enhance the functionality of booting directly from ISO. + +== Secondary liveslak root directory == + +A secondary liveslak root directory can be created by the 'isocomp.sh' script: in the same filsystem where the ISO file is also present. The ISO contains the primary liveslak root, below which you will find directories 'system', 'addons', 'optional', 'core2ram' and so on. The secondary liveslak root can not contain a 'system' subdirectory but it can contain 'addons', 'optional', 'core2ram'. + +Additional Live modules can be placed in these directories. These will be loaded by the Live init after processing corresponding module locations below the primary liveslak root. Meaning, you can load all kinds of additional software without having to modify the official Live ISO. + +== Using container files for persistence or homedirectory == + +Two types of encrypted container are supported by 'isocomp.sh', just like with the 'iso2usb.sh' script: to be used either for storing the Live OS persistence data, or for providing (additional) persistent storage space at a mount point such as ''/home''. Also, the functionality of the Live init has been extended to deal with all this. + +The sequence is as follows: + - Live init checks if the OS was booted from an ISO file. + - If yes, init will additionally check for the existence of an ISO configuration file with the same name as the ISO except its extension (which needs to be '.cfg' instead of '.iso'). + - If the configuration file defines the ISOPERSISTENCE variable, Live init expects its value to be a container file which will be used to store the modifications to the Live OS persistently, instead of writing those to a RAM disk. + - If the configuration file defines the LUKSVOL variable, Live init parses it and mounts all container files defined in there at the mountpoints specified (or ''/home'' if not specified). + - If init determines that it deals with a LUKS-encrypted container, init asks you for its unlock passphrase. + +== Creating an encrypted container == + +The script will create a file of requested size in the same disk partition that also contains the Live ISO, using the 'dd' command. A new loopback device is requested from the OS and the freshly created container file is mapped to the loop device using 'losetup'. The 'cryptsetup luksCreate' command initializes the encryption on this loop device, which causes the script to prompt you with "are you sure, type uppercase YES". After receiving your confirmation, cryptsetup requests you to enter an encryption passphrase three times (two for intializing, and one for unlocking the container subsequently). + +If the container is used for an encrypted /home, the script will copy the existing content of the ISO's /home into the container's filesystem which will later be mounted on top of the ISO's /home (thereby masking the existing /home). + +== 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. + + +=== makemod === + + +The fourth script: + The "makemod" script allows you to create a Slackware Live module easily, with a Slackware package or a directory tree as its input parameter. Usage: @@ -559,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. @@ -568,7 +789,7 @@ You can copy the module you just created (minding the filename conventions for a === setup2hd === -The fourth script: +The fifth script: The "setup2hd" script is a modified Slackware installer, so you will be comfortable with the process. The 'SOURCE' section offers two types of choices: a regular Slackware network installation using a NFS, HTTP, FTP or Samba server, as well as a choice of installing the Live OS which you are running. The script knows where to find the squashfs modules, so the "Install Live OS" selection will not prompt further inputs. * The Slackware network installation is identical to that of the official Slackware installation medium. @@ -578,7 +799,7 @@ The "setup2hd" script is a modified Slackware installer, so you will be comforta === pxeserver === -The fifth script: +The sixth script: The ''pxeserver'' script works as follows: * It requires a wired network; wireless PXE boot is impossible. @@ -591,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= @@ -606,7 +828,7 @@ kbd=<server_kbd_layout> === upslak.sh === -The sixth script: +The seventh script: The "upslak.sh" script's runtime usage is explained in detail in a previous paragraph "Updating the kernel (and more) on a USB stick". @@ -618,14 +840,18 @@ When the script is started, it will do some sanity checks and then extracts the * the current USB wait time is checked. Depending on the parameters passed to the script, it will then perform one or more of the following actions: -== Update the kernel and moules == +== Update the kernel and modules == 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 == @@ -639,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. @@ -651,7 +881,7 @@ Creating an ISO image of Slackware Live Edition requires that you are running Sl You also need the "liveslak" script collection which can be downloaded from any of the links at the bottom of this page. -Liveslak is a directory tree containing scripts, bitmaps and configuration files. Only 6 scripts are meant to be run by you, the user. These scripts ("make_slackware_live.sh", "iso2usb.sh", "makemod", "setup2hd", "pxeserver" and "upslak.sh) are explained in more detail in the section "Scripts and tools" higher up. When creating a Live ISO from scratch, you only need to run the "make_slackware_live.sh" script. +Liveslak is a directory tree containing scripts, bitmaps and configuration files. Only 7 scripts are meant to be run by you, the user. These scripts ("make_slackware_live.sh", "iso2usb.sh", "isocomp.sh", "makemod", "setup2hd", "pxeserver" and "upslak.sh) are explained in more detail in the section "Scripts and tools" higher up. When creating a Live ISO from scratch, you only need to run the "make_slackware_live.sh" script. === Liveslak sources layout === @@ -677,6 +907,7 @@ The toplevel 'liveslak' directory contains the following files: * blueSW-128px.png , blueSW-64px.png - these are bitmaps of the Slackware "Blue S" logo, used for the "live" user icon and in the XDM theme. * grub.tpl - the template file which is used to generate the grub menu for UEFI boot. * iso2usb.sh - this script creates a bootable USB version wih persistence from a Slackware Live ISO. + * isocomp.sh - when you boot directly from a Slackware Live ISO using Grub or a multi-boot manager like Ventoy, this script adds capabilities like persistence, an encrypted home, and the ability to load further live modules from disk. * languages - this file contains the input configuration for language support. One language per line contains the following fields: "code:name:kbd:tz:locale:xkb". Example: "nl:nederlands:nl:Europe/Amsterdam:nl_NL.utf8:" * code = 2-letter language code * name = descriptive name of the language @@ -709,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, @@ -719,16 +951,19 @@ The script's parameters are: -m pkglst[,pkglst] Add modules defined by pkglists/<pkglst>,... -r series[,series] Refresh only one or a few package series. -s slackrepo_dir Directory containing Slackware repository. - -t <none|doc|mandoc|bloat> - Trim the ISO (remove man and/or doc and/or bloat). + -t <none|doc|mandoc|waste|bloat> + Trim the ISO (remove man, doc, waste and/or bloat). -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. -R runlevel Runlevel to boot into (default: 4). + -S privkey:cert Enable SecureBoot support and sign binaries + using the full path to colon-separated + private key and certificate files. -X Use xorriso instead of mkisofs/isohybrid. </code> @@ -743,6 +978,9 @@ When all pre-reqs are met, you issue a single command to generate the ISO. The Another example which creates a MATE variant, configuring runlevel '3' as default and specifying a custom path for the Slackware package repository root (note that the script will look for a subdirectory "slackware64-current" below this directory if you are generating this ISO for slackware64-current): # ./make_slackware_live.sh -d MATE -R 3 -s ~ftp/pub/Slackware +An example on how to create a DAW Live ISO which supports UEFI SecureBoot (since liveslak 1.5.0 and only for 64-bit), is compressed using 'zstd' instead of the default 'xz' and is generated using xorriso instead of mkisofs. You need to provide the full path to a SSL private key and certificate file: + # ./make_slackware_live.sh -d DAW -c zstd -X -S /root/liveslak.key:/root/liveslak.pem + If you want to know what package sets are included in any of these Desktop Environments, run the following command: # grep ^SEQ_ make_slackware_live.sh for MATE, you will find: @@ -808,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). @@ -850,6 +1105,7 @@ What does the 'liveslak' init script do? * The complete RAM filesystem which underpins the overlay is made available to the user of the Live OS as "/mnt/live" * The filesystem of the Live media is made available to the user of the Live OS as "/mnt/livemedia". If the media is a USB stick then you will have write access to "/mnt/livemedia". * With the root filesystem assembled, the Live OS is configured before it actually boots: + * If a OS-specific configuration file (by default ''/liveslak/slackware_os.cfg'') exists, its contents will be parsed. Values of the variables defined in this file overrule any default liveslak or boot commandline values. * if you specified "swap" on the boot commandline, any available swap partition will be added to "/etc/fstab" in the Live OS. * if you specified a custom keyboard layout for the console (and optionally another for X) by using the "kbd" and "xkb" boot parameters then these will be confifured in "/etc/rc.d/rc.keymap" and "/etc/X11/xorg.conf.d/30-keyboard.conf" in the Live OS. * Same for any custom locale which was specified with the "locale" parameter, this will get added to "/etc/profile.d/lang.sh". @@ -865,6 +1121,25 @@ What does the 'liveslak' init script do? * From this moment onward, you are booting a 'normal' Slackware system and the fact that this is actually running in RAM and not from your local harddisk is not noticeable. +=== OS configuration file for persistent media === + +If present, the liveslak init will load a OS config file from a persistent Live medium such as a USB stick. In the case of 'Slackware Live Edition' this file is called "/liveslak/slackware_os.cfg" - i.e. is placed in the "liveslak" directory of your USB drive. For custom non-Slackware Live OS-es based on liveslak, the filename may be different. +This file contains one or more "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. +Values for the variables defined in this configuration file override the values already set via liveslak's own defaults or via boot-up command-line parameters. + +When booting your persistent //Slackware Live Edition//, the optional boot-time parameter "cfg" deals with this OS configuration file. The "cfg" parameter understands two possible argument values: + * "cfg=write" will (over)write the OS configuration file to your USB drive, using the values for all of the above variables that are valid for that particular boot. So if your timezone is "PST" then one of the lines in that file will read "TZ=PST". + * "cfg=skip" will skip processing of an existing "/liveslak/slackware_os.cfg" file. + +The OS configuration file is not present by default. You either create it at boot-time using "cfg=write" (which is a persistent change) or you create it manually using an ASCII text editor, after mounting theUSB partition on a computer. As an example, here is the content of ''/liveslak/slackware_os.cfg'' on my own USB stick: <code> +KEYMAP=nl +LIVE_HOSTNAME=zelazny +LOCALE=nl_NL.utf8 +TWEAKS=tpb,syn +TZ=Europe/Amsterdam</code> + + === Slackware Live module format === @@ -876,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) @@ -897,7 +1173,7 @@ Naturally, there have been many who went before me, and since I started as a n00 Website: https://www.slax.org/ -SLAX was the original Live variant of Slackware. The linux-live scripts which are used to create a SLAX ISO were generalized so that they can create a Live version of any OS that is already installed to a harddrive. SLAX development stalled a couple of years ago but its creator seems to have warmed up recently. However, the current SLAX is no longer based on Slackware - Debian is its base now. +SLAX was the original Live variant of Slackware. The linux-live scripts which are used to create a SLAX ISO were generalized so that they can create a Live version of any OS that is already installed to a harddrive. SLAX development stalled a couple of years ago but its creator seems to have warmed up recently. New versions of SLAX were no longer based on Slackware but used Debian as its base. In 2022, a new SLAX variant emerged which is again based on Slackware. The Live functionality of SLAX is based on aufs and unionfs which requires a custom-built kernel with aufs support compiled-in. It is small and has its boot scripts tweaked for startup speed. |