grub error 18 nach Kernelupdate

Zitat

Original von groti
Wichtige Frage jetzt: Kann ich ohne Neuinstallation den alten Kernel wiederherstellen? Die Platte zu formatieren würde mir echt Magengeschwüre verursachen. Habe Mahlzeit 3.2.

Üblicherwiese wird bei Installationen einer neuen Kernel[-Version] der alte Kernel nicht gelöscht .

Einzig deine menu.lst dürfte überschrieben/geändert worden sein .

Sobald der grub-Bildschirm erscheint kannst du mit <ESC> oder den Cursortasten die Automatik unterbrechen und mit <e> den gewählten Eintrag edititeren .

Setze dort deinen alten Kernel , editiere dann die menu.lst und gut ist .

HJS

hoffentlich unterstützt die grub-Version in LinVDR das Editieren.

in der Zeile
kernel /boot/vmlinuz vga=0x000 root=/dev/hda1 quiet

müsste dann aus vmlinuz vmlinuz-2.6.18 werden

vmlinuz-2.6.18 ist der Kernel, der bei der 3.2 ab Werk dabei ist. Den hast Du ja sicher nicht gelöscht.
Kontrollier nochmal genau die Schreibweise

kernel /boot/vmlinuz-2.6.18 vga=0x000 root=/dev/hda1 quiet

Die vga-Option ist irrelevant

notfalls lade ein Ubuntu iso runter und brenne es auf CD. Davaon kannst Du dann booten und auf die LinVDR-Partition zugreifen

na, dann ist der Abend ja gerettet

ich würde trotzdem den Steinzeit-Kernel nur als Übergangslösung betrachten. Wo beim nächsten update die Kerneldatei landet, ist allerdings m.E. Glückssache.

Umgehen kann man das nur, wenn man eine kleine Boot-Partition am Anfang der Platte einrichtet. Aber das ist schon einiger Aufwand.

Was ich noch nicht probiert habe: Vielleicht kann man eine CF-Karte in einem IDE-Adapter als Bootpartition betreiben.
Es müssen dazu aber ein paar Änderungen am LinVDR vorgenommen werden.

ich denke wir sollten der Tatsache realistisch ins Auge sehen, dass es nach bald 2 Jahren beta-Phase wohl keine finale mahlzeit4 mehr geben wird. Das müsste inzwischen auch von Grund auf neu entwickelt werden, denn der alte Unterbau geht wirklich gar nicht mehr.

Wenn die CF-Karte bootfähig ist und praktisch nur grubund die vmlinuz enthält, dann würde ab dem Moment, wo der Kernel geladen ist, von Platte gebootet. Es muss ja nicht die komplette boot-Partition in der CF liegen. Die CF würde wie eine Art Boot-Diskette agieren. Was übrigens auch noch eine Option wäre. Aber jedesmal das Schnarren des Floppy-Laufwerks, wenn der vdr bootet?

Warum kein usbstick? Klein, billig, Wegwerfen wenn kaputt?

aber ob ein Board, dessen BIOS mit einer 400GB-Platte nicht zurechtkommt, von USB booten kann?

Ich denke ja. Booten von usb wird schon recht lange unterstützt.

Es könnte auch sein, dass die alte linvdr Version Schuld war und nicht das MB. Vielleicht wurde die Platte als /dev/sda gesucht o.ä.

Zitat

Original von wirbel
Ich denke ja. Booten von usb wird schon recht lange unterstützt.

Es könnte auch sein, dass die alte linvdr Version Schuld war und nicht das MB. Vielleicht wurde die Platte als /dev/sda gesucht o.ä.

Wobei son ansonsten nutzloser 16 MB CF für den Zweck ja noch ne Daseinsberechtigung hätte ...

HJS

Hallo Doctor,

Mirko hat doch in der letzten c't gerade einen Artikel zum Erstellen einer aktuellen busybox veröffentlicht.(Artikel Sah mir sehr nach einer Anleitung für ein "do it your self linvdr" aus, oder wie siehst Du das?
Ich werd mir das bei Gelegenheit mal näher anschauen.... (Aber vorher muss ich mich wohl noch dringend mit VMWare beschäftigen

Gruß Micha

P.S. Ich hatte übrigens auch mal ein sporadisches problem mit Error 18 bei Grub, bis ich irgend wann feststellte, dass der Master und Slave-Anschluss am Kabel mit der Platte vertauscht war. Seit dem läuft alles supi mit ner 400-er PATA und linvdr (Siehe Sig 1. vdr)

Hallo Micha,

in Zeiten von Terrabytegroßen Platten kommt es m.E. nicht mehr darauf an, das Betriebssystem so klein wie möglich zu halten. Die Erfahrungen mit LinVDR zeigen eher, dass auf kurz oder lange dann Probleme auftreten, wenn man sich eine Entwicklungsumgebung einrichtet und an verschiedenen punkten feststellt, dass die busybox-befehle nicht alle Parameter unterstützen, die ein Makefile z.B. voraussetzt.

Aber für Spezialdistris, die z.B. auf begrenzten Flashspeicher passen müssen, ist busybox sicher eine tolle Sache.

Gruß
Dr. Seltsam

Zitat

Original von Dr. Seltsam
in Zeiten von Terrabytegroßen Platten kommt es m.E. nicht mehr darauf an, das Betriebssystem so klein wie möglich zu halten.

Da stimme ich dir grundsätzlich zu , aber mit Plattenplatz rumaasen muß man auch nicht gerade ...

Zitat

Die Erfahrungen mit LinVDR zeigen eher, dass auf kurz oder lange dann Probleme auftreten, wenn man sich eine Entwicklungsumgebung einrichtet und an verschiedenen punkten feststellt, dass die busybox-befehle nicht alle Parameter unterstützen, die ein Makefile z.B. voraussetzt.

Naja - Dev Sys hier , Prod Sys dort - dann gibbet auch kein Prob mit Makefiles

HJS