Welcome to the Tiny Core Linux Wiki at tinycorelinux.net!

dCore SCE Overview

An SCE (self-contained extension) consists of a converted Debian package and all it's dependencies, packed into it's own file system and compressed into a single file (SquashFS). The dCore sce-import Command is used to download files and create SCEs.

Although most SCEs are best loaded at boot, a user may choose to load less frequently used extensions after boot utilizing the dCore sce-load Command or dCore sce-ondemand Command. This links the SCE(s) into the RAM mounted file system for use.

The contents of an SCE are transparent and once mounted can be inspected by exploring /tmp/tcloop/. Otherwise copy the extension to a temporary directory, run unsquashfs SCE_name.sce and explore the newly created directory named /tmp/squashfs-root/.

dCore TCE (/tce/) Directory

The /tce/ (Tiny Core extension) directory is utilized to create and store SCE extensions. This is why the tce-setdrive command is used during installation to set up a persistent system. This allows extensions and related data to be stored for re-use, rather than having to re-install them with every fresh boot (ie. typical 'live' boot). The /etc/sysconfig/tcedir/ (/tce/) directory is actually a symbolic link. Exploring dCore's directory structure after installation will reveal that /etc/sysconfig/tcedir/ may be the same as /mnt/sda1/tce/ or whatever partition is used for the installation.

The TCE directory structure:

                      |->  import/
                      |           debinx/
                      |           debs/
                      |->  ondemand/
                      |->  sce/

The /tce/ directory contains the sceboot.lst file. It also contains the mydata.tgz backup file if persistent home and opt are not utilized and a 'backup' was previously completed (CLI backup command, GUI exittc). A second file named mydatabk.tgz will be present if a safe backup was previously used when running exittc. Safe backup simply backs up the existing mydata.tgz file before overwriting a fresh backup, an easy method to save an earlier backup if configuration changes were made during the session. If running the wbar application launcher a xwbar.lst file may be present.

The ~/.ashrc file contains two built-in alias' for quick navigation. Entering 'tce' into a terminal changes directory to /etc/sysconfig/tcedir/ and entering 'sce' changes to /etc/sysconfig/tcedir/sce/. Note modifying most of these directory contents manually is discouraged, use the appropriate dCore SCE Management Commands whenever possible to manage SCE extensions.

The /tce/ directory contains three sub-directories discussed below: /import/, /ondemand/ and /sce/.

dCore Import (/tce/import/) Sub-Directory

The /tce/import/ directory contains the sub-directories /debinx/ and /debs/.

The /tce/import/debinx/ sub-directory contains numerous plain text database files used by dCore to import and update SCEs:

  • KEEPDOC: Lists packages that should always keep documentation files when imported.
  • NEWDEBINX and OLDDEBINX: Both large files will be present if sce-update -a was previously run, which moves NEWDEBINX to OLDDEBINX and creates a fresh NEWDEBINX. They contain information on all packages in the dCore and Debian or Ubuntu repositories. Used and compared to determine whether updates are available.
  • PKGEXCLUDELIST: Lists blocked Debian and Ubuntu packages known not to function with dCore, from http://tinycorelinux.net/dCore/import/PKGEXCLUDELIST. Currently contains only three KDE desktop packages. Packages can be unblocked by manually editing the file, then import the desired package. If the software works satisfactorily notify the developer so the package(s) can be un-blocked.

The /tce/import/debs/ sub-directory contains all *.deb and *.tar.gz files downloaded and utilized to import and update SCEs. As SCEs are updated or removed, over time the directory may contain deprecated files or those no longer needed by any existing SCE. These files can be purged to reclaim drive space using the dCore sce-debpurge Command.

dCore OnDemand (/tce/ondemand/) Sub-Directory

SCEs available OnDemand have startup scripts in /etc/sysconfig/tcedir/ondemand/. The script is automatically generated when the dCore sce-import Command or dCore sce-ondemand Command is used to add a new or existing SCE to Ondemand (eg. sce-import -o firefox, sce-ondemand firefox). Example of a typical autogenerated OnDemand script:

