| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
This needed some changes because the Slackware rc.0 and rc.6 scripts have
evolved and my old hacks no longer worked.
|
|
|
|
To name the most important:
- The filesystem inside the containers is no longer limited to ext4 and can
now be btrfs, ext2, ext4, f2fs, jfs or xfs. The scripts 'iso2usb.sh' and
'isocomp.sh' now support this filesystem choice via a new '-F' switch.
- The 'upslak.sh' script can now extend the size of your home and persistence
container files, in case you run out of storage there.
- The internal functions used in 'iso2usb.sh' 'isocomp.sh' and 'upslak.sh'
are mostly unified now, and I intend to split all functions off into a
separate file which makes maintenance as well as adding new functionaliy
easier.
- The 'upslak.sh' script will now create a 'kernelmodules' squashfs module
and copies it to liveslak's 'addons' directory after updating the boot
kernel on the USB stick and the kernel-modules inside the initrd image.
This way, you no longer end up with a broken Live OS if you forgot to
install a Slackware kernel-modules package inside the persistent Live OS
prior to running 'upslak.sh' with the '-k' and '-m' parameters.
In addition, the README.txt was updated with these enhancements so that
the liveslak documentation is again completely up to date.
|
|
Changes in Slackware-current in March and May 2023 broke support for
detection of Ventoy disk on UEFI computers.
Liveslak's initrd needed to have efivarfs module added, so that
/sys/firmware/efi/efivars can be mounted by the live init script.
With kernel 6.x the content of what's found under efivars
has changed - instead of being represented as a directory with the
efi datastructures as files, liveslak now needs to deal with
a single file instead and find the offset in there.
|
|
Thanks to Richard Hoyle for pointing this out.
|
|
|
|
|
|
|
|
|
|
This was changed in commit dd0327d77f2741474245ecd3026cf66e55581733 when
adding full Ventoy support but I had not thought through all the consequences.
|
|
New features:
Ventoy is now fully supported.
Liveslak implements the "Ventoy-compatible" guideline. There is nothing you
have to do, this works out of the box.
When you are booting from an ISO file (whether via Ventoy, or through your own
hand-crafted Grub menu entry, or Windows BCD), Operating System persistence
and an encrypted homedirectory are now supported, as well as the ability
to load additional live modules (as 'addons' or 'optional') that are not
part of the ISO.
All of this is possible without the need for any modification to the ISO image.
The configuration is stored in a file next to the ISO.
A new script, "isocomp.sh" aka the ISO Companion script, has been added.
Like with all of my scripts, it accepts a "--help" parameter which will
show you how to use it.
This script allows you to:
- create encrypted containers for OS persistence and a persistent homedirectory
(actually not just for /home but you can create as many containers as
fit on the disk and mount them wherever you want)
- size extension of existing encrypted containers if they threaten to run
out of space
- creating a secondary liveslak root on the disk partition where you can
add more (optional/add-on) live modules that you need in the Live OS
but are not contained in the ISO
The configuration of these new features is stored in a file with the same
name and full path as the ISO file but with a ".cfg" file extension instead
of ".iso". The "isocomp.sh" script manages this configuration file for you,
but you can safely edit and modify it manually if you want to. The "isocomp.sh"
script will leave your customizations alone.
Here is an example of such a configuration file; it is copied from
my own Ventoy disk, for a Slackware LEAN Live ISO image:
LIVESLAKROOT=/liveslak
LUKSVOL=/liveslak/myhome.icc:/home
ISOPERSISTENCE=/liveslak/persistence.icc
TZ=Europe/Amsterdam
LIVE_HOSTNAME=zelazny
I added the variables "TZ" and "LIVE_HOSTNAME" manually by opening the
configuration file in an editor.
The following variables are supported in the isocomp configuration file,
but not managed by "isocomp.sh"; they all correspond to liveslak
boot parameters by the way:
BLACKLIST, KEYMAP, LIVE_HOSTNAME, LOAD, LOCALE,
NOLOAD, RUNLEVEL, TWEAKS, TZ and XKB.
The value of the "LUKSVOL" variable can hold multiple
"containerfile:mountpoint" definitions, separated by commas.
The variable "LIVESLAKROOT" defines the root of a secondary liveslak
directory tree on your disk.
|
|
|
|
|
|
|
|
|
|
Because the used $PERSISTENCE value can have a pathname component,
and the custom naming does not add value anyway.
|
|
Helps visually dividing the script in sections
|
|
Parameter values should only be set from ${DISTRO}_os.cfg if they have
not already been dedfined by commandline parameters.
|
|
toram=
Generic syntax: toram=type[,memperc]
- type: string value; os,core,all,none
- memperc: integer value, percentage RAM to reserve for liveslak
You can use a 'memperc' value for the 'toram' parameter to change
the percentage RAM used by liveslak, which is 50% of all available RAM
for normal operation.
For instance when you have 128 GB of RAM, you can specify a much lower
percentage to be reserved for liveslak. RAM will specifically be used
if you run liveslak without persistence, which means that any changes are
accumulating in RAM instead of on-disk.
Example:
Give liveslak ~6 GB (5%) to run the OS on a computer with 128 GB of RAM:
'toram=none,5'
|
|
When the value of 'debug' parameter is equal to or greater than '2',
the init script enables 'set -x' which results in verbose output of
init script execution. When the 'ash' shell is started as '/bin/sh' instead
of '/bin/ash', it enables bash-compatible mode. Then the script can use
'BASH_XTRACEFD' to log the verbose script output to a file '/debug_init.log'.
This is extremely useful for init debugging. Logging to file is enabled when
the value of 'debug' is '4' or higher.
When you boot with 'debug=4, you will end up in the rescue shell of the initrd.
You can then inspect '/debug_init.log' to diagnose issues with the boot-up,
and you can copy that logfile for instance to /mnt/overlay/root/ if you want
to preserve it. After typing 'exit', the live init will hand-over to
the Slackware OS initialization and after logging in you can copy the logfile
to a network location if you want.
|
|
|
|
|
|
|
|
This so that the live medium can be ejected after booting.
|
|
|
|
The syntax for the 'persistence' boot parameter has been extended.
The persistence directory/container no longer needs to be in the root
of the filesystem; you can specify an absolute path.
Additionally, you can specify the partition containing the filesystem
on which the persistence is located, or simply specify 'scandev',
to request that liveslak tries to find the partition for you:
persistence=/dev/sdX:/path/to/mypersistence
persistence=scandev:/path/to/mypersistence
In addition, a UUID or LABEL value of the filesystem will be accepted:
persistence=cd68b6f5-5b5a-4d27-9649-7827489f94a5:/path/to/mypersistence
This functionality will be useful if you need the persistence directory
or container to be located somewhere else than on the Live USB stick,
for instance on a local hard disk partition.
Useful for network (PXE) boot because the overlayfs does not support a
writable upper layer of your live filesystem over NFS. If you still want
to offer persistence to users of PXE-booted Slackware Live, you can now
use the local harddisk partitions or a local USB stick for persistence.
|
|
|
|
|
|
Excerpt from RFC 8375 (https://tools.ietf.org/html/rfc8375):
Users and devices within a home network (hereafter referred to as
"homenet") require devices and services to be identified by names
that are unique within the boundaries of the homenet [RFC7368]. The
naming mechanism needs to function without configuration from the
user. While it may be possible for a name to be delegated by an ISP,
homenets must also function in the absence of such a delegation.
This document reserves the name 'home.arpa.' to serve as the default
name for this purpose, with a scope limited to each individual
homenet.
|
|
This uses two squashfs modules that are currently only found in the
LEAN and XFCE images: 'min' and 'noxbase'.
These two provide a functional console-only Slackware with a lot of useful
programs. It will connect to a DHCP server automatically and it also
contains the 'setup2hd' script to be able to install Slackware from a network
mirror.
And since the Console OS gets loaded into RAM, you can remove your USB stick
after booting and use that stick for other purposes.
Use-case:
- You have one computer with a network connection and one USB stick, and want
to create a persistent Slackware Live on USB.
- Download an ISO supporting 'Console OS' to the computer's hard drive, and
transfer the ISO to the USB stick using the computer's ISO imaging tools,
making the stick bootable but not persistent.
- Boot from the USB stick, select the "Console OS in RAM" option.
- After you logged into the Console Slackware, mount the computer's hard drive.
- Use the 'iso2usb.sh' script that comes with liveslak to extract the ISO
content to the USB stick, making it persistent. See the README.txt for
instructions.
-----------------------------------------------------------------------------
Implemented as an extension of the liveslak 'toram' boot parameter.
Adding 'toram=core' to the boot commandline will load circa 500 MB of squashfs
modules into RAM and boot into a sparse but functional console environment.
For supported Live variants (currently LEAN and XFCE) the script
'make_slackware_live.sh' will automatically add a menu item "Console OS in RAM"
to the Syslinux and Grub bootloaders, using this 'toram=core' parameter.
TODO: add this as an option to all liveslak variants. Not so trivial to do.
|
|
|
|
|
|
|
|
|
|
toram=all
Prevent writes to disk since we are supposed to run from RAM;
equivalent to parameter "toram".
toram=os
Load OS modules into RAM, but write persistent data to USB.
|
|
New boot parameter: "domain=your_custom_domain",
The domain component defaults to 'example.net'.
|
|
|
|
|
|
Using a squashfs module created from nvidia-kernel and nvidia-driver packages.
A sample script for creating this nvidia module was added to liveslak, see:
./contrib/scripts/makemod_nvidia.
These two packages were created using the scripts from slackbuilds.org:
https://slackbuilds.org/repository/14.2/system/nvidia-kernel/
https://slackbuilds.org/repository/14.2/system/nvidia-driver/
Note that the nvidia-driver package was created on a multilib system so that
it could pick up 32bit compat libraries (needed for Steam among others),
and the CURRENT variable was set to 'yes' so that the nvidia drivers are
fully separated from mesa and xorg-server and do not overwrite system libraries:
# COMPAT32="yes" CURRENT="yes" ./nvidia-driver.SlackBuild
|
|
Liveslak can optionally load a OS config file "@DISTRO@_os.cfg" from within
the 'livemain' directory on the boot medium, which contains "VARIABLE=value"
lines, where VARIABLE is one of the following variables:
BLACKLIST, KEYMAP, LIVE_HOSTNAME, LOAD, LOCALE, LUKSVOL,
NOLOAD, RUNLEVEL, TWEAKS, TZ, XKB.
During boot, any variable from that file will be set in the boot environment
if it has not yet been defined in the init script.
You can prevent this behaviour by adding 'cfg=skip' to the boot commandline.
|
|
These lines became obsolete with Linux kernel 2.6 (Slackware >= 11)
when the kernel module extension changed from .o to .ko.
|
|
The default for 'udevadm trigger' is 'change', not 'add', so the scriptline
basically did nothing. This prevented some network devices from getting
initialized because their subsystem is 'pci' and not 'net'.
Thanks to Kanaya for debugging this with his Nvidia MCP51 ethernet device.
|
|
Do not make assumptions about how partitions and block devices are named.
but check the OS instead (in /sys/block and /sys/class/block).
|
|
Note that UEFI PXE-boot is not yet working, I do not know why.
|
|
|
|
|
|
|
|
|
Eric Hameleers