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

This is an old revision of the document!

Install dCore on Hard-disk

dCore may well be installed to hard-disk in the same frugal way as on a USB-stick. Here we consider, though, a full-fledged installation with persistent '/home/' and '/opt/', Syslog, multiple TTYs and some more goodies. There are quite some choices made and this exposition will give a basic, functional desktop. All of it can later be adapted to once likings.

The persistent directories will reside directly on hard-disk instead of being included into 'mydata.gz'. The advantage over the frugal installation is that there is no need for packing and un-packing those two, possibly quite large directories.


For the sake of simplicity, let's assume that we have a partition that is entirely dedicated to dCore. This is not mandatory, as dCore does not scatter its file system over the partition. It may also be a data partition that is accessed by other file systems.

Create a partition 'sdX#' where dCore should reside and give it a suitable label like e.g. “dCore”. Format it with a POSIX compatible file system, e.g. ext{2,3,4}. Take note of the drive and partition number as well as of the label.

dCore OS-files

Create a directory 'boot/' in the root of that partition and copy the kernel and initrd files into it. They are available at the download repository.

Base extensions for wireless connection (optional)

Follow the instructions for side-loading the base extensions for wireless connection if needed.

Note that before doing so, you must have started the system once so as to have the basic directory structure set up. Restart the system by issueing reboot.


The task of installing and configuring a boot-loader is a generic one. We shall not cover it in full breadth but simply point out a few special cases together and some general strategies.

For the sake of simplicity, we assume that some Linux boot-loader is already installed in the MBR (master boot record) of the hard-disk. This is the case if another GNU/Linux-installation is used on the computer as well. If no boot-loader is installed on the hard-disk then the situation is too complex to give general recommendations. The reader is pointed to the over-view page of the Archlinux-wiki for a starting point.


Let's name Grub, Grub2 and Extlinux (Syslinux) among the available boot-loaders. The original author of this article has a strong preference towards Extlinux, especially in combination with dCore.

Grub2 comes as default boot-loader with Ubuntu as of 12.04. Unfortunately, its configuration files are dynamically handled by update-grub which must be triggered from the Ubuntu installation. Thus it is not so simple - but nevertheless possible as we shall see - to manipulate the configuration from outside the Ubuntu installation.

Extlinux is a light-weight nonetheless very flexible boot-loader. Its main advantage over Grub2 is that its boot-menu configuration is contained in one single file 'extlinux.cfg'. Thus adapting the boot-menu is a simple task of editing entries. Since dCore works quite a lot with boot-codes, this can simplify the work-flow.

Grub (legacy) is quite comparable to Extlinux; the main difference being that Grub, as well as Grub2, can also access files outside the partition it is installed on.

Grub2 in MBR

An ideal case would be to have one initial boot-loader installed in the MBR to chain-load boot-loaders installed in PBR (partition boot record) each. However there is a twist to it, namely that Grub cannot chain-load to Extlinux/Syslinux(*). Thus if Grub is the main boot-loader then one would have to install Grub in the MBR of the dCore-partition to chain-load it (untested).

(*) Contrary to what the source claims, this did not work for a primary partition either.

As a much simpler method, we shall introduce a new menu point to launch dCore and then manipulate the configuration files from within dCore in a consistent way.


Grub2 does not maintain a single configuration file like Grub legacy used to but instead keeps a bunch of configuration files. Upon request, i.e. by calling update-grub, it pulls all the information together and generates the file '/boot/grub/grub.cfg' that is accessed by the boot-loader. The following steps are performed from the original Linux installation.

The individual configuration files are located under '/etc/grub.d'. Adapt the following lines to your likings and add them to '40_custom'.

