Duinsoft - Linux
Monday 27 February 2017      | home | tools | contact

The 'imt' script

The functions in this script started as the ISO functions of the solydfixes script. As the rest of that script is not ISO related, moving these functions to a separate set of 'ISO management tools' seemed appropriate.

The --help option of the script currently provides this list of functions and options:

	Usage: imt [OPTION/ARGUMENT]...

	General options:
	  -c FILE         use FILE as configuration file instead of imt.conf
	  -h, --help      display this text and exit
	  -l              open the log in an editor after the action
	  -o [VAR=VALUE]  set configuration variable directly
	  -y              use the --yes option with apt-get (see apt-get manpage)
	  --remove [+log] remove an installed set, optionally including the log files

	Arguments with related options (if any):
	  abort              abort a running batch (cleanly - after current action)
	  SPEC build         build an ISO
	    -P NUMBER        specify the number of processor cores to use
	    -s               skip specified build actions
	  SPEC chroot CMD    execute a chrooted command in the specified build structure
	  SPEC cmp           compare installed packages in builds (32 versus 64 bit)
	    -e               compare /etc instead of the installed packages
	    -f FILE          compare a 32 bit set with a file instead of a 64 bit set
	                      use . for FILE to download the corresponding file
	  SPEC diff FILE     execute diff on the same file in specified builds
	  get                download the most recent version of this script
	  list               list the available unpacked ISO structures
	    -i               also show each structure's info file
	  packages           check the reference packages
	  SPEC unpack [NAME] unpack an ISO, optionally naming a file or directory
	    -v               verbose - list all files being copied, modified or deleted
	  SPEC update        update the specified build
	    -T               update sources.list to Debian Testing instead of Jessie
	    -e               exclude specified update actions
	    -p               only show the first yes/no prompt (from apt-get) in a batch
	    -t               add 'testing' to the SolydXK repository line
	  SPEC upload        upload a built ISO and checksum file
	    -m MONTH         specify month (CCYYMM) if not current month
	    -n NUMBER        specify optional ordinal number (01-99) to add to month

	SPEC = specifying arguments (as in imt K cmp or imt ke32 update):
	  K or k             SolydK
	  X or x             SolydX
	  E or e             Enthusiast's Edition (implies -T for update)
	  32                 32 bit
	  64                 64 bit

	When a full specification is required, the speficying arguments MUST be given
	without spaces.

Version 3.0.0 of the script is available here (SHA256 hash is 5fc92612ba64d93c7f551922d4d44630dfa2289c53c58e7d103da10aedc3aaa9 - gpg signature is here). This links to a text file with some release history.


Mixing imt and SolydXK Constructor

The imt unpack, update and build sequence can be mixed with the Constructor's Add, Upgrade and Build actions, but not under all circumstances. Unpacking/Adding is essentially the same process for both, but building is not. A lot of what the Constructor does before it actually starts building an ISO, is not done during imt's build action, but during update.
So it's ok to run imt's update and then Build using the Constructor, but doing Upgrade with the Constructor and then building with imt is a bad idea.


Most of my scripts are not distributed as Debian packages but supplied in tarballs. This means you cannot install them using your package manager, but have to download the tarballs and 'install' them yourself. Just create a directory called imt anywhere you like and extract the tarball to it, keeping the layout/structure intact. Any good file manager should do that automatically if you select 'Extract here' or 'Extract to...' from its context menu (yes, I know Thunar messes that up - I did write 'any good file manager'...).

You can run the script from the terminal, open on that directory, with ./imt command ... or from any other directory if you use the full pathname. If you create a symlink to the main script in /usr/local/bin or ~/bin, you can call it from anywhere with just imt.

Alternatively, you can 'install' the script properly, i.e. put the main script in /usr/local/bin and the rest in /usr/local/lib/imt (no package manager involved means using /usr/bin and /usr/lib/imt is out...). You can do that by running ./install from the directory you just created.

Contents of the tarball

The imt tarball currently contains:

