Das verteufelte Grub

Tagchen Xperten,

Nachdem ich mir nun beim experimentieren mit einer neuen Distribution meinen
alten Bootloader LILO mit Grub überschrieben hatte, war ich natürlich daran
versucht, mein altes System auch unter Grub Bootbar zu machen.
Soweit das Problem.

title Good Old Knoppix 2.6
root (hd0,5)
kernel (hd0,5)/boot/vmlinuz-2.6.6 root=/dev/hda6 ro hdc=scsi single
initrd (hd0,5)/boot/initrd.img-2.6.6
savedefault
boot

Aufgeführte Zeilen sollten nun mein altes System booten, doch dummerweise tn
sie es nicht, zwar wird am Anfang irgendwas abgearbeitet (ich nehme mal an, es
wird der angegebene Kernel ausgeführt), aber irgendwann, nach nicht allzu
langer Zeit stoppt das ganze mit der Meldung, die in etwa lautet
„unable to mount hda6“
(Also darauf liefs hinaus)
Meine Vermutung nun: Irgendetwas an den ominösen kernel options mag falsch
gesetzt.
Ich hoffe, hier ist ein Grub Kundiger, der mir helfen kann.
Hier noch ein paar Angaben zu meinem System (welches ich booten möchte):
ROOT (hd0,5) bzw hda6
/boot/vmlinuz-2.6.6
/boot/initrd.img-2.6.6

MfG
Passer

Edit://
Wie mir grade auffällt, verlangt lilo anscheinend gar keine Angabe des Kernel
Images!?
dort fand ich lediglich die angabe des
/boot/initrd.img-2.6.6
gibt es da auch ein äquivalent zu bei grub???
ich nehme fast an, dass angegebenes kernel image ein missratenes experiment
meinerseits war.

Hallo,

„unable to mount hda6“

Das heißt, dass Grub /dev/hda6 nicht mounten kann.
Dies kann zwei Ursachen haben:

Es liegt daran, dass es /dev/hda6 bei dir gar nicht gibt :wink:
Kann es z.B. sein, dass dein Kernel nicht auf /dev/hda6 liegt, sondern auf einer anderen Partition. Vor allem gilt zu beachten, dass Grub bei der (hd0,x) Angabe, bei 0 zu zählen beginnt, also /dev/hda1 entspricht (hd0,0).

Die Partition existiert, aber Grub kann sie nicht mounten, weil er das Dateisystem nicht versteht. Grub kann auf jeden Fall ext2 und ext3 lesen, aber wenn du z.B. ReiserFS, XFS, JFS oder ein anderes Dateisystem verwendest, dann musst du sicher gehen, dass dein Grub dieses Dateisystem beherrscht. Welchen Grub verwendest du denn? Was sagt die Doku die dabei war?

(Also darauf liefs hinaus)
Meine Vermutung nun: Irgendetwas an den ominösen kernel
options mag falsch
gesetzt.

Nö, das wird schon alles passen, aber wenn Grub deinen Kernel gar nicht findet oder das Dateisystem nicht lesen kann, dann kann er ihn auch nicht booten.

Wie mir grade auffällt, verlangt lilo anscheinend gar keine
Angabe des Kernel
Images!?

Das ist richtig, weil LILO den Kernel direkt in den MBR schreibt und von dort lädt. Das hat zwar den Vorteil, dass LILO von Dateisystemen nichts wissen muss, aber dafür muss das dann der Kernel können. Der Kernel darf bei LILO aber auch nicht zu groß sein, weil er sonst nicht in den MBR passt, daher benötigt man bei LILO i.d.R. immer eine INITRD-Ramdisk, wo der Kernel dann die notwendigen Sachen nachladen kann. Auch muss bei jeder Installation eines neuen Kernels LILO neu geschrieben werden, bei GRUB ist das alles meist nicht der Fall.

ich nehme fast an, dass angegebenes kernel image ein
missratenes experiment
meinerseits war.

Nein, Grub muss auf jeden Fall wissen, wo dein Kernel liegt, weil er ihn direkt von der Platte dort lädt.

mfg
deconstruct

Hallo,

„unable to mount hda6“

