Subsections of Startup & System Settings

Configuring the Boot Process

This page describes the boot process and how to configure your GoboLinux system by editing the configuration files used for startup.

General architecture

The BootDriver script (/Programs/BootScript/<version>/bin/BootDriver) manages boot-related tasks. The init program (from the Sysvinit package) running as PID 1 calls BootDriver as specified in /System/Settings/inittab.

BootDriver first loads the boot theme file specified in /System/Settings/BootOptions. Then BootDriver runs the appropriate boot script for the task at hand (startup, shutdown, etc.)

Boot Scripts

GoboLinux boot scripts initialize and configure the system, manage daemons, and perform shutdown. They are located at /System/Settings/BootScripts.

  • BootUp, the primary startup script, is invoked when you turn on the power and the system boots. It contains generic initializations common to most Linux systems. Additional scripts are provided to support particular boot scenarios.
    • Console runs BootUp and performs initializations required for a console session.
    • Graphic runs BootUp and starts X to provide a login window.
  • Shutdown is the primary shutdown script, analogous to BootUp. It is used by the following termination scripts:
    • Reboot runs Shutdown to terminate system services then reboots the machine.
    • Halt runs Shutdown and turns off the power, if possible. Otherwise it halts the processor.

Each of these scripts contains lines of the form:

Exec "Message..." SomeCommand [ parameters ]

For example, to adjust the keyboard delay and repeat rate in the console, you can add this line to /System/Settings/BootScripts/Console:

Exec "Making keyboard speedy..." kbdrate -r 30 -d 250

GoboLinux also provides “boot tasks” as a more sophisticated way of managing services.

Configuration options

When GoboLinux boots, the boot scripts launch programs to configure the keyboard, set the system clock, initialize the network, etc.

The parameters for calling these programs are placed in /System/Settings/BootOptions and /System/Settings/NetworkOptions. Both files contain entries of the form:

Option=value

Note that no space is allowed before or after the = character. This is shell syntax, allowing the options to be imported into the boot scripts using the source command.

The following sections document options available in /System/Settings/BootOptions and /System/Settings/NetworkOptions.

Clock mode

GoboLinux needs to know if your hardware clock is set to GMT or local time. Specify this by editing the ClockMode option. Set ClockMode=GMT if your hardware clock is set to GMT. Set ClockMode=LocalTime if your hardware clock is set to local time.

For obtaining time zone information, Linux applications rely on information provided by Glibc, the C library. Glibc, on its turn, uses the localtime symlink in its Settings directory (/Programs/Glibc/Settings/localtime) to indicate the active time zone. This symlink is created by the installer according to the time zone you selected. You can set this setting manually, by pointing the localtime symlink to a different file under /Programs/Glibc/Current/Shared/zoneinfo.

The ClockMode information is used for the hwclock utility, which is launched at boot time through the SetClock task.

Console setup

Fonts

Fonts in GoboLinux are stored under /System/Index/share/consolefonts and /System/Index/share/fonts. They provide character typefaces for the Linux console, the X Window System, and ghostscript, the Linux postscript interpreter.

Font path configuration for X can be found in /System/Settings/X11/xorg.conf and /System/Settings/fonts/fonts.conf.

To change the default console font used by GoboLinux, use the ConsoleFont option in /System/Settings/BootOptions.

You can also change the console font using the setfont utility. See man setfont for details.

Remember that this setting changes only the console font. On X, applications have their own font settings.

Keymap

Use the KeymapLayout option in /System/Settings/BootOptions to select an appropriate console keyboard layout.

The available keymaps are in the KBD package; they are the .map files. You can set the console keyboard layout at any time by running loadkeys. For example, to set the Dvorak keymap, just type in:

loadkeys dvorak.map

Mouse

The MouseType and MouseDevice options in /System/Settings/BootScripts/BootUp configure mouse support on the console. They are disabled by default.

Graphical display setup (X server)

Keymap

The keyboard layout for programs running under the window manager is mapped according the InputDevice section in /System/Settings/xorg.conf when the graphic display (X server) starts. With the window manager running, you can change keyboard mappings and display settings using setxkbmap, xmodmap, and xset tools. To select a Dvorak keyboard layout, type setxkbmap dvorak in a terminal. These commands can also be placed in $HOME/.xinitrc.

Some desktop environments also offer graphical tools for setting the keyboard layout. For example, in KDE you can configure this at the KDE Control Center.

Mouse

The mouse pointer for the graphical display is defined in an InputDevice section in /System/Settings/xorg.conf. The Installer should correctly detect your hardware and set suitable defaults for your system. If not, you can always try a failsafe setup such as:

Section "InputDevice"
Identifier  "Mouse0"
Driver      "mouse"
Option      "Protocol" "auto"
Option      "Device" "/dev/input/mice"
Option      "ZAxisMapping" "4 5"
EndSection

