Grub Error 2: Partitionsprobleme?

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
555Nase
Beiträge: 15
Registriert: 15.11.2006 19:36:49

Grub Error 2: Partitionsprobleme?

Beitrag von 555Nase » 13.03.2008 21:10:03

Hi,
das Problem ist zwar nicht direkt Debian bezogen, aber da es sowieso mit grub/dem kernel zu tun hat:

Ich habe mir erfolgreich ein LFS (Linux from Scratch) System gebaut welches von einer chroot umgebung soweit auch funktioniert, bekomme jedoch beim (Direktloading) Boot mit grub die Fehlermeldung:
Error 2: Bad file oder directory type
Soweit ich gelesen habe entsteht diese Fehlermeldung durch eben einem falschen Dateityp, zb durch einem Symlink, dass ist jedoch nicht der Fall...

Ich habe einen NoPaste Log angehängt mit allerlei an Kommandoausgaben, dort ist das dann auch nochmal verifiziert...

Ich habe bereits versucht den Kernel von meinen Debian System (ebenfalls selbst kompiliert, vanilla, bootet allerdings perfekt, keine initrd notwendig) ins LFS System reinzukopieren, dort genau das gleiche, kann also auch nicht am Kernel liegen... An Grub eigentlich genausowenig, da es mit sämtlichen anderen Betriebssystemen keinerlei Probleme hat...

Auf der Partition die ich zu booten versuche hatte ich allerdings vorher ein FreeBSD System, dass ich dann einfach per "mkfs.ext3 /dev/sda2" gekillt habe... Könnte da noch ein Problem bezüglich BSD/DOS Disklabel existieren? FreeBSD bootete per chainloading wunderbar...

Hier erstmal der NoPaste Log:

(Anmerkung: Alles unter einer chroot Umgebung ausgeführt, desweiteren bitte nicht über die Dateibesitzer/gruppen wundern, ich nutze als Packetverwaltungssystem eines dass direkt auf User accs und gruppen basiert, dementsprechend sieht das gesamte System so aus, nur entsprechend mit glibc:glibc, binutils:binutils, kernel-headers:kernel-headers etc... Ich habe auch schon den Kernel direkt mit Rootrechten installiert, das macht auch keinen Unterschied)

http://nopaste.debianforum.de/7641

War erstmal alles was mir auf die schnelle eingefallen ist...

Bei dem fdisk kommando sieht man dass bei der partition bei der BLockanzahl ein + steht, dass kommt vermutlich daher dass es dort einen unallokierten Bereich zu geben scheint, der jedoch niemals Probleme bereitet hat und bei der Partitionierung der Platte "von selbst" entstanden ist, und auch früher hatte ich dieses Verhalten auch...

Bei den grub kommandos wollte ich testweise versuchen grub direkt in den bootsektor der partition zu schreiben, aber scheinbar hat grub mit der partition größere probleme, denn stage{1,2} existieren ja...

Der entsprechende Teil meiner menu.lst auf dem Debian Main System, der sich auf das LFS System bezieht:
root@HDFARE767333:/# cat /boot/grub/menu.lst | grep -A 4 LFS
title LFS 6.3
root (hd0,1)
kernel /boot/kernel-2.6.24.2 root=/dev/sda2 ro
savedefault
Danke schonmal!
cu

debianoli
Beiträge: 4165
Registriert: 07.11.2007 13:58:49
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von debianoli » 14.03.2008 11:31:12

hallo,

ich hatte gestern ein ähnliches Problem, als ich Mandriva von einer erweiterten Partition einbinden wollte. So habe ich das Problem gelöst:

/dev/hda2 ist mein Debian Testing, in dem /boot und grub liegen.

/dev/hda5 ist das Root-Verzeichnis von Mandriva.

1. Ich habe /hda5/boot (Mandriva) nach /hda2/boot/mandriva/boot kopiert.
2. Dann im menu.list den Eintrag anpassen: boot (hd0,1)/boot/mandriva/boot root=/dev/hda5

Also Grub lädt Kernel und intit-Skripte aus dem /hda2/boot/mandriva/boot-Verzeichnis, weiß aber, dass das root-Verzeichnis in der erweiterten Partition /dev/hda5 liegt. Dort erfolgt dann auch der Rest des Hochfahrens.

grüße

oli
------------
Dieses verdammte Linux holt mir nicht mal ein Bier aus dem Kühlschrank!

555Nase
Beiträge: 15
Registriert: 15.11.2006 19:36:49

Beitrag von 555Nase » 14.03.2008 16:52:01

jop, habe mir im Makefile des Kernel eine neues versionssuffix angehängt und ihn dann durchkompiliert und /lib/modules/2.6.24.2-<suffix> und /boot/{config,kernel,System.map}-2.6.24.2-suffix auf die main platte verschoben und meine menu.lst angepasst, dass hats getan... dass suffix eben deshalb da ich den gleichen kernel auch auf meiner debian partition verwende und sich dass vom namen her dann haken würde, spätestens bei /lib/modules ^_^

Die sysV init skripte werden weiterhin von der LFS partition gelesen (was auch gut so ist)

Ist zwar nicht die perfekte Lösung, aber solangs funktioniert und meine platte/partition sonst keine probleme hat solls mir recht sein :)

Danke!

Antworten