[Eisfair_dev] [e1] eiskernel 2.0.25 (Status 'testing') verfügbar - 2.6er Kernel für eisfair-1

[Marcus Roeckrath]

Hallo Thomas,

Thomas Bork wrote:

> Wenn Deine Block-Betrachtungen stimmen würden, dann hätte Jürgen sein
> System nicht mehr booten können.
> Das scheint aber nicht der Fall gewesen zu sein.

Der genaue Ausgangszustand und das was danach passiert ist, läßt sich ja
auch nicht mehr exakt rekonstruieren.

Aber wer meine Überlegungen mal genauer unter die Lupe nehmen will, kann ja
mal folgendes tun:

cd /boot
cp kernel kernel.new
cp initrd.gz initrd.gz.new
mv kernel.new kernel
mv initrd.gz.new initrd.gz

Ich würde fast darauf wetten, dass das System danach nicht mehr hochkommt.

Also lieber Finger weg. :-))

Grub arbeitet anders als lilo und ist IMHO gegen solche "Manipulationen"
immun. Lilo legt eine Tabelle aller Blocknummern an, die beim Boot gelesen
werden müssen, also darf sich der Speicherort der Startdateien nicht mehr
ändern, oder man muss eben wieder lilo ausführen.

Ich bin in die Falle zu Zeiten von Suse 7.x auch schon gerannt, als ich mal
eben einen neuen selbstkompilierten Kernel ohne lilo-Aufruf installiert
habe.

Man mag mich gerne korrigieren, wenn ich völlig falsch liege.

Ich habe so eine Theorie, warum das Sytem von Jürgen doch wieder hochkommt.

Du machst ein

mv kernel old-kernel
mv initrd.gz old-initrd.gz

Diese Dateien bleiben also weiterhin an der gleichen Stelle liegen, wo sie
vorher waren. Also passt nun die lilo Blocktabelle doch noch auf gültige
Startdateien.

Ein lilo-Booteintrag startet ja nicht speziell benannte Dateien, sondern
Datenblöcke deren Nummern in der Tabelle stehen.

-- 
Gruss Marcus