There is nothing GoboLinux-specific about mouse setup on X. You can find HOWTOs and tutorials around the net that can give you more detailed instructions about this. (But feel free to drop by at the mailing list if you’re still stuck!)

Kernel modules

Through the use of Udev, GoboLinux is capable of loading kernel modules (e.g. device drivers) automatically at boot. In cases Udev doesn’t load some wanted drivers, the user can explicitly request them.

One way is to edit /System/Settings/modprobe.conf (similar to other Linux distributions), however a simpler way in GoboLinux is to list desired modules in /System/Settings/BootOptions. This is how to load the i810_audio audio driver and sk98lin ethernet driver:

UserDefinedModules=(
    "i810_audio"
    "sk98lin"
)

The startup scripts read this array and run modprobe each line. The entries may include additional parameters.

Network configuration

Wi-Fi

If you are using Wi-Fi, just select your network using the GoboNet widget in the AwesomeWM system tray:

GoboNet Widget GoboNet Widget

Wired network

If you have a wired network, initialize it on boot using standard Linux commands in your bootscripts sequence.

First, check which are your network interfaces typing

ifconfig

You should have a network interface named something like eth0 or enp0s3.

Edit the /System/Settings/BootScripts/BootUp script. If you are using DHCP, just add this:

dhcpcd eth0 &

If you have a static network configuration, place commands similar to the following in BootUp.

ifconfig eth0 192.168.1.5 netmask 255.255.255.0
route add default gateway 192.168.1.1 metric 1 dev eth0

The nameserver can be specified in /etc/resolv.conf (/System/Settings/resolv.conf). To use Google’s nameservers, you can edit resolv.conf to:

nameserver 8.8.8.8
nameserver 8.8.4.4

Automated login

If you wish to use an automated login, there are several ways to achieve this goal.

For KDE (or KDM, it also has a configuration which allows you to tweak it a lot) you can use this:

  1. Open Control Center in administrative mode.
  2. Select Login Manager.
  3. Under the Convenience tab check “Enable auto-login” and select which user you should log in as.
  4. Click “Apply”.

If you do not use KDE or want a non-GUI based solution, one way is to use rungetty.

  1. In your inittab file (for example, nano /etc/inittab) find the line which includes tty1 (it’s your first terminal, the default showing up on login).
  2. Now, you will see agetty in there - change this agetty line to rungetty tty1 --autologin your_username.

Of course, replace your_username with the user you want to login as.

Using another tty than 1 may be useful too.

Printers

GoboLinux comes with CUPS installed by default.

Audio

Note that ALSA is muted by default, to automatically save and restore changes done in e.g. alsamixer, add these lines to your boot scripts.

Done: Exec "Storing ALSA settings..."
alsactl store

Boot Script Tasks

Your boot scripts can make use of “boot tasks”, which are little service scripts that can be shipped by programs. A program includes its tasks under Resources/Tasks, and they’re linked in /System/Tasks. This is roughly equivalent to the /etc/init.d scripts found in many distributions.

You can launch or stop tasks from the command line, using StartTask and StopTask. For example, the following command will load the SSH daemon:

StartTask OpenSSH

Within boot scripts, you don’t need to use these launchers, but you have to add a parameter indicating whether the task is being started or stopped:

Exec "Initializing OpenSSH server..." OpenSSH Start

Creating tasks

Strictly speaking, a task is simply a shell script put in the appropriate directory, which accepts start and stop parameters. In this imaginary example, one could have a file /Programs/Foo/1.0/Resources/Tasks/Foo with these contents:

#!/bin/sh

case "$1" in
[Ss]tart)
    # actions to start foo go here
    foo --silly-walk
    ;;
[Ss]top)
    # actions to stop foo go here
    killall foo
    ;;
esac

It’s a good idea to use the above example as a template for tasks you create. The [Ss] syntax ensures that both start and Start are recognized, which is nice to avoid typos.

Boot Themes

GoboLinux is flexible enough to offer you a choice of themes to control how your GoboLinux looks when starting up.

You can select a theme by setting BootTheme=<ThemeName> in /System/Settings/BootOptions. Available themes include:

  • CheckList - Shows tasks and others that depend on them, then checks them off.
  • Hat - A Red-Hat look-alike: lots of colored [ OK ]s and [FAILED]s are echoed as things are initialized.
  • Progress, Progress-II, or Progress-III - Fancy themes that stress your terminal with tons of escape codes.
  • Quotes - Prints short random quotes to indicate success or failure of every initialized item.
  • Slack - This theme is inspired by the feel of old-school Slackware boots: no distracting messages, no colors, no special effects.

Check /Programs/BootScripts/Current/Themes/ to see all the available themes.

