E-post: salg@linmag.no



9.9.2010 - 13:34
 • Nyheter
 • Om Linux
 • Linuxskolen
 • Spørrespalte
 • Vitsespalte
 • LINUXmagasinet
 • Spill
 • WEBSHOP
 • Diskusjonsforum
 • Linker
 • For annonsører
 • English
 • Om oss
developer.ez.no
www.online4u.no

0

Når Linux tar kvelden


Linuxskolen del 9 (LINUXmagasinet 3/2003)

Når Linux tar kvelden

 
Før eller siden kommer da selv den mest stabile Linux-maskin legger inn årene. Dette skyldes i de fleste tilfeller deg selv eller faktorer som plutselige strømbrudd, ødelagt strømforsyning eller rett og slett gjennom en havarert harddisk. I denne runden av Linuxskolen skal vi dvele litt ved de mulighetene du har i tilfelle uhellet er ute.

Feil i forbindelse med kompilering av ny kjerne som utelatt støtte for IDE harddisk, filsystemer eller chipset, er vanlige feller å tråkke i. Videre er det fort gjort å glemme å kjøre '/sbin/lilo' etter å ha redigert /etc/lilo.conf eller at du rett og slett har glemt å kopiere bzImage til /boot/vmlinuz-2.x.xx etter kompilering. Alle disse fører normalt til at systemet ikke starter opp etter reboot, og du står med skjegget i postkassen. 

Kernel Oops
Det som imidlertid er verdt å nevne noen ord om er "Kernel Oops" og "Kernel Panic". På sitt mest fundamentale nivå kommuniserer Linux-kjernen med resten av systemet via funksjonen printk(). Dersom en beskjed er viktig nok vil printk() skrive denne til konsollet og sende en kopi til klogd for å bli logget til disk. Denne dobbeltkjøringen gir deg muligheten til å oppdage problemer som er så alvorlige at de ikke rekker å logges til disk før systemet er ute av funksjon. Et disk-crash kan jo være et slikt eksempel. Linux-kjernen er programmert til gi ut en slik "Oops"-melding, som er kort sagt er kjernens måte å fortelle at noe galt har skjedd. En slik "Oops" er i virkeligheten en "protection fault" som vanligvis er et resultat av at en strukturell peker har null verdi eller feil adresse. Slike "Oops" opptrer vanligvis på ustabile kjerner hvor det eksprimenteres med drivere og kjerne-kompileringer. 

Kernel Panic
En "Kernel Panic" sendes ut av kjernen dersom den detekterer at noe er alvorlig galt. printk() vil skrive beskjeden ut til konsollet og systemet vil stoppe opp. Slik vil det stå inntil noen ser beskjeden og rebooter. På ubetjente systemer kan det være en fordel å sette det opp til å logge beskjeden deretter å reboote automatisk. Dette kan du fikse ved å legge til følgende i /etc/lilo.conf:
panic=30
Husk '/sbin/lilo' etterpå!!