Das heißt, dass Grub /dev/hda6 nicht mounten kann.
Dies kann zwei Ursachen haben:

Wenn ich die Beschreibung richtig verstanden habe geht es hier schon um linux, nicht um grub.
Und dem KeWrnel wird ja mit root=/dev/hda6 genau dieser String übergeben

Es liegt daran, dass es /dev/hda6 bei dir gar nicht gibt :wink:
Kann es z.B. sein, dass dein Kernel nicht auf /dev/hda6 liegt,
sondern auf einer anderen Partition. Vor allem gilt zu
beachten, dass Grub bei der (hd0,x) Angabe, bei 0 zu zählen
beginnt, also /dev/hda1 entspricht (hd0,0).

Die Partition existiert, aber Grub kann sie nicht mounten,
weil er das Dateisystem nicht versteht. Grub kann auf jeden
Fall ext2 und ext3 lesen, aber wenn du z.B. ReiserFS, XFS, JFS
oder ein anderes Dateisystem verwendest, dann musst du sicher
gehen, dass dein Grub dieses Dateisystem beherrscht. Welchen
Grub verwendest du denn? Was sagt die Doku die dabei war?

Auch hier wieder grub mountet erstmal garnix, es lädt nur den Kernel. Und wenn die Fehlermeldung was von /dev/hda6 sagt ist es ganz sicher kein grub-problem, denn der würde ja hd(0,5) sagen.

Was aber sein kann ist dass der Support für das root-Filesystem (welches ist es denn?) nicht oder nur als Modul einkompiliert ist.
Und wenn man das fest einkompiliert kann man sich das rumgeeiere mit initrd sparen.

Grüße,
Moritz

Es liegt daran, dass es /dev/hda6 bei dir gar nicht gibt :wink:
Kann es z.B. sein, dass dein Kernel nicht auf /dev/hda6 liegt,
sondern auf einer anderen Partition. Vor allem gilt zu
beachten, dass Grub bei der (hd0,x) Angabe, bei 0 zu zählen
beginnt, also /dev/hda1 entspricht (hd0,0).

Also hda6 sollte es schon geben, zumindest kann ich in dem bootbaren System mein altes System aus /dev/hda6 in ein Verzeichnis mounten

Die Partition existiert, aber Grub kann sie nicht mounten,
weil er das Dateisystem nicht versteht. Grub kann auf jeden
Fall ext2 und ext3 lesen, aber wenn du z.B. ReiserFS, XFS, JFS
oder ein anderes Dateisystem verwendest, dann musst du sicher
gehen, dass dein Grub dieses Dateisystem beherrscht. Welchen
Grub verwendest du denn? Was sagt die Doku die dabei war?

