1997.05.17 Flugs Artikel

Meine Abenteuer bei der Installation von Debian 1.2

Vorgeschichte

Im Gegensatz zu den meisten anderen Linux Usern komme ich nicht von der Windows
Welt her. Meine erste Computer Erfahrung (1981) war eine Dual-Z80 (Terminal und
Host) Maschine gewesen. In der Lehre, am Technikum und im Beruf hatte ich lange
an DEC PDP-11 und VAX Maschinen gearbeitet. Einen 286er+1MB-RAM+40MB-HD mit DOS
3.3 (die beste Software die MS je gemacht hat) und darin eine Transputer Karte
mit Occam hatte ich 1988 für Zuhause besorgt, damals natürlich ohne Windows.
Auch ein 386er mit DOS 3.3 und Dbase im Beruf sowie ein geliehener Macintosh SE
waren zu verbuchen. Daneben hatte ich im Beruf ein paar wenige unbefriedigende
Zusammenstösse mit Windows 3.0 (Absturz beim geringsten Programmierfehler,
Rekord 4 mal in 10 Minuten).

Als der 286er mir zu wenig wurde (anfangs 1991) wollte ich für Zuhause etwas
besseres. DOS war mir zu eng geworden, Windows grauste mir, OS/2 2.0 hatte mich
nicht überzeugt, der Mac war schlicht zu teuer für das gebotene (und zu
geschlossen), eine VAXstation war mir schlicht unbezahlbar. Für Helios (ein
Microkernal Pseudo-Unix für die Transputer Karte mit ca Minix "Komfort") hatte
ich mich ebenfalls nicht begeistern können. Da tauchte der NeXT auf, zwar
ebenfalls mit diesem "Unix Zeugs", aber versteckt unter einer schönen GUI wie
beim Mac, mit einem Preis wie ein grosser Mac aber der Architektur und Leistung
einer VAXstation. Trotz meiner Ablehnung vom Helios her lernte ich Unix bald zu
schätzen (ist ja fast wie VMS!) und wurde somit zum Unix Hacker.

Kurz darauf begann ein Kollege im CCW (Ernst Gosteli, heute auch im LUGS) immer
mehr von einem Unix namens Linux zu schwärmen, aber es interessierte mich nicht
gross. Ich hatte ja ein Unix System (und zwar ein "richtiges"!) nicht so ein
"PC-Spielzeug" (damals war der Kernal 0.96 aktuell und Ernst war schon für
seine Vorliebe für das primitive Helios berüchtigt).

Eines Tages anfangs 94 schickte ein mir damals Unbekannter namens Philip
Markwalder mir eine Mail mit der Anfrage wie die NiCE NeXT User Group (ich war
damals deren Präsident) zu einem Clubraum an der ETH (haben sie heute nicht
mehr) gekommen sei, er wolle eine Linux User Group zu gründen und brauche dafür
einen Clubraum. Als er die Einladung zur Gründerversammlug auch an mich
schickte ging ich einfach aus "Gwunder" vorbei und stiess auf einen Haufen
Verrückter, deren Begeisterung mich an die Anfänge des CCW vor 10 Jahren
errinnerte. Also genau der Ort an dem ich eigentlich hingehörte:-)

Die ersten Treffen, die ich dann besuchte brachten mich schnell dazu im
November 94 ein Linux System auf einem alten 386er+4MB-RAM+100MB-HD (lebt heute
noch als leo.franklin.lugs.ch) zu installieren (eine bereits damals 7 Monate
alte Slackware mit Kernal 1.0.8, die im Linux Kernal Programmierung Buch dabei
gewesen war). Da hab ich dann sehr schnell gemerkt, dass Linux wirklich Unix
ist, und erst noch ein interessantes dazu, vom Freeware Konzept einmal ganz
abgesehen. Der 386er bekam folglich eine 2GB HD, ein neueres Linux 1.2.9 (eine
frühe SUSE, eigentlich eine Slackware mit SUSE Install Programm und
zusätzlichen Paketen), einen besseren Prozessor 486DX/4-100 und wurde meine
Hauptmaschine. Linux ist das bessere Unix als NeXTstep, offener, mehr gutes
Zeugs, etc. Der NeXT wurde Mitte 96 verkauft.

Im Laufe der Zeit wurde diese Installation immer veralteter. Alter Kernal,
altes XFree, alter FVWM, kein ELF, langsames Netzwerk. Also entschloss ich
mich im Februar 97 auf einen 2.0.x Kernal und ELF aufzusteigen. Aber welche
der inzwischen vorhandenen Distributionen? Ueber SUSE wurde immer öfter
gestänkert. David hatte so von Debian geschwärmt, also entschloss ich mich,
mal das auszuprobieren.

Datenträger besorgen

Manche haben einen schnellen Internet Anschluss und können eine Distribution
einfach runterholen. Das scheidet bei meinem 14400 Modem aus, also musste es
eine CD-ROM sein. David hatte in seinen Debian Mails die Firma i-connect als
Verteiler von Debian CDs erwähnt, aber bei denen stiess ich nur auf einen
Telefonbeantworter. Nach etwa 5 Versuchen wurde mir das zu blöd. Werner Burri
erwähnte dann die SUSE Decathlon, eine Sammlug von 10 CDs mit Server Downloads,
darunter neben der SUSE Distribution auch Debian, Original-Slackware und
Red Hat, Ausserdem waren da noch sunsite und tsx-11 darauf (falls ich es ohne
Distribution versuchen wollte). Also besorgte ich mir einen solchen Disk Satz.
SUSE hat zwar bei ihrer eigenen Distribution nicht gerade den besten Ruf aber
Server downloaden sollten sie doch noch können (dachte ich damals noch).

