|
2. Genomförande
Till att börja med måste man ha en tom partition på ungefär 650MB, som blir utgångspunkten för Blue Linux. Dessa steg måste utföras från en annan Linux installation på datorn. Att skapa partition ordnar man med cfdisk. Sedan skall partitionen få ett Linux filsystem (ext2fs). Detta ordnar man med mke2fs
Nu är partitionen identisk med en minimal installation av Debian. Katalogerna /initrd och /lost+found är överflödiga och kan tas bort. I /lost+found läggs filer som räddats från en trasig hårddisk, men i vårat fall är detta överflödigt, dels eftersom vi inte använder oss av hårddisk, och dels eftersom filsystemet är skrivskyddat, och därför kan inga filer läggas där. Katalogen /initrd används endast om man använder sig av en speciell ramdisk teknik, något vi inte gör. Därefter skall filen /sbin/unconfigured.sh raderas, för att systemet skall tro att allt är konfigurerat och klart . För att öka överskådligheten skapas katalogerna /blue och /blue/tmp där vissa Blue Linux specifika filer placeras. Man får inte heller glömma att sätta korrekta rättigheter på /tmp katalogen . Alla skall ha rätt att göra allt i denna katalog. Kommandot chmod 777 /tmp ordnar detta.
När detta är klart är det bara att modifiera vissa filer i /etc katalogen, mer om dessa modifieringar senare. Dock skall inte de skript som aktiverar ramdiskarna läggas in ännu, eftersom viss programinstallationen måste utföras på det riktiga filsystemet först. Nu kan Blue Linux startas upp, och man kan slutföra installationen. För att underlätta installationen av programpaketen (deb-filer), skriver man ett skript som installerar det man vill ha. Vi använder oss av apt-get när vi installerar deb-filer, eftersom alla filer ett program är beroende av då installeras automatiskt. För att uppdatera paketdatabasen med apt-get skriver man apt-get update. För att installera ett paket skriver man apt-get install
En minimal installation av Debian, alltså motsvarigheten till våran grunduppsättning filer, innehåller alla viktiga program och kommandon. Därför är behovet av fler program egentligen ganska litet, om man inte skall göra något väldigt specifikt. Vi har försökt att hålla antalet installerade program så lågt som möjligt. Även om en CD skiva rymmer 650 MB tycker vi att det är onödigt att lägga in program som man nästan aldrig använder. Vi har dock lagt in det grafiska systemet X Windows System, med alla dess grafikservrar, samt den populära skrivbordsmiljön KDE och fönsterhanteraren Window Maker. KDE är ett av de större Open Source projekten, vars mål är att skapa både försterhanterare, programmerings-gränssnitt och en stor mängd program för Linux. För en komplett lista över installerade programpaket, se Bilaga 7.
När alla program är installerade och konfigurerade kan man aktivera ramdiskarna. Detta görs genom att ändra i skriptet /etc/init.d/rcS, som körs när Linux startar, så att den startar skriptet /blue/onstart, som i sin tur skapar ramdiskarna. När detta är klart är det dags att starta om Blue Linux. Nu kommer systemet inte längre skriva några data till hårddisken, men systemet fungerar perfekt ändå, tack vare ramdiskarna. Nu innehåller alltså den 650MB stora partitionen precis det som vi vill ha på CD skiva.
Whiptail är ett program som genererar textbaserade dialogrutor. Det finns flera program i denna kategori, bland annat dialog och lxdialog. Vilket av dessa man väljer är egentligen en smaksak, man tar den som man anser är snyggast. Alla bygger på principen att man, antingen från kommando raden eller från ett skript, ger programmet ett antal parametrar, och därefter genereras en användarvänlig dialogruta. Vi använde oss av Whiptail för att skapa alla våra dialogrutor. Till vänster återfinns en dialogruta, skapad med följande kommando: whiptail --backtitle "Blue Linux" --title "Netconfig" --fb --inputbox "Enter your netmask: " 10 60 "255.255.255.0". I detta fall kommer en dialogruta upp och ber användaren mata in en nätmask i en textruta. Det går även att skapa menysystem med Whiptail. Vi har använt oss av Whiptail i alla våra skript, förutom startskriptet onstart, vilket är det enda skriptet som inte visar någon dialogruta. För mer information hänvisar vi, som vanligt, till manual sidorna, man whiptail.
Nu är det dags att bränna ut systemet på en CD skiva. Detta måste göras från en annan Linux installation. Varför bränningen överhuvudtaget måste ske från Linux beror på att vi måste bränna med Linux filsystem ext2fs, annars skulle filerna på CD skivan inte få de rätta attributen, och därmed bli obrukbara. För att kunna bränna med ext2fs som filsystem måste man använda sig av en loopback-device. Denna speciella teknik monterar en fil, som om den skulle ha varit ett filsystem. Först skapar man en 650 MB stor fil och fyller den med tomrum, dd if=/dev/zero of=/blue.iso bs=1024k count=650. Då är filen /blue.iso 650MB stor, och helt tom. Nu skall den här filen få agera filsystem. Men först måste Linux filsystemet skapas med mke2fs -b 2048 /blue.iso. Sedan monterar man detta filsystem med hjälp av loopback-device, mount /blue.iso -o loop=/dev/loop0 /mnt. Sedan skall alla filer från Blue Linux partitionen kopieras över till /mnt, som motsvaras av filen /blue.iso. För att alla filer, inklusive special filerna i /dev och symboliska länkar skall kopieras korrekt, måste man ställa sig i rot katalogen på Blue Linux partitionen och skriva find ./ -print | cpio -pmd /mnt. Då har hela Blue Linux hamnat i /mnt, och därmed i /blue.iso. Därefter kan blue.iso monteras bort med umount /mnt.
Nu är prepareringarna inför bränningsprocessen klara. I Linux finns det ett textbaserat brännarprogram vid namn cdrecord. Med cdrecord -v speed=4 dev=0,0,0 -data /blue.iso påbörjas själva bränningen av CD-skivan. För att ta reda på vilka parametrar man skall ha efter dev= skriver man cdrecord -scanbus. Då kommer alla SCSI enheter att visas i en lista, med tillhörande parametrar. Om man, som i vårat fall, har en IDE brännare måste denna emulera SCSI för att man skall kunna bränna . För att det skall fungera måste kärnan ha stöd för detta, och dessutom bör man i lilo lägga till hdc=ide-scsi, om CD brännaren är ansluten som sekundär master. Detta för att SCSI emuleringen skall fungera.
Till en början kanske det är bäst att förklara vad en bootloader gör. Dessvärre finns det inget bra svenskt ord för motsvarande, startladdare låter inte rätt. Hur som helst, en bootloader är ett litet program som laddas när datorn startar. Sedan är det bootloaderns uppgift att starta operativsystemet. En bootloader kan även låta användaren välja olika alternativ som rör starten av operativsystemet.
Hittills har starten av Blue Linux skett med hjälp av en redan befintlig bootloader, och med en befintlig kärna (kernel på engelska). Båda dessa tillhör egentligen den redan existerande Linux installationen, som man var tvungen att ha för att kunna arbeta med Blue Linux partitionen. Men Blue Linux skall egentligen startas från diskett, och dessutom från vilken dator som helst, utan krav på att man redan har Linux. En bra utgångspunkt för startdiskett medföljer på Debians installations CD, /dists/stable/main/disks-i386/current/disks-1.44/rescue.bin. Denna fil innehåller rådata som skrivs till disketten med dd if=/dists/stable/main/disks-i386/current/disks-1.44/rescue.bin of=/dev/fd0. Nu ligger syslinux, som är en diskettanpassad bootloader, samt en enkel kärna på disketten, som hanterar systemstarten. När datorn startas med disketten laddas syslinux, som ger användaren möjligheten att välja vilken kärna och partition som skall laddas. Man kan även ändra storlek på ramdiskarna. I filen syslinux.cfg, som ligger på disketten, konfigurerar man bootloadern. Där anger vi bland annat storleken 11000 KB på ramdiskarna, samt vilken text som skall visas. Den kärna som ligger med på disketten från början är inte tillräckligt omfattande. Därför skapar vi en egen kärna och lägger den på disketten. Denna kärna skapar vi från den befintliga Linux installationen, med hjälp av den senaste stabila källkoden vars versionsnummer är 2.2.14. Denna kärna skall vara så omfattande och stödja så många olika enheter som möjligt. De vanligaste enheterna kompileras in i kärnan, medan de lite mer udda enheterna kompileras som moduler, så att de kan laddas in under drift om behovet finns.
För att Linux skall bete sig som vi vill har vi modifierat några filer för att nå olika mål.
/etc/init.d/checkroot.sh - Kontrollerar root-filsystemet. Denna fil har modifierats för att inte kräva speciell filsystemskontroll. /etc/init.d/checkfs.sh - Kontrollerar filsystem. Denna fil har modifierats för att inte kräva speciell filsystemskontroll. /etc/kbd/default.kmap.gz - Modifierad för att Linux skall fungera bättre med svensk tangentbordslayout. /etc/fstab - Modifierad för att filsystemet skall fungera från en okänd enhet . /etc/hostname - Modifierad för att sätta hostname till bluelinux. /etc/hosts - Modifierad för att bland annat sätta domän till bluelinux.dune.nu /etc/issue - Modifierad för att visa textmeddelande vid inloggnings prompten. /etc/motd - Modifierad för att visa en text logotype efter inloggning. /etc/init.d/rcS - Fil som körs när Linux startar. Modifierad för att starta skriptet /blue/onstart. /etc/apt/sources.list - Modifierad för att man skall kunna lägga till program med apt-get. Denna fil innehåller ett par stycken sökvägar till programpaket. /etc/X11/XF86Config - Modifierad för att man skall kunna starta X Window System med standardinställningar utan att behöva konfigurera. Fungerar inte dessa standardinställningar måste man dock konfigurera X på egen hand. Vidare så har vi även anpassat vissa filer på startdisketten. debian.txt - Innehåller den text som skall visas när man startar från disketten. Vi har skrivit start anvisningar och satt en liten Blue Linux inspirerad prägel på texten. syslinux.conf - I denna fil konfigurerar man själva funktionaliteten hos startmenyn, bland annat vilka parametrar som Linux skall startas med.
Följande filer har vi själva skapat. De är alla enkla skal skript, placerade i /blue katalogen.
onstart (Bilaga 1)
blue (Bilaga 2)
ram_fl (Bilaga 3)
fl_ram (Bilaga 4)
bluemouse (Bilaga 5)
bluenet (Bilaga6)
Under projektets gång har vi stött på ett antal oförutsedda problem. En del problem löste vi ganska snabbt, medan andra krävde lite mer efterforskningar. Det första man gör om man kör fast är att leta information i den inbyggda manualen, man
Det första problemet upptäcktes när vi skulle prova att starta det 40 MB stora root-filsystemet. Det visade sig starta en del konfigurationsprogram automatiskt. Vi insåg ganska snabbt att vi var tvungna att göra oss av med dessa, eftersom det inte går att arbeta med systemet om det hela tiden vill konfigurera sig självt. Även om vi gjorde alla konfigurationer som vi ombads göra blev inte resultatet tillfredsställande. Med andra ord så var det bara att starta det befintliga Linux systemet och börja felsökningen. Efter att ha studerat de flesta skript som körs vid starten, konstaterades att vissa kollade om filen sbin/unconfigured.sh fanns. Om filen fanns skulle vissa kommandon utföras. Med tanke på filnamnet så borde ju filen ha något med den automatiska, med störande, konfigurationen. Eftersom det var många skript som kollade om denna fil fanns, så insåg vi att det var lika bra att ta bort filen. Det gjorde vi, och resultatet blev att konfigurationstvånget var borta. Det andra problemet upptäcktes mycket senare. Det visade sig nämligen vara omöjligt att läsa de inbyggda manualsidorna med man-kommandot. Utan dessa manualer kommer man inte särskilt långt i Linux. Såväl nybörjare som proffs använder dem flitigt. Felmeddelandet antydde något om att man inte hade rättighet att läsa manualen. Det spelade ingen roll om man försökte läsa dem som superanvändaren root, eller som vanlig användare, inget fungerade. Då var det dags att undersöka vilken fil eller katalog som inte hade tillräckligt generösa rättigheter. De två första katalogerna man kommer att tänka på är var och tmp. Var-katalogen innehåller bland annat filer som ändras under drift, och tmp katalogen innehåller temporära filer. Var-katalogen är ganska komplex, med sina många underkataloger, och det var så gott som omöjligt att hitta något möjligt fel här. I fallet med tmp-katalogen var det lättare, eftersom den katalogen inte innehöll några filer. Då var det bara att kolla själva katalogens rättigheter, och mycket riktigt, denna katalog hade inte de rättigheter som den borde ha. Alla användare skall få göra allt i denna katalog, så det var bara att köra chmod 777 /tmp så funkade allt bra sedan. Problem nummer tre var att lösa frågan hur man bränner en skiva med en IDE brännare. I vanliga fall brukar IDE vara ett lättanvänt gränssnitt i jämförelse med SCSI, men icke i detta fall. Det textbaserade brännarprogrammet cdrecord, som är det enda hyfsade programmet i denna kategori, har endast stöd för SCSI brännare. Efter att ha läst howto filen för cd bränning under Linux blev vi något klokare. Där stod det att cdrecord hade stöd för ATAPI, som är ett gränssnitt för IDE baserade läsare/brännare att kommunicera med SCSI kommandon. Vidare förklarades vissa kriterier för hur kärnan skulle vara utformad. Det slutade med att vi fick kompilera om kärnan med mer utbyggd SCSI hantering. Sedan hittade cdrecord våran IDE brännare, och bränningsprocessen gick utmärkt. Problem nummer fyra visade sig, som en del andra problem, just i starten av systemet. När man kör root-filsystemet från en CD skiva påpekar Linux att filsystemet bör kontrolleras, och vips så hamnar man i en situation där man får välja om man skall starta om datorn, eller manuellt köra ett program som kontrollerar filsystemet. Med andra ord ingen vacker start, mycket opraktiskt alltså. Eftersom vi får förutsätta att det inte är något fel på filsystemet (om det skulle ha varit fel kan det ändå inte korrigeras, eftersom CD skivan är skrivskyddad), så ser vi till att dessa felkontroller aldrig utförs. Vi upptäckte att dessa startas från /etc/init.d/checkfs.sh och /etc/init.d/checkroot.sh. Om inte annat så ser man på filnamnen att de har något med saken att göra. Då stänger vi bara av de rader som startar själva kontrollen, och efter en omstart kan vi konstatera att problemet är borta. Problem nummer fem har med vart filsystemet som skall laddas in är placerat. I filen /etc/fstab anges en viss enhet som root-filsysten, exempelvis /dev/hdc1, men Blue Linux kanske startas från en annan enhet, och då börjar det genast krångla. Proc-filsystemet, som också står med i samma fil, slutar att fungera om sökvägen till root-filsystemet är felaktig. Efter lite experimenterade visade det sig att om man stängde av den raden som har med root-filsystemet att göra, så monterades root-filsystemet ändå, eftersom hänvisningen hämtas från bootloadern i stället, dock blir filsystemet alltid skrivskyddat, men det gör inget, eftersom det är precis det vi eftersträvar. Dock fungerade inte proc-filsystemet, det monterades helt enkelt inte. Då lade vi in följande rad i vårat start skript /blue/onstart: mount -t proc proc /proc; vi monterade alltså manuellt, och det visade sig fungera bra.
Resultatet blev en CD skiva och en diskett, innehållandes ett fullt fungerande Linux system. Målsättningen, att hårddisken inte skulle vara inblandad, är uppfylld. Dessutom fick vi en del användbara skript, som kan komma till användning för användaren. Vi är ganska stolta över att Blue Linux bara förbrukar lite drygt 10 MB mer minne än en vanlig Linux distribution. Vidare så har vi lagt upp arbetet på Internet, på adressen www.dune.nu.
|