You can use the TestBootTheme script to see how a boot theme looks like without actually rebooting your computer. TestBootTheme is described on section Testing a boot theme.

You can also set the boot theme from GRUB by adding BootTheme=<ThemeName> to the boot line. This can be handy if BootOptions file specifies a broken or nonexistent theme, because GoboLinux will not boot without a valid one.

Physically, a GoboLinux boot theme is a single script file located in /Programs/BootScripts/*<version>*/Themes.

The theme file is loaded by the boot scripts core, and is called once for every runlevel change. Although interesting stuff can be done in the script body, a compliant boot script has only to implement the following functions:

  • ThemeInit
  • ThemeFile
  • ThemeBefore
  • ThemeAfter
  • ThemeFinish

These functions are the hotspots that glue the theme and the boot scripts core together.

Subsections of Boot Themes

Creating a boot theme

This section explains how you can create your own boot script theme.

Section “The boot scripts anatomy” already explained that a theme is a single script file. In fact, if you really want, you can create a theme that spreads through multiple files (but this is not necessarily a good idea). The point here is that one file is enough. This file implements a five functions: ThemeInit, ThemeFinish, ThemeBefore ThemeAfter, and ThemeFile.

So, if you want to create a boot theme for GoboLinux, all you have to do is to create a script file like /Programs/BootScripts/*<version>*/Themes/MyVeryOwnBootTheme that implements those functions (and optionally something in the script body) with all the bells and whistles you want.

Subtopics:

  1. Implementing a boot theme
  2. Testing a boot theme

Implementing a boot theme

This section describes how each of the obligatory theme functions must be implemented.

ThemeInit

This, as the name implies, is the standard location to perform initializations. Below is an example on how you can use the standard $PREVLEVEL variable (from the Sysvinit init program) to echo some message when system initializes or goes down.

if [ "$PREVLEVEL" = "N" ]
  then
    echo "GoboLinux is initializing..."
  else
    echo "GoboLinux is going down..."
fi

ThemeFile

GoboLinux boot scripts work by processing a sequence of files (again, check section “Customizing the initialization” for more details). Before starting to process each of these files, the boot scripts core will call ThemeFile passing as the first (and only) parameter the name of the file that is starting to be processed. Needless to say, you are not obligated to give feedback on what file is being processed (the “Hat” theme, example, does nothing in its implementation of ThemeFile.

A very simple example implementation of ThemeFile follows.

function ThemeFile() {
  echo "Entering file '$1'..."
}

ThemeBefore and ThemeAfter

These functions wrap the execution of commands. ThemeBefore runs before a program is executed and ThemeAfter, as expected, afterwards.

ThemeBefore is given two parameters: an identifier and a message. The identifier is a numeric id so you can match calls to ThemeBefore and ThemeAfter. Likewise, ThemeAfter is given two parameters, the identifier and a numeric result code, indicating success (zero) or failure (other values).

If your theme supports only sequential booting (ie, does not use Fork and Wait to parallelize the execution of the boot tasks), you can ignore the identifier – most themes do, as sequential boots are more common and that makes the themes simpler. On parallel boot, however, programs can end in a different order than they were started; with some escape code trickery, one can represent graphically the intrincacies of parallel booting (the CheckList theme is an attempt at that).

Here’s a quick example of ThemeBefore and ThemeAfter:

function ThemeBefore() {
  shift # ignore id
  echo -n "===> $@... "
}
function ThemeAfter() {
  if [ "$2" -eq 0 ]
    then echo "{SUCCESS}"
    else echo "{ERROR}"
  fi
}

ThemeFinish

The ThemeFinish function is called as the last step in a runlevel switch (after everything else was done). Hence, this is the place to add any finalization code. A common task performed by ThemeFinish is writing to the issue file, whose contents are displayed on the screen just before the login prompt. The issue file name is passed as the first (and only) ThemeFinish parameter.

The following example shows a sample ThemeFinish implementation that just writes an issue file that clears the screen.

function ThemeFinish() {
    clear > $1
    echo "Welcome!!" >> $1
}

Testing a boot theme

Fortunately you don’t have to reboot your computer to test every feature you add to your boot theme. The TestBootTheme script is your friend. Just run it passing your boot script name as a parameter:

TestBootTheme MyVeryOwnBootTheme

This will simulate a boot procedure with lots of things getting executed. Some of them will be quiet, some will echo a lot of text, some will succeed, some will fail… Just press enter when it ends up at the “login” prompt to finish. If you don’t give it a Theme name, it will output the list of available Themes from /Programs/BootScripts/Current/Themes/ instead.

Of course, this script is also useful to see how the various boot themes are, so that you can choose which one is your favorite.

Note

Some themes may not display correctly in an Xterm/Konsole/other graphical terminal, or with a non-standard console font. It’s probably best to run TestBootTheme in the same environment you boot in!