Auspacken und Zurechtfinden

Die CD Nummer 7 war mit Debian angeschrieben, also wanderten die anderen 9
unbesehen in die Schublade. CD 7 landete in Laufwerk meines Servers (mein
Desktop hat kein CD-ROM Laufwerk). Mount auf /cdrom, cd /cdrom, ls. Ein 2MB
grosses File namens INDEX.gz zeigt sich, also es lesen. Es beinhaltet das
Inhaltsverzeichnis aller Dateien aller 10 CDs, in der Reihenfolge 1 10 (ist
riesig) 2 3 4 5 6 7 8 9. Und je länger ich im less in Richtung 7 herunter
scrolle um so mehr swapte der Server (er hat nur 8MB RAM). Das war eine
schlechte Idee, das auf dem Server zu lesen:-) Also auf dem Desktop mount
server:/cdrom /cdrom, cd /cdrom, INDEX.gz nochmals in den less, das ist besser.
In /cdrom/debian soll ein README sein, also das lesen. Und /cdrom/debian/doc
hat eine Reihe von FAQs, also auch die lesen.

Booten

Gemäss dem README sollten zum Installieren eine boot Floppy (genannt resq, kurz
für rescue), eine root, eine driver und 4 base Disketten benützt werden. Ja,
das sind satte 7 Floppies um das Basis System zu installieren (Vergleich 1.0.8
brauchte noch 2, 1.2.9 brauchte 3). Letztere 5 Disketten sind als 1200k und als
1440k Diskimages vorhanden, die beiden ersten sind als universelle Diskimages
da (zumindest sollten sie so sein gemäss dem README).

Also ab ins /cdrom/debian/rex/disks-i386/1996-12-8 Directory (Rex war der
Projektname für Debian Version 1.2 und 1996-12-8 zeigt, dass die Decathlon
nicht gerade allzu aktuell ist, es ist inzwischen März geworden). Dort finden
sich erwartungsgemäss root.bin, drv1200.bin, drv1440.bin, base12-1.bin,
base14-1.bin und sofort bis base14-4.bin. Aber wo ist der erwartete resq.bin?
Und warum hat es ein resq1440.bin (und dieses ist 1440k gross)? Das README
stimmt offensichtlich nicht. Vielleicht ist auch resq diskgrössenabhängig, aber
es hat kein resq1200.bin. Vielleicht ist der Name einfach falsch, also resq1440
benutzen (einfach die ersten 1200k davon). Die anderen 6 Floppies sind
problemlos.

Bootversuch von der abgeschnittenen resq1440. Crash! Das mit dem Abschneiden
war offensichtlich keine gute Idee. Diese CD kann nur von einem 1440k Laufwerk
aus installiert werden. Mein PC hat aber nicht nur ein 1200k Laufwerk (wie Roli
am 1. Mai erstaunt feststellte), sondern auch noch dieses als erstes Laufwerk.
Und ich hab echt keine Lust 1 Stunde zu schrauben damit das 1440 das erste ist
(mein PC Gehäuse ist zwar sehr schön und kompakt aber äusserst eng, also müsste
ich es komplett zerlegen). Und ich hab sowieso keine freien 1440 Floppies (es
ist jetzt Sonntag um 18.00, alle Läden sind also zu).

Was ist eigentlich auf so einer resq Disk? Also beim Vater eine 1440k Floppy
(er hatte genau eine ungebrauchte, aber keine 7) geholt, resq1440 drauf, unter
1.2.9 (inzwischen wieder gebootet) einfach mal mount /dev/fd1 /floppy, dann
ordentlich staunen. Das ist ja eine MS-DOS formatierte Floppy! Gulp! Genauer:
es ist ein MS-DOS Filesystem mit einem speziellen Bootsektor (namens LDLINUX),
der zuerst (!) eine RAM-DISK Image lädt und dann den Linux Kernal (beide sind
als DOS Dateien auf der Floppy). Und leider sind diese beiden Dateien zusammen
grösser als 1200k, daher also keine resq1200.bin. Aergerlich.

Jetzt sitz ich fest, also Grübeln. Aber halt mal, ich hab doch ein relativ
neues Motherboard, vielleich kann das BIOS von mehr als nur A: und C: booten.
Nun, das kann es nicht, aber es hat eine Swap A:/B: Option, also diese
einschalten. resq1440.bin auf der 1440k Floppy einlegen, booten, es geht.

Installieren Basis System

Die resq Flopy bootet direkt in ein Installmenu. Dieses offeriert schrittweise
jeweils alle zum entsprechenden Zeitpunkt sinnvollen Optionen, wobei der
wahrscheinlichste zuobert ist, schön. Erstens Tastaturauswahl, es ist keine
"SG" Tastatur in der Liste, also nehm ich "US" (die kenn ich blindlings).
Fdisk lass ich weg (die HD hat 4 Partitionen, davon eine 470MB die leer ist).
Formatieren ohne Probleme. Dann Module für meine Hardware laden, was bestens
geht bis es zur Ethernet Karte kommt (die ist wichtig, da die Install CD ja im
Server steckt). Ich wähle DEPCA, das Modul wird geladen und verabschiedet sich
sofort mit "keine Karte an Adresse 200". Logisch, meine DEPCA ist ja
schliesslich auf 300 geschaltet. Unter 1.2.9 erkennt das die Autodetection des
Kernals. Kann 2.0.27 (das ist in der Debian 1.2 drin) das nicht mehr?

