====== dCore Test Drive on a USB Stick (Beginners 101) ======
Take dCore for a spin to understand how it works! Each step is performed manually first before it is eventually automated. Altogether it will lead to a more or less complete installation and deeper understanding of dCore.

=== Burn ISO image to USB and use dCore-usbinstall ===
The easiest way to install dCore to USB is to download a dCorePlus ISO.  Below are some links to release candidate dCorePlus images:

[[http://tinycorelinux.net/dCore/x86/release_candidates/dCore-bionic/dCorePlus-bionic.iso|dCorePlus-bionic.iso]]

[[http://tinycorelinux.net/dCore/x86/release_candidates/dCore-bionic/dCorePlus-bionic.iso.md5.txt|dCorePlus-bionic.iso.md5.txt]]


[[http://tinycorelinux.net/dCore/x86_64/release_candidates/dCore-bionic64/dCorePlus-bionic64.iso|dCorePlus-bionic64.iso]]

[[http://tinycorelinux.net/dCore/x86_64/release_candidates/dCore-bionic64/dCorePlus-bionic64.iso.md5.txt|dCorePlus-bionic64.iso.md5.txt]]


[[http://tinycorelinux.net/dCore/x86/release_candidates/dCore-stretch/dCorePlus-stretch.iso|dCorePlus-stretch.iso]]

[[http://tinycorelinux.net/dCore/x86/release_candidates/dCore-stretch/dCorePlus-stretch.iso.md5.txt|dCorePlus-stretch.iso.md5.txt]]


[[http://tinycorelinux.net/dCore/x86_64/release_candidates/dCore-stretch64/dCorePlus-stretch64.iso|dCorePlus-stretch64.iso]]

[[http://tinycorelinux.net/dCore/x86_64/release_candidates/dCore-stretch64/dCorePlus-stretch64.iso.md5.txt|dCorePlus-stretch64.iso.md5.txt]]

In Windows, there are utilities like Rufus and Unetbootin, the latter also available for linux.  To install Unetbootin, add the following PPA if using Ubuntu:

ppa:gezakovacs/ppa

The simplest but least safe way to write an ISO to USB is using the dd command, but one must be absolute certain of their device name or data loss can occur.  To find which drives on the system are USB, the below command will list them:

<code>
for I in `ls /dev/disk/by-id/ | grep usb`; do E=`readlink /dev/disk/by-id/"$I" | sed 's/[0-9]*//g' | sed "s/[./]//g"`;  echo ""$E"_"$I"" ; done
</code>

If your USB device is /dev/sdb, then the following command will write the dCorePlus ISO to the USB:

<code>
dd if=dCorePlus-stretch64.iso of=/dev/sdb
</code>

Now you are ready for the initial boot of the USB to set up the final install.  Reboot and set up internet connection.  Then issue the following commands from a terminal window:

<code>
sce-import dCore-usbinstall
sce-load dCore-usbinstall
sudo dCore-usbinstall
</code>

The USB will not be mounted after booting with the ISO written to it, so the same USB can be used to install to.  dCore-usbinstall will guide you through choices between x86 and x86_64, BIOS and UEFI, release and release candidates, and which dCore port you wish to install.  It will create a bootable USB formatted with ext2 and the TCE directory will be located on the USB and used during future boots. 

The following below is a more hands-on method of installing dCore to USB.

=== Manual install to USB ===
dCore will be installed on a USB-stick. The system basically consists of the following files:
  - Linux kernel and initial RAM disk, typically named 'vmlinuz' and 'core.gz'
  - an archive 'mydata.tgz' containing persistent user data
  - a folder 'sce/' containing extensions (sce-archives)
  - lists of files for loading on demand or on boot, respectively

All these files or folders may well reside on any type of file system, even ones not respecting Linux permissions. 

===== Optional Steps =====
The user data in '/opt/' or '/home/' could well be stored on a partition of its own with a Linux file system. We shall not endeavour to doing so here, however.
===== Building blocks for a basic desktop installation =====
As [[dcore:core_concepts_explained|explained]], dCore consists of a Linux kernel, a root file system in RAM, an init-process that governs the behavior of the kernel, BusyBox utilities, a choice of extensions and some persistent user data. What all is needed to get started with a basic desktop installation?

  - In order to install applications, one will need network connectivity. The easiest, of course, is wired but also wireless can be used.
  - dCore by itself provides a shell running in a virtual console. In order to start a graphical desktop, one must, of course, first have X11 with the necessary video drivers.
  - X11 would allow one to start graphical programs from the command line. In order to have some sort of graphical starting mechanism as well as resizeable windows, a window manager needs to be installed. [[http://en.wikipedia.org/wiki/FLWM|FLWM]] is used, like in TinyCore, as basic standard but of course this can be changed at will.
  - Furthermore, a configurable dock allows to start applications from their icons; [[http://lxlinux.com/wbar.html|Wbar]] is used as basic standard.
  - Some applications demand a tray (or notification area) for which [[http://stalonetray.sourceforge.net/|Stalonetray]] is a suitable lightweight candidate.
  - International users will need to take care of localisation questions.

=== Boot Codes and Persistence ===
All the above should start automatically so the system boots into a graphical desktop. This necessitates the appropriate boot codes as well as some persistent storage for configuration files.
=== Additional Software ===
Additional software, including system software, is available by importing and loading extensions.
===== Preparation =====
These notes were created by using computers already with standard Ubuntu Linux installations; notably Grub2 as boot-loader. It should be trivial to adapt the outline to other boot loaders or environments.
  - Check the [[http://forum.tinycorelinux.net/index.php/topic,17870.0.html|forum]] for recent release announcements. Look out for kernel version (3.16.6 for Trusty in this case here).
  - Download files from 'http://tinycorelinux.net/dCore/x86/release/dCore-trusty/':
    - Kernel: 'vmlinuz-trusty'
    - InitRD: 'dCore-trusty.gz'
As usual, double-checking MD5-sums is worthwile.
===== First Boot =====
Use a regular USB-drive with FAT32 file system. The choice of file system is purposeful as it should provide insights into the dependency of dCore on the file system. 
This example uses the Grub2 boot-loader of the harddisk. Other set-ups will work just the same, of course.

¡Warning: dCore will detect and use an existing swap partition on harddisk. So make sure that there is no hibernation file saved in swap from some other OS on the computer!

  - Put the kernel and the initrd in the root of the USB-drive.
  - Boot your computer into a Grub2 shell and make it load dCore-Trusty by the following commands.
    - ''set root=(hd1,msdos1)''
    - ''linux /vmlinuz-trusty''
    - ''initrd /dCore-trusty.gz''
    - ''boot''
Adapt the first step to your specific situation; ''ls'' gives information about available drives.

Using Syslinux 3.63-3.70 from the USB-stick, the boot stanza is ''/vmlinu~1 initrd=/dcore-~1.gz'' (cf. [[http://www.syslinux.org/wiki/index.php/Common_Problems#What.27s_the_real_name_of_that_file.3F|explanation]] for the 8.3-file names.)

And voilà! You are presented with a GNU/Linux command line system. This all happens incredibly fast (5 seconds on a legacy netbook).
=== Basic Properties ===
Some note-worthy facts that will be changed in the definitive set-up:
  * There is one single virtual terminal tty1.
  * There is a standard user "tc" who can gain root privileges by 'sudo'.
  * The host name is "box".
  * Language and keyboard are set to [[http://en.wikipedia.org/wiki/British_and_American_keyboards|US-English]].
  * There is no persistence at all. Changing any file will happen only on a temporary file system in RAM which will be discarded at shut-down. Rebooting will give you the absolutely identical system.
  * Yes, the beeping when pressing the TAB-key is annoying, indeed! (You can get rid of it temporarily by issueing ''rmmod pcspkr''.) 
===== Extensions =====
Let's play around a bit in order to get better acquainted with some of the guiding principles of the way dCore operates! As a first thing, one probably wants to have something more than just a bare command line system.

=== Assumptions ===
For simplicity a wired network connection is used. Assuming a working Ethernet port, the connection is automatically set up at boot via DHCP.
==== Extensions: sce-import & sce-load ====
The command ''sce-import sl'' will ...
  - check the repos for packages whose name begins with "sl" and then ask you to specify the right one.
  - ask you to certify that you, being of sound mind and body, do indeed mean to import that specific package.
  - gather the dependency information from the repos and allow you to review the list of packages that will be included into the extension 'sl.sce'
  - ask you to  confirm that now the time has come to finally add some steam to dCore!
  -  download the packages and merged them into a dCore extension. The appropriate file will be saved under '/tmp/tce/sce/' and the down-loaded Ubuntu packages under '/tmp/tce/debs/'. (As said before, this is only on a temporary file system in RAM.)

From the sce-directory, the extension can be loaded by the command ''sce-load sl''. Now you can let the steam blow by the newly added command ''sl''; also try the options ''-a'', ''-l'', ''-F'' while you are at it or also mis-spell it as ''ls'' ... . (In case you should wonder what the name "sl" signifies, check out the [[http://manpages.ubuntu.com/manpages/precise/en/man6/sl.6.html|man page]].)

NB: adding the option ''-n'' to ''sce-import'' makes it proceed in a non-interactive fashion.

=== About Loading Extensions ===
What does "loading" an extension mean? Each extension consists of a SquashFS-file with ending '.sce' that is stored under 'sce/' in the tce-directory. The command ''sce-load'' mounts this file system under '/tmp/tcloop/' as is easily detected by ''mount''.

Let's explore the contents for once! '/tmp/tcloop/sl/' contains
<code Bash>
etc/: ld.so.conf.d/
lib/: i386-linux-gnu/  ld-linux.so.2
usr/: games/  lib/ local/
</code>
Clearly, this whole file system is layed over the root file system, making all files available.

'/tmp/tcloop/sl/usr/games/' contains ''LS'', ''sl'' and ''sl-h''
which all have their executable bit set. Luckily, '/usr/games' is included in the PATH.
In case you should wonder about the commands ''LS'' and ''sl-h'', just try them out!
==== Persistence for Extensions ====
There are two kinds of persistence to deal with. First there are the extensions. As [[http://wiki.tinycorelinux.net/dcore:core_concepts_explained#core_specifics|explained]], extensions come with their own file system (à la SquashFS), so they should work even with FAT32; however, there is a twist to it as we shall find out soon.

Home storage seems to be a different case as it does depend on a POSIX compatible file system being available. We shall deal with that case later.

=== tce-setdrive ===
After a reboot, the extension //sl// is not available anymore because it had been stored under '/tmp' in RAM which got discarded. To be cautious, you may want to verify that the command ''sl'' does not work anymore, indeed.

Let's set up persistent storage for extensions! The command ''tce-setdrive'' sets up persistent storage for the extensions; it will ...
  - allow you to choose the hard-drive (choose the USB-drive for the moment).
  - create the directory 'tce/' in the root of the partition, together with sub-directory 'sce/' and two files named 'mydata.tgz' and 'sceboot.lst'.
From now on, the imported extensions will be stored under 'tce/sce/'.

=== Unpacking in RAM ===
Trying to import //sl// by a simple ''sce-import sl'' quits with an error message, complaining that the tce-directory resides on a Windows filesystem. Furthermore it suggests to try again with the ''-r'' flag to unpack files in RAM. Indeed, 'tce' may well reside on a Windows filesystem, but in order to unpack and repack packages, a POSIX compatible file system is necessary. Given sufficient RAM, this can be provided in an ephemeral fashion. 

''sce-import -r sl'' will import //sl// as an extension into the tce-directory. ''sce-load sl'' will mount the extension and provide you with the 'sl' command to play with.

=== Graphic Drivers ===
The extension //graphics-<KERNEL>-tinycore// adds some resolution types which is nice for eg. netbooks. Try it out and see if it changes your resolution or that of your computer to the better! In case it does, treat is as part of the standard installation even if it is not always explicitly mentioned.
=== A Graphical Environment ===
Let's venture on to get a graphical desktop up and running from our USB-dCore! Import and load the extensions //xorg-all// and //flwm// one by one (also //graphics-<KERNEL>-tinycore// if desired). //xorg-all// is a huge meta-package, consisting of all available X-drivers; later on, one may want to reduce that.

As an aside, take note that the //Xprogs// extension -- which is mentioned in earlier documentation -- has become a [[http://forum.tinycorelinux.net/index.php/topic,18384.msg112091.html#msg112091|dependency]] of any //xorg//-extension.

The command ''startx &'', however will fail with the rather uninformative message that the connection to the X server was lost. For a comparison, launching ''sudo startx'' will present a graphical Xterm in full-screen without decoration but with a functional mouse cursor. Exit with ''Ctrl+D'' back to the command line and see if we can shoot the trouble!

Inspecting 'startx', one can see that it calls '~/.xinitrc' which ...
  - reads in the variable 'DESKTOP' from the file '/etc/sysconfig/desktop', specifying the chosen desktop manager (Flwm in our case).
  - starts the desktop manager, dumping errors to '/tmp/wm_errors'.
  - calls '/usr/bin/setupdesktop' as well as '~/.setbackground', '~/.mouse_config' provided the latter exist; the same it does with all files in the directory '~/.X.d/', waiting until all of the called programs have terminated.
 
Obviously, the information which desktop manager to call is missing for the moment. So create a file with the appropriate content by issueing 
  sudo su -c "echo flwm > /etc/sysconfig/desktop" 

Now try again with ''startx &'' and admire a shiny dCore desktop!
At the moment, it does not contain much but by clicking anywhere on the desktop, an Flwm menu opens, giving you access to terminal, editor etc. After a playful moment, exit back to the command line prompt.

===== Automatically Boot Into a Graphical Environment =====
The previous steps have to be repeated after every boot:
  - set the tce-directory
  - load the desired extensions
  - edit configuration files as needed
  - issue startup commands for applications

More specifically:
  - ''tce-setdrive''
  - ''tce-load'' to load the extensions xorg-all, flwm (optionally also graphics-<KERNEL>-tinycore)
  - '/etc/sysconfig/desktop': add //flwm//
  - call ''startx &''

The only step so far in direction of persistence has been to set up a tce-directory in order to avoid having to down-load every extension anew. Let's tackle the other issues one-by-one! Later on, we shall also provide persistent home storage. 

Just for the graphical environment, these steps can be automated very easily.

==== Boot Parameter 'tce' ====
The [[wiki:boot_options|boot parameter]] ''tce'' specifies the partition containing the tce-directory (in its root directory or else the directory must be explicitly specified), eliminating the need for calling ''tce-setdrive'' manually. So one wants to enhance the kernel boot stanza by adding ''tce=sdXn'' which stands for the device (sdb1 in my case). Take note that the syntax does //omit// the usual ''/dev/'' from the device name!

In the case of a USB-drive, however, one has to add the additional code ''waitusb=5'' to the boot stanza because otherwise dCore will simply rush trough too fast, even if the USB device needs more time to get ready. It is possible that some slower USB devices need a longer time-out; adjust the value as necessary!

All in all the Syslinux boot stanza has grown to ''/vmlinu~1 waitusb=5 tce=sdX# initrd=/dcore-~1.gz''. As a result, the partition is mounted and the tce-directory is linked as '/etc/sysconfig/tce'.

=== tce-setdrive ===
In our approach here it is necessary to call ''tce-setdrive'' manually because we had started without a tce-directory. After having created one, we point dCore to it by means of the ''tce'' boot-code. 

If one quickly wants to get to a dCore-installation, one will set up boot-loader, kernel and initrd and include the ''tce'' boot-code at the first start. dCore then recognizes that the tce-directory does not exist yet in the specified location and thus calls ''tce-setdrive'' by itself.

=== Outlook: UUID, LABEL ===
For the sake of completeness, we would like to point out that the partition can also be specified by uuid or label (cf. the [[http://distro.ibiblio.org/tinycorelinux/faq.html#pendrives|FAQ about pendrives]]). This is highly recommended for USB-installations as one cannot know under what name the USB-stick will be recognized by the system in general. To keep matters simple, however, we leave this out.
=== Automatic Extension Loading: 'sceboot.lst' ===
The tce-directory contains a text file 'sceboot.lst' which specifies extensions that should automatically be loaded after boot, eliminating the need for calling ''sce-load'' manually. So let's put a list of desired extensions into that (persistent) file by the following command! (The option '-e' forces 'echo' to correctly interpret the escaped newline characters.)
<code Bash>
echo -e "xorg-all\nflwm" > /etc/sysconfig/tcedir/sceboot.lst
</code>

=== Boot Parameters for '/etc/sysconfig/' ===
The folder '/etc/sysconfig/' contains files whose respective content is taken from boot codes. Among others, there can be the following files (shown here with their respective boot code and, if applicable, standard values in parentheses):
  * 'desktop': desktop; window manager, as seen above
  * 'tcuser': user ("tc")

In an analogous fashion, the hostname in '/etc/hostname' may be set by the ''host'' boot-code (with standard value "box").

Combining these options into a single (here: Syslinux) boot stanza does make it desirable to have it included in the boot-loader menu, indeed. You may do that or also keep on typing it in manually a few more times only (promised!).

''/vmlinu~1 waitusb=5 tce=sdX# desktop=flwm user=<USER> host=<HOST> initrd=/dcore-~1.gz''

This boots into a graphical desktop (''startx'' is automatically called). The boot time is prolonged by having each extension loaded, especially //xorg-all//.

Clearly, the codes ''user'' and ''host'' can be omitted in the future but try them out once just for kicks! Omitting the 'desktop' entry will drop one back to the command line after an unsuccessful launch of the graphical desktop (as explained above).

=== Removing Extensions: sce-remove ===
In case one does not need an extension anymore, one could simply delete its respective file from the tce-directory. However the command ''sce-remove'' is  specifically designed for this task and does some more house-keeping than simply removing the files. 
Try it with the //sl// extension (even though, it is a pitty, isn't it?)!
===== Persistence for Regular Files =====
Other than persistence for extensions there are two more cases of persistence, namely home storage and system configuration files. Both cases pertain to regular files as opposed to extensions which consist of an entire file system themselves. 

Thus a simple solution for persistent home storage is to have it on a regular file system that gets mounted; the same may be done with '/opt/'. This is the regular approach for a fully fledged dCore installation. It necessitates a POSIX compatible file system, of course. 

Let's venture on with our minimalistic set-up, however, where only a FAT32 system is available! As promised, this adventure will teach us more about dCore. Furthermore, our dCore set-up already provides us with all the necessary mechanisms for persistent user data; we just have to start making use of them.

Providing a POSIX compatible file system is not a problem; as usual, it is wrapped into an archive that can be extracted to RAM which can be stored on any kind of file system. Since ''/home/'' and ''/opt/'' essentially contain user data, these folders are combined in one file system.

There is one major draw-back to this approach; namely that files actually "live" in RAM and are only copied to persistent storage upon request, for instance at shutdown. Seen the other way, one gains the choice if a session should be stored (backed up) or not.

=== Note About Persistent File Systems ===
If one wanted to keep persistent storage on a separate file system, the Kernel would have to know about its location already during the boot process. For specifying a file system, the [[http://distro.ibiblio.org/tinycorelinux/faq.html#bootcodes|boot codes]] ''home'' and ''opt'' are used.

Why prefer this approach? One major advantages is that it avoids having to un-wrap yet another, possible quite large SquashFS for the user data.

=== Terminology ===
Oftentimes, the usage of persistent file systems is coined "persistent home" or "persistent opt", respectively. We use the term persistent here in the sense of not ephemeral.
=== 'mydata.tgz' ===
All user files are wrapped up in the archive file 'mydata.gz' that resides in the root of the tce-directory. This file does not need to be touched as its content is un-packed by dCore, providing the home- as well as the opt-directory.

=== '/opt/.filetool.lst' ===
The choice of files to be extracted is stored in the file '/opt/.filetool.lst'.
Initially, it contains only the name of the folders 'opt' and 'home'. Two remarks about this content:
  * Notice the missing slash ('/') in front of the folders. Currently it seems there is no need for this anymore as also files with absolute path are backed-up, indeed (cf. a [[http://forum.tinycorelinux.net/index.php?topic=6413.0|forum entry]] from 2010, however). So better be safe than sorry and leave out the initial slash. It does save energy, too!
  * Also notice that white-space is //not// stripped from the end of a line.
  * The seeming self-reference, namely telling to backup '/opt/' in the file '.filetool.lst' which is stored under '/opt/ itself does no harm. (Think about it, draw a flow-chart or take a break!)

=== '/opt/.xfiletool.lst' ===
Complementary, there is '.xfiletool.lst' which lists files to be excluded from the backup. This file obeys to different semantics than '.filetool.lst'. Indeed, the entries are [[http://www.gnu.org/software/tar/manual/tar.html#SEC109|patterns]] as used by the command ''tar''. Briefly put, they describe the **ending** of a file, including its path.
=== Backup ===
When exiting from the graphical desktop, a selection window is presented with options to shutdown, reboot and a drop-down menu for the backup options. We shall discuss these in a moment.

Exit back to the command line (with no backup being performed) and let's create two files in order to see this all in action!
<code Bash>
echo 'Personal file' > ~/Pers-test
echo 'Opt file' > /opt/Opt-test
sudo su -c "echo 'Configuration file' > /etc/Conf-test"
</code>

If one were to reboot now, these files would be lost because backup does not happen automatically at shutdown but must be triggered by the user. Since 'Pers-test' and 'Opt-test' are stored under '/home/' or '/opt/', respectively, they are already marked for backup. The file '/etc/Conf-test', however, must be included into '.filetool.lst' anew by 
  echo etc/Conf-test >> /opt/.filetool.lst

Launching ''backup'' will ...
  - ask if the backup location is correct.
  - back up the files into 'mydata.tgz'

=== 'filetool.sh' ===
Since ''/usr/bin/backup'' simply is a wrapper around ''/usr/bin/filetool.sh'', we can take a closer look at its proceedings by calling ''filetool.sh -bv'' which will **b**ackup and produce a **v**erbose listing. As expected, all files under '/home/' and '/opt/' are listed as well as '/etc/Conf-test'. These file now persist across a reboot.

NB: do not mistake 'filetool.sh' for 'filetool', the latter being a graphical wrapper of the former.

=== Restoring Files ===
If a file is erroneously deleted then it can be restored from 'mydata.gz', provided no backup has happened yet. Let's for example ''rm ~/Pers-test'' and restore it by ''filetool.sh -rv''.

=== Backup from the Graphical Desktop ===
Shutting down the graphical desktop, the backup command can be triggered in the selection window.

=== Safe Backup ===
In the graphical desktop, one can choose "Safe" as backup option. This means that an already existing 'mydata.tgz' is copied to 'mydata**bk**.tgz' before overwriting it with the new state.
This is equivalent to ''filetool.sh -s''.

If need be, the old version 'mydatabk.tgz' can be substituted for the new version or stored away under a different name.

=== Getting Rid of Persistent Files ===
For files in '/home/' or '/opt/' it suffices to simply delete them and trigger a backup. Files like '/etc/Conf-test' must be excluded from '.filetool.lst' in addition. This can be done by launching ''vi /opt/.filetool.lst'', moving to the desired line with the arrow keys and hitting the 'D'-key twice. Save and quit by hitting ''Esc : w q'' or quit without saving by hitting ''Esc : q !''. Of course, one may achieve the same in the graphical desktop by launching the editor (which is provided by the //Xprogs// extension, BTW; cf. the [[#A graphical environment|aside]] above).

Now get rid of the three test files for good and go take some [[https://en.wikibooks.org/wiki/Learning_the_vi_Editor/BusyBox_vi|lessons in Vi]] if necessary!

=== Note about 'mydata.tgz' and '.filetool.lst' ===
The location or, more precisely, the full path and name of the file used for storing persistent user data, is read from '/etc/sysconfig/mydata' which can be specified through the [[http://distro.ibiblio.org/tinycorelinux/faq.html#bootcodes|boot-code]] 'mydata'.

Similarily, the choice of files to be extracted from persistent user data into the root file system can be specified by an arbitrary file named 'yyy.lst' within the given tce-directory through the [[http://distro.ibiblio.org/tinycorelinux/faq.html#bootcodes|boot-code]] 'lst'.

===== Automatically Run Commands =====
The [[#Automatically boot into the graphcial environment|above catalogue]] of desirable features has only been partially completed. The crucial point being "issue startup commands for applications". 

Before taking a closer look at it, let us make clear that there are several distinct situations where one may find need for automatically running commands.
  - During system startup: essential system commands (with root privileges) that serve for "circumventing" some peculiarities of dCore imposed by its ephemeral philosphy. dCore provides a special mechanism for this case, taking the role of '/etc/rc.local' in standard Debian.
  - Similarly during system shutdown.
  - When launching a shell.
  - When starting a graphical desktop: auto-starting applications (with user privileges).

dCore provides the following mechanism adapted to these situations:
  - '/opt/bootsync.sh' and '/opt/bootlocal.sh' (cf. below for an thorough discussion)
  - '/opt/shutdown.sh' (ditto)
  - '~/.ashrc' can be used as usual
  - '~/.xinitrc' calls alls cripts under '~/X.d/', so individual auto-start settings can be stored there.
=== 'bootlocal.sh', 'bootsync.sh', 'shutdown.sh' ===
These files, residing in '/opt/', are shell scripts, interpreted by an Almquist shell ('ash').
  * 'bootsync.sh' is executed at system startup. Its commands are meant be terminated before moving on; i.e. they should //not// be made running in the background by adding a ampersand sign ('&'). As such they may influence the duration of the boot process.
    * 'bootlocal.sh' is meant to be the //last// command called by 'bootsync.sh' and it //is// run in the background. As such the system does not wait for them to complete before it moves on with the boot-process.
  * 'shutdown.sh' is similar to 'bootsync.sh' but it does in addition do some house cleaning of files matching the patterns from '/opt/.xfiletool.lst'.

So system startup commands that need to be completed before other processes can be called go into 'bootsync.sh'. Commands that have to run during startup but where nothing depends on them go into 'bootlocal.sh'. Individual shutdown commands go into 'shutdown.sh'.

These files run with root privileges and, accordingly, can only be manipulated as root user, so one must use ''sudo vi'' (or ''sudo editor'' in the GUI).

=-= Simple Examples ===
Let's, for example, generate a symbolic link '/tce' in the root of the file system to the tce-directory '/etc/sysconfig/tcedir/'. Furthermore, we want to remove the //pcspkr// kernel module in order to get rid of that bleepin' beeping!
The following commands will add appropriate lines to '/opt/bootlocal.sh'.
<code Bash>
sudo su -c "echo 'ln -s /etc/sysconfig/tcedir/ /tce' >> /opt/bootlocal.sh"
sudo su -c "echo 'rmmod pcspkr' >> /opt/bootlocal.sh"
</code>
Don't forget to trigger a backup before rebooting!

=== Note About Blacklisting Kernel Modules ===
The black-listing of kernel modules can also be achieved via [[http://distro.ibiblio.org/tinycorelinux/faq.html#bootcodes|boot codes]]. In case one should not have been able to say aloud "bleepin' beeping" five times in a row without mis-spelling, one should include ''blacklist=pcspkr'' (also compare the discussion in the [[http://forum.tinycorelinux.net/index.php/topic,12133.0.html|forum]]) into the boot-stanza.
===== Summary =====

=== Synopsis ===
This sample set-up addressed the following issues:
  * Running a basic dCore installation from a FAT32 file system
  * Persistently importing extensions into the tce-directory
  * Booting into a minimal graphical desktop 
  * Using boot codes to set system variables (especially ''desktop'')
  * Automatically loading extensions via 'sceboot.lst'
  * Persistently storing user data in 'mydata.tgz' for selected files listed in '.filetool.lst'
  * Automatically running system command during startup or shutdown
=== Outlook ===
Where to head from here? Check out the page about
[[dcore:installations|installations]]
and see if there is one that suits your needs. 
If not, you might want to produce one of your own and document it here in the wiki.
Contributions are very welcome!

This sample set-up leaves desire, among other things, for ...
  * handling the boot-loader from within dCore
  * [[dcore:installations#localisation|localisation]] (in the command line as well as in the X environment)
  * [[dcore:wireless_set-up|wireless connections]]
  * [[dcore:handling_extensions|updating extensions]]
  * [[dcore:installations#maintenance|upgrading the system]]

=== Further Reading ===
There are several explanations in the [[dcore:welcome|wiki]] that provide very informative reading after having followed all along. A recommended track consists of a [[dcore:basic_desktop_installation|basic desktop installation]] followed by a [[dcore:migrating_from_flwm_to_lxde|switch to LXDE]]. A study of the techniques for [[dcore:handling_extensions|handling extensions]] is pretty mandatory.

**[[http://wiki.tinycorelinux.net/dcore:welcome|> Return to the dCore Wiki Welcome page]]**