Debian Lilo Partimage und Probleme

[frindly]

Hallo
ich habe Debian 4 auf einer xfs Partition installiert und mit Partimage gesichert.
Das ging bisher prima!
Aber seit heute:
Ich lese das Image zurück und boote neu.
Alles ok. Dann schalte ich den Rechner aus und wieder ein:
---> lilo kommt nich tmehr nur 99 99 99 etc
Ich starte von der Debian DVD, gehe in den rescue modus und logge mich auf der root partiton ein.
Dann gebe ich ein Lilo und der Bootlader wird neu erzeugt. Alles ok.
Aber beim nächsten Partimage... das gleiche.
Was geht da schief?

[pingu!]

Hi,

Der Errorcode 99 für LILO bedeutet:

99 invalid second stage index sector (LILO)

Wie sieht denn die lilo.conf aus.
Wie installierst du lilo auf den MBR.

Frage: wieso installierst du nicht GRUB?

Gruss pingu!

[Teddybear]

Wie kommst du darauf,
das alles auf der Festplatte an Physisch gleicher Stelle liegt, wenn du ein image der Partition zurück spielst?
Lilo ist nunmal so "pingelig" das es genauestens wissen will/muss wo es was findet.

Und wenn du das verhalten von Lilo nun kennst, wieso regst du dich darüber auf?
Mach es doch gleich "richtig"
Also wenn er nach dem aufspielen des Images durchbootet, einfach kurz lilo aufrufen.
Und das Problem ist keines mehr.

[rendegast]

Du kannst mit dem GAG oder einer generischen GRUB-Disk das System selbst starten, und dann lilo aufrufen.
Vielleicht sind beim Einloggen im Rescuemode über DVD die BIOS-ID nicht gleich den ID im normalen Start,
sodaß dann der lilo ins Leere zeigt.

[frindly]

die 99 stand nicht einmal da, sondern immer wieder ... 99 99 99 99 und so weiter.
installiert wurde lilo vom debianinstaller, in den mbr der einzigsten platte.
grub kann ich nicht nehmen, weil er ja noch kein xfs starten kann. debian schlägt lilo vor. bei ubuntu hab ich das mal probiert, der hat grub genommen (ubuntu 8.04) und dann bootete der rechner kommentarlos nicht.
also lilo...

Hi,

Der Errorcode 99 für LILO bedeutet:

99 invalid second stage index sector (LILO)

Wie sieht denn die lilo.conf aus.
Wie installierst du lilo auf den MBR.

Frage: wieso installierst du nicht GRUB?

Gruss pingu!

[frindly]

naja. aufregen tue ich mich nicht. ich will nur verstehen.
ich lese das image zurück. leider wird der mbr dabei nicht restauriert. partimage bietet mir zwar an den mbr zurück zu lesen, das scheitert dann aber mit "device busy".
ich habe also das image zurückgelesen. dann starte ich den rechner mit reboot neu.
klappt auch alles.
wenn ich den rechner dann ausschalte und wieder einschalte, dann hängt sich der lilo weg.
wenn ich das image aber zurücklese, dann in das debian starte und per hand lilo aufrufe (als root)
dann schreibt er den kram neu und alles geht einwandfrei.

komisch ist nur... vorher brauchte ich das nie. vor ein paar tagen habe ich herumexperimentiert. mandriva. suse. ubuntu. und jetzt ist dieses verhalten.....
immer wieder wenn ich das image zurücklese....

ok. ich kenn jetzt die macke. aber ich suche eine erklärung. nen grund muss es ja geben...

Wie kommst du darauf,
das alles auf der Festplatte an Physisch gleicher Stelle liegt, wenn du ein image der Partition zurück spielst?
Lilo ist nunmal so "pingelig" das es genauestens wissen will/muss wo es was findet.

Und wenn du das verhalten von Lilo nun kennst, wieso regst du dich darüber auf?
Mach es doch gleich "richtig"
Also wenn er nach dem aufspielen des Images durchbootet, einfach kurz lilo aufrufen.
Und das Problem ist keines mehr.

[rendegast]

Code: Alles auswählen

immer wieder wenn ich das image zurücklese....

Von einem Reservesystem aus?

Den MBR zu sichern sichert nur die Partitionstabelle (mit einem Timestamp(?)),
lilo sitzt im Bereich nach dem MBR.
Dort(?) stehen die Sprungadressen zur Kernelmap, zu den Kerneln.

Vielleicht bei xfs die Tools xfs_freeze, xfs_copy, xfsdump|xfsrestore verwenden?



Aus der wikipedia:

[GRUB] liest verschiedene Dateisysteme (ext2, ext3, UFS, UFS2, ReiserFS, FAT, NTFS, ISO9660, JFS, Minix, FFS, XFS ab GRUB 0.91)

...

Diese Aufteilung des Bootloaders in zwei Stufen hatte den Nachteil, dass der Bootloader nach Verschieben oder Änderungen von Stage 2 nicht mehr bootfähig war. Deswegen wurde zwischen Stage 1 und 2 eine Zwischenstufe, Stage 1.5, eingeführt. Diese liegt auf den Datenblöcken zwischen MBR bzw. Stage 1 und dem ersten Block der ersten Partition und ist in der Lage, genau ein Dateisystem zu lesen. Dabei wird die Variante installiert, welche das Dateisystem der Partition unterstützt, auf welcher Stage 2 liegt. Zur Zeit gibt es Stage 1.5 für die Dateisysteme FAT, Minix, Ext2, Ext3, JFS, ReiserFS sowie XFS. Unterstützung für Reiser4 gibt es in einem Extra-Patch.

Sollte also nicht mehr den Sektor 0 des XFS zerstören.
Vielleicht eine Macke im Bereich MBR<->Part1 ?