Wieder Zeit zum Grübeln. Im Installmenu hat es einen Punkt "Shell", also
starten und herumstochern. Es hat kein /root Directory auf der RAM Disk, wohl
aber ein Skript, das dieses hätte erzeugen müssen (oder noch erzeugen wird?).
Das Installmenu wird direkt aus dem /sbin/init gestartet, daher war also kein
Login nötig. Es findet sich eine Moduldokumentation in der steht, dass Module
keine Autodetection machen können, weil dies den laufenden Kernal abstürzen
könnte (ich hab bisher unter 1.2.9 noch nie Module benutzt, daher war das mir
unbekannt). Also das ist ein Mist, ich hab echt keine Lust meine DEPCA
unzuschalten (1/2 Stunde schrauben). Aber Module kennen Parameter (das
Installprogram fragt jedenfalls nach solchen). Nur: wo sind die dokumentiert?
In der Docu zum DEPCA Treiber steht schlicht "Treiber für DEPCA", wie
hilfreich!

Alte Hackerregel in solchen Fällen: RTFS (Read The F***ing Source). 1.2.9
booten und in INDEX.gz nach depca suchen. Aha, im CD7/cesdis.gsfc.nasa.gov/
drivers/depca-0.37.tar.gz hat es was, sogar erst noch die bereits eingelegte
CD7, wie freundlich. Die Zeile um die Default-Adresse zu setzen für Modul
Betrieb ist logischerweise ganz am Ende der Datei, der Programmier hat noch
nie etwas von #define von wichtigen Parametern gehöhrt. Doch wie kann ich
(falls ich schnell die Source ändere) diese als Modul für 2.0.27 compilieren,
wenn ich unter 1.2.9 (falsche include Dateien) bin? Und wenn ich unter 2.0.27
boote (von der resq1440) dann hab ich keinen Compiler (ausser dem auf dem
Server, der ja mangels Ethernet Treiber nicht ansprechbar ist). Und eigentlich
will ich doch nur zwei Bytes mit Zahlen drin ändern.

Weitere Hackerregel in solchen Fällen: PTB (Patch The Binary). Auf der VAX
hatte ich mal eine Library mit einem fehlerhafter String, den ich nach jedem
Linken (kein Schreibrecht auf des .LIB) reparieren musste, dazu habe ich das
.EXE File auf meinen DOS 386er kopiert und mit den Norton Utilities gepatcht.
Unter Linux kann man zum Glück dafür direkt den Emacs (in Overwrite Mode)
benützen. Aber wie findet man die beiden zu ändernden Bytes im Binary? Indem
man im Source die vorbesetzten Werte Variablen in deren Umgebung anschaut und
dann diese Bytefolge im Binary sucht (nein, das ist nichts für Anfänger). Also
in der Source nach Bytefolgen gesucht, dann mit dem Emacs in der Binary
gesucht, aber nicht gefunden! Langsam kommt der Verdacht, das dieser Source
nicht zum Binary passt. Um Klarheit zu bekommen hab ich die Strings und deren
Reihenfolge verglichen. Sie sind ähnlich aber genügend Differenzen, dass es
offensichtlich eine andere (ältere? neuere?) Version der Source ist. Nochmals
zur CD zurück, und in die Debian geschaut (da hat grep keine Datei mit depca
im Namen gefunden) und dabei /cdrom/debian/rex/source/devel/
kernal-source-2.0.27_1.00.orig.tar.gz gefunden, daraus drivers/net/depca.c
ausgepackt. Ah, da sind ja die richtigen Strings, in der richtigen Reihenfolge
und am Schluss die Parameter, die gesetzt werden - inclusive einer
Documentation der insmod Parameter! Patchern ist also überflüssig. Wenn diese
Documentation bloss im Installprogram drin wäre!

Die 6 1200 Floppies installieren geht dann ohne Problem. Danach beendet sich
das Install Program von selbst durch reboot. Ich lande wegen des Partition
Activate Flags natürlich in meinem 1.2.9 System, also im LILO die neue
Partition eintragen, reboot, und lande im Debian. Wieder kein Login, aber
sofort die Aufforderung, ein Root-Passwort einzugeben und einen User Account
anzulegen. Als endlich der Prompt erscheint habe ich zuerst ein df gemacht, um
zu sehen was gemacht worden ist. 15MB sind bereits weg! Daher also die 7
Floppies. Was ich vermisse ist, dass trotz 15MB ich noch immer nicht meine
endgültige Tastatur einstellen kann.

Installieren von Paketen

Jetzt habe ich ein laufendes Basissystem, also Pakete installieren. Dazu wird
(gemäss Doku) das Tool dselect benutzt. Bei der Frage nach dem Direktory mit
den Paketen geb ich /cdrom/debian/rex/binary-i386 an, worauf nur "official"
Pakete aber keine contrib oder non-free Pakete erkannt werden (Debian
unterteilt in offizielle Pakete (von ihnen), contributed (von Drittpersonen)
und non-free (mit Restriktionen, z.B. Shareware)). SUSE hat auf der Decathlon
also nur einen Teil der Debian Pakete kopiert (wenigstens den grösseren und
wichtigsten).