menuentry "dCore Trusty" {
    search --label --set=root "dCore"
    linux /boot/vmlinuz-trusty tce=LABEL="dCore" home=LABEL="dCore" opt=LABEL="dCore" user=<USER> host=<HOST> desktop=flwm tz=<TIMEZONE> syslog multivt
    initrd /boot/dCore-trusty.gz
  • Instead of labels, one may also use the UUIDS of the partition with an equivalent syntax for the tce, home and opt boot-codes. The first line must read
    search --fs-uuid --set=root <UUID>
  • For the time zone, please refer to the wiki page about time zone or the man-page of 'tzset', explaining the string format (e.g. “CET-1CEST,M3.5.0,M10.5.0/3” for central Europe). The BIOS-time needs to be set to UTC.
  • If you intend to use a different window manager than Flwm, adapt the respective boot-code. For starters, however, Flwm is a good choice and it can be changed later on if desired.

Finally, run sudo update-grub to up-date 'grub.cfg'.


There are two options for changing the boot menu later on. If one does not mind the hold-up then one can boot into the original Linux installation, change the file '40_custom' and update Grub. This is especially advisable if one wants to add new menu entries for e.g. specific configurations of boot-codes.

From dCore itself, one may well change the file 'boot/grub.d/grub.cfg' after having made it writeable by chmod u+w. This is especially useful for quickly adding or changing some boot-codes. However, these changes would get over-written by a subsequent update-grub from the original Linux installation. In order to prevent that from happening, one must add the same changes to the file '40_custom'. Running update-grub at a later point in time will then create a consistent 'grub.cfg'.

First launch


First test if everything works fine.

  • mount should show the dCore-partition mounted three times, once as '/mnt/sdX#/', '/home/' and '/opt/' each.
  • '/home/<USER>' and '/opt/' should contain a few files, some hidden
  • '/etc/sysconfig/tce-dir' should be a symbolic link to '/mnt/sdX#/tce/'

In case any of the above should not hold then …

  • verify that the kernel and initrd files are in place.
  • check the label in the boot stanza by running blkid.
  • verify that the essential boot stanza (containing only kernel and intird) works in principle by launching it from the shell of the boot-loader (Grub can use tab-completion which is helpful here).


The specified user is given the hard-coded password “tcuser”. In general, it does not make much sense to specify an individual password because it is not straight-forward to keep it safe. There are some suitable boot-options available, though.


In principle, files under '/home' or '/opt' do not have to be included into 'mydata.gz' anymore. Any persistent file outside these two directories, e.g. configuration files under '/etc/', must be listed in '/opt/.filetool.lst', however, and such files only are backed-up upon request.

Thus it makes sense to clear out '/opt/.filetool.lst' (but leave the empty file in place!). However, the backup mechanism does not handle an empty 'mydata.gz' well. So it will automatically add “opt/.filetool.lst” to the file upon first occasion. Do not worry about that (but notice the omitted initial slash!). Launch backup for a first time then. (Recall that shutdown from the command line would not perform it on its own.)

Wireless (preliminary set-up)

Follow the outline about setting up a wireless connection from the command line if no Ethernet connection is available.

X Server

The extension xorg-all is a meta-package that will pull in all available X drivers. It is good for getting the system up and running; however due to its large size, one may later want to reduce to the necessary drivers for the specific system.

The standard window manager ist Flwm in the top-side variant as provided by the package “flwm_topside”. Other than the original variant, it features a horizontal window bar. For smaller wide-screens, however, the original may be better suited.

For the moment, import the extensions graphics-<KERNEL>-tinycore, xorg-all and flwm or flwm_topside with the option -b set, marking them for loading at boot-time. After a reboot, dCore starts a graphical desktop.

Desktop environment

Strictly speaking, the desktop environment is almost complete now. Getting acquainted with Flwm may prove helpful. For instance, it provides a (compiled-in) set of keyboard short-cuts.

For the standard *Core-desktop, we shall add Wbar. Though, strictly speaking, there is no real need for it as everything can be accessed through the Flwm-menu. More important is the addition of a tray as there are some applications that do not run if they cannot detect any such; we use Trayer.

Simply importing wbar and trayer with the -b option will suffice for Wbar; for Trayer, create the following file '~/.X.d/trayer'.

/usr/bin/trayer --edge right --align right --widthtype request --heighttype request &

This will create an empty, almost invisible tray in the lower right corner of the screen that will grow as needed.

Wireless (final set-up)

Follow the outline about running wireless in the graphical desktop to switch from a preliminary to the final set-up.


Now that one has a functional desktop, one can move on in different directions. The welcome page provides additional information.

  • Some hardware may require special attention which is provided in the page about system software.
  • One may want to adapt the desktop environment by exchanging window manager or even importing a complete desktop manager. Such topics are outlined in the page about the X-desktop.
  • Importing and loading desktop applications, e.g. a web-browser, an office suite etc., are discussed in the page about extensions.
  • Finally, localisation is a topic of its own that deserves special mention.
  • One most certainly wants to get rid of the bleepin' beeping on the console.