Wenn ein Rootserver nicht in das lokale System bootet, wird folgendes im Rescue-System durchgeführt. fdisk -l zur prüfung ob die Festplatte eingebunden ist
fdisk -l
Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 128 1028128+ 83 Linux
/dev/hda2 129 383 2048287+ 82 Linux swap / Solaris
/dev/hda4 384 9729 75071745 5 Extended
/dev/hda5 384 1021 5124703+ 83 Linux
/dev/hda6 1022 1659 5124703+ 83 Linux
/dev/hda7 1660 3572 15366141 83 Linux
/dev/hda8 3573 9729 49456071 83 Linux
Nun wird das Filesystem einer Prüfung unterzogen. Man kann sehen, ob ein Ergebnis bei der Prüfung der Filesysteme erzielt werden konnte.
Wichtig:
Die Partitionen dürfen hier auf keinen Fall gemountet sein. Sollte während der Prüfung mit xfs_repair allerdings die unten genannte Fehlermeldung auftreten, muss das Filesystem gemountet und anschliessend wieder unmountet werden, bevor xfs_repair erneut durchführt wird:
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed. Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair. If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
fsck -y /dev/hda1 xfs_repair /dev/hda5
xfs_repair /dev/hda6
xfs_repair /dev/hda7
xfs_repair /dev/hda8
Sollte ein xfs-Filesystem so zerstört sein, dass xfs_repair zu keinem positiven Ergebnis so können Sie es noch mit xfs_db (FileSystem Debugger) versuchen.
Hinweis:
Möglicherweise muss hier anstelle von /dev/mdx auch /dev/hdx oder /dev/sdx verwendet werden. Das kann jedoch bei der Ausgabe von fdisk -l genauer ausgelesen werden.
Das Lokale-System mit /mnt mounten funktioniert dann wie folgt:
mount /dev/hda1 /mnt
mount /dev/hda5 /mnt/usr
mount /dev/hda6 /mnt/var
mount /dev/hda7 /mnt/home
mount /dev/hda8 /mnt/srv
Hinweis:
Möglicherweise muss hier wieder anstelle von /dev/hdax auch /dev/mdx oder /dev/sdx verwendet werden.
Nun wechselt man mit chroot /mnt die Root-Benutzerebeneauf das Lokale System
Als erstes prüfen Sie bitte, ob die boot.msg beim letzten Versuch lokal zu booten, geschrieben wurde.
www:~ # ls -la /var/log/boot.msg -rw-r--r-- 1 root root 25264 May 22 10:13 /var/log/boot.msg
Wurde diese so gespeichert, so kann man dort nach dem Fehler suchen.
Tipp:
Hier kommt man häufig weiter, wenn man nach "eth0" sucht.
Falls das Datum der Datei vor dem letzten lokalen Bootversuch liegt, zeigt dies,
dass das System erst garnicht gestartet werden kann. Das kann unter anderem an einem falsch verlinkten Kernel oder einem fehlerhaftgen "MBR" liegen.
Falls alles weitere stimmt kann hier das einfache Auführen von lilo das Problem lösen.
www:~ # ls -la /boot/ total 6536
drwxr-xr-x 3 root root 4096 May 22 09:59 .
drwxr-xr-x 21 root root 4096 May 24 15:29 ..
-rw-r--r-- 1 root root 1322662 Dec 16 13:16 System.map-2.6.16.27-061216a
-rw-r--r-- 1 root root 512 Jun 9 2005 backup_mbr
lrwxrwxrwx 1 root root 1 May 22 09:55 boot -> .
-rw-r--r-- 1 root root 512 Jun 9 2005 boot.0800
-rw-r--r-- 1 root root 512 May 22 09:59 boot.0810
-rw-r--r-- 1 root root 29112 Dec 7 16:03 config-2.6.16.27-061207a
-rw-r--r-- 1 root root 29112 Dec 16 13:08 config-2.6.16.27-061216a
drwxr-xr-x 2 root root 4096 Jun 9 2005 grub
-rw------- 1 root root 120320 May 22 09:59 map
lrwxrwxrwx 1 root root 25 May 22 09:55 vmlinuz -> vmlinuz-2.6.16.27-061216a
-rw-r--r-- 1 root root 2568468 Dec 7 16:10 vmlinuz-2.6.16.27-061207a
-rw-r--r-- 1 root root 2567123 Dec 16 13:16 vmlinuz-2.6.16.27-061216a
lrwxrwxrwx 1 root root 25 May 22 09:55 vmlinuz.old -> vmlinuz-2.6.16.27-061207a
Der Link vmlinuz zeigt auf den aktuell verwendeten Kernel: lrwxrwxrwx 1 root root 25 May 22 09:55 vmlinuz -> vmlinuz-2.6.16.27-061216a |
Sollte der Kernel hier nicht stimmen, so muss dieser ausgetauscht werden. Die Kernel, welche verwendet werden können, finden Sie unter "update.pureserver.info" (per FTP oder Browser). Sie liegen dort unter "local-updates --> kernel". Die zu verwendenten Dateien sind dort mit der endung *tar.gz zu finden. Welcher Kernel zu welchem System passt, sieht man an der Bezeichnung.
Dazu die Datei herunterladen und unter in der Hauptebene "/" ablegen, abschließend auspacken:
Dabei werden die notwendigen Dateien in den dafür vorgesehenen Ordnern abgelegt.
Unter anderem findet ihr nun eine Datei mit der Kernelbezeichnung im Verzeichnis
/boot. Nun vmlinuz auf diesen Kernellink verlinken. ln -sf <zieldatei> vmlinuz |
Abschliessend muss noch der Befehl lilo ausgeführt werden, damit das ganze in den Master Boot Record (MBR) geschrieben wird.
|