Redningsplankene kan grovt sett deles opp i to stabler:
1.	"Rescue disker" som enten følger med Linux-systemet ditt i form av en floppy eller en cd-rom, eller floppyer produsert av installasjonsprogrammet under installasjonen. Begge vil være spesielt beregnet for denne spesifikke Linux-varianten, og således stort sett ubrukelig for andre versjoner. Den smaleste av disse er floppyen du lager under installasjonen, som i tillegg til å være distribusjonsavhengig også er fokusert på partisjoner, drivere osv. i akkurat den maskinen den lages for.
2.	Den andre varianten er distribusjonsuavhengige "rescue-disker". Disse er utrolig kjekke å ha for hånden når uhellet er ute, bl.a fordi de som regel inneholder flere verktøy du kan benytte under reparasjonen, samt flere drivere for enheter i maskinen eller filsystemer. Dette med filsystemene kan lett få deg oppi store problemer. De aller fleste veiledninger for hvordan du skal berge deg ut av diskfeil tar utgangspunkt i at du benytter "ext2" filsystem. Med flere nye såkalte "journaliserende" filsystemer å velge i som ReiserFS og Ext3 (journalisering for Ext2), er det stor sannsynlighet for at du ikke har Ext2 på den disken eller partisjonen hvor feilen ligger. Da er det godt å vite at redningen muligens ikke er lengre unna enn en floppy. Eksempler på en slike er "tmsrtbt", RIP (Rescue is Possible) og H. Peter Anvin's SuperRescue. Den mest brukte er "tmsrtbt" grunnet alle verktøyene Tom Oecher har greid å trykke inn på en eneste 1.44 MB floppy (formateres til 1.7 MB av Toms installasjonsprogram). Fordelen med RIP er at den inneholder filsystemet ReiserFS. Både "tmsrtbt" og RIP kan også fåes både i form av en bootbar CD og floppy, mens SuperRescue er så svært at det kun kan lastes ned som et disk image og brennes til CD-Rom. Jeg har ikke tenkt å ta for meg alle tre i denne omgangen, men det er verdt å nevne at SuperRescue er faktsik et eget Linux-system basert på RedHat 7.2, med støtte for blant annet ReiserFS, Ext3 og nettverk. I tillegg inneholder den  XWindow med en fullt fungerende KDE!! Vi skal imidlertid se nærmere på "tmsrtbt" om litt.

Vel, vi kan for enkelhets skyld deler jeg prodblemene du kan tenkes å havne i, i 4 hovedgrupper:
•	Linux booter ikke:
I all hovedsak er slike problemer forårsaket av feilaktig avmontering (umount) av partisjoner ved "shutdown" av maskinen. Strømbrudd, ødelagt strømforsyning eller rett og slett slurv fra din side er nok de mest vanlige. Etter en slik hendelse vil Linux automatisk kjøre 'fsck' for å forsøke å rette opp feilene i filsystemet. Som oftest klarer systemet selv å rette opp problemene, men ikke alltid. La oss for enkelhets skyld anta at du benytter Ext2 filsystem. Linux ber deg først oppgi passordet til root og du blir deretter presentert et root-prompt. Følg nøye med under den delen av bootingen som går greit, siden du da vil kunne se hvilke partisjoner som er ok, og hvilket nummer den ødelagte har. Når du har funnet dette nummeret, for eksempel /dev/hda3, kjører du kommandoen 'fsck.ext2 /dev/hda3'. Linux vil da forsøke å rette opp eventuelle feil, samt at du blir gitt muligheten til å bestemme hvilke deler av filsystemet som skal rettes opp. Dette kan ta lang tid, siden det ofte er nødvendig å fikse en masse såkalte Inoder. Du blir promptet for hver enkelt som behøver reparasjon. En enklere måte å gjøre jobben på er å gi kommandoen 'fsck.ext2 -a'. Da slipper du å gi noen inputs og forhåpentligvis går alt bra. Etter endt fsck på de partisjonene som inneholdt feil avslutter du med 'exit'. Linux vil da reboote normalt.

Andre ganger stopper bootingen med et LI-prompt. Dette er imidlertid ikke så vanlig lengre, siden denne feilen normalt oppsto som en følge av at linux-kjernen og bootmap tidligere måtte ligge under sylinder 1024 på boot-disken. Med de nye variantene av LILO er dette problemet fjernet, og man står friere til å partisjonere slik man ønsker. I de tilfeller man fikk dette problemet var det som regel ifm første boot etter installasjon. Det man da måtte  gjøre var å re-partisjonere å legge inn en liten boot-partisjon (20-50 MB) helt i starten av ledig diskplass. Kjerne og bootmap ville da bli plassert her i stedet for langt ute på disken. Andre slike LI-problemer kunne skyldes at LILO ikke klarte å få kontroll over harddiskens geometri. Ifm bruk av store disker kunne det være nødvendig å fortelle LILO mer om geometrien ved å legge inn ekstra opsjoner i /etc/lilo.conf som for eksempel "linear", "lba32" eller med dagens enda større harddisker kan det sågar være nødvendig med "lba48". Et slikt problem som dette vil kreve at du har en boot-disk tilgjengelig. Du kan nå enten benytte CD-en du installerte Linux fra, den floppyen du kanskje laget under installasjonen eller du kan slå følge med meg i det jeg gir deg to alternativer til en slik boot-floppy.