ondemand -e firefox.sce

Supported Window Managers automatically place these SCEs in the OnDemand menu for easy loading and launching. The sce-ondemand command can also be used to remove SCEs from OnDemand. Using the dCore sce-remove Command also automatically removes an SCE from OnDemand.

Extensions may be loaded using the sce-ondemand command or dCore sce-load Command then manually launched. The trade-off of having SCEs load at boot vs OnDemand is slower boot time or having to wait for SCE(s) to load during runtime. Rarely used SCEs are typically placed in OnDemand.

An OnDemand script may occasionally be modified manually to change launch behaviour or perform additional tasks (modified qpdfview OnDemand script example).

dCore SCE (/tce/sce/) Sub-Directory

Imported SCEs are stored in /etc/sysconfig/tcedir/sce/ and only become usable when loaded. Each SCE extension will also have it's own *.sce.debinx and *.sce.md5.txt files. The *.sce.debinx file contains the md5sum of the /etc/sysconfig/tcedir/import/debinx/NEWDEBINX (Debian Index) database file used to create the SCE when first imported or re-imported during an update. This provides a quick update check mechanism. If the md5sum of a refreshed NEWDEBINX database file (refreshes when running sce-update) still matches the md5sum listed in the SCE's *.sce.debinx file then the NEWDEBINX package database has not changed since the SCE was imported and a formal update check is not required. This is why an SCE update check sometimes completes almost instantaneously!

The *.sce.md5.txt file is also created when an SCE is first imported or re-imported during an update and is used primarily for extension integrity. All SCEs require an *.sce.md5.txt file for the extension to load. During the loading process the SCE's actual md5sum is checked against the *.sce.md5.txt file contents for integrity and will not load if there is a mismatch. This may be due to data corruption or nefarious activity. If this occurs the SCE should be re-imported. Diligent users may routinely copy all SCE md5sums to a secure file, updating the file whenever SCEs are imported or updated, and periodically check file contents against the actual SCEs for corruption or tampering. The process could be automated with a reasonably simple script.

SCEs imported using the dependency option (eg. sce-import -d) will also have an associated *.sce.dep file in the /sce/ directory, which lists all SCE(s) that may provide dependencies for the extension. Lastly, SCEs imported using the list option (eg. sce-import -l favourite_apps) will have an associated *.sce.lst file, which lists all packages installed in the list extension.

SCEs loaded at boot time are listed in /etc/sysconfig/tcedir/sceboot.lst (see dCore sceboot.lst). SCEs available OnDemand have their startup scripts in /etc/sysconfig/tcedir/ondemand/. All extensions presently loaded can be found in /tmp/tcloop/ (eg. ls /tmp/tcloop/). All packages presently installed (ie. *.deb packages) can be found in /tmp/.installed (eg. cat /tmp/.installed).

The /sce/ directory also contains an /sce/update/ sub-directory, which is used to temporarily store updated SCEs until system reboot (see dCore sce-update Command). To clarify, the /update/ sub-directory only contains updated SCEs when the outdated version was already loaded into RAM. If the SCE has not been loaded since boot, upon updating it will directly replace the old version in the /sce/ directory, rather than place it in the /update directory. So if an already loaded SCE is updated a reboot is necessary to use the updated version. However, if the SCE has not yet been loaded, then gets updated, loading the SCE after the update will load the updated version without the need to reboot. In reality it is more complex, as SCEs often contain the same dependencies as other SCEs, a non-updated and loaded extension may already have the outdated dependency loaded. For a security conscious user, the only true way to ensure all loaded libraries are fully up to date is to run ''sce-update -a'' (update all SCEs) then reboot.

> Return to the dCore Wiki Welcome page

dCore sceboot.lst

