Bij het bouwen van bootdisks, zal het systeem bij de eerste pogingen waarschijnlijk niet booten. De algemene benadering bij het bouwen van een root-disk is componenten vanuit je bestaande systeem te assembleren, en het op een diskette gebaseerd systeem te krijgen en uit te proberen tot op het punt waar het berichten op de console weergeeft. Zodra het éénmaal met je begint te communiceren, is het halve leed geleden omdat je dan kunt zien waar het problemen mee heeft, en kun je individuele problemen herstellen net zolang tot het systeem soepel werkt. Als het systeem zonder verklaring hangt, kan het uitzoeken van de oorzaak moeilijk zijn. Om een systeem geboot te krijgen tot die fase waarin het met je zal communiceren, is het vereist dat verscheidene componenten aanwezig zijn en correct zijn geconfigureerd. De aanbevolen procedure voor het onderzoeken van het probleem waar het systeem niet met je zal communiceren is als volgt:
Kernel panic: VFS: Unable to mount root fs on XX:YYDit is een algemeen probleem en het kan slechts door een paar dingen worden veroorzaakt. Vergelijk allereerst het device XX:YY met de lijst device-codes; is het 't juiste root-device? Als dit niet zo is, heb je waarschijnlijk de
rdev -R
niet uitgevoerd,
of paste je het toe op het verkeerde image.
Als de device-code correct is, controleer dan nauwkeurig de device-drivers
die in je kernel zijn gecompileerd. Overtuig jezelf ervan dat er ingebouwde
ondersteuning voor een diskette, ramdisk en ext2 bestandssysteem in de kernel
voorkomt.
/bin
.
/lib
directory op je harddisk is.
/dev
directory op
je bestaande systeem ook voorkomen in het bestandssysteem op je root-diskette,
waar die links naar devices zijn die je op je root-diskette hebt opgenomen.
In het bijzonder zijn de /dev/console
links in veel gevallen
essentieel.
/dev/tty1, /dev/null, /dev/zero,
/dev/mem, /dev/ram
en /dev/kmem
bestanden hebt opgenomen.
Nu dat we deze algemene aspecten éénmaal hebben gehad, zijn hier nog een aantal specifiekere bestanden om te controleren:
init
is opgenomen als /sbin/init of
/bin/init. Zorg ervoor dat het uitvoerbaar is.
ldd init
uit om op de library's van init te controleren.
Meestal is dit gewoon libc.so
, maar controleer het toch maar.
Zorg ervoor dat je de benodigde library's en loaders hebt opgenomen.
ld.so
voor a.out of ld-linux.so
voor ELF.
getty
(of een op getty
-lijkend programma, zoals
agetty
, mgetty
of
getty_ps
).
Controleer deze tweemaal
met inittab
op je harddisk.
Controleer de manpages van het te gebruiken programma om er zeker van te
zijn dat deze zin hebben. inittab
is mogelijk het lastigste onderdeel
omdat de syntax en inhoud ervan afhangen van het in gebruik zijnde init
programma en de natuur van het systeem. De enige manier om het aan te pakken
is de manpages van init
en inittab
te lezen en exact
uit te werken wat je bestaande systeem doet wanneer het boot.
Controleer voor de zekerheid of
/etc/inittab een systeeminitialisatie-entry heeft. Hierin zou
een commando moeten staan voor het uitvoeren van het systeem initialisatiescript, dat voor moet komen.
init
, ldd
uit op getty
om te
zien wat het nodig heeft, en zorg ervoor dat de benodigde library-bestanden
en loaders in je root-bestandssysteem zijn opgenomen.
bash
of ash
) die capabel is in het uitvoeren van al je rc-scripts.
Als init
start, maar je een melding krijgt als:
Id xxx respawning too fast: disabled for 5 minutes
komt het vanuit init
, waarmee gewoonlijk wordt aangegeven dat
getty
of login
afsterft zodra het opstart.
Controleer de getty
en login
uitvoerbare bestanden en de library's waar ze afhankelijk van zijn.
Zorg ervoor dat de aanroepingen in /etc/inittab juist zijn.
Als je vreemde meldingen krijgt van getty
, kan het zijn dat de aanroepende
vorm in /etc/inittab onjuist is. De opties van de getty
programma's zijn variabel; zelfs van verschillende versies van
agetty
wordt gerapporteerd dat ze verschillende incompatibele
aanroepende vormen hebben.
Als je een login-prompt krijgt, en je een geldige loginnaam intikt, maar het systeem vraagt je onmiddellijk om een andere loginnaam, kan het probleem te maken hebben met PAM of NSS. Zie Sectie PAM en NSS. Misschien dat het probleem tevens is dat je shadow passwords gebruikt en /etc/shadow niet naar je bootdisk kopieerde.
Als je één of ander uitvoerbaar bestand, zoals df
probeert uit te voeren, wat zich op je rescue-disk bevindt, maar het levert
je een bericht op als: df: not found
, controleer dan op twee
zaken: (1) Verzeker je ervan dat de directory met het binaire bestand zich
in je PATH bevindt, en (2) zorg ervoor dat de library's (en loaders) die
het programma nodig heeft er zijn.