Das FS des alten Linux ist das gleiche, wie das des neuen, nämlich ReiserFS und da ich a) das alte im neuen mounten und b) das neue bootbar ist,
nehme ich an, dass weder das alte FS zerschossen, noch Grub jenes nicht versteht.
Zudem scheint der Kernel von
hd0,5/boot…
ja auszuführen, stopt dann aber an einer stelle mit angegebenem nichtmounten :frowning:(

(Also darauf liefs hinaus)
Meine Vermutung nun: Irgendetwas an den ominösen kernel
options mag falsch
gesetzt.

Nö, das wird schon alles passen, aber wenn Grub deinen Kernel
gar nicht findet oder das Dateisystem nicht lesen kann, dann
kann er ihn auch nicht booten.

Wie mir grade auffällt, verlangt lilo anscheinend gar keine
Angabe des Kernel
Images!?

Das ist richtig, weil LILO den Kernel direkt in den MBR
schreibt und von dort lädt. Das hat zwar den Vorteil, dass
LILO von Dateisystemen nichts wissen muss, aber dafür muss das
dann der Kernel können. Der Kernel darf bei LILO aber auch
nicht zu groß sein, weil er sonst nicht in den MBR passt,
daher benötigt man bei LILO i.d.R. immer eine INITRD-Ramdisk,
wo der Kernel dann die notwendigen Sachen nachladen kann. Auch
muss bei jeder Installation eines neuen Kernels LILO neu
geschrieben werden, bei GRUB ist das alles meist nicht der
Fall.

ich nehme fast an, dass angegebenes kernel image ein
missratenes experiment
meinerseits war.

Nein, Grub muss auf jeden Fall wissen, wo dein Kernel liegt,
weil er ihn direkt von der Platte dort lädt.

mfg
deconstruct

Mhh, letzteres ist gut zu wissen, wahrscheinlich war dieses vmlinuz-2.6.6 gar nicht mein Goo Old 2,6er Kernel, sondern irgendein Fehlkonstrukt meinerseits aus Kernelcompilierungsversuchen…
Woraus sich allerdings ein anderes Problem erklären, dieses aber nicht lösen lässt :frowning:(

Ich kann ja an dieser Stelle mal anders herum Fragen:
Kann ich mit Zugriff auf meine alte Partition (lilo etc.) irgendwie den Ursprungszustand wieder herstellen???

MfG
Passer

Was aber sein kann ist dass der Support für das
root-Filesystem (welches ist es denn?) nicht oder nur als
Modul einkompiliert ist.
Und wenn man das fest einkompiliert kann man sich das
rumgeeiere mit initrd sparen.

Grüße,
Moritz

Das root-FS war Reiser, ging vorher mit diesem Kernel, also sollte es doch folgerichtig jetzt immer noch gehen?

Hallo,

Das root-FS war Reiser, ging vorher mit diesem Kernel, also
sollte es doch folgerichtig jetzt immer noch gehen?

Hm. Bootest du mit initrd-Unterstützung?
Ansonsten: mach mal ein
grep CONFIG_REISERFS_FS .config
in deinem linux-src Verzeichnis (meist /usr/src/linux-2.?.*).
Wenn da
CONFIG_REISERFS_FS=y steht weisst du dass dein Kernel es kann.

HTH,
Moritz

Mhh, was immer es bringen soll, ich werde es mal probieren…

Kleine Frage anbei…
Gibt es eventuell eine „grafische“ Rinrichtungshilfe von Grub, wo man sich die komponenten quasi zusammenklicken kann?
MfG
Passer

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Hallo,

Auch hier wieder grub mountet erstmal garnix, es lädt nur den
Kernel.

Natürlich „mountet“ Grub die Partition, wie soll er sonst wissen wo das Kernel-Image ist? Ich kann auf der Grub-Konsole auch mit cat jede Datei anschauen. Und das kann Grub nur machen, wenn er das Dateisystem „versteht“. Er „mountet“ es aber natürlich nicht mit dem „mount“-Programm von Linux, sondern er greift über eigene Dateisystem-„Treiber“ darauf zu.

Und wenn die Fehlermeldung was von /dev/hda6 sagt ist
es ganz sicher kein grub-problem, denn der
würde ja hd(0,5) sagen.

Gut, das ist schon eher ein Punkt, was ich zunächst überlesen habe.Wobei ich da aber auch nicht so sicher wäre, weil es Grub-Versionen gibt, die so gepatched sind, dass sie Linux-Devicepfade verstehen um es dem Benutzer einfacher zu machen.

Was aber sein kann ist dass der Support für das
root-Filesystem (welches ist es denn?) nicht oder nur als
Modul einkompiliert ist.

Das kann sicher sein, wenn der Kernel selbst sagt, er kanns nicht mounten, die Partition aber besteht und nicht defekt ist, dann fehlt ihm mit an Sicherheit grenzender Wahrscheinlichkeit der Dateisystemtreiber.

Und wenn man das fest einkompiliert kann man sich das
rumgeeiere mit initrd sparen.

Jo, initrd suckt sowieso :stuck_out_tongue:

mfg
deconstruct

kann yast das nicht? *duck* (owT)
.

Kleine Frage anbei…
Gibt es eventuell eine „grafische“ Rinrichtungshilfe von Grub,
wo man sich die komponenten quasi zusammenklicken kann?

Es gibt sowas namnes grubconf oder so ähnlich - keine Ahnung was das kann.

LG
Stuffi

.

Keine Ahnung, Suse ist mir zu… doof (obwohl ich manches Mal für sowas wie Yast ganz dankbar gewesen wäre; aber nach nem Semester aufgedrängtem Suse hab ich von selbigem die Schnauze voll)