SCEs loaded at boot time are listed in /etc/sysconfig/tcedir/sceboot.lst. This replaces the “onboot” concept of Tiny Core. It should include any kernel modules and drivers required to run hardware and any extensions typically utilized at every boot. For most users this will include the X Window system (Xvesa or X.org), Xprogs (required for graphics), Alsa/sound, preferred Window Manager, web browser and file manager plus any firewall, networking and system monitoring extensions.

SCEs can automatically be added to sceboot.lst during import (eg. sce-import -b firefox). Alternatively the /etc/sysconfig/tcedir/sceboot.lst can be carefully edited manually (leave one blank line at the end of the list). Example of a typical sceboot.lst:


This does not mean all extensions automatically open at boot, just load into the RAM file system. Like Tiny Core the ~/.X.d directory (for user/graphic items) and /opt/bootlocal.sh file (for root items) is typically utilized.

The ~/.X.d directory accepts single or multiple plain text files (not executable scripts) with one or more start up items per file, each on their own line. Example of a user created ~/.X.d/startups file (create any file name):

conky &
dillo &
emelfm &
xset s 300 &

Example of a /opt/bootlocal.sh entry to configure iptables at boot:

# put other system startup commands here
/sbin/iptables-restore < /home/tc/iptables-config

> Return to the dCore Wiki Welcome page

dCore Repositories

Standard Repositories