Um die Pakete auszuwählen hat dselect ein graphisches Menu. Ziemlich aufwendig,
sehr leistungsfähig (und daher auch nicht ganz einfach zu beherrschen). Man
muss dazu etwa 10 Tasten merken um es zu benutzen oder dauernd in der sehr
guten eingebauten Hilfe nachsehen (P.S: ich hab immer noch keine richtig
eingestellte Tastatur und die meisten Tasten sind Sonderzeichen!). Die
einzelnen Pakete werden in einem scrollenden Feld (halbe Bildschirmhöhe)
angezeigt, die zweite Hälfte hat den Erklärungstext zum momentan aktiven Paket.
Schön gemacht, aber bei 713 Paketen (laut grep "^Packa" /cdrom/debian/rex/
vailable | wc) verliert man schnell die Uebersicht. Zum Glück kann man ja
später Pakete addieren und löschen (mit den sehr schnellen und flexiblen dpkg
Utility, dselect ruft ja letztlich auch nur dieses auf). Mein grösstes Problem
mit dselect war das Fehlen von Grössenangaben der Pakete und einer
"installierten Menge" Angabe. Man muss einfach hoffen, dass die HD reicht (sie
hat). Dies überrascht, da im /cdrom/debian/rex/available die Paketgrössen
aufgeführt sind!

Nach dem Auswählen kommt das eigentliche Installieren, ein Bandwurm von
Operation, ohne das man mehr als bloss zusehen muss. Der erste Versuch lief und
lief und lief... Paketnahmen die schon einmal da waren kamen wieder und wieder,
das nennt man eine Endlosschleife. Da ich beim Eingeben der Paketverzeichnisse
einen Mist gemacht hatte kam ich zum Schluss, dass er jetzt alles 4 mal machen
wird, und habe nach einer Stunde abgebrochen (inzwischen ist es 3 Uhr morgens).

Am nächsten Tag habe ich daher frisch angefangen mit Floppy boot, formatieren,
Basis System install, dselect, Verzeichniswahl, Paketwahl (inzwischen mit etwas
mehr Ortskenntnis). Wieder Install start und wieder Endlos. Ich wollte gerade
stoppen als unsere Katze vom Monitor herunterfiel (sie liebt es an warmen
Orten zu liegen und der Monitor heizt, aber die Oberfläche ist schräg und sie
hat sich im Halbschlaf umgedreht und ist ausgerutscht). Ich hatte schwarze
Schrift auf schwarzen Grund. Also das Videokabel wieder einstecken, dabei hab
ich den lose sitzenden Powerstecker des Servers rausgezogen. 0 Volt shutdown,
Mist. Zum Server CD remounten muss ich mich einloggen, das Debian hat noch kein
laufendes IP, also unter 1.2.9 booten, danach wieder Debian. Ich hoffe einfach
mal, dass die Installation schon alles auf die HD kopiert hat.

Nach dem Installieren kommt im dselect Menu das Configurieren der Pakete, dazu
wird für jedes neu installierte Paket das zugehörige "packagename.postinst"
Script ausgeführt. Ein riesiger Bandwurm von Output zieht über den Bildschirm,
lesen kann man das alles nicht, geschweige denn sich merken. Leider wird das zeugs (anders als bei der Slackware) nicht automatisch in einer Datei
protokolliert. Dass einem jede Menge der Scripts unablässig nach Parametern
fragen, von denen man noch gar nicht weiss, was man einstellen will ist
unangenehm. Zum Glück kann man ja später alles in den jeweiligen Config Files
anpassen. Linux sei dank, sind das ja alles Text Files. Und, Debian sei dank,
liegen sie alle (ausnahmelos!) in /etc und seine Unterverzeichnissen (kein
einziges Config File ist in /usr oder /var!). Selbst XF86Config ist in
/etc/X11/XF86Config (in /usr/lib/X11 = /var/X11R6/lib/X11 ist nur ein Symlink).
Ja selbst die Wahl von Programalternativen ist im /etc, wer z.B. als vi den
nvi oder den elvis will stellt dies im /etc/alternatives ein: /bin/vi ist ein
Symlink auf /etc/alternatives/vi, dieses ist dann ein Symlink auf entweder
/usr/bin/nvi oder /usr/bin/elvis, ebenso awk=mawk/gawk, pgp=pgp-us/pgp-i und
logisch auch die dazugehörigen man-Pages. Sehr schön gemacht.

Addition 1999.07.05:
Die Tastatur kann nach installation des kbd Paketes gesetzt werden, indem man
das richtige File aus /usr/lib/kbd/keytables/*.map nach /etc/kbd/default.map
kopiert oder symlinkt. Das ist bei mir sg-latin1.map (ohne latin1 hat es keine
ä, ö, ü, das mit 450 am Schluss ist für DEC Tastatur layout).


Systembetrieb

Nach dem dselect will ich das System erforschen. Aber df verabschiedet sich
gleich mit "library not found". Es stellt sich heraus, dass Debian nach dem
dselect/install/config kein ldconfig macht (wegen das abgebrochenen install?),
also das schnell nachholen. Der df geht jetzt, es sind nun von den 470MB noch
ganze 60MB available. Später nach einer dpgk Löschaktion hab ich dann 117MB
frei, trotzdem das Daten hinzugekommen sind.

Nun zum Filesystem erforschen. Also mc eingetippt, "libgpm not found",
nochmaliges ldconfig, immer noch "libgpm not found", nach libgpm gesucht, sie
ist schlicht nicht vorhanden. Am nächsten LUGS Abend bekam ich von David einen
Tip, es fehlt eine Dependancy (Abhängigkeits-Angabe) im mc Paket. Nachdem ich
libgpm mit dpkg installiert habe läuft der mc anstandslos.

Ohne mc (der lief erst 10 Tage später) brauche ich einen anderen Anlauf, also
ls und cd benutzen. Das ist aber auf einer 80x25 Console ein Mist, aber in
einem 80x62 xterm ist das schon deutlich besser, also X starten. Tippe startx,
"command not found". Hmmm, startx ist ja normalerweise ein Script das xinit
aufruft, vielleicht ist es im Debian nicht vorhanden. Also xinit, "command not
found", das wird langsam ärgerlich. Nach einer kurzen Suche steht fest, es ist
kein X Windows auf der HD! Ich hab aber im dselect sowohl einen Xserver
(Mach32), die xlib und das xbase Paket angewählt. Und der Xserver ist da,
ebenso die Xlib, nur xbase ist nicht da. Es stellt sich am Schluss heraus,
dass das xbase Paket schlicht auf der CD7 nicht drauf ist! Damit ist auch der
Endlos-Lauf des dselect zu verstehen, es versuchte einfach die Installation zu
vervollständigen.

Wo krieg ich nun ein X Windows her (ohne ist Linux schlicht eine Zumutung).
Beim durchsuchen der Decathlon CDs (nun auch der anderen 9, die in der
Schublade verschwanden) finde ich auf CD1 (wo denn sonst:-)) ein README in dem
unter anderem eine Liste von "fehlenden Dateien weil sie kaputt waren" ist,
darunter ist auf CD7 genau eine: xbase. Also diese Datei von www.debian.org
herunterlanden. Murphy hat bei der Wahl von xbase nicht schlecht zugeschlagen,
es ist gemäss /cdrom/debian/rex/available das grösste der 713 Pakete, 2MB. Da
ich gerade am nächsten Tag bei Dolphins zu Besuch bin wollte ich es dort
schnell downloaden, leider hab ich vergessen, Floppies mitzunehmen und bei
Dolphins sind funktionierende Floppies (wir haben 4 kaputte gefunden) eine
Mangelware (sie haben ja jede Menge HDs, Ethernet und eine Standleitung...).
Also zuhause downloaden, mit meinem 14400 Modem und einem Provider, der ganze
0.9kB/s hinkriegt und während der FTP Uebertragung mich 4 mal rauswirft (ich
war noch bei Eunet) geht das 3/4h, gut für die Telefonrechnung (Fernzone 1).

Xbase mit dpkg installiert, xbase.postinst erzeugt ein XF86Config, aber es ist
kein 1152x864 Modus drin, also merge ich mein altes XF86Config mit dem neuen.
In /root hab ich vorsorglich meine .xxx Files bereit. Dann xinit eingegeben,
Abbruch mit "/dev/mouse fehlt", also dies auf /dev/ttyS0 gesetzt. Neustart,
Abbruch mit "fvwm: lib not found", Es stellt sich heraus, dass lib/X11 nicht
in /etc/ld.so.conf eingetragen ist, also nachtragen.

Der xinit mag ja für die einem schön sein, aber ich ziehe xdm vor (richtiges
Workstation Feeling wie beim NeXT). Also /etc/init.d/xdm starten, nichts
passiert, total gar nichts, kein Xserver, keine Login Box, nichts. Ein ps
zeigt, dass tatsächlich ein xdm Prozess am laufen ist, aber der sitzt einfach
dort und wartet auf Godot. Als schuldig stellt sich /etc/X11/xdm/Xservers
heraus, es fehlt dort schlicht die Zeile, die einen X Server auf der Console
verlangt. Vermutlich ist auch dies eine Folge des fehlenden xbase Pakete zum
Zeitpunkt, an dem der Xserver configuriert wurde. Endlich hab ich ein
laufendes X und kann nun das System erforschen.

Beim Booten am nächsten Tag gibts wieder Aerger, /etc/init.d/boot beschwert
sich darüber, dass das Filesystem eigentlich ein fsck nötig habe aber es nicht
gemacht werde. Wie bitte? Eine Suche ergibt, dass dies die Folge eines if [ -f
/fastboot ] ist, nur es hat keine Datei /fastboot! Neu booten, wieder selbiges
Resultat, aber immer noch keine Datei. Dann find ich ein rm /fastboot weiter
unten, also wird es dort gelöscht. Nur wo wird diese Datei dann wieder
erstellt? Ich habs nicht getan, also muss es beim shutdown automatisch
entstehen. Richtig, man shutdown erklärt, dass diese Datei entsteht wenn man
mit shutdown -f herunterfährt. Und siehe da, mein ~/.fvwm hat auf Ctrl-Alt-Del
ein shutdown -rf now. Das hab ich vor Jahren aus der 1.0.8 Slackware
/etc/inittab übernommen, unter Slackware und SUSE wird /fastboot einfach
ignoriert und dann gelöscht, ich hatte nie etwas davon gemerkt. Jetzt unter
Debian gibts Aerger damit, also weg damit.

Einzelne Pakete

Unter den beim Debian (trotz der SUSE fehlenden) mitgelieferten Paketen sind
eine ganze Menge gute Sachen (ich habe momentan 194 der 713 installiert).
Darunter einige bisher von mir direkt vom Netz geholte Sachen wie Apache (Web
Server), netcat (universelles Netz Tool), lxtools (HP100 Backup (und bei mir
auch PC110 Backup)). 

Ausserdem kamen mit: der xterm (im xbase Paket), alle Shell Utilities die ich
benütze, Emacs (in emacs), xclock (in xbase) und xsysinfo. Anstelle von xload
(ist auch da) hab ich das bessere procmeter genommen. Ein kleines und feines
Paketchen ist mbr, ein 444 Bytes grosser Bootmanager, der den DOS MBR ersetzt
(erst damit hat man seinen Linux-PC endgültig von kommerzieller Software
befreit, P.S: wer von euch benutzt noch den DOS MBR zum booten? Das ist
eigentlich ein DOS Copyright Verstoss, und dabei erst noch völlig überflüssig).

Fvwm2 ist unter Debian ganz interessant configuriert worden. In /etc/X11/fvwm2/
hat es einige systemweite Dateien. Diese erwarten unter .fvwm2/* einen Satz von
userspezifischen Erweiterungen, die Hooks genannt werden. Wenn Debian einen
neueren fvwm2 liefert kommen bessere systemweite Dateien mit, die ziehen
einfach die bestehenden userspezifischen rein. Resultat ist ein sofortiger
Update ohne von Hand die Dateien zu mergen.

Dosemu ist im Debian dabei, und voll konfiguriert, aber mit einem kleinen aber
bösen Fehler: der VGA Font (der mit den IBM Sonderzeichen drin) wird zwar als
/usr/lib/X11/fonts/misc/vga.pcf installiert, aber nicht im fonts.dir
eingetragen. Folglich findet Dosemu ihn nicht und verwendet statt dessen den
misc/9x15 Font, was ässert hässlich aussieht wenn man einen Norton Commander
startet. Zum Glück wusste ich grob wie X Fonts organisiert werden, denn dazu
gibt es keine Anleitung (man muss im /usr/lib/X11/fonts/misc/fonts.dir die
Zeile "vga.pcf vga" addieren, sowie die Zahl in der ersten Zeile um eins
erhöhen). Als HD Image Datei habe ich einfach eine Kopie meiner alten DOS 3.3
Partition benutzt, das beiliegende FreeDos hab ich nicht ausprobiert.

Dip lief sofort, fiel aber ebenfalls sofort durch erheblich langsameren
Betrieb auf. Ich nehm an, dass das von den neu aufgerufenen nach-login und
bevor-logout Scripts herkommt. Aber dabei blieb es nicht bei meinem Internet
Anschluss. Ich hatte ja bisher immer SLIP benutzt. Nun wechselte ich den
Provider und hatte ohne gross nachzudenken beim neuen PPP angekreuzt (Linux hat
ja ein ppp0 Interface (der NeXT hatte keines und mein alter Account stammte aus
NeXT-Zeiten). Also den dip.rc an ppp angepasst, aber es lief einfach nicht,
genauer: es wählte, loggte ein, aber die Verbindung wurde dann einfach nicht
benutzt. Zeit für das PPP-HOWTO. Aha, ich brauch dafür das pppd Paket (ich
hatte es nicht installiert wegen des irreführenden Kommentars im dselect, da
wurde etwas über Win95/NT Logins geschwafelt). Als ich dem pppd ein chat Script
gegeben hatte war der dip überflüssig, ich hab es folglich mit dpkg gelöscht.

Ssh und pgp fehlen auf der Decathlon CD (sie sind auch im www.debian.org nur
für die Amis herunterladbar). Dafür ist ein README.non-US im /cdrom/debian drin
mit der Adresse, wo diese Pakete zu finden sind (an der tu-dresden.de, pervers:
Krypto-SW kann man nicht aus den USA exportiern, also holt man sie aus der
ex-DDR:-)). SUSE hätte diese doch ohne weiteres selber holen und auf die CD
mitgeben können. Was solls, es sind beides kleine Pakete (444k und 265k), also
Modem wieder beschäftigen. Ssh generiert direkt beim installieren (mit dem
ssh.postinst) seine Schlüssel automatisch, pgp will das man das selber macht
(Phil Zimmermann ist misstrauisch).

Vermisst hab ich xeyes (hätte ich im xbase vermutet), xcalc (ebenso), beides
nicht so wichtig. Ganz im Gegensatz dazu ist der fehlende Web Browser (es ist
nur der VT-Terminal Browser Lynx dabei) äussert unangenehm. Netscape ist zwar
als Debian Paket erhältlich, aber das befindet sich in einem der auf der
Decathlon fehlenden non-free Paketen (ist ja Shareware), ich hab daher
kurzerhand ein herumliegendes Netscape-3.01.tar.gz ausgepackt und installiert.

User Account

Beim ersten Einloggen muste ich einen Useraccount generieren. Debian meint, das
man in dem arbeiten soll, nicht dauernd als root (wie ich es bisher immer
gemacht habe). Verschiedene LUGSer sind ebenfalls der Meinung. Also probier ich
das mal so. Hier nun die Horrorstory:-()

Als erstes habe ich alle meine Dateien mit chown -R neil:neil behandelt,
gleichzeitig hab ich auch noch chmod 640 gesetzt (die gehen andere User ja
nichts an) und die umask auf 027 gesetzt (damit es in Zukunft so bleibt). Das
User Directory von neil hab ich gleich dem von root gesetzt (ich will nicht
alle meine .xxx Dateien doppelt führen müssen), dann logout (als root) und
login als neil.

Nichts passiert (genauer, die Login-Box verschwindet aber kein fvwm2 kommt).
Mit Ctrl-Alt-Backspace den X Server killen und wieder als root einloggen geht
bestens. Das ist ein guter Hinweis auf mangelnde Privilegien für den User neil
(und vermutlich alle anderen User ausser root), aber wo in den über 300MB
Linux? Da der Loginvorgang offensichtlich hängt hab ich mich in einer
virtuellen Konsole als root eingeloggt und mal ps -auxOp gemacht. Der User neil
hat als letzten Prozess xrdb -merge gestartet, also su neil, xrdb getippt, es
hängt ohne Kommentar, ^C, xmodmap (der nächste Befehl den neil machen würde)
getippt, "DISPLAY not found", also DISPLAY=:0.0, xmodmap, "no access to
display". Hmmm, es ist also der X Server, der den Zugriff verweigert, aber
.Xauthority gehört dem User neil. Wieder Zeit zum Grübeln.

Aus Jux (oder die Hoffnung der Verzweifelten?) hab ich nach einer Stunde xterm
in die virtuelle Console getippt, und siehe da: ein xterm erscheint auf dem X,
also ist es nicht der X Server! Jetzt die extreme Aktion: /etc/X11/Xsession
eingetippt, tonnenweise Fehlermeldungen der Sorte "bash: no access to
/dev/null". Da liegt also der Hund begraben, dieses ist nämlich chown root:sys
und chmod 640, natürlich geht das nicht. Nach einem chmod 666 /dev/null kann
neil ohne Probleme einloggen. Ursache für diese Fehleinstellung war übrigens:
~/.netscape/cookies ist bei mir ein Link zu /dev/null, als ich chmod 640
~/.netscape/* eingeben hatte wurde halt eben der /dev/null "verbeult":-)

Als nächstes will ich mein 1.2.9 Filesystem mounten um einige Dateien zu holen,
es geht nicht, normale User dürfen nicht mounten. Das mag für dichte Security
nötig sein, bei mir aber nicht, also mount kurzerhand mount zu SUID erklärt
(P.S. in NeSTstep funktioniert das Mounten als normaler User, aber alle SUID
Bits auf der gemounteten Disk werden einfach ignoriert, das ist das erste Mal,
das Linux nicht an NeXTstep heran kommt!).

Ich will Mail holen. Der pppd beschwert sich über keinen Zugriff auf seine
Config Files (die sind chown root:root und chmod 640), der chat doppelt nach.
lso zuerst chown root:neil, dann wieder root:root aber dafür neil in die Gruppe
root aufgenommen. Der popclient geht bestens (die Ausnahme, wow). Beim Absenden
der Mails will sendmail -q nicht (das darf auch nur root). Bloss das Ding ist
schon SUID und der Test ist im sendmail Code, wie krieg ich den als neil zum
Laufen, gar nicht. Also richte ich im fvwm2 einen Menupunkt xterm-su ein, sogar
mit der Option -bg salmon, damit ich dieses scharfe xterm nicht verwechsle,
dafür kill ich die SUID/Gruppe von vorhin. Das gibt dafür ein hin-und-her
springen zwischen verschiedenen xterms. Unschön.

Beim berüchtigten 1.Mai Besuch bei Hitline hole ich ein Program namens wget
(einen Web Roboter) vom Netz, ist nur Source, also make (das geht noch unter
User neil), dann make install, wird verwiegert, also schon wieder ins xterm-su.

Ernste Frage: wenn ich dauernd im xterm-su bin, wozu hab ich dann noch einen
wenig-privilegierten Account, da kann ich doch gleich dauernd root sein. Das
spart das hin-und-her schalten, geschweige denn die Unfälle wenn man in
xterm-su vergisst das man root ist. Das mit dem separatem Account gibt ja nur
Aerger! Ein gekilltes Sytem einmal alle paar Jahre (ist mir in 6 Jahren Unix
noch nie passiert) ist da deutlich weniger schlimm. Also hab ich den neil
Account gekillt, alle Basteleien zurückgestellt. Fazit: nie wieder etwas
anderes als root sein!

Andere Maschinen

Neben meinem Desktop, der bisher alles vom Debian abbekommen hat habe ich noch
andere Maschinen. Auch die sollten nun upgradet werden.

Als erstes kam der PC110 an die Reihe, der hat bisher nur DOS 5.0 gekannt (das
hab ich direkt nach dem Erhalten im Februar als Notlösung aufgesetzt, weil das
schnell geht). Da xbase zu diesem Zeitpunkt noch nicht geholt war hab ich vom
1.2.9 System aus Debian als /mnt und eine 1440 Floppy als /floppy gemountet
und von Hand (gemäss der Anleitung in Bootdisk-HOWTO) ein root Filesystem
zusammengestellt. Linux auf 1440k (1390k frei nach dem ext2 formatieren) ist
ein Krampf, allein der /lib/libc.so.5 will schon 564k der Disk. Am Schluss hab
ich eine bootfähiges (aber danach nutzloses) Filesystem, selbst ein mount
beschwert sich über keinen Platz für den /etc/mtab~. Schnell vmlinuz auf eine
zweite Floppy, booten, Diskwechsel, Absturz. Nach einigen wenigen gelungenen
Bootversuchen und vielen Abstürzen (und mehreren gelungenen Booten auf Pauls
PC110 steht fest: mein PC110 hat einen teilweise kaputten Floppy Controller
(unter IBM-BIOS/DOS geht er einwandfrei)). Ich hab momentan keine Zeit, dem
Fehler nachzugehen. Der PC110 läuft heute immer noch unter DOS 5.0, aber bald
werd ich es wieder versuchen (noch vor den Sommerferien).

Als zweites ist mein uralt 386er an der Reihe. Da dieser wie mein Desktop mit
SCSI läuft bau ich dazu einfach seine HD in den Desktop ein. Fdisk, mke2fs,
tar c | tar x, ein paar /etc/* Datein (hostname, IP Addr, etc) angepasst,
Floppy boot, lilo. Mein Desktop bootet bestens ab der HD. Im 386er eingebaut
will es nicht mehr gehen, der Boot verendet mit "this Kernal needs 486 or
better CPU, stopped". Ich Volltrottel, hab ich doch beim Kernal kompilieren
486 gewählt (ist der selbige Kernal wie auf dem Desktop). Also einen neuen
Kernal mit 386 Support aber immer noch die selbige Meldung. Naja, da der 386er
eh nur fürs Backup gedacht war und jetzt ja einen vollen Backup hat, lass ich
ihn einfach mal bootunfähig liegen.

Als drittes war der CCW 486er Server dran. Da er keinen 386er hat war da nichts
zu befürchten. Dafür aber hat er IDE, also auch den (zum Glück separaten) IDE
Adapter mit ausbauen und in meinen Desktop stecken (eigentlich hat mein
Desktop einen IDE Adapter auf dem Motherboard aber der Stecker ist nicht
zugänglich im kompakten Gehäuse (liegt genau unter einem Träger), und ich hab
ihn eh abgestellt). Wenn man ein IDE Drive nicht ins BIOS einträgt bootet es
trotz IDE vom SCSI und Linux ist trotzdem dann intelligent genug die IDE zu
benützten. Aber Linux wurde hoch instabil, dauernde Prozessabbrüche mit
"segmentation fault", core dumps (Debian installiert ulimit -c unlimited, das
hab ich schnell korrigiert), am Schluss ging nicht einmal mehr der ls. Reboot,
diesmal brach Linux schon beim Booten zusammen. Dritter Versuch, Linux kann
nicht mal die root Disk mounten und init starten. Also IDE ausgebaut, Linux
bootet ohne auch nur ein Mucks. Nochmals IDE eingebaut, ich schaf gerade noch
das fdisk und den tar c | tar x, schon crasht es wieder. Dann die IDE Adapter
und HD in den Server, das geht wieder einwandfrei (der Server hat schon 1/2
Jahr Linux 1.2.9 ohne Probleme hinter sich, damals von Floppy/CD installiert,
daher hatte ich nie mit derartigen Problemen gerechnet).

Ein zweiter Installversuch auf dem 386er etwa 1 Monat später war ein voller
Erfolg, er bootet anstandslos, keine Ahnung was ich anders gemacht habe. Nur
etwas hab ich beim zweiten Mal neu gelernt: wenn man mit dem inzwischen
gesetzten umask 027 einen tar c | tar x macht sind alle Dateizugriffsrechte
auf der zweiten HD kaputt. man muss tar c | tar xp verwenden (bei umask 022
fiel das vorhin nicht auf).

Nach diesem Erfolg und der umask Erkenntnis und einigen Config File
Aenderungen will ich auch den CCW Server aktuell machen, sprich neu
installieren. Wieder die IDE Probleme, nur das diesmal der Desktop Crash
(während tar c | tar xp) beim nächsten Boot zu einem "do a manual fsck" führt.
Dieses gibt eine Liste von 14 Dateien (7 Paare) mit gemeinsamen Blöcken aus,
also hab ich die vom 386er wiederhergestellt (ich war natürlich so vorsichtig,
zuerst den zum Laufen zu bringen). Da mein Desktop offensichtlich IDE nicht
mag hab ich dann versucht herauszufinden, ob es am Apapter oder an der HD
liegt. Mit der HD am Motherboard IDE Adapter (grosse Bastelarbeit) bootete
Linux ohne Problem, tar c | tar xp ging, mein Motherboard mag offensichtlich
den Adapter vom Server nicht, trotz ausgeschaltetem Motherboard IDE (du sollst
keinen Adapter ausser mir haben...). Womit wieder mal bewiesen ist, das man
Linux nur mit spinnender Hardware zum daneben benehmen bringt.

Abschliessend

Wie ist Debian nun, nach alledem? Die Programme in den Paketen sind aktuell,
die Auswahl ist gross, dpkg is schnell und einfach, das System benimmt sich
voll wie Linux es sollte, alle Config Files in /etc ist eine tolle Sache, man
merkt dass die Debians sich angestrengt haben.

Aber es gibt ein paar Haare in der Suppe. Die SUSE Decathlon ist eindeutig
wurmstichig (resq1200, xbase und Folgefehler, ssh/pgp), und manches davon sind
ernsthafte guru-only Probleme. Aber auch ohne die SUSE Schwierigkeiten ist die
Debian nicht umbedingt einfach für Anfänger in den Griff zu kriegen (z.B. die
Modul Sache, der Dosemu Font).

Ich werde auf jeden Fall mein System auf Debian belassen, bis mit einem 2.2.x
Kernal (in einem Jahr etwa?) wieder eine Totalinstallation ansteht.

Und das nächste Mal, was werd ich da nehmen? Bisher hab ich Slackware, SUSE und
Debian probiert, folglich werden ich dann Rethat oder Do-It-Yourself probieren.
Aber das nur um neue Erfahrungen zu bekommen, nicht weil Debian schlecht ist,
das ist es nämlich nicht.