Rescue-disk fra original CD
Den kanskje raskeste metoden er dersom du ikke har tilgang til en rescue-CD er å lage deg en boot-floppy ved hjelp av det rescue-imaget som vanligvis ligger på /images på installasjons-CD-en. Ved å putte denne CD-en i en annen Linux-maskin og mounte den opp i for eksempel /mnt/CD-Rom vil du kunne gjøre følgende:

* Putt i en floppy
* Åpne et terminalvindu og kjør følgende kommando: 'dd if=/mnt/CD-Rom/images/rescue.img of=/dev/fd0'
* Når prosessen over er ferdig kan du putte den nye rescue-disken i maskinen med feil på og boote opp.

Hvis du ikke har tilgang til enda en Linux-PC kan du like gjerne benytte en DOS- eller Windows-maskin til jobben. Normalt ligger det et program på den CD-en du henter rescue-imaget fra som heter "rawrite". Du bruker dette slik:

* Åpne et terminalvindu og let opp "rawrite" på CDen. Dette ligger vanligvis på /mnt/CD-Rom/dos-utils/.
* Gi så kommandoen '/mnt/CD-Rom/dos-utils/rawrite'
* rawrite vil så spørre deg om plasseringen til rescue-imaget. La oss si /mnt/CD-Rom/images/rescue.img
* Neste steg er å fortelle rawrite hvor den skal putte det nye disk-imaget. Dette svarer du vanlivis 'a:' på.
* Vips! Du har en rescue-floppy og kan boote den ødelagte maskinen med denne.

tomsrtbt
Dette er verktøyet en Linux administrator aldri skulle være uten! tomsrtbt står for:

"Tom's floppy which has a root filesystem and is also bootable."

Det sier egentlig alt. Hvordan lager du deg så et slikt "vidunderverktøy", og hvordan kan du bruke den? Følg med!

* Last ned http://www.tux.org/pub/distributions/tinylinux/tomsrtbt/tomsrtbt-2.0.103.tar.gz for Linux
* eller http://ftp.sunsite.utk.edu/ftp/pub/mini-linux/tomsrtbt/tomsrtbt-2.0.103.dos.zip dersom du bare har tilgang til en DOS- eller Windows-pc.

Vi tar kun for oss Linux-løsningen her:
* Pakk ut til /usr/src og kjør 'cd /usr/src/tomsrtbt-2.0.103/'
* Putt en floppy i floppy-driven og følg eksemplet under.

[kolbjorn@aldebaran kolbjorn]$ su
Password: 
[root@aldebaran kolbjorn]# cd /usr/src/tomsrtbt-2.0.103/
[root@aldebaran tomsrtbt-2.0.103]# ./install.s 

Don't forget to READ the FAQ.

Insert a blank writable 3.5" floppy diskette then strike ENTER.

About to fdformat /dev/fd0u1722
Double-sided, 82 tracks, 21 sec/track. Total capacity 1722 kB.
Formatting ... done
Verifying ... done
About to dd floppy image
3444+0 records in
3444+0 records out
About to verify floppy image
Succeeded!

Du er nå klar til å "nød-boote" maskinen med den nye floppyen. La oss si at du har kompilert ny kjerne, og i det du gjør '/sbin/reboot' kommer du på at du har glemt å kjøre 'sbin/lilo' etter å ha redigert lilo.conf. Den gamle kjernen er slettet fra /boot så du vet at maskinen aldri booter med den eksisterende konfigurasjonen. Hva gjør du?