Debian-based dCores automatically have access to their respective Debian main, contrib, non-free and security repositories. Ubuntu-based dCores automatically have access to their respective main, universe, multiverse and security repositories. dCore does not utilize a sources.list file. The repositories accessed by dCore can be found in /opt/. Further clarification can be found in /etc/sysconfig/tcedir/import/debinx/. Each repository will have it's own debinx (Debian index database file), which gets updated when importing or updating SCEs.

  • Main repository: The /opt/debmirror file indicates the main Debian or Ubuntu repository used (eg. http://us.archive.ubuntu.com/ubuntu). This is clarified in /etc/sysconfig/tcedir/import/debinx/debinx (eg. ubuntu_wily_main_i386_Packages). Although the default Debian and Ubuntu mirrors provide reliable access, the /opt/debmirror file can be manually updated to reflect another mirror, preferably more local. The package database is also located in /etc/sysconfig/tcedir/import/debinx/. For example, an ~12 MB plain text database file named 'ubuntu_wily_main_i386_Packages'. This database file is retrieved from http://tinycorelinux.net/dCore/x86/. It is synced from the original Debian or Ubuntu repository, then pruned to speed up searching the large files.
  • Security repository: The /opt/securitymirror file indicates the Debian or Ubuntu security updates repository used (eg. http://security.ubuntu.com/ubuntu). This is clarified in /etc/sysconfig/tcedir/import/debinx/debinx_security (eg. ubuntu_wily_security_i386_Packages). The package database is also located in /etc/sysconfig/tcedir/import/debinx/. For example, a <1 MB plain text database file named 'ubuntu_wily_security_i386_Packages'. This database file is retrieved from http://tinycorelinux.net/dCore/x86/. It is synced from the original Debian or Ubuntu repository, then pruned to speed up searching the large files.
  • dCore repository: The /opt/tcemirror file indicates the dCore repository used (http://repo.tinycorelinux.net/). It is presently the only source/mirror. The plain text database file that contains all packages available from the dCore repository are listed in /etc/sysconfig/tcedir/import/debinx/PKGPREBUILTDEP. This are the same extensions available when using the sce-searchprebuilt command, which are imported using sce-import. These packages can be found online at http://tinycorelinux.net/dCore/x86/import/. The '*.deb2sce' files are dCore start-up scripts and the '*.tar.gz' files contain package data.

Additional Repositories

Additional repositories can be added by the user to access additional or updated software, such as backports. These additional repositories are added in /opt/debextra/, one file per repository, one line per file. Create a non-executable appropriately named text file containing the exact repository information for each repository added, similar to Debian's /etc/apt/sources.list. For example, create five plain text extra repository files in /opt/debextra/:

FilenameFile Contents
01http://ppa.launchpad.net/niko2040/e19/ubuntu wily main
02http://us.archive.ubuntu.com/ubuntu/ wily-backports main
03http://us.archive.ubuntu.com/ubuntu/ wily-backports multiverse
04http://us.archive.ubuntu.com/ubuntu/ wily-backports restricted
05http://us.archive.ubuntu.com/ubuntu/ wily-backports universe

On the next run of sce-import a debinx database file, named after the /opt/debextra/ file, gets created in /tcedir/import/debinx/ for every extra repository added. Each of these debinx files contains a database of packages available from that particular repository. Example of debinx files created from the above /opt/debextra/ repositories:


Each of these repositories will become accessible via the dCore sce-import Command to search and install the desired software. Note a /opt/debextra/ entry can be disabled by commenting out (use #) the desired entry, allowing selective use of extra repositories, example:

 #http://ppa.launchpad.net/niko2040/e19/ubuntu wily main

Visit the dCore Extra Repositories sub-forum for more information.

Repository Processing Order

Extra repositories in /opt/debextra/ take precedence over the standard Debian and Ubuntu repositories when importing software. As there is currently no automated mechanism to compare available software versions between repositories, these /opt/debextra/ debinx files are processed in ASCII sorting order for preferential processing. They can be named numerically, as the above example, or however the user wishes. The first correct package name hit when sequentially processing the repositories will be imported.

> Return to the dCore Wiki Welcome page

Noteworthy miscellaneous SCE-related files not discussed above:

  • /tmp/: The /tmp/ directory is used extensively by various dCore SCE management scripts to create temporary files and directories containing menu entries, temporary package lists, etc. Reviewing the main (sce-*) and helper SCE management scripts in /usr/bin and observing the /tmp/ directory when managing SCEs can be insightful. Only the most useful temporarily created files are discussed below, likewise some are also discussed in their respective dCore SCE Management Command section.
  • /tmp/.debinstalled: Lists all installed Debian or custom packages.
  • /tmp/.desktop: Lists installed extensions that have desktop files.
  • /tmp/.installed: Contains already run startup scripts.
  • /tmp/sceloadlock and /tmp/scelock: Examples of *lock files created when an applicable SCE management command is run. Used to prevent running simultaneous counterproductive commands, such as sce-import and sce-debpurge. The *lock files contain the PID of the locking process.
  • /tmp/tcloop/: Loading an extension loop mounts it's SquashFS file in a read-only sub-directory, from there these files are symbolically linked to the root file system for use. The /tmp/tcloop/ directory is the most efficient method to explore the full contents of a particular SCE, rather than manually dig through the system's entire file system.
  • /tmp/tcloop/<SCE_name>/usr/local/sce/<SCE_name>/SCE_import_summary: A summary of the import including date, new or re-import, whether the -R or -S flag was used and any additional packages, whether any dependency SCE(s) were used and the packages provided by these SCE(s) and a summary list of all packages contained within the extension.
  • /tmp/tcloop/<SCE_name>/usr/local/tce.installed: Shows all Debian packages and dependencies utilized to create that particular SCE.
  • /usr/local/: The directory is populated by the system during boot and contains many SCE extension related files.
  • /usr/local/sce/: One directory is created for each loaded SCE. It contains numerous files related to the SCE and it's dependencies.
  • /usr/share/applications and /usr/local/share/applications: These direcories contain the desktop files of installed applications.
  • /usr/local/tce.installed/: One start script per loaded Debian package, mostly as specified in the Debian package, often calls /usr/local/postinst/<PACKAGE> configure, may contain dCore-specific loading scripts which are pulled in as '.deb2sce' files from dCore repository.

> Return to the dCore Wiki Welcome page

QR Code
QR Code dcore:handling_extensions (generated for current page)