CONTENT
License
Important notes (read this before installing anything!)
Operating system distribution support
Front-end support
Notes for the WsLib-based Monitors
Notes for the Gtk+ Monitor
Installation/deinstallation
Boot command-line options
Hacking
The process
Monitor invocation
Notes for the WsLib-based Monitors
Notes for the Gtk+ Monitor
Build structure
Versions
LICENSE
Aurora graphical Linux boot version redhog.16
Copyright (C) 1999-2000 by RedHog (Egil Möller) <redhog@lysator.liu.se>
Changes 2000-2001 by Mandrakesoft,
RedHog (Egil Möller) <redhog@mandrakesoft.com>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
IMPORTANT NOTES (READ THIS BEFORE INSTALLING ANYTHING!)
* This version is tested for RedHat 6.0 and 6.2 and Mandrake 6.1, 7.0,
7.1, 7.2 and 8.0 _only_. Any other usage is subject to unknown behavior.
* IF YOU SKREW EVERYTHING UP: Do not panic. Reboot your computer. On the boot-
command-line, enter the kernel parameter "init=/bin/sh". You will, after
kernel boot, be dumped into a shell with the root filesystem mounted
read-only. Remount the root read/write with the command "/bin/mount
-w -o remount /". Then go to the Aurora source directory and do a
"make uninstall". If this does not work, probably due to Aurora
being installed on an unsupported distribution and the init scripts
patched to hell, rebbot this way and then use "rpm -U --oldpackage
initscripts.rpm" where initscripts is the package containing the
init scripts. Of course, on non-rpm systems (eg deb-systems), the
command will be something else.
OPERATING SYSTEM DISTRIBUTION SUPPORT
The support for different distributions (Redhat, Debian, Slackware,
etc.) resides in directories named after the distribution, inside the
"Archs" directory. Note that each of these have its own version and
may be maintained by by some third party. Please see the README in
each such directory for more information about issues about your
distribution. Some distributions may have built-in support for
Aurora. They are listed without version-number. Supported
distributions:
Distribution Version Authors E-mail
RedHat.6.0 redhog.f Egil Möller redhog@mandrakesoft.com
RedHat.6.2 richard.0.redhog.0 Richard June rjune@bravegnuworld.com
Egil Möller redhog@mandrakesoft.com
Mandrake.6.1 redhog.b.robin.1.redhog.1
Robin Verduijn robin@warande.net
Egil Möller redhog@mandrakesoft.com
Mandrake.7.0 redhog.f Egil Möller redhog@mandrakesoft.com
Mandrake.7.1 redhog.f Egil Möller redhog@mandrakesoft.com
Mandrake.7.2 Egil Möller redhog@mandrakesoft.com
Mandrake.8.0 Egil Möller redhog@mandrakesoft.com
FRONT-END SUPPORT
Aurora can use different front-ends (Monitors). It should be fairly
easy to create additional such front-ends, given that you have a
suitable widgetset to use (e.g. Gtk, WsLib, Qt, FLTK, etc). The system
administrator of the computer at which Aurora is installed/is to be
installed can shoose which Monitor to use by changing the symlink
/etc/aurora/Monitor to point to any other of the files in
/lib/aurora/Monitors.
Name Version Authors E-mail
NewStyle-WsLib redhog.0 Egil Möller redhog@mandrakesoft.com
Traditional-WsLib redhog.0 Egil Möller redhog@mandrakesoft.com
Traditional-Gtk+ redhog.12 Egil Möller redhog@mandrakesoft.com
NOTES FOR THE WSLIB-BASED MONITORS
There are two Monitors which are not using the X Windowing system,
NewStyle-WsLib and Traditional-WsLib. They reside in
/sbin/Monitor-NewStyle-WsLib and /sbin/Monitor-Traditional-WsLib,
respectively. They do not need the X Windowing System, nor any of its
libraries to build or run. However, they need a framebuffer-kernel,
with a graphical video-mode enabled. To enable this, say yes to
FrameBuffer device in the kernel configuration, and add
vga=some_video_mode_number to your lilo.conf. If your kernel comes
with FrameBuffer support by default, but not enabled (as the one
shipped with Mandrake 7.2 and later does), you need only to add a
suitable vide-mode number to your /etc.lilo.conf, run lilo and
reboot. Available vide-mode numbers are listed in the file
/usr/share/doc/HOWTO/HTML/en/Framebuffer-HOWTO.html, for VESA cards
(most graphic-cards), the modes are:
Resolution 640x400 640x480 800x600 1024x768 1280x1024 1600x1200
Colours +-----------------------------------------------------
4 bits | ? ? 0x302 ? ? ?
8 bits | 0x300 0x301 0x303 0x305 0x307 0x31C
15 bits | ? 0x310 0x313 0x316 0x319 0x31D
16 bits | ? 0x311 0x314 0x317 0x31A 0x31E
24 bits | ? 0x312 0x315 0x318 0x31B 0x31F
32 bits | ? ? ? ? ? ?
NOTES FOR THE GTK+ MONITOR
Traditiopnal-Gtk+ is an X Windowing System Monitor, which uses the
GTK+ widgetset. Thus, it does not need a FrameBuffer-kernel, but
instaed need the X Windowing System, and the GTK+-libraries. It
resides in /usr/sbin/Monitor-Traditional-Gtk+.
INSTALLATION/DEINSTALLATION
After unpacking the source archive, do a "make install". This will try to
autodetect your OS distribution (RedHat, Debian, Slackware, etc.). If it fails,
you may supply it with the name of the correct one. This is done with the
command line parameter arch=distribution_name to make. To find correct names, cd
into the directory "Archs" and issue an "ls". Note to previous users of Aurora:
There is no longer any "bootlocation=" option to make. The moment to start
Aurora during the bootprocess is now autodetected during the bootprocess.
To uninstall Aurora (Would you really want that? You'r crazy, man!),
simply go to your Aurora source directory and type "make
uninstall". If you have erased it, you'l just have to download
_the_same_version_ of Aurora again, unpack it and then proceed with
make uninstall.
To turn a source archive into an RPM, do either of make rpm or make
rpm-mdk. The former will produce an RPM suitable for all supported
distributions, while the latter will produce an RPM suitable only for
Linux-Mandrake (In fact, any distribution that have Aurora-supporting
initscripts out of the box, but that's only Linux-Mandrake at the
moment), but which is slightly smaller and cleaner.
BOOT COMMAND-LINE OPTIONS
There are two boot (kernel) command-line options for use with Aurora. In fact,
only one of them is Aurora-specific; textboot.
"textboot" Temporary reverts to old-style textual boot. This does only apply
to the current boot and does not uninstall Aurora. This is
especially usefull in conjunction with the "single" command if
you have to change graphic card and need to boot to reconfigure X
for the new card.
"init=/bin/sh" Bypass the init process and start a shell. Described under
"IMPORTANT NOTES", "IF YOU SKREW EVERYTHING UP".
HACKING
THE PROCESS
In order to display a graphical representation of the boot-process, the output
from the init-scripts (Those residing in /etc/rc.d on a Red Hat system) is
redirected via a pipe (/tmp/aurora/input) to the Monitor program. This program
interprets the input it gets. This interpretation has two main states; normal
output interpretation which consists of dividing up the output in groups of
lines that comes from the same command and guessing if the command turned out to
be successfull or not, and command interpretation that consists of reading
direct commands to Monitor. The previous state is the default when Monitor is
started. To enter the later state, a line with only the text "§command§" must be
written to the pipe. To exit from the later state again, a line with only the
text "§end§" must be written.
Each command consists of one line of text. The text is a set of space-separated
words. These words forms sort of a "path" to the command. To shorten the text in
the command list, the following format is used:
word1 Description of all commands starting with "word1"
word2 Description of all commands starting with "word1 word2"
word3 Description of the command "word1 word2 word3"
These are the commands available in the command-state:
set Configure Monitor's behavoir and look.
confirm Tells Monitor whetever to display a "pressed" confirm
button or not.
runlevel Instructs Monitor to show what runlevel we are in. The
runlevel is the first character on the next line of
input.
missionsize Tells Monitor how many commands we have to execute
before we are done with entering the runlevel we are
entering. The number of commands is the decimal number
on the next line of input.
completion Sets the text that must be at the end of each output-block
in order for Monitor to consider it (positively/
negatively) completed. Each of these commands takes one
line of text as its parameter.
ok Sets the text that must be at the end of each output block
in order for Monitor to consider it positively completed.
passed Sets the text that must be at the end of each output block
in order for Monitor to consider it neither positively nor
negatively completed but completed.
failed Sets the text that must be at the end of each output block
in order for Monitor to consider it negatively completed.
pixmap Sets the pixmap to use to present various things in the
interface. Each of these commands takes one line of text
as its parameter. The text should be a valid name of an
xpm file.
logo Sets the logo to show to the left of the display in
various states.
normal Sets the logo to display in the normal state.
excuse Sets the logo to display if _any_ of the output blocks
since the last missionsize-command completed negatively.
completion Sets the pixmap to show to the right of each block of
output.
ok Sets the pixmap to show to the right of each block of
output that completed positively.
passed Sets the pixmap to show to the right of each block of
output that completed but neither positively nor
negatively.
failed Sets the pixmap to show to the right of each block of
output that completed negatively.
path Sets paths to resources of various kinds. Each of these
commands takes one line of text as its parameter. The text
should be a valid path to a directory.
icons Sets the path to the directory containing icons for output
blocks. These are the icons shown to the left of each
output block. Monitor determines which file in the
directory to show based on the first line of text in the
block; The file whose name is the longest prefix (except
for its extension, which must allways be .xpm) to that
line of text is selected.
config-scripts Sets the path to the directory containing
service-configuration scripts. These scripts are run if
the user clicks on one of the service icons. Monitor
determines which file in the directory to run based on the
first line of text in the block; The file whose name is
the longest prefix (except for its extension, which must
allways be .sh) to that line of text is selected.
dialog
title Sets the title of an existing dialog. The dialog's name
should be given at the next line of input. All subsequent
lines, up to one containing only the text §end§, are used
as a new dialog title.
text
runlevel Sets the title of one of the runlevel buttons. The
runlevel should be given at the next line of input. All
subsequent lines, up to one containing only the text
§end§, are used as a new title.
confirm Sets the title of the service-confirmation button. All
subsequent lines, up to one containing only the text
§end§, are used as a new title.
control Sets the title of the control-button collumn. All
subsequent lines, up to one containing only the text
§end§, are used as a new title.
clear Sets the title of the clear-button. All subsequent
lines, up to one containing only the text §end§,
are used as a new title.
progress Sets the title-pattern of the progress-bar. All subsequent
lines, up to one containing only the text §end§,
are used as a new title. For information on the codes
usable in the pattern, see the Gtk-documentation for
gtk_progress_set_format_string.
get Returns values to the output.
confirm Returns yes or no depending on if the confirm-button is
pressed.
create
dialog Creates a new dialog. The parameter to this command is
rather complex, and consist of a set of lines, all ended
with a line containing only the text §end§. The first of
those lines should contain the name of the dialog to
create, and the second its title (The question to ask the
user). These two lines are mandatory. All subsequent lines
defines answer buttons. Each answer button definition
consists of its title (One line of text, that is to be
shown uppon the button), and a set of lines, terminated by
one containing only the text §end§, to send to the output
if the users answers the dialog by pressing that button.
show
dialog Shows a dialog, if the users hasn't previously selected to
answer the same to all subsequent dialogs of this type.
The parameter to this command is the next line of text,
which is considered the name of the dialog to show.
The response text for the selected or preselected button
is written to the output.
reset
dialog Resets the repeat option for a dialog. This forces the
user to answer the next dialog manually. This command
takes one line of text as its parameter, which is the name
of the dialog to reset.
Note: Those commands taking multi-line parameters (i.e. set dialog title and
create dialog), does not include the last new-line in the parameter. This
enables you to specify a parameter that does not end with a new-line.
As a quick reference, I include here the same list with all the comments
removed:
set
runlevel
missionsize
completion
ok
passed
failed
pixmap
logo
normal
excuse
completion
ok
passed
failed
path
icons
config-scripts
dialog
title
text
runlevel
confirm
control
clear
progress
get
confirm
create
dialog
show
dialog
reset
dialog
To ease the use of the command mode, there is a shell (sh) function library that
may act as an abstraction layer on top of the command mode. This library is
usually located in /etc/aurora/functions. All functions in the library begins
their names with "aurora_", and are mostly named as their command mode command
equivalents, but with spaces replaced by underscores. All functions whose
command equivalents takes only a single-line parameter, takes their parameter
as $1. Multiline parameters must however be printed with echo and ended with
aurora_end. For an example of the usage of this library, see the default
/etc/aurora/rc configuration file.
Note: All monitors may not support all commands. Currently, gMonitor
supports all of them, and wsMonitor most of them, but not all. All
non-implemented commands fails in a non-fatal way.
MONITOR INVOKATION
The Monitor program should be a shell-script, that starts the Monitor
itself. The Monitor itself is allways named as the shell-script, but
with a Monitor- prepended to its name. The fisrt argument to the
script is a command, and can be "start", "query" or
"startable". "start" takes one additional parameter, a decimal number
designating the virtual console to start the Monitor on. "query"
returns true if the Monitor is currently running, and false
otherwize. "startable", finally, returns false if there are
_permanent_ problems that would cause a "start" to fail, that is,
problems that would need a reboot, or new kernel or something similar
to go away. currently, this is only used in the WsLib based Monitors,
and checks whethever there is FrameBuffer-support enabled or
not.
NOTES FOR THE WSLIB-BASED MONITORS
The WsLib-based Monitors must be started using the 'open' command, as
they can not switch by itself to a new virtual terminal (This is
automatically done by their wrapper-scripts). The Monitors takes up to
three command line parameters. All of these have default values which
applies when a certain parameter is left out. The parameters are, in
order:
Input filename: /tmp/aurora/input
The pipe from which gMonitorBin is to read the output of the boot
scripts and its commands.
Output filename: /tmp/aurora/output
The pipe to which gMonitorBin is to write any (user supplied) feedback
to the init scripts.
Initial runlevel display: N
The name of the runlevel in which we currently are or wants gMonitorBin
to beleave we are. This value affects which of the runlevel radio
buttons are initially selected.
In addition to this, the WsLib-based Monitors needs two environment
variables to be set up (They are automatically set up by their
wrapper-scripts): MOUSEDEVICE and MOUSETYPE. MOUSEDEVICE should be the
full path to the mouse-device (e.g. /dev/psaus, /dev/ttyS0,
/dev/mouse, etc.). MOUSETYPE should be a string describing the
mousetype. The strings are to be compatible with teh strings you can
supply the "gpm" command's -t flag. For a list of supported
mousetypes, please see the documentation of the WsLib library (Or look
into the file mouselib.c in the source for WsLib).
NOTES FOR THE GTK+ MONITOR
The Traditional-Gtk+ Monitor starts an X-server, and a Gtk+-based
Monitor that uses the X-server to present its outup. This Monitor
takes exactly the same parameters as the WsLib-based ones.
BUILD STRUCTURE
The Aurora build structure is divided up into several modules. One
for the architecture(distribution)-dependent parts (Archs), one for
the general initscript output parser (Monitor), one for data specific
to the WsLib-based Monitors (wsData), and finally one for each
Monitor. The main Makefile does not have a list of Monitors, but
rather treat every subdirectory whose name matches Monitor-* as a
Monitor.
VERSIONS
Several parts of Aurora have version-, release- and
build-numbers. All these numbers are contained in files named
"version" in each build module. These files should never be
manipulated by hand, but by the script version.sh in the topplevel
directory. It is called from the makefiles as soon as a rebuild is
done. Normally, it increases the build-number. If you supply
type=release to make, it will reset the build-number and increase the
release-number. If you supply type=version to make, it will increase
the hexadecimal number at the end of the version-name path by one, and
the serial number by one-tenth, and reset both the build- and the
release-number. If you want to append a new modifier name to the
version-path, you have to run the version.sh-script manually with the
version-file as its first arg, appendversion as second arg and the
modifier (your) name as last arg. For a more indepth description of
the version-names used by Aurora, please refer to
http://Opinions.mini.dhs.org/RFCs/Version%20naming/HTML%20version.html.
When making a dis, rpm or rpm-mdk with type=release or type=version,
your editor, as set by the EDITOR environment variable, will be
started, with a file with a changelog-header for the current version,
date and packager (as defined in Aurora.spec.in) allready in
place. This entry will be prepended to either RELEASELOG or CHANGELOG,
depending on type. When making a dis, rpm or rpm-mdk with
type=version, the RELEASELOG will be cleared. You should, for
versions, write a changelog item covering, but not in detail all
changes done in the releases done since the last version.