1. Boot opp maskinen med den nye rescue-floppyen
2. Velg en passende video mode for din skjerm (størrelse på bokstaver og tall)
3. Velg keyboard (også norsk)
4. Logg inn som root med passordet som oppgies

Du har nå bootet opp og logget inn, klar for en kjapp reparasjon. Bare for å demonstrere fleksibiliteten på denne floppyen kan jeg fortelle at mens du sannsynligvis booter en ny maskin med den, så jeg nå gjort det samme med en eldgammel Compaq Contura 4/25c laptop med 640x400 VGA. Selv der funket den!! La oss gå videre.

Så må du få tilgang til filene på harddisken. Disken er ennå ikke hengt på noe filsystem, så det er her vi starter. Problemet er å finne ut hvilken partisjon som inneholder /etc hvor de fleste konfigurasjonsfilene burde ligge. Dette avhenger av partisjoneringen du gjorde da du installerte systemet. Har du latt installasjonsprogrammet gjøre alt for deg kan du satse på at dette er /dev/hda1, men har du gjort dette selv og lagt til /boot på en egen partisjon helt først på disken vil dette i så fall være /dev/hda1. Siden jeg liker den siste varianten best går vi for at det er slik du også har gjort det. Vi sier da at /etc vil befinne seg på neste partisjon som da vanligvis vil være /dev/hda5 (eller /dev/hda3) og at filsystemet er Ext3 for / og Ext2 for /boot.

Fremdeles som root:
1. Sjekk først at /mnt er tom med 'ls -al /mnt'
2. 'mount -t ext3 /dev/hda5 /mnt/' og deretter 'mount -t ext2 /dev/hda1 /mnt/boot'
3. Dersom du nå tar en 'ls -al /mnt/' skulle du se alle de normale katalogene under vanlig /.
4. For at du skal kunne få kjørt programmer fra den disken du nå har mountet gjør du slik:
   'chroot /mnt /bin/bash'.
5. Dersom du nå tar en 'ls -al /' vil de finne at dette nå er den katalogen som før befant seg under /mnt/.
    Du har mao begynt å få et "normalt" system å jobbe på.
6. Det neste vi gjør er å sjekke at /etc/lilo.conf er ok. 'joe /etc/lilo.conf' skulle gjøre jobben.
    Når du er fornøyd trykker du Ctrl-k-x for å lagre og avslutte. Gjør du feil trykker du Ctrl-c for
    å avbryte.
7. Kjør så '/sbin/lilo' for å oppdatere systemet.
8. Ta ut bootdisken og reboot med '/sbin/reboot'. Du skulle nå kunne boote som normalt.

Fordelen med "tmsrtbt" sammenlignet med RIP (http://www.tux.org/pub/people/kent-robotti/looplinux/rip/) er at den førstnevnte inneholder nettverksdrivere på samme floppy. Du kan mao komme deg på nett med et lite utvalg nettverkskort for å hente drivere, programmer eller annet nødvendig for at du skal komme helskinnet ut av et problem. Den inneholder også drivere for de mest brukte SCSI-kort og for PCMCIA. For mere info, sjekk: http://www.toms.net/rb/tomsrtbt.FAQ

•	Filsystemfeil:
Kan jo for eksempel oppstå som følge av at man setter inn en ekstra disk i maskinen, og under justeringen av /etc/fstab gjør du en feil som ikke manifesterer seg før ved neste oppstart. Denne filen kan du rette opp på samme måte som i eksemplet med lilo.conf.

I tillegg kan du oppleve faktiske filsystem-feil hvor du må til med verktøy som tune2fs og debugfs. Begge disse finner du på "tmsrtbt".

La oss også ta for oss et eksempel der du ikke klarer å reparere skaden på disken. Dette er en av de gangene hvor du ender opp med et system du ikke får bootet, men hvor det kan la seg gjøre å forsøke å berge så mange konfigurasjonsfiler og andre filtyper som mulig. Det er flere måter å gjøre dette på. Er du bare ute etter konfigurasjonen skulle det holde lenge med å berge unna de viktigste i /etc. Dette burde du klare å få kopiert over på en floppy. Skal du redde enda større datamengder er det nok en god idé å sette inn en ny harddisk og kopiere dem over til den. Vi tar for oss floppy-metoden:

1. Boot opp med "tmsrtbt" først og logg inn som root. Ta så ut boot-disken og sett inn en ubrukt floppy.

[root@aldebaran kolbjorn]# fdformat /dev/fd0u1440
Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.
Formatting ... done
Verifying ... done

[root@aldebaran kolbjorn]# mkfs.ext2 /dev/fd0
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
184 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
1 block group
8192 blocks per group, 8192 fragments per group
184 inodes per group

Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 31 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Det neste vi må gjøre nå er å mounte den partisjonen som inneholder /etc. La oss si at dette er /dev/hda5 med Ext2 filsystem. Vi gjør da slik for å kopiere de data som leigger der over til floppyen:

1. 'mkdir /mnt/image'
2. 'mkdir /mnt/floppy'
3. 'mount -t ext2 /dev/hda5 /mnt/image'
4. 'mount -t ext2 /dev/fd0 /mnt/floppy'
5. 'cp -Rf /mnt/image/etc/<den filen jeg ønsker> /mnt/floppy/'

Gjenta punkt 5 inntil du har berget det du ønsker over på den nye floppyen. Etter dette kjører du 'umount /mnt/floppy' FØR du tar disketten ut, samt 'umount /mnt/image' for å koble av /dev/hda5.

•	Kjerneproblemer:
Du kan også redde en maskin med en defekt kjerne med en rescue-disk. Gjør som i eksemplet med lilo.conf med å boote opp, mounte nødvendige partisjoner ( / og /boot + evt. andre du ønsker montert). Kjør så chroot som nevnt i samme eksempel, og utfør deretter en normal kjernekonfigurasjon vha 'make menuconfig' eller 'make config' i tekstmodus. Kompiler og installer kjernen på normalt vis. Reboot etter justering av lilo.conf og '/sbin/lilo'.

•	Hardwarerelaterte problemer:
På den laptoppen jeg benytter som gateway, en Compaq Armada 1592DT opplevde jeg etter en reinstallsjon av Linux til en nyere variant (RedHat 7.2) at den ikke lengre ville boote normalt. Det som skjedde var at den bare "spydde" ut en masse svada om "machine check exeption" ditt og datt før den crashet helt. Etter en del leting fant jeg at dette er en sjekk av prosessor som jeg ikke MÅ ha. For å slippe å rekompilere kjernen benyttet jeg en "switch" i lilo.conf som sier append="nomce". Du får da en lilo.conf ala dette:

boot=/dev/hda
map=/boot/map
vga=normal
default=linux
keytable=/boot/no-latin1.klt
prompt
nowarn
timeout=100
message=/boot/message
menu-scheme=wb:bw:wb:bw
image=/boot/vmlinuz
        label=linux
        root=/dev/hda1
        initrd=/boot/initrd.img
        append="quiet devfs=mount nomce mem=64M"
        vga=788
        read-only
image=/boot/vmlinuz
        label=linux-nonfb
        root=/dev/hda1
        initrd=/boot/initrd.img
        append="devfs=mount"
        read-only
image=/boot/vmlinuz
        label=failsafe
        root=/dev/hda1
        initrd=/boot/initrd.img
        append="failsafe devfs=nomount"
        read-only
other=/dev/fd0
        label=floppy
        unsafe

Da blir den sjekken utelatt og maskinen bootet normalt. For å få lagt dette til lilo.conf må du jo uansett få bootet maskinen en gang slik at du får tilgang til filen. Dette kan du enten gjøre vha "tmsrtbt" eller i dette tilfellet enda enklere ved å gjøre slik:

'LILO: linux nomce'

mao skriver du 'linux nomce' når LILO dukker opp ved boot.
Rediger deretter lilo.conf som normalt. Husk '/sbin/lilo' til slutt.

•	Slettede filer
Å redde slettede filer i Linux er IKKE noen triviell oppgave. Så lenge du arbeider i XWindow og benytter deg av Trash eller Søppelbøtta er det jo plankekjøring, men i det øyeblikket du i en terminal gjør dette: 'rm -rf *.*' i stedet for 'rm -rf *.*~', ja da har du et problem. Sto du til alt overmål i "/" og var root i det du gjorde det, ja da er skaden gjort. I Linux får du det du ber om! Å berge seg ut av eksemplet jeg nettopp gav er nok ikke mulig, men hadde du stått i en katalog med mindre viktige filer, og hvor bare noen få hadde blitt slettet, så kunne du alltids forsøkt med 'debugfs', men da må aktiviteten på filsystemet ha vært liten rett etter at skaden oppsto. Problemet består i at straks du sletter en fil i Linux blir blokkene den opptar på disken frigjort. Dette betyr at dersom det opprettes en ny fil rett etter slettingen kan denne nye få den gamles blokker og løpet er kjørt. Er du interessert i å lære mer om dette kan du gjøre det på http://web.mit.edu/tytso/www/linux/e2fsprogs.html


•	Kjappe løsninger på noen "normale" problemer
Q. Etter installasjon av Windows (dual boot) er LILO borte. Hva gjør jeg?
A. Boot opp med "tmsrtbt" og kjør kommandoen '/sbin/lilo -v'

Q. Hvordan fjerner jeg LILO fra bootsector?
A. Du kan gjøre det med en DOS bootdisk slik: 'fdisk /mbr' eller slik i Linux: ''fdisk -u

Q. Hvordan kan jeg se igjen alle meldingene som flimrer forbi under boot?
A. Enten slik: 'cat /var/log/dmesg' eller bare slik 'dmesg'. Du kan også sjekke de sist modifiserte filene i /var/log med kommandoen 'ls -lt /var/log | head -20'. Husk dog på at alle log-filer i /var/log kun kan leses av root, og dette er slik det MÅ være. Det står mye i de filene ingen andre har behov for å se!

Q. Linux kommer kun opp i Read Only Mode etter 'Shutdown -F now'
A. Gjør slik:
1. Når LILO kommer ved boot skriver du 'linux 1'
2. cd /
3. rm forcefsck
4. cd /etc/rc.d
5. chmod a+x /etc/rc.d/rc.sysinit
Dette skulle løse problemet.

Q. Jeg benyttet grafisk login, men noe har skjedd slik at X ikke starter lengre etter boot.
A. Når LILO dukker opp under boot skriver du 'linux single' og trykker enter. Linux vil
     nå boote i single user mode og gi deg en kommandolinje login. Du kan nå rette opp feilen for
     deretter å reboote normalt. Ønsker du å kvitte deg med grafisk login redigerer du /etc/inittab og
     setter linjen "id:5:initdefault: til id:3:initdefault:"

Q. Jeg har glemt passordet til root. Hva gjør jeg nå?
A. 'linux 1 init=/bin/sh' når LILO dukker opp under boot gir deg tilgang til root-shell med alle
      rettigheter. Bruk så 'passwd' for å gi root sitt nye passord. Dette er dog ikke noen spesielt sikker
      konfigurasjon iom at alle som setter seg fremfor maskinen kan kjøre samme kommando, og dermed
      få tilgang til roots privilegier. Jeg har på http://arctic.linux.tnett.no/sikkerhet.html satt opp noen tips
      på hvordan du bedre sikrer deg her.

Linker til ytterligere informasjon:
http://www.linuxdoc.org/HOWTO/Bootdisk-HOWTO/index.html
http://www.linuxdoc.org/HOWTO/Bootdisk-HOWTO/premade.html
http://www.linuxdoc.org/HOWTO/BootPrompt-HOWTO.html
http://www.linuxdoc.org/HOWTO/LILO-crash-rescue-HOWTO.html#toc1



0








0 0