lib/imt/overwritesdirectory with templates for the update function
lib/imt/buildscript for the build function
lib/imt/building-an-isoa text file describing how to build a 32-bit SolydK ISO
lib/imt/functionsmiscellaneous support functions
lib/imt/historysome notes about the development of the script (not as detailed as a change log)
lib/imt/imt.conf.examplean example of the main configuration file
lib/imt/settingsnon user specific settings
lib/imt/trackerslist of torrent trackers from SolydXK Constructor
lib/imt/unpackscript for the unpack function
lib/imt/updatescript for the update function
lib/imt/webseedslist of urls of ISO seeds (backup in case pulling the real one from the website fails)
imtthe main script
installscript that takes care of installing or upgrading the set to a new version

No README or manpage, sorry. This webpage will have to do.

Some items the script will create and use are scratch space (/tmp/imt.d), a directory for variable/cached data (/var/local/imt) and a log file (/var/log/imt.log). The latter can be opened in a graphical editor with the imt -l command (that's a lower case L, by the way).

Library directory

The lib/imt subdirectory is the library directory. This is where the script expects to find all its support files. Keeping this in the unpacked imt directory is fine, but it is not where the script itself would put it.

Upgrading the script

The script uses a simple DNS call to check whether a new version is available. If there is one, it will tell you about it and you can download the new version from this site or use the command imt get to make the script download it itself. The get function will download the tarball and 'install' the script and support files in the default locations (see above). If the old version of the script is running from another directory called 'bin' (e.g. in your home directory), the new version will end up there. If necessary a 'lib/imt' directory will be created on the same path.

Removing the script

Removing the script and associated files and directories can be done with the command imt --remove. If you want the log files gone as well, use imt --remove +log. This command will work on an installed set and also on a set which is not actually installed but stored in a directory with the name of the script.
Be aware this command executes immediately (after asking your sudo password) and bluntly removes the entire script set. If you used one of its directories to store anything you want to keep, move it out of the way first.


You will need a properly set up imt.conf file before you can use the script. Use the imt.conf.example file from the tarball or create something yourself and make sure all the required variables have values that apply to your system. Also check out the reference packages section.

The script uses two files for configuration, imt.conf with the system specific configuration and settings with ISO related settings.


The script needs to know where the unpacked ISOs are stored on your machine. You should set this in the imt.conf file. This file should be placed in the .config subdirectory of your home directory, but it will also be found in the library directory. It will be read ('sourced') as if it's part of the script, so assigning values to variables must be done in the same way as in a regular shell script.
Be aware that if you change the values of the 'Script...' variables set at the start of the script, you run the risk of seriously messing up the script's functionality.

An example version of imt.conf is provided in the tarball. It starts like this:

# In this example, all ISO build directories are subdirectories of one single
# directory, specified in BuildsPath, which will be used as a prefix when the
# actual locations are set (in the array ISOBuild). If a k or x variable
# contains a full path (i.e. starts with a /), this prefix will be omitted.
# Remove or comment the variable for any ISO you don't have.
# If any of these structures is on a device that may not be mounted initially,
# be it an internal or external one, the pathname MUST start with either /mnt
# (for internal devices) or /media (for external ones). The script uses this to
# determine the tool to mount the device with (mount or udisksctl). Also, the
# label of the relevant partition (ehd2-e0 in this example) must be part of the
# pathname.

Change this to reflect your own setup.

Other variables you can set in imt.conf are:

BuiltISOsPathdirectory where build ISOs should end up
ImagesPathdirectory used to store (downloaded) disk images
RemoveReferencecode or full pathname of file to use for comparing the ISO's /live/filesystem.packages-remove file
LocalBindirectory with executables which need to be accessible inside the chrooted build environment
AptCachedirectory to use as apt cache for all build structures
NoEditorset to 1 if you don't want the iso cmp result to be opened in a graphical editor
Serverused to indicate which of the Settings array items is the default
Settingsarray of names of remote server settings files for uploads
BuildMirrorcountry code of repository mirror to use during build structure updates
LocalRepoISOsources.list line for local repository - general packages
LocalRepoHoldsources.list line for local repository - held packages
LocalRepoPriopin priority lines for local repository
LocalRepoKeyIDfingerprint of local repository's GPG key
LocalRepoKeyFilefile with local repository's GPG key

All of these are described in more detail below.

Command line

The -o option allows you to change these variables from the command line. For instance, if you have the BuildMirror variable set and the local repository turns out to be off line, you can add -o BuildMirror= to the command line to temporarily switch off the local mirror without having to change the imt.conf file. If you want to change more than one variable, you need to either put the entire sequence between quotes and use semicolons as separators (e.g. -o 'RemoveReference=/home/user/packages-remove;BuildMirror=') or use more than one -o option.
Of course, quotes are also necessary if the value you want to assign contains spaces. If you want that and assign more than one variable in the same -o option, you need two sets of quotes: double quotes around the value following the equals sign and single quotes to enclose the whole sequence (or the other way around). Spaces around the equals sign are a bad idea, by the way. This is shell script (bash) code, so it must conform to bash rules.

The second example in the previous paragraph illustrates something else you need to be aware of when you specify pathnames in the configuration files or on the command line. You cannot use ~/ to refer to your home directory as the script (mostly) runs as root.


Unlike imt.conf, the settings file is not supposed to be altered by the user. It is meant as a central location for various ISO related settings and is sourced immediately before imt.conf. It currently sets the following variables:

BuildRemovalswhitespace separated list of files and directories to remove from BootPath and RootPath before building (build)
ChrootActionsProcess format list of actions after dist-upgrade (update)
FirmwareProcess format list of firmware drivers or driver installer packages
Hold_Process format list of packages to hold (update - main editions)
Hold_eeProcess format list of packages to hold (update - enthusiast's editions)
NotOrphanedcomma separated list of packages not to be treated as orphaned (update)
NotUnavailablecomma separated list of packages not to be treated as unavailable (update)
OffLinewhitespace separated list of packages to be stored in ISO's /boot/offline directory
ReferencePackageswhitespace separated list of packages and files to watch
ReleaseStablemain version number of Debian's current Stable release
ReleaseTestingmain version number of Debian's current Testing release
SyslinuxBinarieswhitespace separated list of binaries to copy to BootPath/isolinux (build)
UpdateRemovalswhitespace separated list if files and directories to remove from BootPath and RootPath (update)

Several of these are described in more detail below.


The available functions are (this list is not in alphabetical but in logical order):

Be aware that you do not need to run the script with su or sudo. In fact, it may complain if you do, because it may need to pick up some information which is not available to root. If it needs root permissions for some action, it will make the necessary sudo call itself.

Check the reference packages - imt packages

The ISO build structures maintained with this script are closely tied to the two main SolydXK editions, the 64-bit SolydK and SolydX. Any significant changes there should be reflected here, if possible. To help keep an eye on things, the script includes a 'watcher' functionality which will notice changes in certain files. This is used by the iso update function as long as the variable ScriptPackageCache is set, but it can be called separately as well: imt packages.
The variable ReferencePackages in settings contains a list of packages and files to check. If differences are detected, you'll have to figure out whether these are relevant yourself, though. They will show up as diffs in the logfile (/var/log/imt.log), by the way, so the first place to look is there.

Should you decide you do not want to use this functionality, you can disable it by adding the line unset -v ScriptPackageCache to imt.conf, which will remove the variable. If however you do want to use it, you should run imt packages at least once after setting up imt.conf, so the directory ScriptPackageCache points to is created.

By default, only 2 older versions of packages will be kept in the subdirectories of the directory set with ScriptPackageCache. You can change that by setting the variable ScriptMaxCached (in imt.conf). Set it to 0 and no maintenance will take place at all and you will have to remove older items (the directories with version numbers as names) yourself.

Keep in mind that you really need a host - or at least a virtual machine - tracking Debian Testing if you want to be able to create ISOs for the Enthusiast's Editions. Otherwise keeping up with the changes these editions go through could become quite hard.

Unpack an ISO - imt unpack

Most of the code for this function is held in a file called unpack, which must exist in the script's library directory.

If you enter the command imt x64 unpack FILENAME-OF-ISO, the script will unpack the ISO file in the correct build structure. The file needs to be in the current directory or on ImagesPath (see below - current directory will take precendence) if no path is specified and the build structure needs to be set in imt.conf, using the BuildsPath and k or x variables as mentioned above.

If you specify a directory instead of a file, the script will scan this directory for suitable ISO files and present a list to choose from. If your system has a directory where you usually keep ISO files, you can specify this in imt.conf using the ImagesPath variable. The example file has:

# Set this to the directory in which you usually keep your ISO Image files.

You can then enter the unpack command without specifying a directory or file and the script will present a list of suitable files from the directory set in ImagesPath.

The -v option (imt -v x64 unpack) will make the script display the name of every file being handled as the ISO is unpacked. While this is a nice way to see what's going on, it will also slow down the process considerably.

List the available unpacked ISO structures - imt list

This function shows a simple list of defined ISO build structures and whether there is actually anything in them. With the -i option, all available info files (/etc/solydxk/info) will also be shown: imt -i list.

You can limit the output to a selection of structures by specifying them. I.e. imt -i list ke32 ke64 will show info about the SolydK Enthusiast's Editions only.

Update a build structure - imt update

Most of the code for this function is held in a file called update. The templates for the files to add or replace are stored in files in the overwrites directory. These items must exist in the script's library directory.

This function performs all kinds of update and cleanup actions, including but not limited to running apt-get update and dist-upgrade in a chrooted environment, removing orphaned or unavailable packages, downloading offline GRUB EFI packages and building the EFI modules.

The sources.list file is also checked (before the apt-get update). By default this should point to the Jessie or Stretch (Testing) repositories, for the main and Enthusiast's Editions respectively.

Local checks on the host

Some of the checks this function performs require more local configuration, to be done in imt.conf. If you want the script to warn you about certain important files changing, you should let it set up a package cache. By default this will be done in /var/local/imt/unpacked, but you can change that by changing the ScriptPackageCache variable (see also the imt packages description).

Another thing to check is which packages are to be removed after installation. This will not change often, but you can let the script keep an eye on any changes by providing a reference file. This can be a file specified by its full pathname, stored anywhere on your machine, or the corresponding file in one of the unpacked ISOs. In that case all you need to specify is the code of the ISO. The imt.conf example has this:

# If you want the update function to check the /live/filesystem.packages-remove
# file, set this variable. You can use the file from one of the unpacked ISOs by
# specifying its code (e.g. x64). Alternatively, enter a full pathname starting
# with a slash to use a file stored anywhere on your machine. If you end that
# name with an underscore, the suffix 'ee' will be added when the function
# handles an Enthusiast's Edition ISO.
# RemoveReference=x64

If you enter a pathname, it must start with a slash. If you specify a name ending in an underscore, the script will look for a file with that exact name when checking a Main Edition ISO and use that name with 'ee' added for an Enthusiast's Edition.

Special bind mounts

From the imt.conf example:

# Set this if you have a directory with executables you want to have access to
# in the chrooted build environment. This directory will be bind mounted over
# the ISO's /usr/local/bin.
# LocalBin=/usr/local/bin

# Set this if all build structures are to use the same cache for apt.
# AptCache=/var/cache/apt/archives

In case you want to be able to access your own binaries or scripts and/or want to have one central apt cache inside the chrooted build structures. The AptCache setting can be quite useful if you have a lot of build environments you need to keep up to date.


By default, upgrading packages in the build structures is done using the default repositories. However, these are in the US and depending on where you are, this can be slow. For me personally, the Dutch mirrors are quite a bit faster. The BuildMirror variable can be used to change this. Be aware that SolydXK only has a limited set of mirrors, so using the code of your country may not work as expected for the SolydXK repository. The Debian repos is another story, but keep in mind that the Enthusiast's Editions use Debian's redirector.

# Optional (country) code. When this is set, the sources will be temporarily
# switched to the local mirror in that country when an ISO structure is
# updated/upgraded. This can speed up large package downloads considerably.
# BuildMirror=nl

Please check your own system for useable country codes (a future version of this page may have something more useful here...).

If you want to include extra packages or use the function's hold action, you will have to set up a local repository. How to do that exactly is not something I intend to describe here. I will just assume you have already done it and want to make this function use it. Looking at the imt.conf example:

# Sources list, pin file and GPG key info for the local repository. How you set
# this up on your machine is entirely up to you, as long as you keep in mind the
# text in LocalRepoISO will get the suffix 'stable' or 'testing' depending on
# the edition.
# This repository will always be added, but may be empty. The 'Hold' repository
# will only be added if the Hold_ or Hold_ee variable (set in settings) exists
# and contains a Process string.
# The texts will end up in a chrooted /etc/apt/sources.list.d/localhost.list and
# .../preferences.d/localhost, temporary files that will not be added to the
# ISO. The key will be added to the chrooted apt's key database and will be
# removed from it during the cleanup immediately before the ISO is built. The
# KeyId must be your key's fingerprint and the KeyFile the full name of a file
# containing the key.
# Uncomment the following lines to enable. 
# LocalRepoISO="deb http://localhost/pkg packages iso-"
# LocalRepoHold="deb http://localhost/pkg packages iso-hold"
# LocalRepoPrio="Package: *\nPin: release a=packages\nPin-Priority: 900"
# LocalRepoKeyID=
# LocalRepoKeyFile=

This references a local repository at localhost/pkg with a 'distribution' called packages and three sections: iso-stable, iso-testing and iso-hold. You can modify everything to suit you, except the stable and testing bit.

Preventing unwanted effects

The update function tries to prevent the apt-get dist-upgrade from starting processes in the chrooted environment. It may not always succeed, so make sure to check the last section of this function's terminal output (i.e. the bit where it says 'looking for unwanted processes running in the chroot').

Also, never ever allow a GRUB upgrade to install anything in your main disk's MBR. An update-grub shouldn't hurt, but if you see configuration screens, triggered by grub-install, asking you where to install GRUB, DON'T!

One of the actions carried out is purging orphaned packages. This is done using deborphan and I've seen at least one occasion where this is a bit too enthusiastic. The variable NotOrphaned can be used to curb this. It should be set in settings and the relevant section in that file currently looks like this:

# Packages that must NOT be treated as orphaned - comma separated list

Another cause of potentially undesirable behaviour is the removal of packages that are no longer in the repositories. This can be prevented with the NotUnavailable variable. Currently in settings:

# Packages that must NOT be treated as unavailable - comma separated list
Specific actions

It's possible to call the iso update function for a specific set of actions. For example, imt k32 update lists upgrade will just run apt-get update and apt-get dist-upgrade. The full list of available actions is (in sequence):

ref-packagescheck reference packages
ref-removecompare ISO's boot/live/filesystem.packages-remove file with (unpacked) reference ISO's or specified file
ref-adjustcompare ISO's root/usr/lib/solydxk/system/adjust.py with host's
refdo the previous three and exit - this one isn't part of a normal update sequence, of course...
sourcescheck sources.list
historycheck update manager history
listsperform apt-get update
holdprocess any hold commands specified in Hold_ or Hold_ee (set in settings)
upgradeperform apt-get dist-upgrade
firmwarecheck all required firmware packages are installed
actionsprocess actions specified in ChrootActions (set in settings)
unavailablecheck unavailable packages
orphanedcheck orphaned packages
plymouthmake sure the plymouth splash screen is correct
defaultscheck SolydXK defaults (from solydxk-system c.a.)
databasesupdate databases like the apt-xapian index, the locate and GeoIP database and the pixbuf cache
firewallmake sure the firewall is set correctly
old-kernelsremove any old kernels
brokencheck for broken packages
cleanupclean up the apt cache and remove obsolete automatically installed packages
kernel-filestake note of the current kernel files
offlineupdate the offline package cache (uses OffLine - set in settings)
removeremove unwanted items (uses UpdateRemovals - set in settings)
overwritereplace or add certain files (templates in overwrites directory)
efibuild EFI boot files
greeterupdate the LightDM greeter
live-usermake sure the live user is available to LightDM
lightdm-uidset minimum UID for LightDM to 1000

If you use the -e option, the actions listed will be skipped. E.g. imt k32 -e update firmware will run every part of a normal update sequence, except checking the firmware.

Execute a chrooted command - imt chroot

If you want to run a (non graphical) command in the environment of one of the ISOs, you can start up the SolydXK Constructor and click the Edit button. The script offers the same functionality.
Say you want to update the package lists of the 32-bit SolydK build, just run imt k32 chroot apt-get update and watch the usual update text scroll by in your terminal window.

There are some limitations. As the function only chroots a single command at a time and not the entire terminal, you can't 'chain' commands with ; or &&. That is, something like imt k32 chroot apt-get update && apt upgrade won't work (and neither will enclosing the commands in accolades or parentheses).

Also, you need to make sure imt doesn't choke on any options the command might need. For instance, running 'apt-get -f install' would need to be entered as imt k32 chroot -- apt-get -f install. The two dashes tell imt to ignore any following options.

Compare packages or /etc - imt cmp

This checks which packages are installed on a 32-bit SolydXK ISO and are missing from the corresponding 64-bit one (and vice versa). It assumes you have at least the 32-bit ISO unpacked on your system somewhere. If you don't have a 64-bit ISO unpacked as well, you can run the comparison against a list of packages in a file. A copy of such a file will be available on this site, updated regularly, and can be downloaded by the script.
Some examples of use:

imt k cmpcompare SolydK 32-bit vs 64-bit when both are available unpacked
imt k cmp -f listcompare if 64-bit is only available as list
imt k cmp -f.ditto - download list

The result of the comparison can be found in /tmp/imt.d/result-k or /tmp/imt.d/result-x, depending on the SolydXK version. The script will attempt to open this file in your favourite (graphical) text editor, unless you uncomment the NoEditor=1 line in imt.conf.

If you've downloaded the 64-bit list, you should also find a result file with '-downloaded' tagged to the name in /tmp/imt.d. This is the result of a comparison carried out on the machine where the 64-bit list was produced and is provided as reference.

What to do with the result

The resulting list is not meant as a ready-to-use recipy for packages to remove from or add to the 32-bit ISO. There will be differences, if only because the community decided to use the non-ESR versions of Firefox. Also, slightly different version numbers (in particular ones with something like '+b1' at the end) don't have to be an issue.
Check the list for obviously superfluous or missing packages and act accordingly, if necessary after consultation.

Comparing /etc

If you run imt -e k cmp, the script tries to go through the entire /etc structure of the 32-bit and 64-bit SolydK ISOs and report differences. [This functionality needs work to improve the handling of the comparison result and because of false 'positives'.]

This does not work with only one ISO unpacked, by the way. You really need them both.

Execute a diff on a specific file - imt diff

This works both across architectures and across desktops.

For instance, the command imt k diff etc/wgetrc will produce a diff for the file /etc/wgetrc in the 32-bit and 64-bit SolydK build structures. With imt 32 diff etc/wgetrc the script will diff the same files in the 32-bit SolydK and SolydX structures.

Of course, this function is only usefull if you have those ISOs unpacked on your system.

Build an ISO - imt build

Most of the code for this function is held in a file called build, which must exist in the script's library directory.

This function runs all the commands required to create an ISO image and an SHA256 checksum and torrent file. It uses what's available in the relevant build structure and creates the files for the current month. That is, in September 2016, imt k32 build would create solydk32_8_201609.iso, solydk32_8_201609.iso.sha256sum and solydk32_8_201609.iso.torrent.
The '8' in the names represents the main version number of Debian's Stable release. This is set in settings with the ReleaseStable variable.

The tracker and seed data needed for the torrent files is taken from the SolydXK Constructor and one of the SolydXK servers respectively. If either of those is not available, the supplied files trackers and webseeds will be used.

The resulting files will be placed in the corresponding build directory unless you set the BuiltISOsPath variable in imt.conf. From the example file:

# Only uncomment and set this if you want built ISOs to be stored in a separate
# directory (otherwise they will end up in the corresponding build directory).
# BuiltISOsPath=

By default, the build function will use half of the available processor cores to build the squashfs file. You can change this with the -P option. On a four core machine, imt -P4 build will use all cores. Be aware this may cause a bit of a strain on your machine and keep an eye on the processor temperature. Press Ctrl+C a couple of times to abort the process if things heat up too much.

Specific actions

The build function also has the option to run a specific set of actions only. However, actually building the ISO is not really suited for leaving bits out, so don't do that unless you know exactly what you are doing. The full list of available actions is (in sequence):

datecheck the build structure has been updated recently
kernelcopy kernel files to the live directory
syslinuxupdate syslinux binaries if necessary
installedbuild a list of all installed packages (live/filesystem.packages)
memtestdisable memtest in the GRUB menu (chmod -x /etc/grub.d/20_memtest86+)
deletedelete various files that should not be in the ISO
gpg-keyremove the local repository's gpg key
fix-sourcesrestore the sources list if necessary
squashfscreate the new squashfs file
md5sumsbuild a list of md5sums for use by the integrity check (live system menu)
efibootcreate the El Torito boot image efiboot.img
isofsbuild the hybrid ISO
checksumcreate the sha256sum file
torrentcreate the torrent file

If you use the -s option, the actions listed will be skipped. E.g. imt k32 -s build torrent will run every part of a normal build sequence, except creating the torrent file (which is just about the only thing you can do without issues if you do not know exactly what you are doing...).

Upload an ISO - imt upload

If you have upload access to the SolydXK repository, you can use this function to upload the built ISO and md5sum file. You'll need the lftp package and have to add some more settings to imt.conf. The example currently has this:

# Default

# This should point to a file containing server settings for ISO uploads.

# Alternatively, you can put all the settings in here and tell the script you
# have done that with a full stop, i.e.
#  Settings[solydxk]=.
#  RemoteServer=server's hostname
#  RemoteUser=username
#  RemotePass=password (or use gkeyring)

It is unlikely you already have another ini file with server settings that you could link to as above, so adding the details to imt.conf itself is probably the easiest.

By default, the script will use the year and month of the current date to determine which files are to be uploaded, so in September 2016, just imt k32 upload should be enough to start uploading a file called solydk32_8_201609.iso (plus its sha256sum file). If you want to upload older files or files with an ordinal number after the month, use the -m and/or -n options (e.g. the August 2016 ISO with '02' added to the name: imt k32 upload -m 201608 -n 02).


If you want to use the upload function of the script, you'll need lftp (it's in the repository). The normal ftp client simply does not cut it for me. I use lftp with these additions to /etc/lftp.conf:

set cmd:save-cwd-history no
set cmd:save-rl-history no
set dns:order "inet"
set ssl:check-hostname no
set ssl:verify-certificate no
set xfer:log yes
set xfer:log-file "/var/log/lftp/transfer"

Not all of these are necessary, but the ssl ones may be useful if you connect to a server that, while supporting secure connections, hasn't been set up entirely correctly.
If you want logging and want to use lftp as non-root, you'll need to chmod the /var/log/lftp directory to 0777.


Under normal circumstances most of the functions mentioned above will be used separately. Some can be chained together or set to act on more than one build structure. Assuming you have these six ISOs unpacked, the command imt -y k32 x32 ke32 xe32 ke64 xe64 update build upload would update the structures, build the ISOs and upload them, all without manual intervention. Something like imt -y k32 x32 update or imt ke32 xe32 ke64 xe64 upload is also possible, i.e. you don't have to use the full run.

Batch functionality is only available for the update, build and upload functions.

It is not advisable to use this with Enthusiast's Editions in times of disruptive changes, like major KDE or gcc upgrades. You shouldn't use the -y option then anyway (it suppresses apt-get's confirmation questions) and preferably do update runs with just the list and upgrade actions to make sure nothing is going to break.

If you are confident nothing will break during the update phase of the batch, but you do want to check the first bit (i.e. the upgrade/remove/install list), you can use the -p option instead of -y. This will make the update function ask only the very first apt-get related confirmation.

Aborting the batch

As mentioned above, it's always possible to stop the script with Ctrl+C. However, that is not exactly a 'clean' abort, particularly if it happens during updating, in the middle of some action on the chrooted environment. You should only use it in case of an emergency.
To abort cleanly, with all temporary mounts and files removed, open another terminal window (or the Alt+F2 command line) and enter imt abort. This will create a flag file in the script's temporary directory. The main run of the script will pick that up and stop after the current action has been completed.

Licence and disclaimer

The imt script is provided under the EUPL, version 1.1, which is a FOSS licence, compatible with GPLv2.

The script is still being developed and future versions may be (very) different. As far as I'm aware, it does what it's supposed to do. Nevertheless, you use it entirely at your own risk. That said, if you find a bug, do get in touch with me and I'll see what I can do about it.

Additional notes

This section needs more work. For now, a short list of known issues will have to do: