![[Photo of the Author]](../../common/images/Who.gif)
original in de: Serge Winitzki
de to en: Onbekend
en to nl Guus Snijders
Deze tekst verteld mijn verhaal over het installeren van een recente release van het GNU/Linux besturingssysteem op een laptop computer. Het is bedoeld als een bron van informatie voor mensen die Linux willen installeren op een zelfde laptop of zelfs een desktop computer, en is misschien ook interessant voor ontwikkelaars van Linux distributies. De expositie is vrij technisch, dus lezers zouden enigzins bekend moeten zijn met (of voldoende geïnteresseerd in het leren ervan) het Unix besturingssysteem.
![[Ilustratie]](../../common/images/illustration16.gif)
Dit is de tweede keer dat ik een GNU/Linux besturingssysteem op een laptop installeer. De eerste ervaring was met een Lapnote P510 en is hier gedocumenteerd. Ik heb gebruik gemaakt van informatie op de Slackware CDROM, zoals de verschillende HOWTOs, de Linux Installation Guide version 3.2, en natuurlijk de Linux on Laptops web pagina. Alle informatie hieronder behelst specifiek de installatie van Slackware 3.5 op een Fujitsu 635T. Internet links naar specifieke programma's zijn niet geleverd, ik ga er vanuit dat de lezer in staat is om deze te vinden via de gerefereerde web sites.
Ik schafte me een tweedehands laptop aan, een Fujitsu 635T, via postorder. Zoals ik reeds verwacht had, kwam de machine met het zogenaamde besturingsssteem "Windows", versie "95 OSR 2" voorgeïnstalleerd. De installatie van "Windows" was waarschijnlijk een schone herinstallatie, gedaan door de vorige eigenaar alvorens het systeem te versturen. De geluidskaart was niet herkend en het volledige PCMCIA systeem leek ook afwezig. Ik weet niet zeker of de true-color mode ondersteund werd. Ook heb ik de 'suspend to disk' optie niet geprobeerd omddat er geen suspend-to-disk partitie op de harde schijf aanwezig was, en ik vermoedde dat het niet zou werken, en mogelijk de aanwezige partitie zou beschadigen door de afwezigheid van een suspend-to-disk partitie. (Mijn angst was ongegrond: de BIOS herkende dat er geen suspend-to-disk partitie aanwezig was, en gaf een waarschuwing als ik probeerde die optie in te schakelen.
Ik wist dat het niet verstandig was om toe te geven aan de verleiding om "windows" gelijk te verwijderen; Ik moest er nog een paar dingen uit halen. Eerst installeerde ik de "standaard/alleen tekst" printer driver en gebruikte het configuratiescherm om de systeem instellingen af te drukken op papier, voor eventuele toekomstige referentie. Dit bestand was waarschijnlijk het enige nuttige dat uit dit zogenaamde besturingssysteem te halen was, daar de computer zonder handleidingen kwam (geen dank aan de computer dealer, je weet zelf hoe ze zijn). In principe zou al deze informatie in de hardware manuals te vinden moeten zijn; maar de marketing techniek van tegenwoordig is om een installatie van "windows" aan te nemen, welke je de informatie over de hardware kan leveren. Vaak krijg je een vermoedelijk correct geïnstalleerde kopie van "windows", waar je kan proberen de informatie uit te halen.
De volgende stap, na het schrijven van de hardware opsomming naar floppy, was rebooten en naar de BIOS setup mode te gaan. De BIOS heeft een prettige interface en staat je toe om te spelen met
|
|
De volgende stap was om uit te vinden hoe de Linux bootdisks te maken. Ik had de Slackware Linux 3.5 distributie reeds gedownload en bladerde door bestanden genaamd README, INSTALL en zo verder. Aansluitend bij de gesuggereerde procedure, gebruikte ik een DOS programma "rawrite.exe", welke door Slackware werd geleverd om bootable floppy images naar de floppy disks te schrijven. Het commando was iets als rawrite.exe bare.i a:, uitgevoerd in de bootdisks.144 directory van de Slackware CDROM, om een bootable floppy te creëren met de simpelste ("bare" (kaal)) kernel en rawrite.exe color.gz a: in de rootdisk directory om een "rootdisk" floppy te maken, welke ook nodig is voor de installatie van Slackware. Later ontdekte ik dat ik de "bareapm.i" startup disk had moeten gebruiken, daar mijn laptop over "advanced power management" (APM) functies beschikte en op deze manier had ik ze al kunnen activeren tijdens de intiële installatie, oftewel, ik zou de laptop kunnen "suspenden" tijdens de installatie en later kunnen verder gaan. Maar in de eerste instantie wilde ik niet anders dan meest basic kernel. Als een resultaat van het gebruik van een kernel zonder APM, traden er een paar vreemde crashes op als ik laptop voor een uur met rust liet en deze in auto-suspend ging. De typische reactie was dat willekeurige programma's weigerderden te draaien en een "zero divide" (deling door nul) CPU niveau fout melding gaven met een register dump. Dit soort foutjes verdwenen toen ik een kernel met ondersteuning voor APM startte.
Na de twee floppies gemaakt te hebben, rebootte ik de computer en kreeg een Linux systeem, in welke ik kon inloggen als "root" zonder password. De login prompt vertelde me dat ik nu een aantal partities op de harde schijf moest maken voor Linux en daarna het "setup" programma starten. Hetzelfde bericht vertelde dat ik of fdisk of cfdisk kon gebruiken voor het partitioneren. Omdat ik wist dat fdisk niet erg prettig in gebruik was, besloot ik om cfdisk eens te proberen en was prettig verbaasd over de eenvoudige en intuïtieve text-mode interface. Ik verwijderde de 1.35 GB FAT partitie (ajuus "windows"!) en creëerde een 64MB swap partitie en twee (300 MB en 1 GB) standaard, type "ext2", Linux partities. Ik ging er van uit dat ik de kleinere partitie zou gebruiken voor systeembestanden en de andere paritie voor gebruikers bestanden en applicaties, zodat ik, als ik later zou besluiten Linux opnieuw te installeren, niet alles zou hoeven te verwijderen.
Toen ik klaar was met cfdisk, startte ik het setup programma. De eerste stappen met de setup waren simpel genoeg: het toetsenbord 'remappen' (indelen), (ik wilde het niet) de swap space aangeven en de installatie-doeldirectories en brondirectories kiezen. Ik koos de kleinere partitie als root partitie (/) en de grotere partitie werd gemount als /usr. Het eerste probleem was met de brondirectory: ik had niet de originele Slackware CDROM, maar had alle bestanden gedownload en deze op de CDROM geplaatst met behulp van "windows". Ik heb het verschillende malen geprobeerd, maar de setup herkende de directories niet. Ik gaf het aan als directories
|
|
De volgende stap was het selecteren van de software pakketten die ik wilde installeren. Ik selecteerde alle pakketten, behalve de spellen, de X server onwikkel kit en de documentatie die zich toch op de CDROM bevond. Toen bood de setup aan om de harde schijf bootable (opstartbaar) te maken met de de lilo bootmanager. Ik koos de "automatic lilo installation" met de bareapm.i kernel. Ik sloeg de netwerk setup over, selecteerde geen eigen fonts, gaf aan dat mijn modem zich op COM2 bevond, dat mijn muis PS/2 was, en dat mijn tijdzone zich in Amsterdam bevond (Waarom gebruikte geen PageDown om naar beneden te scrollen door de enorme lijst met tijdzones?). Tenslotte rebootte ik en kreeg het systeem draaiend, logde in als root, weer zonder wachtwoord, en was klaar om te beginnen met het computer vermogen van zo'n 53 "BogoMips". Dit was ruwweg correct voor een 133 Mhz Pentium (zoals gemeld in de "BogoMips mini-HowTo").
De enige smet zover was dat de ZIP drive op de paralelle poort niet werd herkend. De driver (ppa, paralelle poort adapter) zei in principe dat er zich geen
|
|
Ik heb ook geprobeerd om het lilo configuratie bestand met de hand te bewerken, maar vond dat het gebruik van het liloconfig programma in plaats meer idioot-bestendig was, vooral daar ik meestal vergeet om lilo uit te voeren na het aanpassen van het configuratie bestand.
Laatste opmerkingen: soms verschijnen er foutmeldingen na het uitvoeren van setup functies, maar de foutmeldingen verdwijnen onmiddelijk als het volgende scherm verschijnt. Ik wou dat de foutmeldingen beschikbaar bleven zodat ik kan zien of de setup procedures succes hadden. Dit zou misschien meer werk aan de shell scripts betekenen, maar niet veel meer: op z'n minst zou de output van de commando's omgeleid kunnen worden en weergeven worden wanneer gewenst. Hallo, mr Volkerding, misschien hoort u mij.
Ik ging er van uit dat het eerste grote probleem tijdens het opzetten van het X window system zou optreden, om deze te laten werken met mijn grafische adapter en mijn 800x600 LCD scherm. Maar het eigenlijke proces bleek ver van pijnlijk, en alleen de truecolor mode benodigde enige tweaking.
Slackware Linux komt met XFree86, een vrije X server van hoge kwaliteit, die volledige ondersteuning voor mijn videokaart beloofde. Ik twijfelde over het proberen van Accelerated X maar besloot dit niet te doen, daar XFree86 meer configureerbaar is en ik had er betere ervaringen mee op mijn vorige, minder goed ondersteunde laptop. Er waren twee mogelijkheden voor het instellen van X: het X gebaseerde configuratie programma en de tekst-gebaseerde. De enige muis die ik had was de redelijk versleten en niet helemaal betrouwbare touchpad dus koos ik voor de tekst-gebaseerde configuratie (de interface was een beetje simpel maar recht-toe-rechtaan). Later kwam ik er achter dat de grafische configuratie niet zou hebben gewerkt, omdat het incompatible was met gpm, de tekst-mode muis driver die ik had gekozen om te installeren. Deze stoppen met gpm -k zou hebben geholpen maar de grafische configuratie is niet echt behulpzaam en vereist een muis.
De grafische adapter, een C&T 65550 met 2MB geheugen, was aanwezig in de lijst en ik selecteerde de 800x600 modes in alle kleurdiepten. Het enige probleempje dook op toen, halverwege de setup, werd aangeboden om X -probeonly uit te voeren om de beschikbare video modi te detecteren. Deze faalde omdat de installatie op dat punt nog niet voldoende informatie in de initialisatie bestanden had geschreven. Dus sloeg ik die stap over en ging verder met de overige vragen. Ook negeerde ik de vragen over monitor karakteristieken (zoals de horizontale en de verticale verversings freqeunties); uit eerdere ervaringen wist ik dat deze informatie noch nodig,
|
|
Na het afronden van de config, bekeek het video hardware configuratie bestand /etc/X11/XF86Config. Dit bestand (XF86Config) is meestal gevuld met bagger, automatisch daar geplaatst door het configuratie programma. Het belangrijkste deel ervan, wat de hardware betreft, is de zogenoemde "Modelines" sectie. Iedere "Modeline" beschrijft een scherm resolutie, verversing frequentie etc. Iedere mode heeft een naam, en het configuratie bestand refereert later aan de modes bij naam, als de server wordt verteld welke modes te gebruiken in welke kleurdiepte (in de Screen sectie van het bestand). Als verschillende modes dezelfde naam wordt toegekend, zal de server er maar een gebruiken, en wel degene met de "beste" verversings frequentie en daardoor beeld kwaliteit. Uit mijn eerder ervaring met het configureren van de XFree86 server, wist ik dat de meeste problemen in de automatische configuratie zaten: te weten, er worden teveel modelines met identieke namen toegevoegd, zoals 640x480 of 800x600, en het aan de server overlaten om de "beste" modus voor de opgegeven monitor te kiezen. Maar slechts een paar van de modi met de naam 800x600 zijn in werkelijkheid werkbaar. Wat er in de praktijk gebeurd is dit: de server selecteerd de beste modus, maar als deze om de een of andere reden niet werkt, zit de gebruiker vast. Een betere methode is om deze modi verschillende namen te geven, zoals 800x600a, 800x600b en zo verder, en de server ze allemaal te laten gebruiken. De gebruiker kan dan op Ctrl Alt + en Ctrl Alt - om de schakelen tussen de beschikbare modi en degene die er het beste uitziet, te kiezen.
Dus verwijderde ik alle modi, behalve de 800x600's, hernoemde ze, en nam ze allemaal op in de Screen sectie en typte startx om het X window system te starten. Mijn beste modeline was:
# 800x600 @ 60 Hz, 37.8 kHz hsync Modeline "800x600a" 40 800 840 968 1056 600 601 605 628 +hsync +vsync
Een andere was gelijk bij 56 Hz met bijna dezelfde beeld kwaliteit. In de hoogste resolutie kreeg ik gelijk een goed beeld. Er was echter geen window manager zichtbaar. Ook werkte de truecolor mode niet. (De truecolor mode kon ik starten met startx -- -bpp 24 daar met mijn chip de juiste truecolor mode niet 32 bit was, maar 24 bit per pixel; X configurator pakte dit goed op en paste de 32 bit instelling in de screen sectie aan en gebruikte ook de default kleurdiepte van 8bpp.) Ik startte X met een omgeleide uitvoer (startx >& /tmp/startx-output) en bestudeerde het resulterende bestand. Deze techniek is erg handig voor de diagnose van problemen met X, daar de berichten anders te snel langsvliegen.
|
|
Het probleem met de window manager die niet verscheen lag aan het feit dat de DISPLAY variabele, om de een of andere reden, niet gezet was. Deze omgevings variabele is nodig voor alle programma's, om te weten waar ze hun programma's moeten weergeven. Ik fixte dit door het startx script aan te passen (zie onder).
Het probleem met truecolor was dat X klaagde over de "pixel clock being too high" in the truecolor modes. Blijkbaar is het echte hardware limitatie op de pixel klok. Een tijdje dacht ik dat de truecolor mode onmogelijk te krijgen was, maar toen keek naar de modelines van andere mensen voor de C&T adapters (uit een schat aan informatie, gevonden op de Linux on Laptops web page) en ontdekte de volgende modeline met een lagere klok frequenty.
#800x600 @ 49.5 Hz vsync, 30 kHz hsync, lelijk en flikkerend, zelfs #op een LCD ModeLine "800x600b" 28.3 800 816 856 920 600 603 605 618
Deze mode heeft een erg lage verversings frequenty en lage beeld kwaliteit; toen ik deze inschakelde, hoorde ik de monitor zoemen terwijl mijn ogen waterig werden. LCD schermen geven een betere beeld kwaliteit dan CRT's en het beeld is acceptabel vanaf zo'n 56 Hz verticale verversings frequenty (welke een verschikkelijke pijn aan de ogen oplevert op een standaard 14 inch buis), maar dit was zeker niet genoeg. Ik wist niet wat ik deed, maar ik verhoogde de klok frequenty naar 35.1 in plaats van 28.3, zonder de andere getallen aan te passen. De mode werkte toen een stuk beter. Ik probeerde vervolgens de klok frequentie te vervangen met de lagere grens 35.4 in de oude modeline en het werkte ook! Ik gebruik het nu (in truecolor mode) om dit te schrijven. Ook voegde ik de regel DefaultColorDepth 24 toe aan de Screen sectie van het XF86Config bestand, om de truecolor mode de standaard te maken. Ik herinnerde me dat er een manier was om een bepaalde kleurdiepte per default te gebruiken, maar moest de X manuals doorspitten om het exacte woord "DefaultColorDepth", omdat het X configuratie script geen voorbeeld kleurdiepte had geplaatst.
Om de expermentele 28.3 mode acceptabel te maken voor de X server, moest ik de toegestane monitor frequenties aanpassen. De configurator plaatst deze in twee bereiken:
HorizSync 31.5 - 37.9
VertRefresh 50 - 90
maar de nieuwe 28.3 mode weigerde te starten omdat de
frequenties te laag waren: Ik bestudeerde het
/tmp/startx-output bestand en ontdekte dat X klaagde
over niet-toegestane frequentie bereiken. Dus verlaagde ik de
HorizSync naar 30 in plaats van 31.5 en
VertRefresh naar 48 in plaats van 50. Deze twee
instellingen echter, en vooral de lage grenzen, bleken niet
essentiëel, daar de eigenlijke klok frequenties volledig
via de modeline worden bepaald. In principe staan deze
instellingen hier alleen maar om doorbranden van de monitor door
te hoge frequenties te voorkomen: de X server rekent de
frequenties uit, zoals die voortkomen uit de modelines, en zal
de diegene met frequenties die buiten het bereik vallen, negeren.
Ik kwam er achter dat ik in de praktijk nooit de exacte data van
de monitor mogelijkheden kon achterhalen, en dat ik meestal de
de bereiken licht moest aanpassen om de X server de juiste modelines
te laten accepteren.
Er waren twee laatste dingetjes: ik voegde de regel TextClockFreq 40 toe aan het XF86Config bestand om de juiste tekst frequentie te herstellen als ik van een X sessie terugschakelde naar een tekst console; en modificeerde het startx script (/usr/X11R6/bin/startx) om de virtuele console beschikbaar te houden en de DISPLAY variabele te zetten (die variabele werd verondersteld om door de window manager te worden beheerd, fvwm2, maar dit leek niet te werken). Het laatste deel van het script zag er nu als volgt uit:
export DISPLAY=":0.0"
exec xinit $clientargs -- $serverargs >& /tmp/xinit.out &
De tweede regel hierboven leidt alle output van de X console naar een bestand in een tijdelijke directory en plaatst het hele X window proces in de achtergrond, om te controleren indien nodig.
Het systeem draaide, maar ik had het idee dat ik nog iets miste; ik had twee van de laatste semi-commerciële distributies, RedHat 5.1en SuSE 5.2, beide een ongekend gemak voor installatie en configuratie belovend, maar in plaats daarvan gebruikte ik de kale hacker's distributie, Slackware. Dus besloot ik te proeven van de alternatieven.
|
|
SuSE 5.2 met al zijn geclaimde deugden, bleek niet te booten op mijn laptop. Ik maakte de bootdisks met mijn werkende Slackware installatie, met het commando dd if=/cdrom/disks/eide01 of=/dev/fd0. Geen van zijn IDE bootdisks (eide01 tot eide03) kwam verder dan de melding "Loading Linux..." (met drie punten), mogelijk een geheugen conflict of iets in die geest. Ik heb gehoord van mensen die zeiden dat bootdisks soms crashten en dat men dan moest spelen met de geheugen cache of andere kernels selecteren, maar 1) geen van de kernels
|
|
Toen ik verder ging met RedHat 5.1, was ik nieuwschierig, daar mijn vorige Linux ervaring met RedHat 4.2 was, en ik had gehoord dat er veel was verbeterd. Het installatie script schitterde, ik hoefde alleen maar de bootdisk te maken, welke zonder problemen werkte en me in een zucht door de installatie heen hielp. De paralle poort Zip drive werd succesvol gedetecteerd als "/dev/sda", maar daar ik deze niet nodig had tijdens de installatie, was het meer een aardig detail: zo kon bijvoorbeeld fdisk niet gestart worden, met de klacht "unable to access the default device /dev/sda". Tijdens de setup had ik een vrije paralle console welke reeds bash draaide, en twee fout-log consoles (Ctrl-Alt-F3 en F4) om de voortgang van het script te monitoren. Toen ik verder ging met het script en bij het punt uitkwam waar de individuele pakketten geselecteerd, kon ik zien hoeveel ruimte nodig was voor de installatie van de verschillende componenten, in tegenstelling tot Slackware's script. Maar dit was niet cruciaal daar de totale benodigde ruimte toch onder de 400MB was en ik twee keer zoveel vrije ruimte had op de /usr partitie.
Ik kwam tot de configuratie van X, welke min of meer pijnloos verliep. Het /etc/X11/XF86Config bestand dat uit de configuratie kwam was wat minder geschikt voor mijn hardware, omdat het de relevante 24bpp truecolor mode verzuimde; in plaats daarvan had het de 32bpp moeten verwijderen. Maar ik wist reeds welke modes werkten, dus zo erg was het niet. Mijn grafische adapter (C&T) was correct gedetecteerd. Ik kon X starten zonder problemen (behalve dat de X terminal witte tekst op een zwarte achtergrond gebruikte, wat ik niks vind) en, om op te warmen, probeerde de glorieuze rpm ("RedHat Package Manager", de tool die hun gebruiken om software installatie en de-installatie te managen) om de nieuwe Ghostscript 5.10 uit de redhat/contrib directory te installeren. Dit zou een fluitje van een cent moeten zijn. Ik dacht dat het voldoende was om een simpel en intuïtief commando als "rpm -i pakketnaam.rpm" te gebruiken inplaats van het saaie en cryptische tar zxf pakketnaam.tgz, nietwaar? Oeps... Ik kreeg een melding van rpm dat er een ander pakket nodig was om Ghostscript te installeren, iets als "ghostscript-fonts-standard", en dat pakket was nergens te vinden. Ik heb iets als dit eerder gezien: ik herinner me dat rpm me eens eerder (onder RedHat 4.2) vertelde dat ik "het pakket /bin/sh niet op mijn systeem had"; /bin/sh is de shell, hoe kon ik die commando's intypen zonder deze? Het zou aardig zijn om het me te horen vertellen dat mijn moederbord ontbreekt. Typische "rpm madness", dacht ik en gaf dat op. Over het algemeen leek het systeem langzamer te werken dan met de Slackware installatie, die in principe uit dezelfde componenten bestond.
|
|
Toen probeerde ik de systeem configuratie tool linuxconf, aangeprezen als de beste vriend van de systeembeheerder. Helaas kon ik niet achterhalen wat de vele misplaatse widgets gingen veranderen in het systeem; sommige plaatsen lagen voor de hand terwijl andere volledig cryptisch waren. De hoogste prioriteit voor mij is om de systeem configuratie te begrijpen en in staat te zijn om problemen op te lossen, gebaseerd op dit begrip; ik vermoed dat RedHat en mogelijk andere volgers van de "maak-het-simpel" doctrine proberen om systeem management "simpel" te maken, niet door triviale details te verbergen, maar door de systeembeheerder bepaalde meegeleverde software te laten gebruiken en nooit met de hand te configureren.
Een ander punt: hoewel de ZIP drive gedetecteerd was, was de toegang erg traag omdat de gebruikte driver een erg oude beta versie was, die alleen de traagste toegansmodus ondersteunde, zodat ik de driver (en mogelijk de kernel) opnieuw moest compileren. Ik liep tegen een ander probleem aan tijdens het installeren van de kernel sources, ik weet niet meer wat het was. Vanwege deze overwegingen en de angst voor "rpm madness", besloot ik RedHat te dumpen en terug te keren naar de oude-en-vertrouwde Slackware. Ik rebootte met de Slackware floppies die ik nog steeds had, herhaalde de installatie met de probleempjes die ik reeds kende, en al snel draaide het systeem weer.
In het centrum van een Linux systeem bevindt zich de kernel, en ik wist dat deze ondersteuning voor alle randappartuur die zich in mijn computer bevonden moest bevatten, van de muis tot geluidskaart, van mijn paralle poort ZIP drive tot mijn externe SCSI CDROM drive. Ik wist ook dat de kernel deze apparaten kan ondersteunen in een modulaire vorm, dan worden de drivers op commando geladen en na de tijd verwijderd. Dit maakt de kernel kleiner en flexibeler, daar ik principe de drivers voor niet-compatibele apparatuur kon laden en verwijderen, wanneer nodig. Bijvoorbeeld, de printer driver zou niet-compatible kunnen zijn met mijn ZIP drive, in welk geval ik de driver zou laden voor slechts een van deze tegelijk.
|
|
De kernel die bij standaard Linux distributies komt, bevat ondersteuning voor een aantal standaard apparaten, inclusief die, die ik hoop nooit te hebben; de drivers voor deze apparaten zitten alleen in het geheugen en doen niets. Het is beter om een eigen kernel te compileren die precies de computer ondersteund waar hij op draait.
Met dit in gedachten, begon ik te configureren en de eigen kernel te compileren voor mijn computer. Daar ik er voor had gekozen om de volle kernel sources (versie 2.0.34) te installeren, was het hercompileren van de kernel erg eenvoudig. Ik ging naar de directory /usr/src/linux en zei make menuconfig om het tekst-gebaseerde kernel configuratie script te starten. Na een korte tijd werd een prettig ogende dialoog box met verschillende kernel opties weergegeven. Iedere kernel optie is goed voorzien van commentaar en ik was in staat om ze te doorlopen in bijna geen tijd. Ik schakelde alles in wat ik nodig had, tot aan de geluidskaart, welke niet in de lijst stond, maar zoals ik had gezien in de README's was het een SoundBlaster kloon (al stond hij niet in de lijst als een SoundBlaster kloon, hij zou het wel moeten zijn). Ik koos ieder randapparaat dat ik had om te compileren als module; onder deze bevonden zich het power management ("APM"), SoundBlaster compatibele geluidskaart, een PS/2 muis, seriële poorten, floppy disk, cdrom en SCSI disk support (voor mijn ZIP disk, altijd handig om te hebben). Ik maakte modules van de verschillende netwerk-gerelateerde dingen als SLIP en PPP en voor a.out, ELF en java uitvoerbare formaten (voor het geval ik ze nodig zou hebben). Ik compileerde aparte modules voor Macintosh bestandssysteem (hfs), welke ik nodig had om te kunnen werken met SGI-compatibele ZIP disks, en de geüpdate ondersteuning voor de paralle ZIP drive (deze dingen komen niet met standaard kernel, maar ik had ze nodig). Ook downloadde ik het nieuwste PCMCIA pakket (pcmcia-cs-3.0.4 ) en compileerde de SCSI kaart en de netwerkkaart modules.
Toen gaf ik een make dep; make zlilo; make modules; make modules_install en wachtte zo'n 15 minuten. Nadat alles gedaan was, waren de nieuwe kernel en modules gecompileerd en geplaatst in de juiste locaties. Ik controleerde dat het kernel bestand /vmlinuz nieuwer en kleiner was dan de oude, welke opgeslagen was als /vmlinuz.old, en herstartte... om uit te vinden dat hij niet langer bootte, en zelfs stopte voordat er bestandssystemen waren gemount. De gebruikelijke volgorde van boot berichten stopte na de partitie controle op VFS: mounted root (ext2 filesystem) readonly. Er waren geen bestandssystemen gemount als read-write (lezen en schrijven) en geen systeem initialisatie scripts (gestart door INIT) waren uitgevoerd. Oeps.
Na opnieuw opgestart te hebben met de Slackware boot floppy welke de oude kernel bevatte, had ik mijn systeem terug, en ging weer door de kernel configuratie en begon te denken over wat er fout was in mijn nieuwe kernel. Al snel vond ik de fatale fout: ik was zo dol geweest op het idee om alles modulair te maken dat ik een domme fout maakte en de ondersteuning voor alle uitvoere formaten (dus a.out, ELF en java) als modules had gecompileerd. De kernel en alle programma's waren gecompileerd als ELF. Dus wanneer de kernel startte, was deze niet in staat om programma's uit te voeren zonder de module te laden voor ELF ondersteuning, maar om die module te laden wordt het insmod programma gebruikt, welke ELF is. De oplossing is natuurlijk om de ELF ondersteuning in de kernel te compileren, en niet als module. Dit is ook een natuurlijk iets om te doen, daar de meeste programma's tegenwoordig zijn gecompileerd in ELF. Na het hercompileren van de kernel met deze ene aanpassing, was ik in staat om te rebooten zonder problemen.
Vervolgens ging ik naar de /lib/modules directory en verwijderde alle modules die ouder waren de nieuw-gecompileerde. Zo kwam ik van de foutmeldingen over incompatible modules tijdens het booten af. Ook bewerkte ik het systeem initialisatie script /etc/rc.d/rc.S om kerneld, de "daemon" die modules automatisch laadt en verwijderd, in te schakelen. Met kerneld is het niet nodig om kernel modules met de hand te laden met insmod en verwijderen met rmmod (al is het nog steeds mogelijk om dit te doen). Het commando lsmod geeft een lijst van alle in de kernel geladen modules.
|
|
kerneld werkte perfect, en laadde modules wanneer nodig en verwijderde ze een tijd niet gebruikt waren. Ik moest de regel alias scsi_hostadapter ppa toevoegen aan /etc/conf.modules en de paralle poort module ppa werd automatisch geladen als ik de ZIP drive (/dev/sda) probeerde te mounten. Ik vermoed dat ik dit zal moeten veranderen als ik SCSI kaart gebruik in plaats van de paralle poort adapter.
Een aantal configuratie-verfijningen waren nodig nadat de kernel opnieuw was gecompileerd. Deze waren: toegang configureren voor de externe opslag apparaten (op moment de floppy, CDROM en ZIP drive); ondersteunen van twee muizen tegelijk; ondersteunen van de Russische taal; en het opzetten van de fvwm window manager.
Het Slackware installatie script had de /mnt directory gemaakt, met daarin de subdirectories /mnt/floppy en /mnt/cdrom voor het mounten van de externe bestandssystemen op floppies en CDROMs. Eerst besloot ik dat het hebben van deze in een aparte directory niet handig was, en creëerde /floppy en /cdrom in de root directory. Maar later realiseerde ik me dat ik meer directories nodig had om de apparaten met verschillende opties te benaderen, en liever dan ze allemaal in de root directory te houden, plaatste ik ze in de /mnt hiërarchie.
Ook veranderde ik de mount opties in /etc/fstab Na de installatie bevatte dit bestand redelijke defaults, maar dit was niet genoeg voor mij. Eerst maakte ik de regels voor de floppy, CDROM en ZIP drive, schakelde het automatisch mounten van deze uit, en maakte het mogelijk voor alle users om deze te mounten (de user optie):
/dev/fd0 /mnt/floppy vfat user,noauto,noexec,nonumtail 0 0 /dev/sda4 /mnt/zip vfat user,noauto,noexec,nonumtail 0 0 /dev/hdc /mnt/cdrom iso9660 user,noauto,noexec 0 0
Merk de noexec optie op voor de DOS-compatibele bestandssystemen: het maakt de bestanden op die bestandssystemen niet-uitvoerbaar, wat meestal verstandig is. De nonumtail optie voorkomt het aanmaken van lelijke bestandsnamen: het bestand longname.file zal hernoemd worden naar longname.fil in plaats van longa~1.fil als er geen naamconflicten optreden. Het vfat bestandssysteem ondersteund lange bestandsnamen op een DOS-compatibele manier, in tegenstelling tot het oudere msdos type, dus waarom deze niet gebruiken.
Het mtools pakket gaf problemen: het heeft ofwel lees/schrijf rechten nodig op /dev/fd0 of alleen de superuser kan lezen of schrijven op de floppy. Het zetten van het setuid bit op de mtools bestanden leek niet te helpen. Ik besloot dat ik deze apparaten liever met de hand mountte.
Het verhaal met de muizen was relatief simpel omdat ik dit ook al had moeten uitzoeken met mijn vorige laptop. De laptop heeft een ingebouwde touchpad (in feite een PS/2 muis), en ook wilde ik een externe muis aansluiten op de seriële poort. Beide muizen kunnen eenvoudig samenwerken, met behulp van het programma gpm ("general purpose mouse"). Het programma dient twee doelen: eerst, in tekst consoles maakt het het gebruik van een muis als aanwijzer mogelijk (in
|
|
gpm -t ps2 -m /dev/psaux -2 -M -t mman -m /dev/cua0 -3 -R
Dit kan worden ontcijferd als: de eerste muis is een type PS/2 op een aanvullende poort, heeft twee knoppen, de tweede muis (-M is van het type [Logitech] MouseMan, is aangesloten op COM1 (/dev/cua0), heeft drie knoppen en -R betekend dat de beide muizen beschikbaar moeten zijn voor X window sessies als een muis). Merk op dat de optie -R niet nodig is met gpm versie 1.14 of later. Na het invoegen van deze regel, stopte en herstartte ik gpm (gpm -k; /etc/rc.d/rc.local) en vervolgens werkten beide muizen onmiddelijk en zonder problemen. Ik was zelfs in staat om de seriële muis in te pluggen tijdens het werk in een X window sessie en voila, het werkte meteen. Dergelijke dingen waren niet mogelijk onder het zogenaamde besturingssysteem "windows": deze verteld de gebruiker om de computer te rebooten om enige "nieuwe hardware" te laten werken.
Het volgende dat me bezig hield, was de ondersteuning voor Cyrillische karakters. Ik moet in staat zijn om Russische tekst te lezen en soms te schrijven. Ik installeerde alleen cyrillische support voor het X Window System. Dit bestond uit twee delen: Cyrillische fonts en de Cyrillische keyboard layout. Er bestaan een aantal pagina's op het net met alle details over de "Cyrillisatie van Unix". Een set KOI-8 fonts wordt meegeleverd met Slackware. De "Cyrillic How-To" bevat een pointer naar de collectie van YakuFonts, gecreërd door Serge Yakulenko ([email protected]). Het kan gevonden worden in de collectie cyrillische ondersteuning voor het X Window System. Ik downloadde de twee font pakketten welke identieke fonts bevatten in de KOI-8 en CP1251 (of "Windows") encodings, pakte de font bestanden uit (*.pcf.gz) in subdirectories koi8-r en x-cp1251 van de X window fonts directory /usr/X11R6/lib/X11R6/fonts/ (op mijn Slackware systeem eenvoudiger te benaderen via de link /etc/X11/fonts). Daarna installeerde ik de fonts door deze twee subdirectories toe te voegen aan het "FontPath" in het bestand /etc/X11/XF86Config. Hierna herstartte ik X en alle fonts waren beschikbaar, dus kon ik Netscape (ik gebruikte versie 4.05) om automatisch deze fonts te gebruiken voor de overeenkomstige "encodings" koi8-r en x-cp1251
Toen moest ik nog een driver hebben voor Russische toetsenborden. Ik gebruikte het eenvoudige en niet opdringerige programma xrus welke ik had van Moshkow's Library, the page on Cyrillization en na het patchen van zijn bron bestand etc/X11/app-defaults/Xrus en zijn keyboard layouts waren gelijk aan mijn bekendheid met van de Russische typemachine :) Ik was comfortabel aan het typen in het Russisch.
De laatste stap was het installeren van een programma voor het converteren van bestanden tussen Russische encodings. Ik gebruik een erg eenvoudig, thuis gemaakt script, welke ik de naam 323.pl heb gegeven. Het is in staat tot het converteren tussen CP866 ("DOS" of "alternative"), KOI-8, CP1251 ("Windows") en Macintosh encodings. Ik maakte hardlinks naar 323 genaamd koi2win, alt2mac en zo verder (ln 323 koi2win etc.) en het script bepaald automatisch wat er moet gebeuren, gebaseerd op zijn naam. Met behulp van dit script en de geïnstalleerde fonts, zou men in staat moeten zijn om bijna elke tekst in het Russisch te lezen.
|
|
Alles was correct opgezet voor het X window system, behalve de window manager fvwm2. Al zijn instellingen worden gecontroleerd door een enkel bestand ~/.fvwm2rc of (of als dat bestand niet bestaat, het systeemwijde bestand /etc/X11/fvwm2/system.fvwm2rc). Ik ontdekte dat het bestand dat met Slackware wordt meegeleverd, veel dingen bevatte die waren uitgeschakeld die in het geheel niet bruikbaar waren of zelfs niet werkten. De basis dingen die ik wilde van de window manager waren: een aantal knoppen voor het snel oproepen van een klein aantal nuttige programma's; reageren op toetsenbord en muis voor venster operaties zoals verplaatsen of vergrootten; wat algemene operaties in de titelbalk knoppen van alle venster; en om een menu weer te geven van alle geïnstalleerde X window applicaties. Ideaal zou zijn als dit alles met het toetsenbord bereikbaar zou zijn, zonder de muis aan te raken.
Ik begon met het geleverde bestand en bewerkte het vaak, las de lange en wat compacte manual page (man fvwm2) om uit te vinden hoe de verschillende functies werden aangeroepen en voegde veranderingen een voor een toe. Ik was in het byzonder geïnteresseerd in het nuttig maken van de "Windows 95" toetsen voor verschillende venster operaties. Het resultaat is .fvwm2rc, (kan hier gedownload worden), met hopelijk voldoende commentaar om te zien wat er gebeurd.
De inbel-toegang tot mijn lokale PPP netwerk provider was klaar in zo'n korte tijd dat ik werkelijk verbaasd was. Na het lezen van enkele lastige en verouderd lijkende manuals over PPP setup, inclusief de "Installation Guide", was ik onder de indruk geraakt dat het opzetten van PPP een pijnlijk proces was. Echter, door het willekeurig zoeken naar commando's die begonnen met ppp, ontdekte ik een script dat was meegeleverd door Slackware, genaamd pppsetup, welke me precies de juiste vragen stelde over mijn modem en mijn PPP provider. Van een ding wist ik echter niet zeker wat het was: of het "autenticatie protocol" nu "PAP", "CHAP" of "CHAP-Microsoft" was. Ik selecteerde (willekeurig) "CHAP" en ging verder met de setup. Even later was ik klaar, en werd mij verteld om twee, zelf-uitleggende, commando's te gebruiken, ppp-go en ppp-off voor de controle over de PPP verbinding, en ook was er een gedetailleerde tekst /etc/ppp/pppsetup.txt, welke beschreef wat er was gebeurt met het systeem tijdens pppsetup. In dat bestand werd aangeraden om ifconfig te gebruiken om te zien of de PPP verbinding succesvol was opgezet. Ook werd ik naar de systeem logs /var/log/messages en /var/log/debug verwezen in het geval van problemen (daar de debug optie in het PPP opties bestand /etc/ppp/options per default was ingeschakeld; later schakelde ik deze uit omdat het debug bestand werd gevuld met nu waardeloze pppd berichten).
Het leek allemaal ok, maar toen ik de modem aansloot op de telefoon lijn, leek het ppp-go commando geen verbinding op te zetten. Het /var/log/debug bestand bevatte veel meldingen; ik keek tegen het einde van het bestand en vond een onsuccesvolle uitwisseling tussen pppd en de remote host. Een van de meldingen ontvangen van de remote host was <auth pap>. Aha! Dus ik had "PAP" moeten geselecteren in plaats van de "CHAP" authorizatie. Ik voerde de pppsetup opnieuw uit en de PPP verbinding werkte in minder dan geen tijd. Later bedacht ik me dat het pppscript een paar functies bevatte die het syteem log bestand grep'ten en meldingen afdrukte als " "It seems that they want PAP..." (NL: "Het lijkt dat ze PAP willen..."), enzo, maar om de een of andere reden waren deze functies uitgeschakeld. Bestaat er een betere versie van pppsetup, of was de ontwikkeling ervan nog niet helemaal compleet?
|
|
Hoewel PPP nu goed werkt en ik in staat ben gebruik te maken van fetchmail, ncftp, Pine, netscape en andere goede software, zonder problemen, ben ik niet helemaal tevreden met de setup. Ik wou dat het inbel-proces beter controleerbaar was en dat de foutmeldingen, als die voorkomen, zichtbaar zijn voor de gebruiker. Als de PPP verbinding faalt om een of andere reden, zou ik willen dat er andere manier was om het te achterhalen dan in te loggen als root en de systeem logs te doorzoeken. Misschien dat bij de commerciëlere Linuxes utilities worden meegeleverd om een gebruikers-vriendelijke PPP verbinding zichtbaar te maken (misschien gppp?), maar ik was bang dat die utilities een hele serie afhankelijkheden nodig hadden voor de installatie of dat ze helemaal niet zouden werken zonder hun "eigen" omgeving. Ooit zal ik een vriendelijker utility installeren of Perl/Tk leren en mijn eigen inbel-netwerk widgets schrijven. Of misschien zal ik volledig gaan voor RedHat, als zijn object-georiënteerde desktop manager GNOME volwassen wordt.
Een ander punt met PPP was dat het ppp-go script gestart moest worden door de root gebruiker. Eerst dacht ik erover om on-demand (NL: op aanvraag) bellen op te zetten, maar de kernel bevatte om de een of andere reden geen versie van PPP driver (2.3) die die functie ondersteunde. Toen dook ik in de netwerk archieven en vond een erg kort C programma, "PPP for mortals" (NL: "PPP voor sterfelijken"), welke de setuid(0) aanriep om root te worden en daarna het ppp-go script startte. Ik compileerde deze en installeerde het met het setuid bit gezet op 1 (chmod 4755 ppp_for_mortals). Hierna kon ik dit programma uitvoeren als gebruiker om de PPP verbinding te starten of te stoppen.