[Debconf6-data-commit] r508 - in procedings: .
32-debian-installer-internals 32-debian-installer-internals/orig
Alexander Schmehl
tolimar at costa.debian.org
Mon Apr 10 23:54:29 UTC 2006
Author: tolimar
Date: 2006-04-10 23:54:18 +0000 (Mon, 10 Apr 2006)
New Revision: 508
Added:
procedings/32-debian-installer-internals/
procedings/32-debian-installer-internals/orig/
procedings/32-debian-installer-internals/orig/d-i_debconf6.v2.tex
procedings/32-debian-installer-internals/orig/d-i_debconf6.v2.xml
procedings/32-debian-installer-internals/orig/missfont.log
procedings/32-debian-installer-internals/paper.tex
Modified:
procedings/all.dvi
procedings/all.tex
Log:
'debian installer internals' paper added
Added: procedings/32-debian-installer-internals/orig/d-i_debconf6.v2.tex
===================================================================
--- procedings/32-debian-installer-internals/orig/d-i_debconf6.v2.tex 2006-04-10 23:36:43 UTC (rev 507)
+++ procedings/32-debian-installer-internals/orig/d-i_debconf6.v2.tex 2006-04-10 23:54:18 UTC (rev 508)
@@ -0,0 +1,1055 @@
+% -----------------------------------------
+% Autogenerated LaTeX file from XML DocBook
+% -----------------------------------------
+\documentclass{article}
+\usepackage[T1]{fontenc}
+\usepackage[latin1]{inputenc}
+%\usepackage{a4wide}
+\setcounter{secnumdepth}{5}
+\usepackage{fancybox}
+\usepackage{makeidx}
+\def\hyperparamadd{pdfcreator=DBLaTeX-0.1.8}
+\usepackage[article,hyperlink]{docbook}
+\renewcommand{\DBKcopyright}{Copyright \textnormal{\copyright} 2006 \textnormal{\copyright} Frans Pop \href{mailto:fjp at debian.org}{fjp at debian.org}}
+\title{Debian Installer internals}
+\author{Frans Pop}
+
+% ------------------
+% Table d'Indexation
+% ------------------
+\renewcommand{\DBKindexation}{
+\begin{DBKindtable}
+\DBKinditem{\writtenby}{Frans Pop}
+
+\end{DBKindtable}
+}
+
+ % --------------------------------------------
+\makeindex
+\makeglossary
+% --------------------------------------------
+
+\setcounter{tocdepth}{5}
+
+\setcounter{secnumdepth}{5}
+
+%% ------------
+%% Legalnotices
+%% ------------
+\renewcommand{\DBKlegalblock}{
+\def\DBKlegaltitle{}
+\begin{DBKlegalnotice}
+
+ This article is free; you may redistribute it and/or modify it
+under the terms of version 2 of the GNU General Public License.
+
+\end{DBKlegalnotice}
+}
+\begin{document}
+\long\def\hyper at section@backref#1#2#3{%
+\typeout{BACK REF #1 / #2 / #3}%
+\hyperlink{#3}{#2}}
+
+\maketitle
+\tableofcontents
+
+% --------
+% Abstract
+% --------
+\begin{abstract}
+
+ The Debian Installer is sometimes described as a mini Linux distribution which gives an indication of its complexity. This paper gives an introduction to the inner workings of the installer when it is running, its components (udebs) and its build system.
+
+
+\end{abstract}
+
+\section{Running Debian Installer}
+ The examples in this section reflect the current status of the Installer, the Etch Beta 2 release, and are based on the CD-{}ROM and netboot installation methods for i386. The choice for i386 was made as this is most familiar to most users, but installations for other architectures is not structurally different\footnote{
+ Some architectures currently do not use partman for partitioning, file system creation and mount point selection but instead use other components. Some architectures also use specific additional components as part of their default installation. However, this does not make them structurally different.
+
+}.
+
+
+ So what are the basic steps when the installer is run? In any installation five stages can be distinguished.
+ \begin{enumerate}
+
+\item{} boot and initialization \textemdash{} setting up the installer so that it can load any additional components
+
+
+\item{} loading additional components \textemdash{} expanding the installer to its full functionality)
+
+
+\item{} network configuration (unless already done in stage 1)
+
+
+\item{} partitioning
+
+
+\item{} installing the target system
+
+\end{enumerate}
+
+
+ The first three stages are where the fundamental difference between installation methods can be seen. All components (udebs) used there need to be included in the initrd\footnote{
+ With one exception. In floppy disk based installations, the initrd does not contain all needed components for stage 2, but it does have the ability to load additional components that belong to stage one or are needed for stage 2 from additional floppy disks.
+
+} with which the installer is booted.
+
+
+ The table below shows what components are involved in the first and second stage for the CD-{}ROM and netboot installation methods and also shows where these differ.
+
+\begin{center}
+%%% parse_table %%%
+\resizetable{4}{4}{0cm}{}
+\begin{longtable}{|>{\centering}p{\tsize}|>{\centering}p{\tsize}|>{\centering}p{\tsize}|>{\raggedright}p{\tsize}|}
+\hline
+\rowcolor[gray]{.9}
+S\-t\-a\-g\-e & C\-D\--{}\-R\-O\-M & N\-E\-T\-B\-O\-O\-T & C\-o\-m\-m\-e\-n\-t\-s \tabularnewline
+\hline
+\endhead
+\hline
+-{} & \multicolumn{2}{c|}{i\-n\-i\-t\-r\-d\--{}\-p\-r\-e\-s\-e\-e\-d} & O\-n\-l\-y i\-f \texttt{%% texclean(hyphenon)
+/\-p\-r\-e\-s\-e\-e\-d\-.\-c\-f\-g%% texclean(hyphenoff)
+} i\-s p\-r\-e\-s\-e\-n\-t \tabularnewline
+\hline
+1 & \multicolumn{2}{c|}{l\-o\-c\-a\-l\-e\-c\-h\-o\-o\-s\-e\-r} & L\-a\-n\-g\-u\-a\-g\-e\-/\-c\-o\-u\-n\-t\-r\-y\-/\-l\-o\-c\-a\-l\-e s\-e\-l\-e\-c\-t\-i\-o\-n \tabularnewline
+\hline
+1 & \multicolumn{2}{c|}{k\-b\-d\--{}\-c\-h\-o\-o\-s\-e\-r} & K\-e\-y\-b\-o\-a\-r\-d s\-e\-l\-e\-c\-t\-i\-o\-n \tabularnewline
+\hline
+1 & c\-d\-r\-o\-m\--{}\-d\-e\-t\-e\-c\-t & e\-t\-h\--{}\-d\-e\-t\-e\-c\-t & H\-a\-r\-d\-w\-a\-r\-e d\-e\-t\-e\-c\-t\-i\-o\-n a\-n\-d s\-e\-t\-u\-p \tabularnewline
+\hline
+1 & & n\-e\-t\-c\-f\-g & N\-e\-t\-w\-o\-r\-k c\-o\-n\-f\-i\-g\-u\-r\-a\-t\-i\-o\-n \tabularnewline
+\hline
+-{} & f\-i\-l\-e\--{}\-p\-r\-e\-s\-e\-e\-d & n\-e\-t\-w\-o\-r\-k\--{}\-p\-r\-e\-s\-e\-e\-d & I\-f s\-e\-l\-e\-c\-t\-e\-d a\-t b\-o\-o\-t p\-r\-o\-m\-p\-t \tabularnewline
+\hline
+2 & & c\-h\-o\-o\-s\-e\--{}\-m\-i\-r\-r\-o\-r & M\-i\-r\-r\-o\-r s\-e\-l\-e\-c\-t\-i\-o\-n \tabularnewline
+\hline
+2 & l\-o\-a\-d\--{}\-c\-d\-r\-o\-m (\-a\-n\-n\-a\-) & d\-o\-w\-n\-l\-o\-a\-d\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r (\-a\-n\-n\-a\-) & R\-e\-t\-r\-i\-e\-v\-e a\-n\-d u\-n\-p\-a\-c\-k a\-d\-d\-i\-t\-i\-o\-n\-a\-l c\-o\-m\-p\-o\-n\-e\-n\-t\-s \tabularnewline
+\hline
+3 & e\-t\-h\--{}\-d\-e\-t\-e\-c\-t & & H\-a\-r\-d\-w\-a\-r\-e d\-e\-t\-e\-c\-t\-i\-o\-n a\-n\-d s\-e\-t\-u\-p \tabularnewline
+\hline
+3 & n\-e\-t\-c\-f\-g & & N\-e\-t\-w\-o\-r\-k c\-o\-n\-f\-i\-g\-u\-r\-a\-t\-i\-o\-n \tabularnewline
+\hline
+3 & c\-h\-o\-o\-s\-e\--{}\-m\-i\-r\-r\-o\-r & & M\-i\-r\-r\-o\-r s\-e\-l\-e\-c\-t\-i\-o\-n (\-s\-o\-m\-e\-t\-i\-m\-e\-s n\-e\-e\-d\-e\-d f\-o\-r s\-t\-a\-g\-e 4\-) \tabularnewline
+\hline
+\end{longtable}
+\end{center}
+
+ The remainder of the installation is basically the same for all installation methods.
+
+\begin{center}
+%%% parse_table %%%
+\resizetable{3}{3}{0cm}{}
+\begin{longtable}{|>{\centering}p{\tsize}|>{\centering}p{\tsize}|>{\raggedright}p{\tsize}|}
+\hline
+\rowcolor[gray]{.9}
+S\-t\-a\-g\-e & & C\-o\-m\-m\-e\-n\-t\-s \tabularnewline
+\hline
+\endhead
+\hline
+4 & h\-w\--{}\-d\-e\-t\-e\-c\-t & A\-d\-d\-i\-t\-i\-o\-n\-a\-l h\-a\-r\-d\-w\-a\-r\-e d\-e\-t\-e\-c\-t\-i\-o\-n \tabularnewline
+\hline
+4 & p\-a\-r\-t\-m\-a\-n & P\-a\-r\-t\-i\-t\-i\-o\-n\-i\-n\-g\-, f\-i\-l\-e s\-y\-s\-t\-e\-m c\-r\-e\-a\-t\-i\-o\-n a\-n\-d m\-o\-u\-n\-t p\-o\-i\-n\-t s\-e\-l\-e\-c\-t\-i\-o\-n \tabularnewline
+\hline
+5 & t\-z\-s\-e\-t\-u\-p & T\-i\-m\-e z\-o\-n\-e s\-e\-l\-e\-c\-t\-i\-o\-n \tabularnewline
+\hline
+5 & c\-l\-o\-c\-k\--{}\-s\-e\-t\-u\-p & C\-o\-n\-f\-i\-g\-u\-r\-e f\-o\-r h\-a\-r\-d\-w\-a\-r\-e c\-l\-o\-c\-k s\-e\-t t\-o U\-T\-C o\-r l\-o\-c\-a\-l t\-i\-m\-e z\-o\-n\-e \tabularnewline
+\hline
+5 & u\-s\-e\-r\--{}\-s\-e\-t\-u\-p & S\-e\-t u\-p r\-o\-o\-t a\-n\-d n\-o\-r\-m\-a\-l u\-s\-e\-r a\-c\-c\-o\-u\-n\-t\-s \tabularnewline
+\hline
+5 & b\-a\-s\-e\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r & B\-a\-s\-e s\-y\-s\-t\-e\-m (\-d\-e\-b\-o\-o\-t\-s\-t\-r\-a\-p\-) \ & \tabularnewline
+\hline
+5 & a\-p\-t\--{}\-s\-e\-t\-u\-p & A\-P\-T c\-o\-n\-f\-i\-g\-u\-r\-a\-t\-i\-o\-n i\-n t\-h\-e t\-a\-r\-g\-e\-t s\-y\-s\-t\-e\-m (\-s\-o\-u\-r\-c\-e\-s\-.\-l\-i\-s\-t\-) \tabularnewline
+\hline
+5 & p\-k\-g\-s\-e\-l & S\-e\-l\-e\-c\-t a\-n\-d i\-n\-s\-t\-a\-l\-l a\-d\-d\-i\-t\-i\-o\-n\-a\-l p\-a\-c\-k\-a\-g\-e\-s (\-t\-a\-s\-k\-s\-e\-l\-) \tabularnewline
+\hline
+5 & g\-r\-u\-b\-/\-l\-i\-l\-o\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\-; n\-o\-b\-o\-o\-t\-l\-o\-a\-d\-e\-r & B\-o\-o\-t l\-o\-a\-d\-e\-r i\-n\-s\-t\-a\-l\-l\-a\-t\-i\-o\-n \tabularnewline
+\hline
+5 & p\-r\-e\-b\-a\-s\-e\-c\-o\-n\-f\-i\-g$^{\text{a\-)}}$ & F\-i\-n\-i\-s\-h u\-p t\-h\-e i\-n\-s\-t\-a\-l\-l\-a\-t\-i\-o\-n a\-n\-d r\-e\-b\-o\-o\-t \tabularnewline
+\hline
+\end{longtable}
+\end{center}
+
+ $^{\text{a)}}$ Will soon be renamed to \texttt{%% texclean(hyphenon)
+f\-i\-n\-i\-s\-h\--{}\-i\-n\-s\-t\-a\-l\-l%% texclean(hyphenoff)
+}. The name {`}\texttt{%% texclean(hyphenon)
+p\-r\-e\-b\-a\-s\-e\-c\-o\-n\-f\-i\-g%% texclean(hyphenoff)
+}{'} no longer makes any sense as \texttt{%% texclean(hyphenon)
+b\-a\-s\-e\--{}\-c\-o\-n\-f\-i\-g%% texclean(hyphenoff)
+} was obsoleted with Etch Beta 2.
+
+
+\subsection{Installation methods}
+ The installer supports a lot of different installation methods and in some cases installation methods can be creatively combined. The definition of an installation method is based on the following questions.
+ \begin{itemize}
+
+\item{} How is the installer booted?
+
+
+\item{} From where are additional udebs retrieved?
+
+
+\item{} From where are packages needed to install the base system retrieved?
+
+
+\item{} From where are packages needed to install tasks retrieved\footnote{
+ The last question can also be rephrased as {`}what source lines are set up in the \texttt{%% texclean(hyphenon)
+/\-e\-t\-c\-/\-a\-p\-t\-/\-s\-o\-u\-r\-c\-e\-s\-.\-l\-i\-s\-t%% texclean(hyphenoff)
+} file for the target system{'}.
+
+}?
+
+\end{itemize}
+
+
+ The table below shows the answers to these questions for the most common installation methods.
+
+\begin{center}
+%%% parse_table %%%
+\resizetable{5}{5}{0cm}{}
+\begin{longtable}{|>{\raggedright}p{\tsize}|>{\raggedright}p{\tsize}|>{\raggedright}p{\tsize}|>{\raggedright}p{\tsize}|>{\raggedright}p{\tsize}|}
+\hline
+\rowcolor[gray]{.9}
+M\-e\-t\-h\-o\-d & B\-o\-o\-t & U\-d\-e\-b\-s & B\-a\-s\-e s\-y\-s\-t\-e\-m & T\-a\-s\-k\-s \tabularnewline
+\hline
+\endhead
+\hline
+n\-e\-t\-b\-o\-o\-t & n\-e\-t\-w\-o\-r\-k (\-T\-F\-T\-P s\-e\-r\-v\-e\-r\-) & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+m\-i\-n\-i\-.\-i\-s\-o & C\-D & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+b\-u\-s\-i\-n\-e\-s\-s\-c\-a\-r\-d C\-D & C\-D & C\-D & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+n\-e\-t\-i\-n\-s\-t C\-D & C\-D & C\-D & C\-D & n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+f\-u\-l\-l C\-D\-/\-D\-V\-D & C\-D & C\-D & C\-D & C\-D (\-+ n\-e\-t\-w\-o\-r\-k\-) \tabularnewline
+\hline
+h\-d\--{}\-m\-e\-d\-i\-a$^{\text{a\-)}}$ & h\-a\-r\-d\-d\-i\-s\-k\-/\-U\-S\-B s\-t\-i\-c\-k & C\-D i\-m\-a\-g\-e & C\-D i\-m\-a\-g\-e\-/\-n\-e\-t\-w\-o\-r\-k & C\-D i\-m\-a\-g\-e\-/\-n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+f\-l\-o\-p\-p\-y (\-n\-e\-t\-) & b\-o\-o\-t\-/\-r\-o\-o\-t\-/\-n\-e\-t\--{}\-d\-r\-i\-v\-e\-r\-s & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+f\-l\-o\-p\-p\-y (\-c\-d\-)$^{\text{a\-)}}$ & b\-o\-o\-t\-/\-r\-o\-o\-t\-/\-c\-d\--{}\-d\-r\-i\-v\-e\-r\-s & C\-D & C\-D\-/\-n\-e\-t\-w\-o\-r\-k & C\-D\-/\-n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+\end{longtable}
+\end{center}
+
+ $^{\text{a)}}$ Whether packages for the base system and tasks are retrieved from CD (image) or the network depends on the type of CD used in combination with these boot methods.
+
+
+\subsection{The boot process}
+ The boot process for the installer is similar to the boot of a regular system. A bootloader (in some cases the system's firmware) is responsible for loading the kernel and loading the initrd after which init is started. The boot process can be debugged by adding the {\bf {\tt BOOT\_DEBUG}} parameter.
+
+
+ It is possible to pass additional kernel and boot parameters. Kernel parameters are sometimes needed to get non-{}conformant hardware supported, or to install from serial console instead of an attached keyboard/display.
+
+
+ Boot parameters can also be used to influence the installer itself. More about this in the section on preseeding.
+
+
+ The boot process is currently quite complex as it needs to support several generations of linux:
+ \begin{itemize}
+
+\item{} 2.2, 2.4 and 2.6 kernels with devfs, all subtly different
+
+
+\item{} 2.6 kernels with udev; several generations, both with and without hotplug
+
+\end{itemize}
+
+
+ The following enumeration gives an overview of the main steps in the boot process.
+
+
+\noindent
+\begin{description}
+\item[{1) \textbf{/init} (initramfs) or \textbf{/sbin/init} (initrd)}] Sets up initial environment (\texttt{%% texclean(hyphenon)
+/\-p\-r\-o\-c%% texclean(hyphenoff)
+}, \texttt{%% texclean(hyphenon)
+/\-d\-e\-v%% texclean(hyphenoff)
+}; run \textbf{udev})
+
+\item[{2) \textbf{busybox init}}] \texttt{%% texclean(hyphenon)
+/\-e\-t\-c\-/\-i\-n\-i\-t\-t\-a\-b%% texclean(hyphenoff)
+} is parsed; this contains:
+ \begin{itemize}
+
+\item{}\texttt{%% texclean(hyphenon)
+:\-:\-s\-y\-s\-i\-n\-i\-t\-:\-/\-s\-b\-i\-n\-/\-d\-e\-b\-i\-a\-n\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\--{}\-s\-t\-a\-r\-t\-u\-p%% texclean(hyphenoff)
+}
+
+\item{}\texttt{%% texclean(hyphenon)
+:\-:\-r\-e\-s\-p\-a\-w\-n\-:\-/\-s\-b\-i\-n\-/\-d\-e\-b\-i\-a\-n\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r%% texclean(hyphenoff)
+}
+
+\item{} init for VT2 (busybox shell), VT3 (\texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-o\-g\-/\-m\-e\-s\-s\-a\-g\-e\-s%% texclean(hyphenoff)
+}), VT4 (\texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-o\-g\-/\-s\-y\-s\-l\-o\-g%% texclean(hyphenoff)
+})
+
+\end{itemize}
+
+\item[{3) \textbf{/sbin/debian-{}installer-{}startup}}] This is a run-{}parts like script that executes or sources scripts in \texttt{%% texclean(hyphenon)
+/\-l\-i\-b\-/\-d\-e\-b\-i\-a\-n\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\--{}\-s\-t\-a\-r\-t\-u\-p\-.\-d%% texclean(hyphenoff)
+}. The main functions that are performed are:
+ \begin{itemize}
+
+\item{} mount \texttt{%% texclean(hyphenon)
+d\-e\-v\-f\-s%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+s\-y\-s\-f\-s%% texclean(hyphenoff)
+} if appropriate
+
+
+\item{} run \textbf{udev}/\textbf{hotplug}
+
+\item{} load acpi modules
+
+
+\item{} start syslog
+
+
+\item{} check available memory and, depending on preset limits, enable a lowmem mode if needed
+
+
+\item{} load any debconf templates present in the initrd
+
+
+\item{} parse boot parameters to look for debconf patterns ({\bf {\tt <\texttt{\emph{\small{%% texclean(hyphenon)
+c\-o\-m\-p\-o\-n\-e\-n\-t%% texclean(hyphenoff)
+}}}>/<\texttt{\emph{\small{%% texclean(hyphenon)
+t\-e\-m\-p\-l\-a\-t\-e%% texclean(hyphenoff)
+}}}>=<\texttt{\emph{\small{%% texclean(hyphenon)
+v\-a\-l\-u\-e%% texclean(hyphenoff)
+}}}>}}) and set these in the debconf database
+
+
+\item{} detect the type of console that is used
+
+
+\item{} load framebuffer modules
+
+
+\item{} detect if the installer should run in rescue mode
+
+\end{itemize}
+
+\item[{4) \textbf{/sbin/debian-{}installer}}] This is a run-{}parts like script that sources scripts in \texttt{%% texclean(hyphenon)
+/\-l\-i\-b\-/\-d\-e\-b\-i\-a\-n\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\-.\-d%% texclean(hyphenoff)
+}. The main functions that are performed are:
+ \begin{itemize}
+
+\item{} detect if a framebuffer device is available
+
+
+\item{} initialize the console (blanking, UTF-{}8)
+
+
+\item{} select which debconf frontend is to be used (text, newt, gtk)
+
+
+\item{} start \texttt{%% texclean(hyphenon)
+m\-a\-i\-n\--{}\-m\-e\-n\-u%% texclean(hyphenoff)
+} (see next section)
+
+
+\item{} halt or reboot the system (after \texttt{%% texclean(hyphenon)
+m\-a\-i\-n\--{}\-m\-e\-n\-u%% texclean(hyphenoff)
+} exits)
+
+\end{itemize}
+
+\end{description}
+
+ Scripts in \texttt{%% texclean(hyphenon)
+/\-l\-i\-b\-/\-d\-e\-b\-i\-a\-n\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\-(\--{}\-s\-t\-a\-r\-t\-u\-p\-)\-.\-d%% texclean(hyphenoff)
+} can be architecture specific.
+
+
+\subsection{The Debian Installer Menu}
+ The component \texttt{%% texclean(hyphenon)
+m\-a\-i\-n\--{}\-m\-e\-n\-u%% texclean(hyphenoff)
+} drives the rest of the installation. It is responsible both for dynamically assembling the menu and for executing components when they are selected. Note that the menu is only actually visible when installing at low or medium debconf priority. At higher priorities it is still there, but it will automatically execute the next component without showing the menu to the user.
+
+
+ In some situations the debconf priority is automatically changed. It is reduced when the execution of a component fails, or when the user uses the {\bf {\tt <go back>}} button to back out all the way to the menu. In these cases it will also be increased back to the original level when the next component executed finishes successfully.
+
+
+ An important characteristic of udebs is that execution of their postinst scripts is delayed. On installation udebs are only unpacked; the execution of the postinst is done by main-{}menu and is actually what happens when a component is selected in the menu. In other words, main-{}menu can be said to be responsible for {`}configuring{'} the udeb.
+
+
+ For a component to be included in the menu, it needs to have an \texttt{%% texclean(hyphenon)
+I\-n\-s\-t\-a\-l\-l\-e\-r\--{}\-M\-e\-n\-u\--{}\-I\-t\-e\-m%% texclean(hyphenoff)
+} line in the \texttt{%% texclean(hyphenon)
+d\-p\-k\-g%% texclean(hyphenoff)
+} status file (\texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-i\-b\-/\-d\-p\-k\-g\-/\-s\-t\-a\-t\-u\-s%% texclean(hyphenoff)
+}). The order of components in the menu is determined primarily by its dependencies; the menu item number is used only where the order for two or more components cannot be resolved by dependencies alone.
+
+
+ Provides can be used to define virtual states which other components can depend on, as shown in the next example.
+
+\begin{lstlisting}[firstnumber=1,]
+Package: netcfg
+Status: install ok installed
+Version: 1.23
+Provides: configured-network
+Depends: libc6 (>= 2.3.5-1), libdebconfclient0, libdebian-installer4 (>= 0.37),
+ dhcp-client-udeb | dhcp3-client-udeb | pump-udeb, libiw28-udeb,
+ cdebconf-udeb, ethernet-card-detection
+Description: Configure the network
+Installer-Menu-Item: 18
+
+Package: choose-mirror
+Status: install ok unpacked
+Version: 1.19
+Depends: libc6 (>= 2.3.5-1), libdebconfclient0, libdebian-installer4 (>= 0.38),
+ configured-network
+Description: Choose mirror to install from
+Installer-Menu-Item: 23
+\end{lstlisting}
+
+
+ This example also shows that netcfg has been run successfully ({`}installed{'}) while mirror selection has not yet taken place ({`}unpacked{'}).
+
+
+ Some components are included in the menu but are not run by default. These components have a menu number higher than prebaseconfig. Examples are components that allow to change the debconf priority, to save debug logs, to check the integrity of a CD-{}ROM or to abort the installation.
+
+
+\subsection{Hooks provide additional flexibility}
+ At certain points in the installation, components provide run-{}parts like execution of scripts. This allows other components to just drop scripts there so that commands can be run at that point in the installation, even though the postinst for the component itself is run earlier or later (if the component even has a postinst).
+
+
+ The main hooks are:
+
+\noindent
+\begin{description}
+\item[{\texttt{%% texclean(hyphenon)
+/\-u\-s\-r\-/\-l\-i\-b\-/\-b\-a\-s\-e\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\-.\-d%% texclean(hyphenoff)
+}}] Run by base-{}installer before debootstrap is started.
+
+\item[{\texttt{%% texclean(hyphenon)
+/\-u\-s\-r\-/\-l\-i\-b\-/\-p\-o\-s\-t\--{}\-b\-a\-s\-e\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\-.\-d%% texclean(hyphenoff)
+}}] Run by base-{}installer just before kernel selection/installation.
+
+\item[{\texttt{%% texclean(hyphenon)
+/\-u\-s\-r\-/\-l\-i\-b\-/\-p\-r\-e\-b\-a\-s\-e\-c\-o\-n\-f\-i\-g\-.\-d%% texclean(hyphenoff)
+}}] Run by prebaseconfig.
+
+\end{description}
+
+
+ Other, more special purpose hooks are \texttt{%% texclean(hyphenon)
+/\-u\-s\-r\-/\-l\-i\-b\-/\-a\-p\-t\--{}\-s\-e\-t\-u\-p\-/\-g\-e\-n\-e\-r\-a\-t\-o\-r\-s%% texclean(hyphenoff)
+}, \texttt{%% texclean(hyphenon)
+/\-l\-i\-b\-/\-m\-a\-i\-n\--{}\-m\-e\-n\-u\-.\-d%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+/\-l\-i\-b\-/\-r\-e\-s\-c\-u\-e\-.\-d%% texclean(hyphenoff)
+}.
+
+
+ Besides these general hooks, partman is basically structured as one big collection of hooks where partman components all drop their own scriptlets to extend partman's functionality. The most noteworthy of these hooks is \texttt{%% texclean(hyphenon)
+/\-l\-i\-b\-/\-p\-a\-r\-t\-m\-a\-n\-/\-f\-i\-n\-i\-s\-h\-.\-d%% texclean(hyphenoff)
+} as some bootloaders drop scripts there to add checks that ensure the selected partitioning scheme conforms to their requirements.
+
+
+\subsection{Some special tools}
+ The installer has some special commands which can be used in postinst or preseeding scripts:
+
+\noindent
+\begin{description}
+\item[{\textbf{anna-{}install}}] Used to install additional, non-{}standard d-{}i components (udebs). It will check if \texttt{%% texclean(hyphenon)
+a\-n\-n\-a%% texclean(hyphenoff)
+} has already been run. If it has, the component is unpacked immediately; if it has not, it will be scheduled for installation when \texttt{%% texclean(hyphenon)
+a\-n\-n\-a%% texclean(hyphenoff)
+} is run.
+
+\item[{\textbf{apt-{}install}}] Performs the same function for normal packages and installs them in the target system. Packages will either be installed immediately (if called after base-{}installer) or scheduled for installation as one of the {`}extra{'} packages installed near the end of base-{}installer's postinst script.
+
+\item[{\textbf{log-{}output}}] Allows to run a command and redirect its output (either \texttt{%% texclean(hyphenon)
+s\-t\-d\-o\-u\-t%% texclean(hyphenoff)
+} or \texttt{%% texclean(hyphenon)
+s\-t\-d\-e\-r\-r%% texclean(hyphenoff)
+} or both) to \texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-o\-g\-/\-s\-y\-s\-l\-o\-g%% texclean(hyphenoff)
+}.
+
+\item[{\textbf{in-{}target}}] Allows to run a command in a chroot on \texttt{%% texclean(hyphenon)
+/\-t\-a\-r\-g\-e\-t%% texclean(hyphenoff)
+} with the chroot being set up for more demanding operations. For example, \texttt{%% texclean(hyphenon)
+p\-r\-o\-c%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+s\-y\-s\-f\-s%% texclean(hyphenoff)
+} are mounted and a \texttt{%% texclean(hyphenon)
+p\-o\-l\-i\-c\-y\--{}\-r\-c\-.\-d%% texclean(hyphenoff)
+} is created. Can obviously only be used after the base system has been set up.
+
+\end{description}
+
+
+\subsection{Automating the install using preseeding}
+ There are three preseed methods that are currently supported:
+
+\noindent
+\begin{description}
+\item[{\emph{initrd preseeding}}] The preseed file \texttt{%% texclean(hyphenon)
+/\-p\-r\-e\-s\-e\-e\-d\-.\-c\-f\-g%% texclean(hyphenoff)
+} needs to be present in the initrd. It is read as part of the \textbf{debian-{}installer-{}startup} processing.
+
+\item[{\emph{file preseeding}}] Triggered by the presence of the {\bf {\tt preseed/file}} boot parameter.
+
+\item[{\emph{network preseeding}}] Triggered by the presence of the {\bf {\tt preseed/url}} boot parameter. In versions later than Etch Beta 2 it is also possible to trigger this from the DHCP server.
+
+\end{description}
+ Which of these methods is available depends on the installation method.
+
+
+ The main purpose of preseeding is to set default values for debconf questions. Note that it makes no sense when using file or network preseeding to preseed values for questions that are asked \emph{before} the preseed file is parsed.
+
+
+ Besides offering the option to set default values for debconf questions, preseeding also makes it possible to run scripts at two distinct moments using {\bf {\tt preseed/early\_command}} and {\bf {\tt preseed/late\_command}}. The {\bf {\tt early\_command}} is executed immediately after the preseed file is parsed (only for file and network preseeding); the {\bf {\tt late\_command}} is executed as part of the \textbf{prebaseconfig} component.
+
+
+ These scripts can be made as complex as you like. One option is to use them to install additional packages on the target system (using \textbf{apt-{}install}). The {\bf {\tt early\_command}} could be used to install additional d-{}i components (using \textbf{anna-{}install}) or to install scripts in the various hook script directories (if commands need to be executed at a specific point in the installation).
+
+
+ Additional information about preseeding is available in an appendix of the Installation Guide.
+
+
+\subsection{Debugging the installer}
+ Because most of the installer is scripted, it is fairly easy to debug most problems by adding a {\bf {\tt set -{}x}} in the correct place. The obvious place to start is the postinst of the component you want to debug. The output will appear in \texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-o\-g\-/\-s\-y\-s\-l\-o\-g%% texclean(hyphenoff)
+}, which can most easily be viewed by starting the internal webserver from the {`}Save debug logs{'} menu option (after the network has been configured).
+
+
+ For components written in C debugging is a bit harder. Options are to use the strace udeb (add it to a custom image if needed) or to create a custom version of a component with added debug statements in the source and use that.
+
+
+ For debugging, you will probably want to control when components are started. Booting the installer with {\bf {\tt install debconf/priority=medium}} is a good way to achieve that. It will make sure the menu is displayed before a new component is started.
+
+
+ If you boot the installer at medium priority, you will also be able to load the optional component \texttt{%% texclean(hyphenon)
+o\-p\-e\-n\--{}\-s\-s\-h\--{}\-c\-l\-i\-e\-n\-t%% texclean(hyphenoff)
+}\footnote{
+ If you want to load optional components when installing at the default priority, just back out to the menu and select the component that installs additional installer components.
+
+}. Loading this component will allow you to use \textbf{scp} to copy files from the system being installed to another computer and vice versa. Also useful for testing new versions of scripts or commands without rebuilding the udeb and image. The command \textbf{nc} from the \texttt{%% texclean(hyphenon)
+n\-e\-t\-c\-a\-t%% texclean(hyphenoff)
+} package is available by default in the installer.
+
+
+\section{D-{}I components or udebs}
+ A udeb (or micro-{}deb) is a special kind of Debian package. Technically udebs are very similar to regular packages: you can look at their contents using \textbf{dpkg -{}c}, and extract them using \textbf{dpkg -{}x} and \textbf{dpkg -{}e}.
+
+
+ The main difference is that a lot of policy requirements are waived. For example, a udeb does not contain a changelog, licence, manpages or md5sum\footnote{
+ Of course, the source package for a udeb \emph{does} need to contain a proper licence and changelog.
+
+}. The reason is to minimize size which is important as the installation completely takes place in RAM, with swap only becoming available after stage 4 of the installation (partitioning).
+
+
+ Another important difference is that udebs are not really meant to be uninstalled or upgraded.
+
+
+ The relaxed policy requirements make one of the reasons that udebs should to be installed on a normal system. The other reason being that it just doesn't make sense and it's likely to break things.
+
+
+ Two special classes of udebs should be mentioned here. However, covering these in detail is outside the scope of this paper.
+
+\noindent
+\begin{description}
+\item[{Kernel image and kernel module udebs}] Kernel udebs are built basically by repackaging a regular kernel-{}image package. Reason is again to reduce memory usage: not all modules included in a kernel-{}image package are needed during an installation. Also, different modules are needed in the initrd for different installation methods, remaining modules can either be loaded later or optionally (by manual selection or through dependencies). The package \texttt{%% texclean(hyphenon)
+k\-e\-r\-n\-e\-l\--{}\-w\-e\-d\-g\-e%% texclean(hyphenoff)
+} contains the toolset used to reorganize a kernel-{}image package into multiple kernel (module) udebs.
+
+\item[{Partman and its components}] Partman has a very specific structure and requires a fairly strict conformance to this structure for udebs that extend its functionality.
+
+\end{description}
+
+
+\subsection{Contents of a udeb}
+ For components that are included in the main menu, the udeb will at least contain:
+ \begin{itemize}
+
+\item{} a postinst
+
+
+
+\item{} a debconf template that contains the description for the main menu:
+
+\begin{lstlisting}[firstnumber=1,]
+debian-installer/<component>/title
+Type: text
+_Description: Configure time zone
+\end{lstlisting}
+
+
+\end{itemize}
+
+
+ Other things like additional debconf templates, C programs, hook scripts can be added as needed.
+
+
+ A special type of control file worth mentioning is the \texttt{%% texclean(hyphenon)
+i\-s\-i\-n\-s\-t\-a\-l\-l\-a\-b\-l\-e%% texclean(hyphenoff)
+} file. If a script with this name is present in \texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-i\-b\-/\-d\-p\-k\-g\-/\-i\-n\-f\-o%% texclean(hyphenoff)
+} for a component, the main menu will run this script and only include the component in the menu if the script exits 0.
+
+
+\subsection{Creating a udeb}
+ Creating a udeb is not all that hard, especially if you use \texttt{%% texclean(hyphenon)
+d\-e\-b\-h\-e\-l\-p\-e\-r%% texclean(hyphenoff)
+}. \texttt{%% texclean(hyphenon)
+d\-e\-b\-h\-e\-l\-p\-e\-r%% texclean(hyphenoff)
+} knows the special properties of a udeb and will do the right thing by default at build time. That is, if you don't forget to tell it you are creating a udeb.
+
+
+ The example below shows the \texttt{%% texclean(hyphenon)
+d\-e\-b\-i\-a\-n\-/\-c\-o\-n\-t\-r\-o\-l%% texclean(hyphenoff)
+} file for a udeb that is supposed to be included in the main menu. Note the special section.
+
+
+\begin{lstlisting}[firstnumber=1,]
+Source: kbd-chooser
+Section: debian-installer
+Priority: optional
+Maintainer: Debian Install System Team <debian-boot at lists.debian.org>
+Uploaders: [...]
+Build-Depends: debhelper (>= 5.0.22), libdebian-installer4-dev (>= 0.41), po-debconf (>= 0.5.0), flex | flex-old , bison, libdebconfclient0-dev (>= 0.49)
+
+Package: kbd-chooser
+Architecture: i386 amd64 powerpc alpha hppa sparc [...]
+XC-Package-Type: udeb
+Depends: ${shlibs:Depends}, ${misc:Depends}, console-keymaps
+Description: Detect a keyboard and select layout
+XB-Installer-Menu-Item: 12
+\end{lstlisting}
+
+ The line \texttt{%% texclean(hyphenon)
+X\-C\--{}\-P\-a\-c\-k\-a\-g\-e\--{}\-T\-y\-p\-e%% texclean(hyphenoff)
+} tells \texttt{%% texclean(hyphenon)
+d\-e\-b\-h\-e\-l\-p\-e\-r%% texclean(hyphenoff)
+} to treat the package as a udeb. The \texttt{%% texclean(hyphenon)
+X\-B\--{}\-I\-n\-s\-t\-a\-l\-l\-e\-r\--{}\-M\-e\-n\-u\--{}\-I\-t\-e\-m%% texclean(hyphenoff)
+} is added in the control file for the udeb and will eventually end up in the \texttt{%% texclean(hyphenon)
+d\-p\-k\-g%% texclean(hyphenoff)
+} status file to help \texttt{%% texclean(hyphenon)
+m\-a\-i\-n\--{}\-m\-e\-n\-u%% texclean(hyphenoff)
+} figure out that this udeb should be included in the menu and in what order\footnote{
+ The file \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-d\-o\-c\-/\-d\-e\-v\-e\-l\-/\-m\-e\-n\-u\--{}\-i\-t\-e\-m\--{}\-n\-u\-m\-b\-e\-r\-s\-.\-t\-x\-t%% texclean(hyphenoff)
+} in the d-{}i SVN repository documents menu numbers currently in use.
+
+}.
+ Packaging a udeb becomes a bit harder if it is derived from a regular package but needs to be compiled with different compiler options (e.g. some features disabled or a different optimization).
+
+
+ The main thing to always keep in mind when creating a udeb is size. It is very important to keep size as minimal as possible. This includes using tabs instead of spaces when indenting in scripts and not being too verbose in comments.
+
+
+\subsection{Library udebs}
+ A major recent improvement is the addition of {`}package type{'} support in shlibs files for libraries. This allows \textbf{dpkg-{}dev} and \texttt{%% texclean(hyphenon)
+d\-e\-b\-h\-e\-l\-p\-e\-r%% texclean(hyphenoff)
+} to automatically set correct dependencies on library udebs when a d-{}i component that depends on them is built.
+
+
+ For example, the regular binary package \texttt{%% texclean(hyphenon)
+z\-l\-i\-b\-1\-g%% texclean(hyphenoff)
+} now has the following lines in its shlibs control file:
+
+\begin{lstlisting}[firstnumber=1,]
+libz 1 zlib1g (>= 1:1.2.1)
+udeb: libz 1 zlib1g-udeb (>= 1:1.2.1)
+\end{lstlisting}
+
+
+ The second line is specific to the package type {`}udeb{'}. This alternative line is used when \textbf{dpkg-{}shlibdeps} is called with the \textbf{-{}tudeb} option; \textbf{dh\_shlibdeps} will automatically add this option when processing a udeb.
+
+
+ Generating the extra \texttt{%% texclean(hyphenon)
+u\-d\-e\-b\-:%% texclean(hyphenoff)
+} lines is supported by \textbf{dh\_makeshlibs} if the \textbf{-{}-{}add-{}udeb="<udeb name>"} option is used. For example, the \texttt{%% texclean(hyphenon)
+d\-e\-b\-i\-a\-n\-/\-r\-u\-l\-e\-s%% texclean(hyphenoff)
+} file for \texttt{%% texclean(hyphenon)
+l\-i\-b\-u\-s\-b%% texclean(hyphenoff)
+} contains the following line:
+
+\begin{lstlisting}[firstnumber=1,]
+dh_makeshlibs -V -s --add-udeb="libusb-0.1-udeb"
+\end{lstlisting}
+
+
+\section{Building installer images}
+ This paper will only provide an introduction to building installer images using existing definitions. The README in \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-b\-u\-i\-l\-d%% texclean(hyphenoff)
+} in the SVN repository contains more detailed information about the build system and how to modify existing or define new images.
+
+
+ An image consists of:
+ \begin{itemize}
+
+\item{} a kernel;
+
+
+\item{} an initrd, which is basically a collection of unpacked udebs;
+
+
+\item{} in some cases a boot loader and/or configuration files used for booting.
+
+\end{itemize}
+
+
+ Most d-{}i images are {`}ready for use{'}. The exception are the cdrom images which form only the base (kernel and initrd) for creating the actual CD or DVD images. The package used for creating the CD/DVD images is \texttt{%% texclean(hyphenon)
+d\-e\-b\-i\-a\-n\--{}\-c\-d%% texclean(hyphenoff)
+}.
+
+
+ On some architectures there is one CD image that \emph{is} ready for use: the \texttt{%% texclean(hyphenon)
+m\-i\-n\-i\-.\-i\-s\-o%% texclean(hyphenoff)
+} that is produced as a by-{}product of the netboot target. Reason is that this image does not really support installing from CD, it just allows booting from CD but retrieves all additional udebs and packages over the network.
+
+
+ It is important to distinguish between building images for release and building images for development/testing use.
+
+
+ A release build is done, as for other packages that are to be uploaded, from the \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r%% texclean(hyphenoff)
+} directory using \textbf{debian/rules}. This will create a binary package (needed for uploading) containing some documentation, but the important bit is a tarball containing all installer images. After the upload this tarball needs BYHAND processing\footnote{
+ This entails unpacking the tarball into the correct location on the master mirror server and creating/updating the correct symlinks. See for example \url{http://ftp.debian.org/debian/dists/sid/main/installer-i386/}.
+
+} by FTP-{}masters before the buildds will pick up the upload for other architectures.
+
+
+ Building images for development and testing is done from the \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-b\-u\-i\-l\-d%% texclean(hyphenoff)
+} directory\footnote{
+ This includes the daily built images available from \url{http://www.debian.org/devel/debian-installer}. These are generated and uploaded from machines run by d-{}i porters using the daily-{}build script.
+
+} using \textbf{fakeroot make <\texttt{\emph{\small{%% texclean(hyphenon)
+t\-a\-r\-g\-e\-t%% texclean(hyphenoff)
+}}}>}.
+
+
+ An important difference between release and development builds is that release builds will use udebs for the same suite as the target system being installed, while development builds will by default install testing, but use udebs from unstable\footnote{
+ This is accomplished by including the \texttt{%% texclean(hyphenon)
+/\-i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-b\-u\-i\-l\-d\-/\-u\-n\-s\-t\-a\-b\-l\-e\-.\-c\-f\-g%% texclean(hyphenoff)
+} preseed file in the initrd.
+
+}. This allows to mostly avoid the occasional breakage of the base system and tasks in unstable while using the most recent udebs.
+
+
+\subsection{Requirements for building}
+ For both release and development builds the build dependencies as listed in \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-d\-e\-b\-i\-a\-n\-/\-c\-o\-n\-t\-r\-o\-l%% texclean(hyphenoff)
+} need to be satisfied.
+
+
+ To build installer images from SVN trunk, your build machine needs to be running unstable or you need to set up a sid chroot to build in. (To build images from the sarge branch of the repository, the build machine needs to run Sarge.)
+
+
+ During the build, the needed udebs will be retrieved from a mirror. By default this mirror is based on your \texttt{%% texclean(hyphenon)
+/\-e\-t\-c\-/\-a\-p\-t\-/\-s\-o\-u\-r\-c\-e\-s\-.\-l\-i\-s\-t%% texclean(hyphenoff)
+} (see the generated file \texttt{%% texclean(hyphenon)
+b\-u\-i\-l\-d\-/\-s\-o\-u\-r\-c\-e\-s\-.\-l\-i\-s\-t\-.\-u\-d\-e\-b%% texclean(hyphenoff)
+}). To use a different source, create a file \texttt{%% texclean(hyphenon)
+s\-o\-u\-r\-c\-e\-s\-.\-l\-i\-s\-t\-.\-u\-d\-e\-b\-.\-l\-o\-c\-a\-l%% texclean(hyphenoff)
+}.
+
+
+\subsection{Build targets}
+ To see which targets are available, run \textbf{make}. This will result in a list of some 130 targets, most of which are not really relevant. A more useful list can be obtained with \textbf{make | grep \^{}build}. The table below has the most often used targets for i386.
+ \begin{center}
+%%% parse_table %%%
+\resizetable{2}{2}{0cm}{}
+\begin{longtable}{|>{\raggedright}p{\tsize}|>{\raggedright}p{\tsize}|}
+\hline
+{\bf {\tt b\-u\-i\-l\-d\-\_\-a\-l\-l}} & B\-u\-i\-l\-d\-s a\-l\-l i\-m\-a\-g\-e\-s \tabularnewline
+\hline
+{\bf {\tt b\-u\-i\-l\-d\-\_\-c\-d\-r\-o\-m\-\_\-i\-s\-o\-l\-i\-n\-u\-x}} & B\-u\-i\-l\-d\-s t\-h\-e c\-d\-r\-o\-m i\-m\-a\-g\-e\-s (\-b\-o\-t\-h 2\-.\-4 a\-n\-d 2\-.\-6\-) \tabularnewline
+\hline
+{\bf {\tt b\-u\-i\-l\-d\-\_\-n\-e\-t\-b\-o\-o\-t}} & B\-u\-i\-l\-d\-s t\-h\-e n\-e\-t\-b\-o\-o\-t i\-m\-a\-g\-e\-s (\-b\-o\-t\-h 2\-.\-4 a\-n\-d 2\-.\-6\-) a\-n\-d t\-h\-e m\-i\-n\-i\-.\-i\-s\-o \tabularnewline
+\hline
+{\bf {\tt r\-e\-a\-l\-l\-y\-c\-l\-e\-a\-n}} & C\-o\-m\-p\-l\-e\-t\-e\-l\-y c\-l\-e\-a\-n\-s t\-h\-e b\-u\-i\-l\-d e\-n\-v\-i\-r\-o\-n\-m\-e\-n\-t \tabularnewline
+\hline
+\end{longtable}
+\end{center}
+ The {\bf {\tt reallyclean}} target is often needed when changes are made between builds because otherwise udebs or information may be retrieved from temporary or cache directories and the changes will not take effect. The \texttt{%% texclean(hyphenon)
+r\-e\-b\-u\-i\-l\-d\-\_\-*%% texclean(hyphenoff)
+} targets clean some of this, but not always enough.
+
+
+\subsection{The build system explained}
+ The easiest way to start is with the purpose of the subdirectories in the \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-b\-u\-i\-l\-d%% texclean(hyphenoff)
+} directory.
+
+\begin{itemize}
+
+\item{} \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g%% texclean(hyphenoff)
+}: defines the available targets (per architecture)
+
+
+
+\item{} \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s%% texclean(hyphenoff)
+}: defines which udebs are included in an image (per image type)
+
+
+
+\item{} \texttt{%% texclean(hyphenon)
+b\-o\-o\-t%% texclean(hyphenoff)
+}: contains configuration files and make targets used to make images bootable
+
+
+
+\item{} \texttt{%% texclean(hyphenon)
+l\-o\-c\-a\-l\-u\-d\-e\-b\-s%% texclean(hyphenoff)
+}: allows to use (versions of) udebs not available on the mirror you use
+
+
+
+\item{} \texttt{%% texclean(hyphenon)
+u\-t\-i\-l%% texclean(hyphenoff)
+}: contains helper scripts called from the Makefile
+
+
+\end{itemize}
+
+ Two files containing important configuration info are \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g\-/\-d\-i\-r%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g\-/\-c\-o\-m\-m\-o\-n%% texclean(hyphenoff)
+}. However, normally there should be no need to modify any of the variables defined in these files.
+
+
+ Both the \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s%% texclean(hyphenoff)
+} directories have a tree structure with general configuration defined in the root and more specific configuration defined in branches and leaves. Branches are defined in directories that have the same name as a config file on the higher level. The \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g%% texclean(hyphenoff)
+} directory contains makefile snippets.
+
+
+\subsubsection{config}
+ For example, the definition for i386 images starts with \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g\-/\-i\-3\-8\-6\-.\-c\-f\-g%% texclean(hyphenoff)
+} which, besides the current kernel versions, defines the media supported with the line:
+
+\begin{lstlisting}[firstnumber=1,]
+MEDIUM_SUPPORTED = cdrom netboot floppy hd-media
+\end{lstlisting}
+
+
+ These media correspond to the main targets for i386 and are further defined in \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g\-/\-i\-3\-8\-6%% texclean(hyphenoff)
+}. The \texttt{%% texclean(hyphenon)
+n\-e\-t\-b\-o\-o\-t\-.\-c\-f\-g%% texclean(hyphenoff)
+} file in that directory contains, amongst others, the following three lines:
+
+\begin{lstlisting}[firstnumber=1,]
+FLAVOUR_SUPPORTED = "" 2.6
+MEDIA_TYPE = netboot image
+EXTRATARGETS = build_netboot_2.6
+\end{lstlisting}
+
+
+ This defines that the netboot image has two flavors: the default one (using a 2.4 kernel) and an one using a 2.6 kernel, which is further defined in the \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g\-/\-i\-3\-8\-6\-/\-n\-e\-t\-b\-o\-o\-t\-/\-2\-.\-6\-.\-c\-f\-g%% texclean(hyphenoff)
+} file where the default values of the variables for the kernel version are overruled.
+
+
+ The files in config are processed recursively to dynamically generate the build targets, so in this example you get a netboot, a {\bf {\tt netboot\_2.6}} target and targets for the other media. Building is also recursive, so calling the netboot target will automatically build both the {\bf {\tt netboot}} and {\bf {\tt netboot\_2.6}} images.
+
+
+ The structure of the config files can get quite complex and it can be hard to keep track of the exact role of the different variables set in them.
+
+
+\subsubsection{pkg-{}lists}
+ The list of udebs to be included in an image is built by the \textbf{util/pkg-{}list} script based on definitions in the \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s%% texclean(hyphenoff)
+} directory. Again, processing can be quite complex. Let's take the netboot target for i386 as an example to explain it.
+
+
+ First the file \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-n\-e\-t\-b\-o\-o\-t\-/\-i\-3\-8\-6\-.\-c\-f\-g%% texclean(hyphenoff)
+} is considered and all udebs listed in it are added. Some example lines from that file:
+
+\begin{lstlisting}[firstnumber=1,]
+#include "discover"
+console-keymaps-at
+console-keymaps-usb
+usb-discover [2.4]
+socket-modules-${kernel:Version} ?
+acpi-modules-${kernel:Version} [2.6]
+\end{lstlisting}
+
+
+ The variable \texttt{%% texclean(hyphenon)
+\$\-\{\-k\-e\-r\-n\-e\-l\-:\-V\-e\-r\-s\-i\-o\-n\-\}%% texclean(hyphenoff)
+} is expanded to match the package name of the udeb based on the kernel version and flavor. If the name of a udebs is followed by {`}[2.4]{'} or {`}[2.6]{'}, it is only included if the kernel major version for the image being built matches. If it is followed by a question mark it is skipped if the package is not available (without the question mark an error would be generated).
+
+
+ The first line with the \texttt{%% texclean(hyphenon)
+\#\-i\-n\-c\-l\-u\-d\-e%% texclean(hyphenoff)
+} results in the file \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-d\-i\-s\-c\-o\-v\-e\-r%% texclean(hyphenoff)
+} being processed next in the same way.
+
+
+ The \textbf{pkg-{}list} script will also always look for the presence of files named \texttt{%% texclean(hyphenon)
+c\-o\-m\-m\-o\-n%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+l\-o\-c\-a\-l%% texclean(hyphenoff)
+} and thus \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-n\-e\-t\-b\-o\-o\-t\-/\-c\-o\-m\-m\-o\-n%% texclean(hyphenoff)
+} is processed next. This file exists and lists a number of udebs that belong in any netboot image, independent of the architecture. This file also contains two include directives:
+
+\begin{lstlisting}[firstnumber=1,]
+#include "base"
+#include "kernel"
+\end{lstlisting}
+
+
+ Thus, udebs listed in \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-b\-a\-s\-e%% texclean(hyphenoff)
+} (containing udebs common to all images) and \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-k\-e\-r\-n\-e\-l%% texclean(hyphenoff)
+} (included in all bootable images) are also processed.
+
+
+ The file \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-n\-e\-t\-b\-o\-o\-t\-/\-l\-o\-c\-a\-l%% texclean(hyphenoff)
+} does not normally exist as it is intended for the inclusion of non-{}standard udebs. It is also very useful for testing as it can be used to temporarily add udebs not normally included without teh need to modify the regular files.
+
+
+ Finally, the script will check for \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-l\-o\-c\-a\-l%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-e\-x\-c\-l\-u\-d\-e%% texclean(hyphenoff)
+}. The latter exists and contains some udebs otherwise pulled in by dependencies, but that should not be included because of library reduction, which is covered in the next section. Note that the exclusion if not triggered by the file name, but rather by the dash after the name of the udebs.
+
+
+ All dependencies of udebs listed in \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s%% texclean(hyphenoff)
+} will also be automatically included in the image.
+
+
+ To see how the package list is built for a particular image, set % <code>
+my \$debug=1; in the \textbf{util/pkg-{}list} script.
+
+
+\subsection{Result of the build}
+ If the build is successful, you will find the images under the \texttt{%% texclean(hyphenon)
+b\-u\-i\-l\-d\-/\-d\-e\-s\-t%% texclean(hyphenoff)
+} directory. Depending on the type of build you will also find manifest and log files there.
+
+
+ Before the image is created, its contents are assembled in the directory \texttt{%% texclean(hyphenon)
+b\-u\-i\-l\-d\-/\-t\-m\-p\-/\-<\texttt{\emph{\small{%% texclean(hyphenon)
+t\-a\-r\-g\-e\-t%% texclean(hyphenoff)
+}}}>%% texclean(hyphenoff)
+}. The \texttt{%% texclean(hyphenon)
+t\-r\-e\-e%% texclean(hyphenoff)
+} subdirectory there contains the full contents of the initrd; other subdirectories are used for different purposes.
+
+
+\subsection{Library reduction}
+ Library reduction (relinking a library leaving out unused symbols) is used as yet another method to minimize the size of initrds. The downside of library reduction is that this requires the \texttt{%% texclean(hyphenon)
+d\-e\-v%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+p\-i\-c%% texclean(hyphenoff)
+} packages for the libraries to be reduced to be installed on the build system which also means that their version needs to match the version of the libraries in the udebs.
+
+
+ The size reduction is most significant for libc (40\%) and libm (90\%). Other libraries that are reduced include libresolv, libslang and libnewt. The reduction is done by calling mklibs from the main Makefile.
+
+
+ As only the executables that are included in an image are taken into account during the library reduction, we have provide for executables in components that are installed later as they would fail if they use symbols that have been taken out.
+
+
+ This is the reason that the udebs containing reduced libraries are excluded in \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-e\-x\-c\-l\-u\-d\-e%% texclean(hyphenoff)
+} which results in the udeb not being listed in the \texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-i\-b\-/\-d\-p\-k\-g\-/\-s\-t\-a\-t\-u\-s%% texclean(hyphenoff)
+} file in the intrd. If no udebs that are installed later depend on the library, all is well. If a udeb that does depend on it is installed later, \texttt{%% texclean(hyphenon)
+a\-n\-n\-a%% texclean(hyphenoff)
+} (or rather \textbf{udpkg}) will see that the dependency is not satisfied, and will install the udeb so the unreduced library replaces the reduced version.
+
+
+ Note that library reduction is only done after unpacking udebs for inclusion in an image; the libraries included in udebs are never reduced.
+
+
+\subsection{Using localudebs}
+ The \texttt{%% texclean(hyphenon)
+l\-o\-c\-a\-l\-u\-d\-e\-b\-s%% texclean(hyphenoff)
+} directory allows to use a different version of udebs than is available from the mirror you use. This can be used to test a new version of a udeb or to run the installer with a debug version of a udeb. It can also be used to build an image with a custom udeb.
+
+
+ To use a local udeb, just copy it into the directory. A \texttt{%% texclean(hyphenon)
+P\-a\-c\-k\-a\-g\-e\-s%% texclean(hyphenoff)
+} file will be generated automatically. Your udeb should have a version equal to or greater than the udeb currently on the mirror you use.
+
+
+ Note that local udebs will only be included in the image if the udeb would be included in a normal build too. So it has to be selected by the \textbf{pkg-{}list} script. Create a \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-l\-o\-c\-a\-l%% texclean(hyphenoff)
+} or \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-<\texttt{\emph{\small{%% texclean(hyphenon)
+i\-m\-a\-g\-e%% texclean(hyphenoff)
+}}}>/local%% texclean(hyphenoff)
+} to add udebs to the image that would not normally be included.
+
+
+ Some things to keep in mind when using localudebs.
+
+\begin{itemize}
+
+\item{} If you add an extra udeb, its dependencies will be included too. If those dependencies include virtual packages, the result is not always what you'd expect.
+
+
+
+\item{} Adding extra udebs will increase the size of the initrd; some architectures have limits for initrd size.
+
+
+
+\item{} If you use a \texttt{%% texclean(hyphenon)
+s\-o\-u\-r\-c\-e\-s\-.\-l\-i\-s\-t\-.\-u\-d\-e\-b\-.\-l\-o\-c\-a\-l%% texclean(hyphenoff)
+}, make sure to add as the first line:
+
+\begin{lstlisting}[firstnumber=1,]
+deb copy:<path-from-root-to>/installer/build/ localudebs/
+\end{lstlisting}
+
+
+
+\item{} Don't forget to clean up after you're finished.
+
+
+\end{itemize}
+
+\section{Conclusion}
+ Hopefully this paper will help make Debian Installer more accessible to new developers. If you have any suggestions to improve this document, please mail them to the debian-{}boot list or the author. The intention of the author is to use this paper as the basis for a d-{}i developers reference.
+
+
+ For any kind of work on Debian Installer, you should check out the d-{}i SVN repository on alioth:
+
+\begin{lstlisting}[firstnumber=1,]
+$ svn co svn+ssh://svn.debian.org/svn/d-i/trunk
+\end{lstlisting}
+
+
+ Subscription to the debian-{}boot list is recommended. To request commit access to the repository, please send a mail to that list.
+
+
+ Some additional development oriented documentation can be found in the repository under \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-d\-o\-c\-/\-d\-e\-v\-e\-l%% texclean(hyphenoff)
+} or in \texttt{%% texclean(hyphenon)
+R\-E\-A\-D\-M\-E%% texclean(hyphenoff)
+} files included with the source for various components.
+
+% --------------------------------------------
+% End of document
+% --------------------------------------------
+\end{document}
Added: procedings/32-debian-installer-internals/orig/d-i_debconf6.v2.xml
===================================================================
--- procedings/32-debian-installer-internals/orig/d-i_debconf6.v2.xml 2006-04-10 23:36:43 UTC (rev 507)
+++ procedings/32-debian-installer-internals/orig/d-i_debconf6.v2.xml 2006-04-10 23:54:18 UTC (rev 508)
@@ -0,0 +1,1138 @@
+<?xml version='1.0'?>
+<!-- -*- DocBook -*- -->
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+ "/usr/share/sgml/docbook/dtd/xml/4.2/docbookx.dtd" [
+ <!ENTITY % sgml.features "IGNORE">
+ <!ENTITY % xml.features "INCLUDE">
+ <!ENTITY % dbcent PUBLIC
+ "-//OASIS//ENTITIES DocBook Character Entities V4.2//EN"
+ "/usr/share/sgml/docbook/dtd/xml/4.2/dbcentx.mod"> %dbcent;
+]>
+
+
+<article>
+
+ <articleinfo>
+ <title>Debian Installer internals</title>
+ <authorgroup>
+ <author>
+ <firstname>Frans</firstname>
+ <surname>Pop</surname>
+ </author>
+ </authorgroup>
+
+ <abstract>
+<para>
+
+The Debian Installer is sometimes described as a mini Linux distribution which gives an indication of its complexity. This paper gives an introduction to the inner workings of the installer when it is running, its components (udebs) and its build system.
+
+</para>
+ </abstract>
+
+ <copyright>
+ <year>2006 <trademark class="copyright"></trademark></year>
+ <holder>Frans Pop <email>fjp at debian.org</email></holder>
+ </copyright>
+
+ <legalnotice>
+<para>
+
+This article is free; you may redistribute it and/or modify it
+under the terms of version 2 of the GNU General Public License.
+
+</para>
+ </legalnotice>
+ </articleinfo>
+
+
+ <sect1><title>Running Debian Installer</title>
+<para>
+
+The examples in this section reflect the current status of the Installer, the Etch Beta 2 release, and are based on the CD-ROM and netboot installation methods for i386. The choice for i386 was made as this is most familiar to most users, but installations for other architectures is not structurally different<footnote>
+
+<para>
+Some architectures currently do not use partman for partitioning, file system creation and mount point selection but instead use other components. Some architectures also use specific additional components as part of their default installation. However, this does not make them structurally different.
+</para>
+
+</footnote>.
+
+</para><para>
+
+So what are the basic steps when the installer is run? In any installation five stages can be distinguished.
+
+<orderedlist>
+ <listitem>
+boot and initialization — setting up the installer so that it can load any additional components
+ </listitem><listitem>
+loading additional components — expanding the installer to its full functionality)
+ </listitem><listitem>
+network configuration (unless already done in stage 1)
+ </listitem><listitem>
+partitioning
+ </listitem><listitem>
+installing the target system
+ </listitem>
+</orderedlist>
+
+</para><para>
+
+The first three stages are where the fundamental difference between installation methods can be seen. All components (udebs) used there need to be included in the initrd<footnote>
+
+<para>
+With one exception. In floppy disk based installations, the initrd does not contain all needed components for stage 2, but it does have the ability to load additional components that belong to stage one or are needed for stage 2 from additional floppy disks.
+</para>
+
+</footnote> with which the installer is booted.
+
+</para><para>
+
+The table below shows what components are involved in the first and second stage for the CD-ROM and netboot installation methods and also shows where these differ.
+
+</para>
+
+<informaltable>
+<tgroup cols='4' colsep='1' rowsep='1'>
+ <colspec colname='c1' align='center'/>
+ <colspec colname='c2' align='center'/>
+ <colspec colname='c3' align='center'/>
+ <colspec colname='c4' align='left'/>
+ <thead>
+ <row>
+ <entry>Stage</entry>
+ <entry>CD-ROM</entry>
+ <entry>NETBOOT</entry>
+ <entry>Comments</entry>
+ </row>
+ </thead><tbody>
+ <row>
+ <entry>-</entry>
+ <entry namest="c2" nameend="c3">initrd-preseed</entry>
+ <entry>Only if <filename>/preseed.cfg</filename> is present</entry>
+ </row><row>
+ <entry>1</entry>
+ <entry namest="c2" nameend="c3">localechooser</entry>
+ <entry>Language/country/locale selection</entry>
+ </row><row>
+ <entry>1</entry>
+ <entry namest="c2" nameend="c3">kbd-chooser</entry>
+ <entry>Keyboard selection</entry>
+ </row><row>
+ <entry>1</entry>
+ <entry>cdrom-detect</entry>
+ <entry>eth-detect</entry>
+ <entry>Hardware detection and setup</entry>
+ </row><row>
+ <entry>1</entry>
+ <entry></entry>
+ <entry>netcfg</entry>
+ <entry>Network configuration</entry>
+ </row><row>
+ <entry>-</entry>
+ <entry>file-preseed</entry>
+ <entry>network-preseed</entry>
+ <entry>If selected at boot prompt</entry>
+ </row><row>
+ <entry>2</entry>
+ <entry></entry>
+ <entry>choose-mirror</entry>
+ <entry>Mirror selection</entry>
+ </row><row>
+ <entry>2</entry>
+ <entry>load-cdrom (anna)</entry>
+ <entry>download-installer (anna)</entry>
+ <entry>Retrieve and unpack additional components</entry>
+ </row><row>
+ <entry>3</entry>
+ <entry>eth-detect</entry>
+ <entry></entry>
+ <entry>Hardware detection and setup</entry>
+ </row><row>
+ <entry>3</entry>
+ <entry>netcfg</entry>
+ <entry></entry>
+ <entry>Network configuration</entry>
+ </row><row>
+ <entry>3</entry>
+ <entry>choose-mirror</entry>
+ <entry></entry>
+ <entry>Mirror selection (sometimes needed for stage 4)</entry>
+ </row>
+ </tbody>
+</tgroup>
+</informaltable>
+
+<para>
+
+The remainder of the installation is basically the same for all installation methods.
+
+</para>
+
+<informaltable>
+<tgroup cols='3' colsep='1' rowsep='1'>
+ <colspec colname='c1' align='center'/>
+ <colspec colname='c2' align='center'/>
+ <colspec colname='c3' align='left'/>
+ <thead>
+ <row>
+ <entry>Stage</entry>
+ <entry></entry>
+ <entry>Comments</entry>
+ </row>
+ </thead><tbody>
+ <row>
+ <entry>4</entry>
+ <entry>hw-detect</entry>
+ <entry>Additional hardware detection</entry>
+ </row><row>
+ <entry>4</entry>
+ <entry>partman</entry>
+ <entry>Partitioning, file system creation and mount point selection</entry>
+ </row><row>
+ <entry>5</entry>
+ <entry>tzsetup</entry>
+ <entry>Time zone selection</entry>
+ </row><row>
+ <entry>5</entry>
+ <entry>clock-setup</entry>
+ <entry>Configure for hardware clock set to UTC or local time zone</entry>
+ </row><row>
+ <entry>5</entry>
+ <entry>user-setup</entry>
+ <entry>Set up root and normal user accounts</entry>
+ </row><row>
+ <entry>5</entry>
+ <entry>base-installer</entry>
+ <entry>Base system (debootstrap) & kernel installation</entry>
+ </row><row>
+ <entry>5</entry>
+ <entry>apt-setup</entry>
+ <entry>APT configuration in the target system (sources.list)</entry>
+ </row><row>
+ <entry>5</entry>
+ <entry>pkgsel</entry>
+ <entry>Select and install additional packages (tasksel)</entry>
+ </row><row>
+ <entry>5</entry>
+ <entry>grub/lilo-installer; nobootloader</entry>
+ <entry>Boot loader installation</entry>
+ </row><row>
+ <entry>5</entry>
+ <entry>prebaseconfig<superscript>a)</superscript></entry>
+ <entry>Finish up the installation and reboot</entry>
+ </row>
+ </tbody>
+</tgroup>
+</informaltable>
+
+<para>
+<superscript>a)</superscript> Will soon be renamed to <classname>finish-install</classname>. The name <quote><classname>prebaseconfig</classname></quote> no longer makes any sense as <classname>base-config</classname> was obsoleted with Etch Beta 2.
+</para>
+
+ <sect2><title>Installation methods</title>
+<para>
+
+The installer supports a lot of different installation methods and in some cases installation methods can be creatively combined. The definition of an installation method is based on the following questions.
+
+<itemizedlist>
+ <listitem>
+How is the installer booted?
+ </listitem><listitem>
+From where are additional udebs retrieved?
+ </listitem><listitem>
+From where are packages needed to install the base system retrieved?
+ </listitem><listitem>
+From where are packages needed to install tasks retrieved<footnote>
+
+<para>
+
+The last question can also be rephrased as <quote>what source lines are set up in the <filename>/etc/apt/sources.list</filename> file for the target system</quote>.
+
+</para>
+
+</footnote>?
+ </listitem>
+</itemizedlist>
+
+</para><para>
+
+The table below shows the answers to these questions for the most common installation methods.
+
+</para>
+
+<informaltable>
+<tgroup cols='5' align='left' colsep='1' rowsep='1'>
+ <thead>
+ <row>
+ <entry>Method</entry>
+ <entry>Boot</entry>
+ <entry>Udebs</entry>
+ <entry>Base system</entry>
+ <entry>Tasks</entry>
+ </row>
+ </thead><tbody>
+ <row>
+ <entry>netboot</entry>
+ <entry>network (TFTP server)</entry>
+ <entry>network</entry>
+ <entry>network</entry>
+ <entry>network</entry>
+ </row><row>
+ <entry>mini.iso</entry>
+ <entry>CD</entry>
+ <entry>network</entry>
+ <entry>network</entry>
+ <entry>network</entry>
+ </row><row>
+ <entry>businesscard CD</entry>
+ <entry>CD</entry>
+ <entry>CD</entry>
+ <entry>network</entry>
+ <entry>network</entry>
+ </row><row>
+ <entry>netinst CD</entry>
+ <entry>CD</entry>
+ <entry>CD</entry>
+ <entry>CD</entry>
+ <entry>network</entry>
+ </row><row>
+ <entry>full CD/DVD</entry>
+ <entry>CD</entry>
+ <entry>CD</entry>
+ <entry>CD</entry>
+ <entry>CD (+ network)</entry>
+ </row><row>
+ <entry>hd-media<superscript>a)</superscript></entry>
+ <entry>harddisk/USB stick</entry>
+ <entry>CD image</entry>
+ <entry>CD image/network</entry>
+ <entry>CD image/network</entry>
+ </row><row>
+ <entry>floppy (net)</entry>
+ <entry>boot/root/net-drivers</entry>
+ <entry>network</entry>
+ <entry>network</entry>
+ <entry>network</entry>
+ </row><row>
+ <entry>floppy (cd)<superscript>a)</superscript></entry>
+ <entry>boot/root/cd-drivers</entry>
+ <entry>CD</entry>
+ <entry>CD/network</entry>
+ <entry>CD/network</entry>
+ </row>
+ </tbody>
+</tgroup>
+</informaltable>
+
+<para>
+
+<superscript>a)</superscript> Whether packages for the base system and tasks are retrieved from CD (image) or the network depends on the type of CD used in combination with these boot methods.
+
+</para>
+ </sect2>
+
+ <sect2><title>The boot process</title>
+<para>
+
+The boot process for the installer is similar to the boot of a regular system. A bootloader (in some cases the system's firmware) is responsible for loading the kernel and loading the initrd after which init is started. The boot process can be debugged by adding the <userinput>BOOT_DEBUG</userinput> parameter.
+
+</para><para>
+
+It is possible to pass additional kernel and boot parameters. Kernel parameters are sometimes needed to get non-conformant hardware supported, or to install from serial console instead of an attached keyboard/display.
+
+</para><para>
+
+Boot parameters can also be used to influence the installer itself. More about this in the section on preseeding.
+
+</para><para>
+
+The boot process is currently quite complex as it needs to support several generations of linux:
+
+<itemizedlist>
+ <listitem>
+2.2, 2.4 and 2.6 kernels with devfs, all subtly different
+ </listitem><listitem>
+2.6 kernels with udev; several generations, both with and without hotplug
+ </listitem>
+</itemizedlist>
+
+</para><para>
+
+The following enumeration gives an overview of the main steps in the boot process.
+
+</para>
+
+<variablelist>
+ <varlistentry>
+ <term>1) <command>/init</command> (initramfs) or <command>/sbin/init</command> (initrd)</term>
+ <listitem><para>
+Sets up initial environment (<filename>/proc</filename>, <filename>/dev</filename>; run <command>udev</command>)
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>2) <command>busybox init</command></term>
+ <listitem><para>
+<filename>/etc/inittab</filename> is parsed; this contains:
+
+<itemizedlist>
+ <listitem>
+<literal>::sysinit:/sbin/debian-installer-startup</literal>
+ </listitem><listitem>
+<literal>::respawn:/sbin/debian-installer</literal>
+ </listitem><listitem>
+init for VT2 (busybox shell), VT3 (<filename>/var/log/messages</filename>), VT4 (<filename>/var/log/syslog</filename>)
+ </listitem>
+</itemizedlist>
+
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>3) <command>/sbin/debian-installer-startup</command></term>
+ <listitem><para>
+This is a run-parts like script that executes or sources scripts in <filename>/lib/debian-installer-startup.d</filename>. The main functions that are performed are:
+
+<itemizedlist>
+ <listitem>
+mount <filename>devfs</filename> and <filename>sysfs</filename> if appropriate
+ </listitem><listitem>
+run <command>udev</command>/<command>hotplug</command>
+ </listitem><listitem>
+load acpi modules
+ </listitem><listitem>
+start syslog
+ </listitem><listitem>
+check available memory and, depending on preset limits, enable a lowmem mode if needed
+ </listitem><listitem>
+load any debconf templates present in the initrd
+ </listitem><listitem>
+parse boot parameters to look for debconf patterns (<userinput><<replaceable>component</replaceable>>/<<replaceable>template</replaceable>>=<<replaceable>value</replaceable>></userinput>) and set these in the debconf database
+ </listitem><listitem>
+detect the type of console that is used
+ </listitem><listitem>
+load framebuffer modules
+ </listitem><listitem>
+detect if the installer should run in rescue mode
+ </listitem>
+</itemizedlist>
+
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>4) <command>/sbin/debian-installer</command></term>
+ <listitem><para>
+This is a run-parts like script that sources scripts in <filename>/lib/debian-installer.d</filename>. The main functions that are performed are:
+
+<itemizedlist>
+ <listitem>
+detect if a framebuffer device is available
+ </listitem><listitem>
+initialize the console (blanking, UTF-8)
+ </listitem><listitem>
+select which debconf frontend is to be used (text, newt, gtk)
+ </listitem><listitem>
+start <classname>main-menu</classname> (see next section)
+ </listitem><listitem>
+halt or reboot the system (after <classname>main-menu</classname> exits)
+ </listitem>
+</itemizedlist>
+
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+
+<para>
+
+Scripts in <filename>/lib/debian-installer(-startup).d</filename> can be architecture specific.
+
+</para>
+ </sect2>
+
+ <sect2><title>The Debian Installer Menu</title>
+<para>
+
+The component <classname>main-menu</classname> drives the rest of the installation. It is responsible both for dynamically assembling the menu and for executing components when they are selected. Note that the menu is only actually visible when installing at low or medium debconf priority. At higher priorities it is still there, but it will automatically execute the next component without showing the menu to the user.
+
+</para><para>
+
+In some situations the debconf priority is automatically changed. It is reduced when the execution of a component fails, or when the user uses the <userinput><go back></userinput> button to back out all the way to the menu. In these cases it will also be increased back to the original level when the next component executed finishes successfully.
+
+</para><para>
+
+An important characteristic of udebs is that execution of their postinst scripts is delayed. On installation udebs are only unpacked; the execution of the postinst is done by main-menu and is actually what happens when a component is selected in the menu. In other words, main-menu can be said to be responsible for <quote>configuring</quote> the udeb.
+
+</para><para>
+
+For a component to be included in the menu, it needs to have an <literal>Installer-Menu-Item</literal> line in the <classname>dpkg</classname> status file (<filename>/var/lib/dpkg/status</filename>). The order of components in the menu is determined primarily by its dependencies; the menu item number is used only where the order for two or more components cannot be resolved by dependencies alone.
+
+</para><para>
+
+Provides can be used to define virtual states which other components can depend on, as shown in the next example.
+
+<informalexample><screen>
+Package: netcfg
+Status: install ok installed
+Version: 1.23
+Provides: configured-network
+Depends: libc6 (>= 2.3.5-1), libdebconfclient0, libdebian-installer4 (>= 0.37),
+ dhcp-client-udeb | dhcp3-client-udeb | pump-udeb, libiw28-udeb,
+ cdebconf-udeb, ethernet-card-detection
+Description: Configure the network
+Installer-Menu-Item: 18
+
+Package: choose-mirror
+Status: install ok unpacked
+Version: 1.19
+Depends: libc6 (>= 2.3.5-1), libdebconfclient0, libdebian-installer4 (>= 0.38),
+ configured-network
+Description: Choose mirror to install from
+Installer-Menu-Item: 23
+</screen></informalexample>
+
+</para><para>
+
+This example also shows that netcfg has been run successfully (<quote>installed</quote>) while mirror selection has not yet taken place (<quote>unpacked</quote>).
+
+</para><para>
+
+Some components are included in the menu but are not run by default. These components have a menu number higher than prebaseconfig. Examples are components that allow to change the debconf priority, to save debug logs, to check the integrity of a CD-ROM or to abort the installation.
+
+</para>
+ </sect2>
+
+ <sect2><title>Hooks provide additional flexibility</title>
+<para>
+
+At certain points in the installation, components provide run-parts like execution of scripts. This allows other components to just drop scripts there so that commands can be run at that point in the installation, even though the postinst for the component itself is run earlier or later (if the component even has a postinst).
+
+</para><para>
+
+The main hooks are:
+
+<variablelist>
+ <varlistentry>
+ <term><filename>/usr/lib/base-installer.d</filename></term>
+ <listitem><para>
+Run by base-installer before debootstrap is started.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>/usr/lib/post-base-installer.d</filename></term>
+ <listitem><para>
+Run by base-installer just before kernel selection/installation.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>/usr/lib/prebaseconfig.d</filename></term>
+ <listitem><para>
+Run by prebaseconfig.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+
+</para><para>
+
+Other, more special purpose hooks are <filename>/usr/lib/apt-setup/generators</filename>, <filename>/lib/main-menu.d</filename> and <filename>/lib/rescue.d</filename>.
+
+</para><para>
+
+Besides these general hooks, partman is basically structured as one big collection of hooks where partman components all drop their own scriptlets to extend partman's functionality. The most noteworthy of these hooks is <filename>/lib/partman/finish.d</filename> as some bootloaders drop scripts there to add checks that ensure the selected partitioning scheme conforms to their requirements.
+
+</para>
+ </sect2>
+
+ <sect2><title>Some special tools</title>
+<para>
+
+The installer has some special commands which can be used in postinst or preseeding scripts:
+
+<variablelist>
+ <varlistentry>
+ <term><command>anna-install</command></term>
+ <listitem><para>
+Used to install additional, non-standard d-i components (udebs). It will check if <classname>anna</classname> has already been run. If it has, the component is unpacked immediately; if it has not, it will be scheduled for installation when <classname>anna</classname> is run.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>apt-install</command></term>
+ <listitem><para>
+Performs the same function for normal packages and installs them in the target system. Packages will either be installed immediately (if called after base-installer) or scheduled for installation as one of the <quote>extra</quote> packages installed near the end of base-installer's postinst script.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>log-output</command></term>
+ <listitem><para>
+Allows to run a command and redirect its output (either <filename>stdout</filename> or <filename>stderr</filename> or both) to <filename>/var/log/syslog</filename>.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><command>in-target</command></term>
+ <listitem><para>
+Allows to run a command in a chroot on <filename>/target</filename> with the chroot being set up for more demanding operations. For example, <filename>proc</filename> and <filename>sysfs</filename> are mounted and a <filename>policy-rc.d</filename> is created. Can obviously only be used after the base system has been set up.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+
+</para>
+ </sect2>
+
+ <sect2><title>Automating the install using preseeding</title>
+<para>
+
+There are three preseed methods that are currently supported:
+<variablelist>
+ <varlistentry>
+ <term><emphasis>initrd preseeding</emphasis></term>
+ <listitem><para>
+The preseed file <filename>/preseed.cfg</filename> needs to be present in the initrd. It is read as part of the <command>debian-installer-startup</command> processing.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><emphasis>file preseeding</emphasis></term>
+ <listitem><para>
+Triggered by the presence of the <userinput>preseed/file</userinput> boot parameter.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><emphasis>network preseeding</emphasis></term>
+ <listitem><para>
+Triggered by the presence of the <userinput>preseed/url</userinput> boot parameter. In versions later than Etch Beta 2 it is also possible to trigger this from the DHCP server.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+
+Which of these methods is available depends on the installation method.
+
+</para><para>
+
+The main purpose of preseeding is to set default values for debconf questions. Note that it makes no sense when using file or network preseeding to preseed values for questions that are asked <emphasis>before</emphasis> the preseed file is parsed.
+
+</para><para>
+
+Besides offering the option to set default values for debconf questions, preseeding also makes it possible to run scripts at two distinct moments using <userinput>preseed/early_command</userinput> and <userinput>preseed/late_command</userinput>. The <userinput>early_command</userinput> is executed immediately after the preseed file is parsed (only for file and network preseeding); the <userinput>late_command</userinput> is executed as part of the <command>prebaseconfig</command> component.
+
+</para><para>
+
+These scripts can be made as complex as you like. One option is to use them to install additional packages on the target system (using <command>apt-install</command>). The <userinput>early_command</userinput> could be used to install additional d-i components (using <command>anna-install</command>) or to install scripts in the various hook script directories (if commands need to be executed at a specific point in the installation).
+
+</para><para>
+
+Additional information about preseeding is available in an appendix of the Installation Guide.
+
+</para>
+ </sect2>
+
+ <sect2><title>Debugging the installer</title>
+<para>
+
+Because most of the installer is scripted, it is fairly easy to debug most problems by adding a <userinput>set -x</userinput> in the correct place. The obvious place to start is the postinst of the component you want to debug. The output will appear in <filename>/var/log/syslog</filename>, which can most easily be viewed by starting the internal webserver from the <quote>Save debug logs</quote> menu option (after the network has been configured).
+
+</para><para>
+
+For components written in C debugging is a bit harder. Options are to use the strace udeb (add it to a custom image if needed) or to create a custom version of a component with added debug statements in the source and use that.
+
+</para><para>
+
+For debugging, you will probably want to control when components are started. Booting the installer with <userinput>install debconf/priority=medium</userinput> is a good way to achieve that. It will make sure the menu is displayed before a new component is started.
+
+</para><para>
+
+If you boot the installer at medium priority, you will also be able to load the optional component <classname>open-ssh-client</classname><footnote>
+
+<para>
+If you want to load optional components when installing at the default priority, just back out to the menu and select the component that installs additional installer components.
+</para>
+
+</footnote>. Loading this component will allow you to use <command>scp</command> to copy files from the system being installed to another computer and vice versa. Also useful for testing new versions of scripts or commands without rebuilding the udeb and image. The command <command>nc</command> from the <classname>netcat</classname> package is available by default in the installer.
+
+</para>
+ </sect2>
+ </sect1>
+
+
+ <sect1><title>D-I components or udebs</title>
+<para>
+
+A udeb (or micro-deb) is a special kind of Debian package. Technically udebs are very similar to regular packages: you can look at their contents using <command>dpkg -c</command>, and extract them using <command>dpkg -x</command> and <command>dpkg -e</command>.
+
+</para><para>
+
+The main difference is that a lot of policy requirements are waived. For example, a udeb does not contain a changelog, licence, manpages or md5sum<footnote>
+
+<para>
+Of course, the source package for a udeb <emphasis>does</emphasis> need to contain a proper licence and changelog.
+</para>
+
+</footnote>. The reason is to minimize size which is important as the installation completely takes place in RAM, with swap only becoming available after stage 4 of the installation (partitioning).
+
+</para><para>
+
+Another important difference is that udebs are not really meant to be uninstalled or upgraded.
+
+</para><para>
+
+The relaxed policy requirements make one of the reasons that udebs should to be installed on a normal system. The other reason being that it just doesn't make sense and it's likely to break things.
+
+</para><para>
+
+Two special classes of udebs should be mentioned here. However, covering these in detail is outside the scope of this paper.
+<variablelist>
+ <varlistentry>
+ <term>Kernel image and kernel module udebs</term>
+ <listitem><para>
+Kernel udebs are built basically by repackaging a regular kernel-image package. Reason is again to reduce memory usage: not all modules included in a kernel-image package are needed during an installation. Also, different modules are needed in the initrd for different installation methods, remaining modules can either be loaded later or optionally (by manual selection or through dependencies). The package <classname>kernel-wedge</classname> contains the toolset used to reorganize a kernel-image package into multiple kernel (module) udebs.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Partman and its components</term>
+ <listitem><para>
+Partman has a very specific structure and requires a fairly strict conformance to this structure for udebs that extend its functionality.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+
+</para>
+
+ <sect2><title>Contents of a udeb</title>
+<para>
+
+For components that are included in the main menu, the udeb will at least contain:
+
+<itemizedlist>
+ <listitem><para>
+a postinst
+ </para></listitem>
+ <listitem><para>
+a debconf template that contains the description for the main menu:
+
+<informalexample><screen>
+debian-installer/<component>/title
+Type: text
+_Description: Configure time zone
+</screen></informalexample>
+
+ </para></listitem>
+</itemizedlist>
+
+</para><para>
+
+Other things like additional debconf templates, C programs, hook scripts can be added as needed.
+
+</para><para>
+
+A special type of control file worth mentioning is the <filename>isinstallable</filename> file. If a script with this name is present in <filename>/var/lib/dpkg/info</filename> for a component, the main menu will run this script and only include the component in the menu if the script exits 0.
+
+</para>
+ </sect2>
+
+ <sect2><title>Creating a udeb</title>
+<para>
+
+Creating a udeb is not all that hard, especially if you use <classname>debhelper</classname>. <classname>debhelper</classname> knows the special properties of a udeb and will do the right thing by default at build time. That is, if you don't forget to tell it you are creating a udeb.
+
+</para><para>
+
+The example below shows the <filename>debian/control</filename> file for a udeb that is supposed to be included in the main menu. Note the special section.
+
+</para>
+
+<informalexample><screen>
+Source: kbd-chooser
+Section: debian-installer
+Priority: optional
+Maintainer: Debian Install System Team <debian-boot at lists.debian.org>
+Uploaders: [...]
+Build-Depends: debhelper (>= 5.0.22), libdebian-installer4-dev (>= 0.41), po-debconf (>= 0.5.0), flex | flex-old , bison, libdebconfclient0-dev (>= 0.49)
+
+Package: kbd-chooser
+Architecture: i386 amd64 powerpc alpha hppa sparc [...]
+XC-Package-Type: udeb
+Depends: ${shlibs:Depends}, ${misc:Depends}, console-keymaps
+Description: Detect a keyboard and select layout
+XB-Installer-Menu-Item: 12
+</screen></informalexample>
+
+<para>
+
+The line <literal>XC-Package-Type</literal> tells <classname>debhelper</classname> to treat the package as a udeb. The <literal>XB-Installer-Menu-Item</literal> is added in the control file for the udeb and will eventually end up in the <classname>dpkg</classname> status file to help <classname>main-menu</classname> figure out that this udeb should be included in the menu and in what order<footnote>
+
+<para>
+The file <filename>installer/doc/devel/menu-item-numbers.txt</filename> in the d-i SVN repository documents menu numbers currently in use.
+</para>
+
+</footnote>.
+
+Packaging a udeb becomes a bit harder if it is derived from a regular package but needs to be compiled with different compiler options (e.g. some features disabled or a different optimization).
+
+</para><para>
+
+The main thing to always keep in mind when creating a udeb is size. It is very important to keep size as minimal as possible. This includes using tabs instead of spaces when indenting in scripts and not being too verbose in comments.
+
+</para>
+ </sect2>
+
+ <sect2><title>Library udebs</title>
+<para>
+
+A major recent improvement is the addition of <quote>package type</quote> support in shlibs files for libraries. This allows <command>dpkg-dev</command> and <classname>debhelper</classname> to automatically set correct dependencies on library udebs when a d-i component that depends on them is built.
+
+</para><para>
+
+For example, the regular binary package <classname>zlib1g</classname> now has the following lines in its shlibs control file:
+<informalexample><screen>
+libz 1 zlib1g (>= 1:1.2.1)
+udeb: libz 1 zlib1g-udeb (>= 1:1.2.1)
+</screen></informalexample>
+
+</para><para>
+
+The second line is specific to the package type <quote>udeb</quote>. This alternative line is used when <command>dpkg-shlibdeps</command> is called with the <command>-tudeb</command> option; <command>dh_shlibdeps</command> will automatically add this option when processing a udeb.
+
+</para><para>
+
+Generating the extra <literal>udeb:</literal> lines is supported by <command>dh_makeshlibs</command> if the <command>--add-udeb="<udeb name>"</command> option is used. For example, the <filename>debian/rules</filename> file for <classname>libusb</classname> contains the following line:
+<informalexample><screen>
+dh_makeshlibs -V -s --add-udeb="libusb-0.1-udeb"
+</screen></informalexample>
+
+</para>
+ </sect2>
+ </sect1>
+
+
+ <sect1><title>Building installer images</title>
+<para>
+
+This paper will only provide an introduction to building installer images using existing definitions. The README in <filename>installer/build</filename> in the SVN repository contains more detailed information about the build system and how to modify existing or define new images.
+
+</para><para>
+
+An image consists of:
+
+<itemizedlist>
+ <listitem>
+a kernel;
+ </listitem><listitem>
+an initrd, which is basically a collection of unpacked udebs;
+ </listitem><listitem>
+in some cases a boot loader and/or configuration files used for booting.
+ </listitem>
+</itemizedlist>
+
+</para><para>
+
+Most d-i images are <quote>ready for use</quote>. The exception are the cdrom images which form only the base (kernel and initrd) for creating the actual CD or DVD images. The package used for creating the CD/DVD images is <classname>debian-cd</classname>.
+
+</para><para>
+
+On some architectures there is one CD image that <emphasis>is</emphasis> ready for use: the <filename>mini.iso</filename> that is produced as a by-product of the netboot target. Reason is that this image does not really support installing from CD, it just allows booting from CD but retrieves all additional udebs and packages over the network.
+
+</para><para>
+
+It is important to distinguish between building images for release and building images for development/testing use.
+
+</para><para>
+
+A release build is done, as for other packages that are to be uploaded, from the <filename>installer</filename> directory using <command>debian/rules</command>. This will create a binary package (needed for uploading) containing some documentation, but the important bit is a tarball containing all installer images. After the upload this tarball needs BYHAND processing<footnote>
+
+<para>
+This entails unpacking the tarball into the correct location on the master mirror server and creating/updating the correct symlinks. See for example <ulink url="http://ftp.debian.org/debian/dists/sid/main/installer-i386/"/>.
+</para>
+
+</footnote> by FTP-masters before the buildds will pick up the upload for other architectures.
+
+</para><para>
+
+Building images for development and testing is done from the <filename>installer/build</filename> directory<footnote>
+
+<para>
+This includes the daily built images available from <ulink url="http://www.debian.org/devel/debian-installer"/>. These are generated and uploaded from machines run by d-i porters using the daily-build script.
+</para>
+
+</footnote> using <command>fakeroot make <<replaceable>target</replaceable>></command>.
+
+</para><para>
+
+An important difference between release and development builds is that release builds will use udebs for the same suite as the target system being installed, while development builds will by default install testing, but use udebs from unstable<footnote>
+
+<para>
+This is accomplished by including the <filename>/installer/build/unstable.cfg</filename> preseed file in the initrd.
+</para>
+
+</footnote>. This allows to mostly avoid the occasional breakage of the base system and tasks in unstable while using the most recent udebs.
+
+</para>
+
+ <sect2><title>Requirements for building</title>
+<para>
+
+For both release and development builds the build dependencies as listed in <filename>installer/debian/control</filename> need to be satisfied.
+
+</para><para>
+
+To build installer images from SVN trunk, your build machine needs to be running unstable or you need to set up a sid chroot to build in. (To build images from the sarge branch of the repository, the build machine needs to run Sarge.)
+
+</para><para>
+
+During the build, the needed udebs will be retrieved from a mirror. By default this mirror is based on your <filename>/etc/apt/sources.list</filename> (see the generated file <filename>build/sources.list.udeb</filename>). To use a different source, create a file <filename>sources.list.udeb.local</filename>.
+
+</para>
+ </sect2>
+
+ <sect2><title>Build targets</title>
+<para>
+
+To see which targets are available, run <command>make</command>. This will result in a list of some 130 targets, most of which are not really relevant. A more useful list can be obtained with <command>make | grep ^build</command>. The table below has the most often used targets for i386.
+
+<informaltable><tgroup cols='2'><tbody>
+ <row>
+ <entry><userinput>build_all</userinput></entry>
+ <entry>Builds all images</entry>
+ </row><row>
+ <entry><userinput>build_cdrom_isolinux</userinput></entry>
+ <entry>Builds the cdrom images (both 2.4 and 2.6)</entry>
+ </row><row>
+ <entry><userinput>build_netboot</userinput></entry>
+ <entry>Builds the netboot images (both 2.4 and 2.6) and the mini.iso</entry>
+ </row><row>
+ <entry><userinput>reallyclean</userinput></entry>
+ <entry>Completely cleans the build environment</entry>
+ </row>
+</tbody></tgroup></informaltable>
+
+The <userinput>reallyclean</userinput> target is often needed when changes are made between builds because otherwise udebs or information may be retrieved from temporary or cache directories and the changes will not take effect. The <filename>rebuild_*</filename> targets clean some of this, but not always enough.
+
+</para>
+ </sect2>
+
+ <sect2><title>The build system explained</title>
+<para>
+
+The easiest way to start is with the purpose of the subdirectories in the <filename>installer/build</filename> directory.
+
+</para>
+
+<itemizedlist>
+ <listitem><para>
+<filename>config</filename>: defines the available targets (per architecture)
+ </para></listitem>
+ <listitem><para>
+<filename>pkg-lists</filename>: defines which udebs are included in an image (per image type)
+ </para></listitem>
+ <listitem><para>
+<filename>boot</filename>: contains configuration files and make targets used to make images bootable
+ </para></listitem>
+ <listitem><para>
+<filename>localudebs</filename>: allows to use (versions of) udebs not available on the mirror you use
+ </para></listitem>
+ <listitem><para>
+<filename>util</filename>: contains helper scripts called from the Makefile
+ </para></listitem>
+</itemizedlist>
+
+<para>
+
+Two files containing important configuration info are <filename>config/dir</filename> and <filename>config/common</filename>. However, normally there should be no need to modify any of the variables defined in these files.
+
+</para><para>
+
+Both the <filename>config</filename> and <filename>pkg-lists</filename> directories have a tree structure with general configuration defined in the root and more specific configuration defined in branches and leaves. Branches are defined in directories that have the same name as a config file on the higher level. The <filename>config</filename> directory contains makefile snippets.
+
+</para>
+
+ <sect3><title>config</title>
+<para>
+
+For example, the definition for i386 images starts with <filename>config/i386.cfg</filename> which, besides the current kernel versions, defines the media supported with the line:
+
+<informalexample><screen>
+MEDIUM_SUPPORTED = cdrom netboot floppy hd-media
+</screen></informalexample>
+
+</para><para>
+
+These media correspond to the main targets for i386 and are further defined in <filename>config/i386</filename>. The <filename>netboot.cfg</filename> file in that directory contains, amongst others, the following three lines:
+
+<informalexample><screen>
+FLAVOUR_SUPPORTED = "" 2.6
+MEDIA_TYPE = netboot image
+EXTRATARGETS = build_netboot_2.6
+</screen></informalexample>
+
+</para><para>
+
+This defines that the netboot image has two flavors: the default one (using a 2.4 kernel) and an one using a 2.6 kernel, which is further defined in the <filename>config/i386/netboot/2.6.cfg</filename> file where the default values of the variables for the kernel version are overruled.
+
+</para><para>
+
+The files in config are processed recursively to dynamically generate the build targets, so in this example you get a netboot, a <userinput>netboot_2.6</userinput> target and targets for the other media. Building is also recursive, so calling the netboot target will automatically build both the <userinput>netboot</userinput> and <userinput>netboot_2.6</userinput> images.
+
+</para><para>
+
+The structure of the config files can get quite complex and it can be hard to keep track of the exact role of the different variables set in them.
+
+</para>
+ </sect3>
+
+ <sect3><title>pkg-lists</title>
+<para>
+
+The list of udebs to be included in an image is built by the <command>util/pkg-list</command> script based on definitions in the <filename>pkg-lists</filename> directory. Again, processing can be quite complex. Let's take the netboot target for i386 as an example to explain it.
+
+</para><para>
+
+First the file <filename>pkg-lists/netboot/i386.cfg</filename> is considered and all udebs listed in it are added. Some example lines from that file:
+
+<informalexample><screen>
+#include "discover"
+console-keymaps-at
+console-keymaps-usb
+usb-discover [2.4]
+socket-modules-${kernel:Version} ?
+acpi-modules-${kernel:Version} [2.6]
+</screen></informalexample>
+
+</para><para>
+
+The variable <literal>${kernel:Version}</literal> is expanded to match the package name of the udeb based on the kernel version and flavor. If the name of a udebs is followed by <quote>[2.4]</quote> or <quote>[2.6]</quote>, it is only included if the kernel major version for the image being built matches. If it is followed by a question mark it is skipped if the package is not available (without the question mark an error would be generated).
+
+</para><para>
+
+The first line with the <literal>#include</literal> results in the file <filename>pkg-lists/discover</filename> being processed next in the same way.
+
+</para><para>
+
+The <command>pkg-list</command> script will also always look for the presence of files named <filename>common</filename> and <filename>local</filename> and thus <filename>pkg-lists/netboot/common</filename> is processed next. This file exists and lists a number of udebs that belong in any netboot image, independent of the architecture. This file also contains two include directives:
+
+<informalexample><screen>
+#include "base"
+#include "kernel"
+</screen></informalexample>
+
+</para><para>
+
+Thus, udebs listed in <filename>pkg-lists/base</filename> (containing udebs common to all images) and <filename>pkg-lists/kernel</filename> (included in all bootable images) are also processed.
+
+</para><para>
+
+The file <filename>pkg-lists/netboot/local</filename> does not normally exist as it is intended for the inclusion of non-standard udebs. It is also very useful for testing as it can be used to temporarily add udebs not normally included without teh need to modify the regular files.
+
+</para><para>
+
+Finally, the script will check for <filename>pkg-lists/local</filename> and <filename>pkg-lists/exclude</filename>. The latter exists and contains some udebs otherwise pulled in by dependencies, but that should not be included because of library reduction, which is covered in the next section. Note that the exclusion if not triggered by the file name, but rather by the dash after the name of the udebs.
+
+</para><para>
+
+All dependencies of udebs listed in <filename>pkg-lists</filename> will also be automatically included in the image.
+
+</para><para>
+
+To see how the package list is built for a particular image, set <code>my $debug=1;</code> in the <command>util/pkg-list</command> script.
+
+</para>
+ </sect3>
+ </sect2>
+
+ <sect2><title>Result of the build</title>
+<para>
+
+If the build is successful, you will find the images under the <filename>build/dest</filename> directory. Depending on the type of build you will also find manifest and log files there.
+
+</para><para>
+
+Before the image is created, its contents are assembled in the directory <filename>build/tmp/<<replaceable>target</replaceable>></filename>. The <filename>tree</filename> subdirectory there contains the full contents of the initrd; other subdirectories are used for different purposes.
+
+</para>
+ </sect2>
+
+ <sect2><title>Library reduction</title>
+<para>
+
+Library reduction (relinking a library leaving out unused symbols) is used as yet another method to minimize the size of initrds. The downside of library reduction is that this requires the <classname>dev</classname> and <classname>pic</classname> packages for the libraries to be reduced to be installed on the build system which also means that their version needs to match the version of the libraries in the udebs.
+
+</para><para>
+
+The size reduction is most significant for libc (40%) and libm (90%). Other libraries that are reduced include libresolv, libslang and libnewt. The reduction is done by calling mklibs from the main Makefile.
+
+</para><para>
+
+As only the executables that are included in an image are taken into account during the library reduction, we have provide for executables in components that are installed later as they would fail if they use symbols that have been taken out.
+
+</para><para>
+
+This is the reason that the udebs containing reduced libraries are excluded in <filename>pkg-lists/exclude</filename> which results in the udeb not being listed in the <filename>/var/lib/dpkg/status</filename> file in the intrd. If no udebs that are installed later depend on the library, all is well. If a udeb that does depend on it is installed later, <classname>anna</classname> (or rather <command>udpkg</command>) will see that the dependency is not satisfied, and will install the udeb so the unreduced library replaces the reduced version.
+
+</para><para>
+
+Note that library reduction is only done after unpacking udebs for inclusion in an image; the libraries included in udebs are never reduced.
+
+</para>
+ </sect2>
+
+ <sect2><title>Using localudebs</title>
+<para>
+
+The <filename>localudebs</filename> directory allows to use a different version of udebs than is available from the mirror you use. This can be used to test a new version of a udeb or to run the installer with a debug version of a udeb. It can also be used to build an image with a custom udeb.
+
+</para><para>
+
+To use a local udeb, just copy it into the directory. A <filename>Packages</filename> file will be generated automatically. Your udeb should have a version equal to or greater than the udeb currently on the mirror you use.
+
+</para><para>
+
+Note that local udebs will only be included in the image if the udeb would be included in a normal build too. So it has to be selected by the <command>pkg-list</command> script. Create a <filename>pkg-lists/local</filename> or <filename>pkg-lists/<<replaceable>image</replaceable>>/local</filename> to add udebs to the image that would not normally be included.
+
+</para><para>
+
+Some things to keep in mind when using localudebs.
+
+</para>
+
+<itemizedlist>
+ <listitem><para>
+If you add an extra udeb, its dependencies will be included too. If those dependencies include virtual packages, the result is not always what you'd expect.
+ </para></listitem>
+ <listitem><para>
+Adding extra udebs will increase the size of the initrd; some architectures have limits for initrd size.
+ </para></listitem>
+ <listitem><para>
+If you use a <filename>sources.list.udeb.local</filename>, make sure to add as the first line:
+
+<informalexample><screen>
+deb copy:<<replaceable>path-from-root-to</replaceable>>/installer/build/ localudebs/
+</screen></informalexample>
+
+ </para></listitem>
+ <listitem><para>
+Don't forget to clean up after you're finished.
+ </para></listitem>
+</itemizedlist>
+
+ </sect2>
+ </sect1>
+
+
+ <sect1><title>Conclusion</title>
+<para>
+
+Hopefully this paper will help make Debian Installer more accessible to new developers. If you have any suggestions to improve this document, please mail them to the debian-boot list or the author. The intention of the author is to use this paper as the basis for a d-i developers reference.
+
+</para><para>
+
+For any kind of work on Debian Installer, you should check out the d-i SVN repository on alioth:
+<informalexample><screen>
+$ svn co svn+ssh://svn.debian.org/svn/d-i/trunk
+</screen></informalexample>
+
+</para><para>
+
+Subscription to the debian-boot list is recommended. To request commit access to the repository, please send a mail to that list.
+
+</para><para>
+
+Some additional development oriented documentation can be found in the repository under <filename>installer/doc/devel</filename> or in <filename>README</filename> files included with the source for various components.
+
+</para>
+ </sect1>
+</article>
Added: procedings/32-debian-installer-internals/orig/missfont.log
===================================================================
--- procedings/32-debian-installer-internals/orig/missfont.log 2006-04-10 23:36:43 UTC (rev 507)
+++ procedings/32-debian-installer-internals/orig/missfont.log 2006-04-10 23:54:18 UTC (rev 508)
@@ -0,0 +1,3 @@
+mktextfm ecrm1728
+mktextfm ecrm1440
+mktextfm ecbx1440
Added: procedings/32-debian-installer-internals/paper.tex
===================================================================
--- procedings/32-debian-installer-internals/paper.tex 2006-04-10 23:36:43 UTC (rev 507)
+++ procedings/32-debian-installer-internals/paper.tex 2006-04-10 23:54:18 UTC (rev 508)
@@ -0,0 +1,990 @@
+\section{Abstract}
+
+ The Debian Installer is sometimes described as a mini Linux distribution which gives an indication of its complexity. This paper gives an introduction to the inner workings of the installer when it is running, its components (udebs) and its build system.
+
+
+\section{Running Debian Installer}
+ The examples in this section reflect the current status of the Installer, the Etch Beta 2 release, and are based on the CD-{}ROM and netboot installation methods for i386. The choice for i386 was made as this is most familiar to most users, but installations for other architectures is not structurally different\footnote{
+ Some architectures currently do not use partman for partitioning, file system creation and mount point selection but instead use other components. Some architectures also use specific additional components as part of their default installation. However, this does not make them structurally different.
+
+}.
+
+
+ So what are the basic steps when the installer is run? In any installation five stages can be distinguished.
+ \begin{enumerate}
+
+\item{} boot and initialization \textemdash{} setting up the installer so that it can load any additional components
+
+
+\item{} loading additional components \textemdash{} expanding the installer to its full functionality)
+
+
+\item{} network configuration (unless already done in stage 1)
+
+
+\item{} partitioning
+
+
+\item{} installing the target system
+
+\end{enumerate}
+
+
+ The first three stages are where the fundamental difference between installation methods can be seen. All components (udebs) used there need to be included in the initrd\footnote{
+ With one exception. In floppy disk based installations, the initrd does not contain all needed components for stage 2, but it does have the ability to load additional components that belong to stage one or are needed for stage 2 from additional floppy disks.
+
+} with which the installer is booted.
+
+
+ The table below shows what components are involved in the first and second stage for the CD-{}ROM and netboot installation methods and also shows where these differ.
+
+\begin{center}
+%%% parse_table %%%
+\resizetable{4}{4}{0cm}{}
+\begin{longtable}{|>{\centering}p{\tsize}|>{\centering}p{\tsize}|>{\centering}p{\tsize}|>{\raggedright}p{\tsize}|}
+\hline
+\rowcolor[gray]{.9}
+S\-t\-a\-g\-e & C\-D\--{}\-R\-O\-M & N\-E\-T\-B\-O\-O\-T & C\-o\-m\-m\-e\-n\-t\-s \tabularnewline
+\hline
+\endhead
+\hline
+-{} & \multicolumn{2}{c|}{i\-n\-i\-t\-r\-d\--{}\-p\-r\-e\-s\-e\-e\-d} & O\-n\-l\-y i\-f \texttt{%% texclean(hyphenon)
+/\-p\-r\-e\-s\-e\-e\-d\-.\-c\-f\-g%% texclean(hyphenoff)
+} i\-s p\-r\-e\-s\-e\-n\-t \tabularnewline
+\hline
+1 & \multicolumn{2}{c|}{l\-o\-c\-a\-l\-e\-c\-h\-o\-o\-s\-e\-r} & L\-a\-n\-g\-u\-a\-g\-e\-/\-c\-o\-u\-n\-t\-r\-y\-/\-l\-o\-c\-a\-l\-e s\-e\-l\-e\-c\-t\-i\-o\-n \tabularnewline
+\hline
+1 & \multicolumn{2}{c|}{k\-b\-d\--{}\-c\-h\-o\-o\-s\-e\-r} & K\-e\-y\-b\-o\-a\-r\-d s\-e\-l\-e\-c\-t\-i\-o\-n \tabularnewline
+\hline
+1 & c\-d\-r\-o\-m\--{}\-d\-e\-t\-e\-c\-t & e\-t\-h\--{}\-d\-e\-t\-e\-c\-t & H\-a\-r\-d\-w\-a\-r\-e d\-e\-t\-e\-c\-t\-i\-o\-n a\-n\-d s\-e\-t\-u\-p \tabularnewline
+\hline
+1 & & n\-e\-t\-c\-f\-g & N\-e\-t\-w\-o\-r\-k c\-o\-n\-f\-i\-g\-u\-r\-a\-t\-i\-o\-n \tabularnewline
+\hline
+-{} & f\-i\-l\-e\--{}\-p\-r\-e\-s\-e\-e\-d & n\-e\-t\-w\-o\-r\-k\--{}\-p\-r\-e\-s\-e\-e\-d & I\-f s\-e\-l\-e\-c\-t\-e\-d a\-t b\-o\-o\-t p\-r\-o\-m\-p\-t \tabularnewline
+\hline
+2 & & c\-h\-o\-o\-s\-e\--{}\-m\-i\-r\-r\-o\-r & M\-i\-r\-r\-o\-r s\-e\-l\-e\-c\-t\-i\-o\-n \tabularnewline
+\hline
+2 & l\-o\-a\-d\--{}\-c\-d\-r\-o\-m (\-a\-n\-n\-a\-) & d\-o\-w\-n\-l\-o\-a\-d\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r (\-a\-n\-n\-a\-) & R\-e\-t\-r\-i\-e\-v\-e a\-n\-d u\-n\-p\-a\-c\-k a\-d\-d\-i\-t\-i\-o\-n\-a\-l c\-o\-m\-p\-o\-n\-e\-n\-t\-s \tabularnewline
+\hline
+3 & e\-t\-h\--{}\-d\-e\-t\-e\-c\-t & & H\-a\-r\-d\-w\-a\-r\-e d\-e\-t\-e\-c\-t\-i\-o\-n a\-n\-d s\-e\-t\-u\-p \tabularnewline
+\hline
+3 & n\-e\-t\-c\-f\-g & & N\-e\-t\-w\-o\-r\-k c\-o\-n\-f\-i\-g\-u\-r\-a\-t\-i\-o\-n \tabularnewline
+\hline
+3 & c\-h\-o\-o\-s\-e\--{}\-m\-i\-r\-r\-o\-r & & M\-i\-r\-r\-o\-r s\-e\-l\-e\-c\-t\-i\-o\-n (\-s\-o\-m\-e\-t\-i\-m\-e\-s n\-e\-e\-d\-e\-d f\-o\-r s\-t\-a\-g\-e 4\-) \tabularnewline
+\hline
+\end{longtable}
+\end{center}
+
+ The remainder of the installation is basically the same for all installation methods.
+
+\begin{center}
+%%% parse_table %%%
+\resizetable{3}{3}{0cm}{}
+\begin{longtable}{|>{\centering}p{\tsize}|>{\centering}p{\tsize}|>{\raggedright}p{\tsize}|}
+\hline
+\rowcolor[gray]{.9}
+S\-t\-a\-g\-e & & C\-o\-m\-m\-e\-n\-t\-s \tabularnewline
+\hline
+\endhead
+\hline
+4 & h\-w\--{}\-d\-e\-t\-e\-c\-t & A\-d\-d\-i\-t\-i\-o\-n\-a\-l h\-a\-r\-d\-w\-a\-r\-e d\-e\-t\-e\-c\-t\-i\-o\-n \tabularnewline
+\hline
+4 & p\-a\-r\-t\-m\-a\-n & P\-a\-r\-t\-i\-t\-i\-o\-n\-i\-n\-g\-, f\-i\-l\-e s\-y\-s\-t\-e\-m c\-r\-e\-a\-t\-i\-o\-n a\-n\-d m\-o\-u\-n\-t p\-o\-i\-n\-t s\-e\-l\-e\-c\-t\-i\-o\-n \tabularnewline
+\hline
+5 & t\-z\-s\-e\-t\-u\-p & T\-i\-m\-e z\-o\-n\-e s\-e\-l\-e\-c\-t\-i\-o\-n \tabularnewline
+\hline
+5 & c\-l\-o\-c\-k\--{}\-s\-e\-t\-u\-p & C\-o\-n\-f\-i\-g\-u\-r\-e f\-o\-r h\-a\-r\-d\-w\-a\-r\-e c\-l\-o\-c\-k s\-e\-t t\-o U\-T\-C o\-r l\-o\-c\-a\-l t\-i\-m\-e z\-o\-n\-e \tabularnewline
+\hline
+5 & u\-s\-e\-r\--{}\-s\-e\-t\-u\-p & S\-e\-t u\-p r\-o\-o\-t a\-n\-d n\-o\-r\-m\-a\-l u\-s\-e\-r a\-c\-c\-o\-u\-n\-t\-s \tabularnewline
+\hline
+5 & b\-a\-s\-e\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r & B\-a\-s\-e s\-y\-s\-t\-e\-m (\-d\-e\-b\-o\-o\-t\-s\-t\-r\-a\-p\-) \ & \tabularnewline
+\hline
+5 & a\-p\-t\--{}\-s\-e\-t\-u\-p & A\-P\-T c\-o\-n\-f\-i\-g\-u\-r\-a\-t\-i\-o\-n i\-n t\-h\-e t\-a\-r\-g\-e\-t s\-y\-s\-t\-e\-m (\-s\-o\-u\-r\-c\-e\-s\-.\-l\-i\-s\-t\-) \tabularnewline
+\hline
+5 & p\-k\-g\-s\-e\-l & S\-e\-l\-e\-c\-t a\-n\-d i\-n\-s\-t\-a\-l\-l a\-d\-d\-i\-t\-i\-o\-n\-a\-l p\-a\-c\-k\-a\-g\-e\-s (\-t\-a\-s\-k\-s\-e\-l\-) \tabularnewline
+\hline
+5 & g\-r\-u\-b\-/\-l\-i\-l\-o\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\-; n\-o\-b\-o\-o\-t\-l\-o\-a\-d\-e\-r & B\-o\-o\-t l\-o\-a\-d\-e\-r i\-n\-s\-t\-a\-l\-l\-a\-t\-i\-o\-n \tabularnewline
+\hline
+5 & p\-r\-e\-b\-a\-s\-e\-c\-o\-n\-f\-i\-g$^{\text{a\-)}}$ & F\-i\-n\-i\-s\-h u\-p t\-h\-e i\-n\-s\-t\-a\-l\-l\-a\-t\-i\-o\-n a\-n\-d r\-e\-b\-o\-o\-t \tabularnewline
+\hline
+\end{longtable}
+\end{center}
+
+ $^{\text{a)}}$ Will soon be renamed to \texttt{%% texclean(hyphenon)
+f\-i\-n\-i\-s\-h\--{}\-i\-n\-s\-t\-a\-l\-l%% texclean(hyphenoff)
+}. The name {`}\texttt{%% texclean(hyphenon)
+p\-r\-e\-b\-a\-s\-e\-c\-o\-n\-f\-i\-g%% texclean(hyphenoff)
+}{'} no longer makes any sense as \texttt{%% texclean(hyphenon)
+b\-a\-s\-e\--{}\-c\-o\-n\-f\-i\-g%% texclean(hyphenoff)
+} was obsoleted with Etch Beta 2.
+
+
+\subsection{Installation methods}
+ The installer supports a lot of different installation methods and in some cases installation methods can be creatively combined. The definition of an installation method is based on the following questions.
+ \begin{itemize}
+
+\item{} How is the installer booted?
+
+
+\item{} From where are additional udebs retrieved?
+
+
+\item{} From where are packages needed to install the base system retrieved?
+
+
+\item{} From where are packages needed to install tasks retrieved\footnote{
+ The last question can also be rephrased as {`}what source lines are set up in the \texttt{%% texclean(hyphenon)
+/\-e\-t\-c\-/\-a\-p\-t\-/\-s\-o\-u\-r\-c\-e\-s\-.\-l\-i\-s\-t%% texclean(hyphenoff)
+} file for the target system{'}.
+
+}?
+
+\end{itemize}
+
+
+ The table below shows the answers to these questions for the most common installation methods.
+
+\begin{center}
+%%% parse_table %%%
+\resizetable{5}{5}{0cm}{}
+\begin{longtable}{|>{\raggedright}p{\tsize}|>{\raggedright}p{\tsize}|>{\raggedright}p{\tsize}|>{\raggedright}p{\tsize}|>{\raggedright}p{\tsize}|}
+\hline
+\rowcolor[gray]{.9}
+M\-e\-t\-h\-o\-d & B\-o\-o\-t & U\-d\-e\-b\-s & B\-a\-s\-e s\-y\-s\-t\-e\-m & T\-a\-s\-k\-s \tabularnewline
+\hline
+\endhead
+\hline
+n\-e\-t\-b\-o\-o\-t & n\-e\-t\-w\-o\-r\-k (\-T\-F\-T\-P s\-e\-r\-v\-e\-r\-) & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+m\-i\-n\-i\-.\-i\-s\-o & C\-D & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+b\-u\-s\-i\-n\-e\-s\-s\-c\-a\-r\-d C\-D & C\-D & C\-D & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+n\-e\-t\-i\-n\-s\-t C\-D & C\-D & C\-D & C\-D & n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+f\-u\-l\-l C\-D\-/\-D\-V\-D & C\-D & C\-D & C\-D & C\-D (\-+ n\-e\-t\-w\-o\-r\-k\-) \tabularnewline
+\hline
+h\-d\--{}\-m\-e\-d\-i\-a$^{\text{a\-)}}$ & h\-a\-r\-d\-d\-i\-s\-k\-/\-U\-S\-B s\-t\-i\-c\-k & C\-D i\-m\-a\-g\-e & C\-D i\-m\-a\-g\-e\-/\-n\-e\-t\-w\-o\-r\-k & C\-D i\-m\-a\-g\-e\-/\-n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+f\-l\-o\-p\-p\-y (\-n\-e\-t\-) & b\-o\-o\-t\-/\-r\-o\-o\-t\-/\-n\-e\-t\--{}\-d\-r\-i\-v\-e\-r\-s & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k & n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+f\-l\-o\-p\-p\-y (\-c\-d\-)$^{\text{a\-)}}$ & b\-o\-o\-t\-/\-r\-o\-o\-t\-/\-c\-d\--{}\-d\-r\-i\-v\-e\-r\-s & C\-D & C\-D\-/\-n\-e\-t\-w\-o\-r\-k & C\-D\-/\-n\-e\-t\-w\-o\-r\-k \tabularnewline
+\hline
+\end{longtable}
+\end{center}
+
+ $^{\text{a)}}$ Whether packages for the base system and tasks are retrieved from CD (image) or the network depends on the type of CD used in combination with these boot methods.
+
+
+\subsection{The boot process}
+ The boot process for the installer is similar to the boot of a regular system. A bootloader (in some cases the system's firmware) is responsible for loading the kernel and loading the initrd after which init is started. The boot process can be debugged by adding the {\bf {\tt BOOT\_DEBUG}} parameter.
+
+
+ It is possible to pass additional kernel and boot parameters. Kernel parameters are sometimes needed to get non-{}conformant hardware supported, or to install from serial console instead of an attached keyboard/display.
+
+
+ Boot parameters can also be used to influence the installer itself. More about this in the section on preseeding.
+
+
+ The boot process is currently quite complex as it needs to support several generations of linux:
+ \begin{itemize}
+
+\item{} 2.2, 2.4 and 2.6 kernels with devfs, all subtly different
+
+
+\item{} 2.6 kernels with udev; several generations, both with and without hotplug
+
+\end{itemize}
+
+
+ The following enumeration gives an overview of the main steps in the boot process.
+
+
+\noindent
+\begin{description}
+\item[{1) \textbf{/init} (initramfs) or \textbf{/sbin/init} (initrd)}] Sets up initial environment (\texttt{%% texclean(hyphenon)
+/\-p\-r\-o\-c%% texclean(hyphenoff)
+}, \texttt{%% texclean(hyphenon)
+/\-d\-e\-v%% texclean(hyphenoff)
+}; run \textbf{udev})
+
+\item[{2) \textbf{busybox init}}] \texttt{%% texclean(hyphenon)
+/\-e\-t\-c\-/\-i\-n\-i\-t\-t\-a\-b%% texclean(hyphenoff)
+} is parsed; this contains:
+ \begin{itemize}
+
+\item{}\texttt{%% texclean(hyphenon)
+:\-:\-s\-y\-s\-i\-n\-i\-t\-:\-/\-s\-b\-i\-n\-/\-d\-e\-b\-i\-a\-n\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\--{}\-s\-t\-a\-r\-t\-u\-p%% texclean(hyphenoff)
+}
+
+\item{}\texttt{%% texclean(hyphenon)
+:\-:\-r\-e\-s\-p\-a\-w\-n\-:\-/\-s\-b\-i\-n\-/\-d\-e\-b\-i\-a\-n\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r%% texclean(hyphenoff)
+}
+
+\item{} init for VT2 (busybox shell), VT3 (\texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-o\-g\-/\-m\-e\-s\-s\-a\-g\-e\-s%% texclean(hyphenoff)
+}), VT4 (\texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-o\-g\-/\-s\-y\-s\-l\-o\-g%% texclean(hyphenoff)
+})
+
+\end{itemize}
+
+\item[{3) \textbf{/sbin/debian-{}installer-{}startup}}] This is a run-{}parts like script that executes or sources scripts in \texttt{%% texclean(hyphenon)
+/\-l\-i\-b\-/\-d\-e\-b\-i\-a\-n\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\--{}\-s\-t\-a\-r\-t\-u\-p\-.\-d%% texclean(hyphenoff)
+}. The main functions that are performed are:
+ \begin{itemize}
+
+\item{} mount \texttt{%% texclean(hyphenon)
+d\-e\-v\-f\-s%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+s\-y\-s\-f\-s%% texclean(hyphenoff)
+} if appropriate
+
+
+\item{} run \textbf{udev}/\textbf{hotplug}
+
+\item{} load acpi modules
+
+
+\item{} start syslog
+
+
+\item{} check available memory and, depending on preset limits, enable a lowmem mode if needed
+
+
+\item{} load any debconf templates present in the initrd
+
+
+\item{} parse boot parameters to look for debconf patterns ({\bf {\tt <\texttt{\emph{\small{%% texclean(hyphenon)
+c\-o\-m\-p\-o\-n\-e\-n\-t%% texclean(hyphenoff)
+}}}>/<\texttt{\emph{\small{%% texclean(hyphenon)
+t\-e\-m\-p\-l\-a\-t\-e%% texclean(hyphenoff)
+}}}>=<\texttt{\emph{\small{%% texclean(hyphenon)
+v\-a\-l\-u\-e%% texclean(hyphenoff)
+}}}>}}) and set these in the debconf database
+
+
+\item{} detect the type of console that is used
+
+
+\item{} load framebuffer modules
+
+
+\item{} detect if the installer should run in rescue mode
+
+\end{itemize}
+
+\item[{4) \textbf{/sbin/debian-{}installer}}] This is a run-{}parts like script that sources scripts in \texttt{%% texclean(hyphenon)
+/\-l\-i\-b\-/\-d\-e\-b\-i\-a\-n\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\-.\-d%% texclean(hyphenoff)
+}. The main functions that are performed are:
+ \begin{itemize}
+
+\item{} detect if a framebuffer device is available
+
+
+\item{} initialize the console (blanking, UTF-{}8)
+
+
+\item{} select which debconf frontend is to be used (text, newt, gtk)
+
+
+\item{} start \texttt{%% texclean(hyphenon)
+m\-a\-i\-n\--{}\-m\-e\-n\-u%% texclean(hyphenoff)
+} (see next section)
+
+
+\item{} halt or reboot the system (after \texttt{%% texclean(hyphenon)
+m\-a\-i\-n\--{}\-m\-e\-n\-u%% texclean(hyphenoff)
+} exits)
+
+\end{itemize}
+
+\end{description}
+
+ Scripts in \texttt{%% texclean(hyphenon)
+/\-l\-i\-b\-/\-d\-e\-b\-i\-a\-n\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\-(\--{}\-s\-t\-a\-r\-t\-u\-p\-)\-.\-d%% texclean(hyphenoff)
+} can be architecture specific.
+
+
+\subsection{The Debian Installer Menu}
+ The component \texttt{%% texclean(hyphenon)
+m\-a\-i\-n\--{}\-m\-e\-n\-u%% texclean(hyphenoff)
+} drives the rest of the installation. It is responsible both for dynamically assembling the menu and for executing components when they are selected. Note that the menu is only actually visible when installing at low or medium debconf priority. At higher priorities it is still there, but it will automatically execute the next component without showing the menu to the user.
+
+
+ In some situations the debconf priority is automatically changed. It is reduced when the execution of a component fails, or when the user uses the {\bf {\tt <go back>}} button to back out all the way to the menu. In these cases it will also be increased back to the original level when the next component executed finishes successfully.
+
+
+ An important characteristic of udebs is that execution of their postinst scripts is delayed. On installation udebs are only unpacked; the execution of the postinst is done by main-{}menu and is actually what happens when a component is selected in the menu. In other words, main-{}menu can be said to be responsible for {`}configuring{'} the udeb.
+
+
+ For a component to be included in the menu, it needs to have an \texttt{%% texclean(hyphenon)
+I\-n\-s\-t\-a\-l\-l\-e\-r\--{}\-M\-e\-n\-u\--{}\-I\-t\-e\-m%% texclean(hyphenoff)
+} line in the \texttt{%% texclean(hyphenon)
+d\-p\-k\-g%% texclean(hyphenoff)
+} status file (\texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-i\-b\-/\-d\-p\-k\-g\-/\-s\-t\-a\-t\-u\-s%% texclean(hyphenoff)
+}). The order of components in the menu is determined primarily by its dependencies; the menu item number is used only where the order for two or more components cannot be resolved by dependencies alone.
+
+
+ Provides can be used to define virtual states which other components can depend on, as shown in the next example.
+
+\begin{lstlisting}[firstnumber=1,]
+Package: netcfg
+Status: install ok installed
+Version: 1.23
+Provides: configured-network
+Depends: libc6 (>= 2.3.5-1), libdebconfclient0, libdebian-installer4 (>= 0.37),
+ dhcp-client-udeb | dhcp3-client-udeb | pump-udeb, libiw28-udeb,
+ cdebconf-udeb, ethernet-card-detection
+Description: Configure the network
+Installer-Menu-Item: 18
+
+Package: choose-mirror
+Status: install ok unpacked
+Version: 1.19
+Depends: libc6 (>= 2.3.5-1), libdebconfclient0, libdebian-installer4 (>= 0.38),
+ configured-network
+Description: Choose mirror to install from
+Installer-Menu-Item: 23
+\end{lstlisting}
+
+
+ This example also shows that netcfg has been run successfully ({`}installed{'}) while mirror selection has not yet taken place ({`}unpacked{'}).
+
+
+ Some components are included in the menu but are not run by default. These components have a menu number higher than prebaseconfig. Examples are components that allow to change the debconf priority, to save debug logs, to check the integrity of a CD-{}ROM or to abort the installation.
+
+
+\subsection{Hooks provide additional flexibility}
+ At certain points in the installation, components provide run-{}parts like execution of scripts. This allows other components to just drop scripts there so that commands can be run at that point in the installation, even though the postinst for the component itself is run earlier or later (if the component even has a postinst).
+
+
+ The main hooks are:
+
+\noindent
+\begin{description}
+\item[{\texttt{%% texclean(hyphenon)
+/\-u\-s\-r\-/\-l\-i\-b\-/\-b\-a\-s\-e\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\-.\-d%% texclean(hyphenoff)
+}}] Run by base-{}installer before debootstrap is started.
+
+\item[{\texttt{%% texclean(hyphenon)
+/\-u\-s\-r\-/\-l\-i\-b\-/\-p\-o\-s\-t\--{}\-b\-a\-s\-e\--{}\-i\-n\-s\-t\-a\-l\-l\-e\-r\-.\-d%% texclean(hyphenoff)
+}}] Run by base-{}installer just before kernel selection/installation.
+
+\item[{\texttt{%% texclean(hyphenon)
+/\-u\-s\-r\-/\-l\-i\-b\-/\-p\-r\-e\-b\-a\-s\-e\-c\-o\-n\-f\-i\-g\-.\-d%% texclean(hyphenoff)
+}}] Run by prebaseconfig.
+
+\end{description}
+
+
+ Other, more special purpose hooks are \texttt{%% texclean(hyphenon)
+/\-u\-s\-r\-/\-l\-i\-b\-/\-a\-p\-t\--{}\-s\-e\-t\-u\-p\-/\-g\-e\-n\-e\-r\-a\-t\-o\-r\-s%% texclean(hyphenoff)
+}, \texttt{%% texclean(hyphenon)
+/\-l\-i\-b\-/\-m\-a\-i\-n\--{}\-m\-e\-n\-u\-.\-d%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+/\-l\-i\-b\-/\-r\-e\-s\-c\-u\-e\-.\-d%% texclean(hyphenoff)
+}.
+
+
+ Besides these general hooks, partman is basically structured as one big collection of hooks where partman components all drop their own scriptlets to extend partman's functionality. The most noteworthy of these hooks is \texttt{%% texclean(hyphenon)
+/\-l\-i\-b\-/\-p\-a\-r\-t\-m\-a\-n\-/\-f\-i\-n\-i\-s\-h\-.\-d%% texclean(hyphenoff)
+} as some bootloaders drop scripts there to add checks that ensure the selected partitioning scheme conforms to their requirements.
+
+
+\subsection{Some special tools}
+ The installer has some special commands which can be used in postinst or preseeding scripts:
+
+\noindent
+\begin{description}
+\item[{\textbf{anna-{}install}}] Used to install additional, non-{}standard d-{}i components (udebs). It will check if \texttt{%% texclean(hyphenon)
+a\-n\-n\-a%% texclean(hyphenoff)
+} has already been run. If it has, the component is unpacked immediately; if it has not, it will be scheduled for installation when \texttt{%% texclean(hyphenon)
+a\-n\-n\-a%% texclean(hyphenoff)
+} is run.
+
+\item[{\textbf{apt-{}install}}] Performs the same function for normal packages and installs them in the target system. Packages will either be installed immediately (if called after base-{}installer) or scheduled for installation as one of the {`}extra{'} packages installed near the end of base-{}installer's postinst script.
+
+\item[{\textbf{log-{}output}}] Allows to run a command and redirect its output (either \texttt{%% texclean(hyphenon)
+s\-t\-d\-o\-u\-t%% texclean(hyphenoff)
+} or \texttt{%% texclean(hyphenon)
+s\-t\-d\-e\-r\-r%% texclean(hyphenoff)
+} or both) to \texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-o\-g\-/\-s\-y\-s\-l\-o\-g%% texclean(hyphenoff)
+}.
+
+\item[{\textbf{in-{}target}}] Allows to run a command in a chroot on \texttt{%% texclean(hyphenon)
+/\-t\-a\-r\-g\-e\-t%% texclean(hyphenoff)
+} with the chroot being set up for more demanding operations. For example, \texttt{%% texclean(hyphenon)
+p\-r\-o\-c%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+s\-y\-s\-f\-s%% texclean(hyphenoff)
+} are mounted and a \texttt{%% texclean(hyphenon)
+p\-o\-l\-i\-c\-y\--{}\-r\-c\-.\-d%% texclean(hyphenoff)
+} is created. Can obviously only be used after the base system has been set up.
+
+\end{description}
+
+
+\subsection{Automating the install using preseeding}
+ There are three preseed methods that are currently supported:
+
+\noindent
+\begin{description}
+\item[{\emph{initrd preseeding}}] The preseed file \texttt{%% texclean(hyphenon)
+/\-p\-r\-e\-s\-e\-e\-d\-.\-c\-f\-g%% texclean(hyphenoff)
+} needs to be present in the initrd. It is read as part of the \textbf{debian-{}installer-{}startup} processing.
+
+\item[{\emph{file preseeding}}] Triggered by the presence of the {\bf {\tt preseed/file}} boot parameter.
+
+\item[{\emph{network preseeding}}] Triggered by the presence of the {\bf {\tt preseed/url}} boot parameter. In versions later than Etch Beta 2 it is also possible to trigger this from the DHCP server.
+
+\end{description}
+ Which of these methods is available depends on the installation method.
+
+
+ The main purpose of preseeding is to set default values for debconf questions. Note that it makes no sense when using file or network preseeding to preseed values for questions that are asked \emph{before} the preseed file is parsed.
+
+
+ Besides offering the option to set default values for debconf questions, preseeding also makes it possible to run scripts at two distinct moments using {\bf {\tt preseed/early\_command}} and {\bf {\tt preseed/late\_command}}. The {\bf {\tt early\_command}} is executed immediately after the preseed file is parsed (only for file and network preseeding); the {\bf {\tt late\_command}} is executed as part of the \textbf{prebaseconfig} component.
+
+
+ These scripts can be made as complex as you like. One option is to use them to install additional packages on the target system (using \textbf{apt-{}install}). The {\bf {\tt early\_command}} could be used to install additional d-{}i components (using \textbf{anna-{}install}) or to install scripts in the various hook script directories (if commands need to be executed at a specific point in the installation).
+
+
+ Additional information about preseeding is available in an appendix of the Installation Guide.
+
+
+\subsection{Debugging the installer}
+ Because most of the installer is scripted, it is fairly easy to debug most problems by adding a {\bf {\tt set -{}x}} in the correct place. The obvious place to start is the postinst of the component you want to debug. The output will appear in \texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-o\-g\-/\-s\-y\-s\-l\-o\-g%% texclean(hyphenoff)
+}, which can most easily be viewed by starting the internal webserver from the {`}Save debug logs{'} menu option (after the network has been configured).
+
+
+ For components written in C debugging is a bit harder. Options are to use the strace udeb (add it to a custom image if needed) or to create a custom version of a component with added debug statements in the source and use that.
+
+
+ For debugging, you will probably want to control when components are started. Booting the installer with {\bf {\tt install debconf/priority=medium}} is a good way to achieve that. It will make sure the menu is displayed before a new component is started.
+
+
+ If you boot the installer at medium priority, you will also be able to load the optional component \texttt{%% texclean(hyphenon)
+o\-p\-e\-n\--{}\-s\-s\-h\--{}\-c\-l\-i\-e\-n\-t%% texclean(hyphenoff)
+}\footnote{
+ If you want to load optional components when installing at the default priority, just back out to the menu and select the component that installs additional installer components.
+
+}. Loading this component will allow you to use \textbf{scp} to copy files from the system being installed to another computer and vice versa. Also useful for testing new versions of scripts or commands without rebuilding the udeb and image. The command \textbf{nc} from the \texttt{%% texclean(hyphenon)
+n\-e\-t\-c\-a\-t%% texclean(hyphenoff)
+} package is available by default in the installer.
+
+
+\section{D-{}I components or udebs}
+ A udeb (or micro-{}deb) is a special kind of Debian package. Technically udebs are very similar to regular packages: you can look at their contents using \textbf{dpkg -{}c}, and extract them using \textbf{dpkg -{}x} and \textbf{dpkg -{}e}.
+
+
+ The main difference is that a lot of policy requirements are waived. For example, a udeb does not contain a changelog, licence, manpages or md5sum\footnote{
+ Of course, the source package for a udeb \emph{does} need to contain a proper licence and changelog.
+
+}. The reason is to minimize size which is important as the installation completely takes place in RAM, with swap only becoming available after stage 4 of the installation (partitioning).
+
+
+ Another important difference is that udebs are not really meant to be uninstalled or upgraded.
+
+
+ The relaxed policy requirements make one of the reasons that udebs should to be installed on a normal system. The other reason being that it just doesn't make sense and it's likely to break things.
+
+
+ Two special classes of udebs should be mentioned here. However, covering these in detail is outside the scope of this paper.
+
+\noindent
+\begin{description}
+\item[{Kernel image and kernel module udebs}] Kernel udebs are built basically by repackaging a regular kernel-{}image package. Reason is again to reduce memory usage: not all modules included in a kernel-{}image package are needed during an installation. Also, different modules are needed in the initrd for different installation methods, remaining modules can either be loaded later or optionally (by manual selection or through dependencies). The package \texttt{%% texclean(hyphenon)
+k\-e\-r\-n\-e\-l\--{}\-w\-e\-d\-g\-e%% texclean(hyphenoff)
+} contains the toolset used to reorganize a kernel-{}image package into multiple kernel (module) udebs.
+
+\item[{Partman and its components}] Partman has a very specific structure and requires a fairly strict conformance to this structure for udebs that extend its functionality.
+
+\end{description}
+
+
+\subsection{Contents of a udeb}
+ For components that are included in the main menu, the udeb will at least contain:
+ \begin{itemize}
+
+\item{} a postinst
+
+
+
+\item{} a debconf template that contains the description for the main menu:
+
+\begin{lstlisting}[firstnumber=1,]
+debian-installer/<component>/title
+Type: text
+_Description: Configure time zone
+\end{lstlisting}
+
+
+\end{itemize}
+
+
+ Other things like additional debconf templates, C programs, hook scripts can be added as needed.
+
+
+ A special type of control file worth mentioning is the \texttt{%% texclean(hyphenon)
+i\-s\-i\-n\-s\-t\-a\-l\-l\-a\-b\-l\-e%% texclean(hyphenoff)
+} file. If a script with this name is present in \texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-i\-b\-/\-d\-p\-k\-g\-/\-i\-n\-f\-o%% texclean(hyphenoff)
+} for a component, the main menu will run this script and only include the component in the menu if the script exits 0.
+
+
+\subsection{Creating a udeb}
+ Creating a udeb is not all that hard, especially if you use \texttt{%% texclean(hyphenon)
+d\-e\-b\-h\-e\-l\-p\-e\-r%% texclean(hyphenoff)
+}. \texttt{%% texclean(hyphenon)
+d\-e\-b\-h\-e\-l\-p\-e\-r%% texclean(hyphenoff)
+} knows the special properties of a udeb and will do the right thing by default at build time. That is, if you don't forget to tell it you are creating a udeb.
+
+
+ The example below shows the \texttt{%% texclean(hyphenon)
+d\-e\-b\-i\-a\-n\-/\-c\-o\-n\-t\-r\-o\-l%% texclean(hyphenoff)
+} file for a udeb that is supposed to be included in the main menu. Note the special section.
+
+
+\begin{lstlisting}[firstnumber=1,]
+Source: kbd-chooser
+Section: debian-installer
+Priority: optional
+Maintainer: Debian Install System Team <debian-boot at lists.debian.org>
+Uploaders: [...]
+Build-Depends: debhelper (>= 5.0.22), libdebian-installer4-dev (>= 0.41), po-debconf (>= 0.5.0), flex | flex-old , bison, libdebconfclient0-dev (>= 0.49)
+
+Package: kbd-chooser
+Architecture: i386 amd64 powerpc alpha hppa sparc [...]
+XC-Package-Type: udeb
+Depends: ${shlibs:Depends}, ${misc:Depends}, console-keymaps
+Description: Detect a keyboard and select layout
+XB-Installer-Menu-Item: 12
+\end{lstlisting}
+
+ The line \texttt{%% texclean(hyphenon)
+X\-C\--{}\-P\-a\-c\-k\-a\-g\-e\--{}\-T\-y\-p\-e%% texclean(hyphenoff)
+} tells \texttt{%% texclean(hyphenon)
+d\-e\-b\-h\-e\-l\-p\-e\-r%% texclean(hyphenoff)
+} to treat the package as a udeb. The \texttt{%% texclean(hyphenon)
+X\-B\--{}\-I\-n\-s\-t\-a\-l\-l\-e\-r\--{}\-M\-e\-n\-u\--{}\-I\-t\-e\-m%% texclean(hyphenoff)
+} is added in the control file for the udeb and will eventually end up in the \texttt{%% texclean(hyphenon)
+d\-p\-k\-g%% texclean(hyphenoff)
+} status file to help \texttt{%% texclean(hyphenon)
+m\-a\-i\-n\--{}\-m\-e\-n\-u%% texclean(hyphenoff)
+} figure out that this udeb should be included in the menu and in what order\footnote{
+ The file \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-d\-o\-c\-/\-d\-e\-v\-e\-l\-/\-m\-e\-n\-u\--{}\-i\-t\-e\-m\--{}\-n\-u\-m\-b\-e\-r\-s\-.\-t\-x\-t%% texclean(hyphenoff)
+} in the d-{}i SVN repository documents menu numbers currently in use.
+
+}.
+ Packaging a udeb becomes a bit harder if it is derived from a regular package but needs to be compiled with different compiler options (e.g. some features disabled or a different optimization).
+
+
+ The main thing to always keep in mind when creating a udeb is size. It is very important to keep size as minimal as possible. This includes using tabs instead of spaces when indenting in scripts and not being too verbose in comments.
+
+
+\subsection{Library udebs}
+ A major recent improvement is the addition of {`}package type{'} support in shlibs files for libraries. This allows \textbf{dpkg-{}dev} and \texttt{%% texclean(hyphenon)
+d\-e\-b\-h\-e\-l\-p\-e\-r%% texclean(hyphenoff)
+} to automatically set correct dependencies on library udebs when a d-{}i component that depends on them is built.
+
+
+ For example, the regular binary package \texttt{%% texclean(hyphenon)
+z\-l\-i\-b\-1\-g%% texclean(hyphenoff)
+} now has the following lines in its shlibs control file:
+
+\begin{lstlisting}[firstnumber=1,]
+libz 1 zlib1g (>= 1:1.2.1)
+udeb: libz 1 zlib1g-udeb (>= 1:1.2.1)
+\end{lstlisting}
+
+
+ The second line is specific to the package type {`}udeb{'}. This alternative line is used when \textbf{dpkg-{}shlibdeps} is called with the \textbf{-{}tudeb} option; \textbf{dh\_shlibdeps} will automatically add this option when processing a udeb.
+
+
+ Generating the extra \texttt{%% texclean(hyphenon)
+u\-d\-e\-b\-:%% texclean(hyphenoff)
+} lines is supported by \textbf{dh\_makeshlibs} if the \textbf{-{}-{}add-{}udeb="<udeb name>"} option is used. For example, the \texttt{%% texclean(hyphenon)
+d\-e\-b\-i\-a\-n\-/\-r\-u\-l\-e\-s%% texclean(hyphenoff)
+} file for \texttt{%% texclean(hyphenon)
+l\-i\-b\-u\-s\-b%% texclean(hyphenoff)
+} contains the following line:
+
+\begin{lstlisting}[firstnumber=1,]
+dh_makeshlibs -V -s --add-udeb="libusb-0.1-udeb"
+\end{lstlisting}
+
+
+\section{Building installer images}
+ This paper will only provide an introduction to building installer images using existing definitions. The README in \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-b\-u\-i\-l\-d%% texclean(hyphenoff)
+} in the SVN repository contains more detailed information about the build system and how to modify existing or define new images.
+
+
+ An image consists of:
+ \begin{itemize}
+
+\item{} a kernel;
+
+
+\item{} an initrd, which is basically a collection of unpacked udebs;
+
+
+\item{} in some cases a boot loader and/or configuration files used for booting.
+
+\end{itemize}
+
+
+ Most d-{}i images are {`}ready for use{'}. The exception are the cdrom images which form only the base (kernel and initrd) for creating the actual CD or DVD images. The package used for creating the CD/DVD images is \texttt{%% texclean(hyphenon)
+d\-e\-b\-i\-a\-n\--{}\-c\-d%% texclean(hyphenoff)
+}.
+
+
+ On some architectures there is one CD image that \emph{is} ready for use: the \texttt{%% texclean(hyphenon)
+m\-i\-n\-i\-.\-i\-s\-o%% texclean(hyphenoff)
+} that is produced as a by-{}product of the netboot target. Reason is that this image does not really support installing from CD, it just allows booting from CD but retrieves all additional udebs and packages over the network.
+
+
+ It is important to distinguish between building images for release and building images for development/testing use.
+
+
+ A release build is done, as for other packages that are to be uploaded, from the \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r%% texclean(hyphenoff)
+} directory using \textbf{debian/rules}. This will create a binary package (needed for uploading) containing some documentation, but the important bit is a tarball containing all installer images. After the upload this tarball needs BYHAND processing\footnote{
+ This entails unpacking the tarball into the correct location on the master mirror server and creating/updating the correct symlinks. See for example \url{http://ftp.debian.org/debian/dists/sid/main/installer-i386/}.
+
+} by FTP-{}masters before the buildds will pick up the upload for other architectures.
+
+
+ Building images for development and testing is done from the \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-b\-u\-i\-l\-d%% texclean(hyphenoff)
+} directory\footnote{
+ This includes the daily built images available from \url{http://www.debian.org/devel/debian-installer}. These are generated and uploaded from machines run by d-{}i porters using the daily-{}build script.
+
+} using \textbf{fakeroot make <\texttt{\emph{\small{%% texclean(hyphenon)
+t\-a\-r\-g\-e\-t%% texclean(hyphenoff)
+}}}>}.
+
+
+ An important difference between release and development builds is that release builds will use udebs for the same suite as the target system being installed, while development builds will by default install testing, but use udebs from unstable\footnote{
+ This is accomplished by including the \texttt{%% texclean(hyphenon)
+/\-i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-b\-u\-i\-l\-d\-/\-u\-n\-s\-t\-a\-b\-l\-e\-.\-c\-f\-g%% texclean(hyphenoff)
+} preseed file in the initrd.
+
+}. This allows to mostly avoid the occasional breakage of the base system and tasks in unstable while using the most recent udebs.
+
+
+\subsection{Requirements for building}
+ For both release and development builds the build dependencies as listed in \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-d\-e\-b\-i\-a\-n\-/\-c\-o\-n\-t\-r\-o\-l%% texclean(hyphenoff)
+} need to be satisfied.
+
+
+ To build installer images from SVN trunk, your build machine needs to be running unstable or you need to set up a sid chroot to build in. (To build images from the sarge branch of the repository, the build machine needs to run Sarge.)
+
+
+ During the build, the needed udebs will be retrieved from a mirror. By default this mirror is based on your \texttt{%% texclean(hyphenon)
+/\-e\-t\-c\-/\-a\-p\-t\-/\-s\-o\-u\-r\-c\-e\-s\-.\-l\-i\-s\-t%% texclean(hyphenoff)
+} (see the generated file \texttt{%% texclean(hyphenon)
+b\-u\-i\-l\-d\-/\-s\-o\-u\-r\-c\-e\-s\-.\-l\-i\-s\-t\-.\-u\-d\-e\-b%% texclean(hyphenoff)
+}). To use a different source, create a file \texttt{%% texclean(hyphenon)
+s\-o\-u\-r\-c\-e\-s\-.\-l\-i\-s\-t\-.\-u\-d\-e\-b\-.\-l\-o\-c\-a\-l%% texclean(hyphenoff)
+}.
+
+
+\subsection{Build targets}
+ To see which targets are available, run \textbf{make}. This will result in a list of some 130 targets, most of which are not really relevant. A more useful list can be obtained with \textbf{make | grep \^{}build}. The table below has the most often used targets for i386.
+ \begin{center}
+%%% parse_table %%%
+\resizetable{2}{2}{0cm}{}
+\begin{longtable}{|>{\raggedright}p{\tsize}|>{\raggedright}p{\tsize}|}
+\hline
+{\bf {\tt b\-u\-i\-l\-d\-\_\-a\-l\-l}} & B\-u\-i\-l\-d\-s a\-l\-l i\-m\-a\-g\-e\-s \tabularnewline
+\hline
+{\bf {\tt b\-u\-i\-l\-d\-\_\-c\-d\-r\-o\-m\-\_\-i\-s\-o\-l\-i\-n\-u\-x}} & B\-u\-i\-l\-d\-s t\-h\-e c\-d\-r\-o\-m i\-m\-a\-g\-e\-s (\-b\-o\-t\-h 2\-.\-4 a\-n\-d 2\-.\-6\-) \tabularnewline
+\hline
+{\bf {\tt b\-u\-i\-l\-d\-\_\-n\-e\-t\-b\-o\-o\-t}} & B\-u\-i\-l\-d\-s t\-h\-e n\-e\-t\-b\-o\-o\-t i\-m\-a\-g\-e\-s (\-b\-o\-t\-h 2\-.\-4 a\-n\-d 2\-.\-6\-) a\-n\-d t\-h\-e m\-i\-n\-i\-.\-i\-s\-o \tabularnewline
+\hline
+{\bf {\tt r\-e\-a\-l\-l\-y\-c\-l\-e\-a\-n}} & C\-o\-m\-p\-l\-e\-t\-e\-l\-y c\-l\-e\-a\-n\-s t\-h\-e b\-u\-i\-l\-d e\-n\-v\-i\-r\-o\-n\-m\-e\-n\-t \tabularnewline
+\hline
+\end{longtable}
+\end{center}
+ The {\bf {\tt reallyclean}} target is often needed when changes are made between builds because otherwise udebs or information may be retrieved from temporary or cache directories and the changes will not take effect. The \texttt{%% texclean(hyphenon)
+r\-e\-b\-u\-i\-l\-d\-\_\-*%% texclean(hyphenoff)
+} targets clean some of this, but not always enough.
+
+
+\subsection{The build system explained}
+ The easiest way to start is with the purpose of the subdirectories in the \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-b\-u\-i\-l\-d%% texclean(hyphenoff)
+} directory.
+
+\begin{itemize}
+
+\item{} \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g%% texclean(hyphenoff)
+}: defines the available targets (per architecture)
+
+
+
+\item{} \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s%% texclean(hyphenoff)
+}: defines which udebs are included in an image (per image type)
+
+
+
+\item{} \texttt{%% texclean(hyphenon)
+b\-o\-o\-t%% texclean(hyphenoff)
+}: contains configuration files and make targets used to make images bootable
+
+
+
+\item{} \texttt{%% texclean(hyphenon)
+l\-o\-c\-a\-l\-u\-d\-e\-b\-s%% texclean(hyphenoff)
+}: allows to use (versions of) udebs not available on the mirror you use
+
+
+
+\item{} \texttt{%% texclean(hyphenon)
+u\-t\-i\-l%% texclean(hyphenoff)
+}: contains helper scripts called from the Makefile
+
+
+\end{itemize}
+
+ Two files containing important configuration info are \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g\-/\-d\-i\-r%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g\-/\-c\-o\-m\-m\-o\-n%% texclean(hyphenoff)
+}. However, normally there should be no need to modify any of the variables defined in these files.
+
+
+ Both the \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s%% texclean(hyphenoff)
+} directories have a tree structure with general configuration defined in the root and more specific configuration defined in branches and leaves. Branches are defined in directories that have the same name as a config file on the higher level. The \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g%% texclean(hyphenoff)
+} directory contains makefile snippets.
+
+
+\subsubsection{config}
+ For example, the definition for i386 images starts with \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g\-/\-i\-3\-8\-6\-.\-c\-f\-g%% texclean(hyphenoff)
+} which, besides the current kernel versions, defines the media supported with the line:
+
+\begin{lstlisting}[firstnumber=1,]
+MEDIUM_SUPPORTED = cdrom netboot floppy hd-media
+\end{lstlisting}
+
+
+ These media correspond to the main targets for i386 and are further defined in \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g\-/\-i\-3\-8\-6%% texclean(hyphenoff)
+}. The \texttt{%% texclean(hyphenon)
+n\-e\-t\-b\-o\-o\-t\-.\-c\-f\-g%% texclean(hyphenoff)
+} file in that directory contains, amongst others, the following three lines:
+
+\begin{lstlisting}[firstnumber=1,]
+FLAVOUR_SUPPORTED = "" 2.6
+MEDIA_TYPE = netboot image
+EXTRATARGETS = build_netboot_2.6
+\end{lstlisting}
+
+
+ This defines that the netboot image has two flavors: the default one (using a 2.4 kernel) and an one using a 2.6 kernel, which is further defined in the \texttt{%% texclean(hyphenon)
+c\-o\-n\-f\-i\-g\-/\-i\-3\-8\-6\-/\-n\-e\-t\-b\-o\-o\-t\-/\-2\-.\-6\-.\-c\-f\-g%% texclean(hyphenoff)
+} file where the default values of the variables for the kernel version are overruled.
+
+
+ The files in config are processed recursively to dynamically generate the build targets, so in this example you get a netboot, a {\bf {\tt netboot\_2.6}} target and targets for the other media. Building is also recursive, so calling the netboot target will automatically build both the {\bf {\tt netboot}} and {\bf {\tt netboot\_2.6}} images.
+
+
+ The structure of the config files can get quite complex and it can be hard to keep track of the exact role of the different variables set in them.
+
+
+\subsubsection{pkg-{}lists}
+ The list of udebs to be included in an image is built by the \textbf{util/pkg-{}list} script based on definitions in the \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s%% texclean(hyphenoff)
+} directory. Again, processing can be quite complex. Let's take the netboot target for i386 as an example to explain it.
+
+
+ First the file \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-n\-e\-t\-b\-o\-o\-t\-/\-i\-3\-8\-6\-.\-c\-f\-g%% texclean(hyphenoff)
+} is considered and all udebs listed in it are added. Some example lines from that file:
+
+\begin{lstlisting}[firstnumber=1,]
+#include "discover"
+console-keymaps-at
+console-keymaps-usb
+usb-discover [2.4]
+socket-modules-${kernel:Version} ?
+acpi-modules-${kernel:Version} [2.6]
+\end{lstlisting}
+
+
+ The variable \texttt{%% texclean(hyphenon)
+\$\-\{\-k\-e\-r\-n\-e\-l\-:\-V\-e\-r\-s\-i\-o\-n\-\}%% texclean(hyphenoff)
+} is expanded to match the package name of the udeb based on the kernel version and flavor. If the name of a udebs is followed by {`}[2.4]{'} or {`}[2.6]{'}, it is only included if the kernel major version for the image being built matches. If it is followed by a question mark it is skipped if the package is not available (without the question mark an error would be generated).
+
+
+ The first line with the \texttt{%% texclean(hyphenon)
+\#\-i\-n\-c\-l\-u\-d\-e%% texclean(hyphenoff)
+} results in the file \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-d\-i\-s\-c\-o\-v\-e\-r%% texclean(hyphenoff)
+} being processed next in the same way.
+
+
+ The \textbf{pkg-{}list} script will also always look for the presence of files named \texttt{%% texclean(hyphenon)
+c\-o\-m\-m\-o\-n%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+l\-o\-c\-a\-l%% texclean(hyphenoff)
+} and thus \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-n\-e\-t\-b\-o\-o\-t\-/\-c\-o\-m\-m\-o\-n%% texclean(hyphenoff)
+} is processed next. This file exists and lists a number of udebs that belong in any netboot image, independent of the architecture. This file also contains two include directives:
+
+\begin{lstlisting}[firstnumber=1,]
+#include "base"
+#include "kernel"
+\end{lstlisting}
+
+
+ Thus, udebs listed in \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-b\-a\-s\-e%% texclean(hyphenoff)
+} (containing udebs common to all images) and \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-k\-e\-r\-n\-e\-l%% texclean(hyphenoff)
+} (included in all bootable images) are also processed.
+
+
+ The file \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-n\-e\-t\-b\-o\-o\-t\-/\-l\-o\-c\-a\-l%% texclean(hyphenoff)
+} does not normally exist as it is intended for the inclusion of non-{}standard udebs. It is also very useful for testing as it can be used to temporarily add udebs not normally included without teh need to modify the regular files.
+
+
+ Finally, the script will check for \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-l\-o\-c\-a\-l%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-e\-x\-c\-l\-u\-d\-e%% texclean(hyphenoff)
+}. The latter exists and contains some udebs otherwise pulled in by dependencies, but that should not be included because of library reduction, which is covered in the next section. Note that the exclusion if not triggered by the file name, but rather by the dash after the name of the udebs.
+
+
+ All dependencies of udebs listed in \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s%% texclean(hyphenoff)
+} will also be automatically included in the image.
+
+
+ To see how the package list is built for a particular image, set % <code>
+my \$debug=1; in the \textbf{util/pkg-{}list} script.
+
+
+\subsection{Result of the build}
+ If the build is successful, you will find the images under the \texttt{%% texclean(hyphenon)
+b\-u\-i\-l\-d\-/\-d\-e\-s\-t%% texclean(hyphenoff)
+} directory. Depending on the type of build you will also find manifest and log files there.
+
+
+ Before the image is created, its contents are assembled in the directory \texttt{%% texclean(hyphenon)
+b\-u\-i\-l\-d\-/\-t\-m\-p\-/\-<\texttt{\emph{\small{%% texclean(hyphenon)
+t\-a\-r\-g\-e\-t%% texclean(hyphenoff)
+}}}>%% texclean(hyphenoff)
+}. The \texttt{%% texclean(hyphenon)
+t\-r\-e\-e%% texclean(hyphenoff)
+} subdirectory there contains the full contents of the initrd; other subdirectories are used for different purposes.
+
+
+\subsection{Library reduction}
+ Library reduction (relinking a library leaving out unused symbols) is used as yet another method to minimize the size of initrds. The downside of library reduction is that this requires the \texttt{%% texclean(hyphenon)
+d\-e\-v%% texclean(hyphenoff)
+} and \texttt{%% texclean(hyphenon)
+p\-i\-c%% texclean(hyphenoff)
+} packages for the libraries to be reduced to be installed on the build system which also means that their version needs to match the version of the libraries in the udebs.
+
+
+ The size reduction is most significant for libc (40\%) and libm (90\%). Other libraries that are reduced include libresolv, libslang and libnewt. The reduction is done by calling mklibs from the main Makefile.
+
+
+ As only the executables that are included in an image are taken into account during the library reduction, we have provide for executables in components that are installed later as they would fail if they use symbols that have been taken out.
+
+
+ This is the reason that the udebs containing reduced libraries are excluded in \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-e\-x\-c\-l\-u\-d\-e%% texclean(hyphenoff)
+} which results in the udeb not being listed in the \texttt{%% texclean(hyphenon)
+/\-v\-a\-r\-/\-l\-i\-b\-/\-d\-p\-k\-g\-/\-s\-t\-a\-t\-u\-s%% texclean(hyphenoff)
+} file in the intrd. If no udebs that are installed later depend on the library, all is well. If a udeb that does depend on it is installed later, \texttt{%% texclean(hyphenon)
+a\-n\-n\-a%% texclean(hyphenoff)
+} (or rather \textbf{udpkg}) will see that the dependency is not satisfied, and will install the udeb so the unreduced library replaces the reduced version.
+
+
+ Note that library reduction is only done after unpacking udebs for inclusion in an image; the libraries included in udebs are never reduced.
+
+
+\subsection{Using localudebs}
+ The \texttt{%% texclean(hyphenon)
+l\-o\-c\-a\-l\-u\-d\-e\-b\-s%% texclean(hyphenoff)
+} directory allows to use a different version of udebs than is available from the mirror you use. This can be used to test a new version of a udeb or to run the installer with a debug version of a udeb. It can also be used to build an image with a custom udeb.
+
+
+ To use a local udeb, just copy it into the directory. A \texttt{%% texclean(hyphenon)
+P\-a\-c\-k\-a\-g\-e\-s%% texclean(hyphenoff)
+} file will be generated automatically. Your udeb should have a version equal to or greater than the udeb currently on the mirror you use.
+
+
+ Note that local udebs will only be included in the image if the udeb would be included in a normal build too. So it has to be selected by the \textbf{pkg-{}list} script. Create a \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-l\-o\-c\-a\-l%% texclean(hyphenoff)
+} or \texttt{%% texclean(hyphenon)
+p\-k\-g\--{}\-l\-i\-s\-t\-s\-/\-<\texttt{\emph{\small{%% texclean(hyphenon)
+i\-m\-a\-g\-e%% texclean(hyphenoff)
+}}}>/local%% texclean(hyphenoff)
+} to add udebs to the image that would not normally be included.
+
+
+ Some things to keep in mind when using localudebs.
+
+\begin{itemize}
+
+\item{} If you add an extra udeb, its dependencies will be included too. If those dependencies include virtual packages, the result is not always what you'd expect.
+
+
+
+\item{} Adding extra udebs will increase the size of the initrd; some architectures have limits for initrd size.
+
+
+
+\item{} If you use a \texttt{%% texclean(hyphenon)
+s\-o\-u\-r\-c\-e\-s\-.\-l\-i\-s\-t\-.\-u\-d\-e\-b\-.\-l\-o\-c\-a\-l%% texclean(hyphenoff)
+}, make sure to add as the first line:
+
+\begin{lstlisting}[firstnumber=1,]
+deb copy:<path-from-root-to>/installer/build/ localudebs/
+\end{lstlisting}
+
+
+
+\item{} Don't forget to clean up after you're finished.
+
+
+\end{itemize}
+
+\section{Conclusion}
+ Hopefully this paper will help make Debian Installer more accessible to new developers. If you have any suggestions to improve this document, please mail them to the debian-{}boot list or the author. The intention of the author is to use this paper as the basis for a d-{}i developers reference.
+
+
+ For any kind of work on Debian Installer, you should check out the d-{}i SVN repository on alioth:
+
+\begin{lstlisting}[firstnumber=1,]
+$ svn co svn+ssh://svn.debian.org/svn/d-i/trunk
+\end{lstlisting}
+
+
+ Subscription to the debian-{}boot list is recommended. To request commit access to the repository, please send a mail to that list.
+
+
+ Some additional development oriented documentation can be found in the repository under \texttt{%% texclean(hyphenon)
+i\-n\-s\-t\-a\-l\-l\-e\-r\-/\-d\-o\-c\-/\-d\-e\-v\-e\-l%% texclean(hyphenoff)
+} or in \texttt{%% texclean(hyphenon)
+R\-E\-A\-D\-M\-E%% texclean(hyphenoff)
+} files included with the source for various components.
Modified: procedings/all.dvi
===================================================================
(Binary files differ)
Modified: procedings/all.tex
===================================================================
--- procedings/all.tex 2006-04-10 23:36:43 UTC (rev 507)
+++ procedings/all.tex 2006-04-10 23:54:18 UTC (rev 508)
@@ -5,10 +5,10 @@
\usepackage{scrpage} % changing pagestyle
\usepackage{tocloft} % better table of contents
-\usepackage{fancybox} % added for 60-Security-Enhanced-Linux-UML-instances/paper.tex
-\usepackage[english]{varioref} % added for 60-Security-Enhanced-Linux-UML-instances/paper.tex
-
+\usepackage{fancybox} % added for 60-Security-Enhanced-Linux-UML-instances
+\usepackage[english]{varioref} % added for 60-Security-Enhanced-Linux-UML-instances
\usepackage{graphicx} % added for 41-port-together
+\usepackage{/usr/share/xml/docbook/stylesheet/dblatex/latex/style/docbook} % added for 32-debian-installer-internals and 22-community-guidelines
\begin{document}
@@ -120,7 +120,7 @@
\chapter[Debian Installer internals]
{Debian Installer internals\\
\small{by Frans Pop}}
-%\input{32-debian-installer-internals/paper}
+\input{32-debian-installer-internals/paper}
\chapter[Let's port together. Debian fun for everyone]
{Let's port together. Debian fun for everyone\\
More information about the Debconf6-data-commit
mailing list