Archiv verlassen und diese Seite im Standarddesign anzeigen : Root unmountbar durch Gerätetreiberrechte?
Hallo!
Ich habe hier ein eingebettetes System auf einem DiskOnChip-Flash-Baustein. Der Kernel ist ein 2.6er mit integriertem DOC- und ext2-Treiber. Als Bootloader kommt Lilo zum Einsatz. Soweit startet das System, ich bekomme nur ein "Kernel panic: Not syncing! VFS: Cannot mount root on "<NULL>" or unknown-block(254,0)".
Der Doc wird aber richtig erkannt und der Treiber meldet, das die Root-Partition dem Device /dev/nftla1 zugewiesen wird. /dev/nftla1 habe ich vom Host-System kopiert.
Da alles mit den Treibern und der lilo.conf zu stimmen schient, habe ich mir gedacht (ich weiss es aber nicht), ob vielleicht mit den rechten dieser device-node was nicht stimmt, sodass der Kernel quasi nicht in der Lage ist, mit dem Gerätetreiber zu kommunizieren. Könnte das sein? Wie müssten die Rechte gestezt sein/werden? Sonst noch eine Idee?
Gruß Stephan
Sind die Rechte für das Blockgerät (major/minor 93,0) 0660 ?
Was sagt: rdev <kernelimage> ?
Vielleicht testest Du mal
rdev -r vmlinuz "93,0"
(prüfe ob 93 als major korrekt ist)
Das "unknown-block(254,0)" läßt mich vermuten, daß dieser Wert im Kernelimage
nicht stimmt.
Gruss,
Wolfgang
Hallo Wolfgang!
Danke für deine Hilfe!
Ich habe mich selbst mit diesem Projekt ins kalte Wasser geschmissen; gar nicht so einfach so ein embedded-linux-system zu entwickeln...
"rdev vmlinuz-2.6.9" ergab "Root device /dev/dm-0". Okay, das passt schonmal nicht...
Bin dann gerade mal nach /dev reingegangen. Entschuldige meine Unwissenheit bzgl. der Rechte... Ein "ls -l nftla1" ergibt "brw------- 1 root 93, 1 19. Dez 17:49". (Was das jetzt als Zahl heisst, hab ich nicht auf dem Schirm... )
Das sollte so auch sein (Major 93, Minor 1). Das device "nftla" hat , bei gleichen Rechten, die Major 93 und die Minor 0.
Ich versuche mal, das Kernelimage mit rdev zu tunen und melde mich dann wieder.
Gruß Stephan
brw------- ist 0600 (zum Mounten als root beim Booten reicht das ;) )
man 2 chmod sagt Dir das bitweise.
Gruß,
Wolfgang
Nachtrag: das Setzen des Root-Device mit rdev ist natürlich ok, und
unabhängig vom Bootloader.
Bei Verwendung von Lilo kann (flexiblerweise) auch eine Zeile
append="root=/dev/nftla1" das gleiche bewirken (bin mir nicht ganz
sicher, ob lilo das gleiche daraus macht wie bei einem "root=/dev/nftla1"
direkt in der lilo.conf, hab lilo eine Weile nicht mehr benutzt)
Hallo Wolfgang!
Schlechte Nachrichten: :(
Ich habe mir "rdev -r vmlinuz-2.6.9 "93,0"" versucht, das Device passend einzustellen, aber bei einem erneuten "rdev vmlinuz-2.6.9" zeigt er mir immer wieder "Root device /dev/dm-0" an.
In meiner lilo.conf stand schon "root=/dev/nftla1", aber ich habe trotzdem noch einmal "append="root=/dev/nftla1"" hinzugefügt; leider ohne Erfolg. Die meldung ist immer noch "...unknown-block(254,0)".
Hast du sonst noch eine Idee?
Gruß Stephan
Nachtrag:
Hab gerade nochmal um absolut sicher zu sein das root-device "nftla" in der lilo.conf eingetragen; aber die Fehlermeldung ist immer noch exakt die gleiche.
Ich würde nochmal prüfen, ob der nftl-Treiber wirklich statisch einkompiliert ist
(also kein Modul).
Block major 254 ist laut <kernel>/Documentation/devices.txt für
"LOCAL/EXPERIMENTAL USE. For devices not assigned official numbers".
Benutzt Du evtl. einen anderen als den Linux-internen Treiber ?
Mehr fällt mir derzeit leider nicht ein.
Gruss,
Wolfgang
EDIT: etwas noch: hast Du devfs einkompiliert ? raus damit, oder benutze
Boot-Option devfs=nomount.
Also, die Treiber sind auf jeden Fall richtig drin. Beim Start sagt er mir ja, kurz bevor er sich raushängt, das er einen 16MB-Doc gefunden hat und die Partition an nftla1 zugewiesen hat.
Ich habe schon den neuen NAND-DiskOnChip-Treiber verwendet; der ist aber noch nicht ganz fertig (dürfte ende beta sein). Der herkömmliche Treiber wird in Zukunft auch nicht mehr in den MTD-Quellen enthalten sein. Der Kernel wurde vor dem Überstetzen auch noch mit den neuesten Updates aus dem CVS gepatcht.
DEVFS ist leider nicht mit drin gewesen.
Ich werde wohl nochmals versuchen, einen GRUB ans laufen zu kriegen. Leider sagte der mir bisher immer "Error 23: Error while parsing number". Ich habe auch schon die Mailing-List angeschrieben, da kam aber nichts zurück :(
EDIT:
Ich werde jetzt so vorgehen: Ich kompiliere den DOC-Kernel meines Rechners neu, diesmal aber mit built-in Treiber. Dann teste ich, ob und wie der Treiber funktioniert. Sollte sich rausstellen, das man irgendwas besonderes beachten muss, werde ich das natürlich auf den embedded-Kernel/FS anwenden.
Ansonsten bleibt leider nur die Methode Module & INITRD.
Das es am Bootloader liegt, mag ich weitgehendst ausschließen.
Gruß Stephan
Also, wenn ich in meinen Entwicklungsrechner-Kernel die Treiber fest einkompiliere, funktioniert alles wie gehabt wunderbar. Der Zugruff erfolgt über MAJOR 93.
Ich habe zum Testen mal die älteren Treiber, die in den Sources als "mißbilligt" angepriesen werden, einkompiliert. Diese sagen mir beim Systemstart nur, das sie alles Mögliche nicht mehr unterstützen und das ich besser die neuen Treiber nehmen soll. Es endet mit nem panic, aber mit "... or unknown-block(253,0)" (anstatt 254,0).
Kann man jetzt sagen, das es definitiv ein Kernel-Fehler ist? Oder könnte es am Bootloader liegen? Der von mir verwendete lilo war speziell für den DOC vorkompiliert und ist schon sehr alt (Jahr 2001...2002)...
Ich tippe eher auf den Kernel, vor allem wegen dem "Kernel panic - not syncing ". Ich hatte diesen Fehler mal bei einem Kernel für meinen PC, wo ein Teil des IDE-Supports fehlte und der Kernel deshalb nicht richtig mit der Festplatte kommunizieren konnte.
Ich weiss im Moment nicht so recht, wo ich weiter machen soll...
Gruß Stephan
Der von mir verwendete lilo war speziell für den DOC vorkompiliert und ist schon sehr alt (Jahr 2001...2002)...
Inwiefern "speziell vorkompiliert" ? Gibt's dazu mehr Infos ?
Ich tippe eher auf den Kernel, vor allem wegen dem "Kernel panic - not syncing "Diese Fehlermeldung sagt leider nichts, sie kommt immer, wenn
das root-Dateisystem nicht gemountet werden kann.
Was genau meintest Du mit dem ewähnten "error 23" von grub ?. Tritt das bei der grub-Installation oder beim Booten auf ? Da grub deutlich flexibler als Lilo ist,
wäre es nicht verkehrt, den zu testen.
Das vorkompilierte lilo beinhalted eine lilo-mtd-binary zum schreiben des Bootsektors und eine passende boot.b. Man findet das Paket im /ptaches-Verzeichnis im MTD-CVS.
Grub ist eine ganz feine Sache, die aber leider nicht funktioniert. Da der DOC ein NAND-Flash-Baustein ist, könnte ein Rechner normalerweise nicht davon starten. Der DOC hat aber einen speziellen Adressbereich, der es Ermöglicht, einen Bootloader mit einem NAND-Treiber zu installieren. Diesen "Bootloader" bezeichnet man auch als DOC-Firmware. Sie ist als binär-Datei beim Hersteller vefügbar. In diesem Fall startet sie zunächst und springt dann in den Lilo-Code rein. Also Quasi BIOS->DOC-Firmware->Lilo-Bootsektor->boot.b->Linux-Kernel....
Die Grub-Patches im MTD-CVS haben die besonderheit, das sie eine neue Firmware erstellen können. Man tauscht also die Binärdatei der Firma mit dieser sog. grub_firmware-Datei aus (soll in /grub/stage1) zu finden sein. Der Startvorgang sieht dann so aus: BIOS->grub_firmware->Linux-Kernel. Ich habe es einmal geschafft, diese zu erstellen. Ich weiss aber nicht mehr, aus welcher Kombination aus patch und grub-sources.
Das Firmware, welches ich erstellt habe, funktioniert mit der Festplatte wunderbar. Ein "root (hd0,0)" liefert irgendwas mit "found ext2-FS" zurück. Ein "root (dc0,0)" brachte immer "Error 23: Error while parsing number".
Ein Tutorial findet man unter: http://lakeshoremicro.com/diskonchip-grub-howto.html
Die neueren Versionen von Lilo haben DiskOnChip-Support schon mit an Bord. Ich habs gerade mal durch den Compiler gedreht, aber er will den Bootsektor nicht schreiben.
Als letzte Möglichkeit sehe ich vielleicht noch U-Boot. Der hat, wie ich gestern zufällig gelesen habe, auch DOC-Support. Das ist dieser Bootloader, wie er auch beim Linux@D-Box2-Projekt verwendet wird.
Okay, das mit dem U-Boot vergessen wir mal schnell wieder; ich habe mir das gerade mal angesehen. Ich habe leider kein Informatik-Studium hinter mir.
Noch so ne kleine Überlegung:
Der Kernel sagt, er kann das root-fs nicht auf "unknown-block(254,0)" mounten. So wie ich das verstanden habe, versucht er also, über MAJOR 254 mit dem Gerätetreiber zu kommunizieren, richtig?
Das ginge dann natürlich nicht, da /dev/nftla1 Major 93 / Minor 1 ist.
"rdev <Kernel>" meldet immer "Root device /dev/dm-0" (was immer das heisst; auch google machte mich da nicht schlauer). Nachdem ich versuche, den Wert mit "rdev -r <Kernelimage> "93,0"" einzustellen und den eingestellten Wert danach wieder auslese, erscheint immer noch "dm-0". Versuche mit vollkommen willkürlich gewählten Zahlen bringen auch immer "dm-0" zurück. Möglicherweise ein Fehler von rdev?
Aber auch das kann normalerweise nicht sein, da wir dem Kernel ja das root-Device in der Lilo.conf mitteilen. Und /dev/nftla1 verweist ja auf Node 93/1.
Wobei wir wieder beim lilo wären. Wenn lilo dem Kernel nicht das passende root-Device übergibt (lilo ist übrigens Ver 21 von 1998), gibts n panic. Wenn man den root-dev-Eintrag aber mit rdev fest ins Kernelimage bauen kann, so müsste es streng genommen "93,1" sein, da "93,0" der DOC als ganzes ist und "93,1" die erste Partition auf dem Kernel.
Ich würde es ja gerne mal mit ner Initrd probieren, aber mein Fedora fummelt da immer RedHat nash mit rein und dann geht gar nichts mehr... :(
Der Kernel sagt, er kann das root-fs nicht auf "unknown-block(254,0)" mounten. So wie ich das verstanden habe, versucht er also, über MAJOR 254 mit dem Gerätetreiber zu kommunizieren, richtig?
Das ginge dann natürlich nicht, da /dev/nftla1 Major 93 / Minor 1 ist.
"rdev <Kernel>" meldet immer "Root device /dev/dm-0" (was immer das heisst;
auch google machte mich da nicht schlauer). Nachdem ich versuche, den Wert mit "rdev -r <Kernelimage> "93,0"" einzustellen und den eingestellten Wert danach wieder auslese, erscheint immer noch "dm-0". Versuche mit vollkommen willkürlich gewählten Zahlen bringen auch immer "dm-0" zurück. Möglicherweise ein Fehler von rdev?
dm ist der Linux device-mapper (kernelsource/drivers/md), bzw. Doku in
Documentation/device-mapper/*.txt. (s. auch man dmsetup)
Hast Multidevice-support (RAID and LVM) einkompiliert ?
Es wäre denkbar, daß der device-mapper meint, das Blockgerät wäre
was für ihn (er wird IIRC vor anderen Blocktreibern abgefragt), und der
nftl-Blocktreiber leer ausgeht.
Prüft das mal (Option CONFIG_MD in der 2.6er Kernel-.config)
EDIT:
Fällt mir gerade ein: prüfe ob Support für den LDM (Windows logical Disk
Manager, aka Dynamic Disks) einkompiliert hast, der basiert IMO auch
auf dem dm...
Das war es leider auch nicht; nichts dergleichen ist einkompiliert. Das einzige was drin ist, ist support für IDE-HD´s und CDROM´s.
Hab gerade nochmals die mailing-list kontaktiert; melde mich auf jeden Fall wenn´s was neues gibt...
Hallo Stephan,
ich habe gestern zufällig mit einem Bekannten gesprochen, der in seiner Firma
schon DOCs von M-Systems auch unter Linux für eigene Steuerungsrechner
eingesetzt hat, und dabei erfahren, daß je nach Chip- bzw. Firmware-Version die
Major-Nummer des Blockgerätes von 93 abweichen kann (als Firmware wurde
Version < 5.0 empfohlen).
Genaueres konnte er mir nicht sagen, da er DOCs zugunsten von Flash aufgegeben
hat (Probleme mit Datenintegrität unter Linux und DOS), er meinte das sei in
einem Buch zum Thema publiziert (OReilly).
Vielleicht findest Du Informationen in dieser Richtung (würde sehr gut zu
Deiner Fehlerbeschreibung passen).
Gruß,
Wolfgang
Nachtrag:
mknod /dev/mtd0 c 90 0
mknod /dev/nftla b 93 0
mknod /dev/nftla1 b 93 1Prüfe, ob das erste dieser Geräte auf dem
/dev/ des Chips vorhanden ist (soll für nftl* nötig sein).
Weiter: beim Formattieren des DOC, hast du die Offset-Option benutzt
(wegen Reservierung von Speicher für den Bootloader) ? Also:
nftl_format /dev/mtd0 OFFSET
Hallo Wolfgang!
Das wäre natürlich eine Möglichkeit..
Mhhh... Diese Firmware ist nur für den Bootvorgang relevant. Auch ohne kann auf den DOC zugegriffen werden. Das sich aber die MAJOR durch die Bootrom-ware ändert, kann ich nicht nachvollziehen; zumal sie nur den richtigen Bootloader laden soll.
Fakt ist: Am Chip selbst kann es nicht liegen, da er im Host-Rechner über 93 angesprochen wird.
Platz für diese Romware habe ich natürlich gelassen. Ich habe nicht nftl_format benutzt, sondern "dformat /win:d800 /s:doc514.exb /y /empty /nodos" und nachdem ich das FS erstellt und lilo installiert habe: "dformat /win:d800 /s:doc514.exb /y /noformat /first".
Diese Variante bringt im Prinzip das gleiche Ergebnis. Das hat auch schonmal funktioniert, wo ich einen 2.4er Kernel in Verbindung mit den originalen M-Systems TrueFFS-Treibern benutzt habe :ugly: .
Aber mal ganz logisch gedacht: :rolleyes:
Der Kernel sagt, er kann nicht auf unknown-block(254,0) mounten. Jemand aus der mailing-list (das war auch die einzige Antwort) hat geschrieben: "You aren't giving a correct 'root=' argument to the kernel.".
Das wiederum kann nicht stimmen:
root=/dev/nftla1
Wenn alles stimmen würde, müsste ja folgendes passieren (korrigiere mich bitte!):
-Lilo hat zugriff auf das ext2-fs und ließt 93,1 aus der /dev/nftla1; wie in der lilo.conf angeführt (93,1 stimmt auch; habe ich per Hand erstellt)
-Dann übergibt Lilo die 93,1 dem Kernel, den er aus /boot in den RAM kopiert hat
-WENN ein Fehler vorliegt, meldet der Kernel "...unknown-block(93,1)"
-ABER der Kernel meldet "...unknown-block(254,0)"
Somit müsste ja im Prinzip a)der Bootloader den Wert falsch auslesen/übergeben oder b)im Kernel dieser Wert verfälscht werden.
Ich wollte deshalb extra eine andere Linux-Version testen. Habe versucht, Gentoo zu installieren (stage1; hat ne halbe Ewigkeit gedauert über die Shell) und als er nach 5 Stunden abgebrochen hat weil er einen Server nicht kontaktieren konnte hätte ich den ganzen Kram am liebsten aus dem Fenster geworfen... :mad:
Ich denke, ich werde mal auf Debian umsatteln; die hatte ich auch noch nie..
Gruß Stephan
PS: Dieses Buch von O´Reilley habe ich als e-book. Auch bei den panic´s habe ich keine brauchbaren Info´s bekommen. Der 2.6er Kernel und die NAND-DOC-Treiber sind ja auch noch *brandneu*...
HALT STOP!
Du hast in deinem letzten Post geschrieben:
mknod /dev/mtd0 c 90 0
Das könnte es sein! Ich habe nur nftla-dev´s erstellt und keine mtd. Diese könnten aber theoretisch sehr wichtig sein für das Funktionieren der MTD-Treiber.
Jetzt habe ich natürlich gerade ein halbes, (nicht lauffähiges) Gentoo auf meinem Entwicklungsrechner und das ganze root-fs-doc gelöscht. :mad: :mad: :mad: :ugly:
Morgen installiere ich wieder die gute alte Fedora und dann werde ich diese verdammten mtd-nodes erstellen.
Drücke mir bitte die Daumen!!
Gruß Stephan (der jetzt ins Bett gehen wird)
Mhhh... Diese Firmware ist nur für den Bootvorgang relevant. Auch ohne kann auf den DOC zugegriffen werden. Das sich aber die MAJOR durch die Bootrom-ware ändert, kann ich nicht nachvollziehen; zumal sie nur den richtigen Bootloader laden soll.
Ich hatte selber nicht mit DOCs zu tun, das hab ich gestern aus dem
Gespräch so verstanden. Deswegen - ich weiß nicht wofür die Firmware
im Detail benutzt wird, auch kenne ich die Tools (dformat) selber nicht.
Der Kernel sagt, er kann nicht auf unknown-block(254,0) mounten. Jemand aus der mailing-list (das war auch die einzige Antwort) hat geschrieben: "You aren't giving a correct 'root=' argument to the kernel.".
Das sah für mich ja auch so aus, deswegen meine erster Vorschlag mit rdev.
-Lilo hat zugriff auf das ext2-fs und ließt 93,1 aus der /dev/nftla1; wie in der lilo.conf angeführt (93,1 stimmt auch; habe ich per Hand erstellt)
-Dann übergibt Lilo die 93,1 dem Kernel, den er aus /boot in den RAM kopiert hat
Nein, so seh ich das nicht. Lilo hat (im Gegensatz zu grub) keine Kenntnisse
von Dateisystemen. Deswegen muß man lilo auch für jedes neue Kernelimage
neu installieren. IMO lädt lilo den Kernel über die Adresse (Offset) seiner
Image-Datei. Lies mal die Dokumentation, die mit lilo (bzw. bei Debian lilo-doc)
in /usr/share/doc/lilo-doc installiert wird (tech.ps und user.ps).
In tech.ps ist ein Diagramm, mit der Belegung des Real-Mode-Speichers.
Die commandline für den Kernel (bzw. deren Adresse) ist dort beschrieben
(0x9D600).
-WENN ein Fehler vorliegt, meldet der Kernel "...unknown-block(93,1)"
-ABER der Kernel meldet "...unknown-block(254,0)"
Der Kernel liest per default den im Image angegebenen Wert für das root-device.
Wenn eines in der commandline angegeben wird, wird dieses stattdesen
genommen.
Ab dieser Stelle bin ich mir nicht sicher (könnte man in den Kernel-Quellen
prüfen ;) ). Meine Annahme: der device-mapper versucht das passende
Blockgerät zu finden, was in Deinem Fall scheitert, obwohl ich das noch
nicht verstehe (ob diese "Zwischenstufe" Kernel 2.6-spezifisch ist ?)
Die Meldung "unknown Blockdevice" lese ich als "keiner meiner Treiber fühlt
sich für das angegebene Gerät zuständig".
Mußt du denn 2.6 benutzen ?
Habe versucht, Gentoo zu installieren (stage1; hat ne halbe Ewigkeit gedauert über die Shell) und als er nach 5 Stunden abgebrochen hat weil er einen Server nicht kontaktieren konnte hätte ich den ganzen Kram am liebsten aus dem Fenster geworfen... :mad:
Ich denke, ich werde mal auf Debian umsatteln; die hatte ich auch noch nie..... ich hab letzteres seit knapp 10 Jahren :D (und verkneife mir Bemerkungen
zu Gentoo :p )
Was ich machen würde: ein paar printk() in den Quellen des device-mappers
drivers/md/ und des nftl-code drivers/mtd/nftl* (speziell die init-Funktionen)
einpflanzen. Sollte in wenigen Stunden klärbar sein.
Viel Erfolg,
Wolfgang
PS: hab Deinen letzen Post zu spät gesehen: schön wär's :)
Okay, ich werde nachher mal versuchen, das mtd[N] zu erstellen.
Sollte das nicht klappen, versuche ich einen anderen Bootloader zu installieren (Grub oder RedBoot geht glaube ich auch). Mein Bauch sagt mir irgendwie, das der Bootloader nicht passend funktioniert.
Wenn er dann immer noch nicht hoch geht, muss es ja irgendein Kernel-Fehler sein. Dazu könnte ich mal den Kernel auf meinem "Hauptrechner", wo Suse 9.0 drauf ist, kompilieren. Ebenfalls sehe ich mal nach, ob auf dem Entwicklungsrechner irgendein Device unter MAJOR 254 eingetragen ist.
Der Device-Mapper oder sonstwas (Volume-manager, RAID, ..) ist im Kernel definitiv nicht vorhanden.
Gruß Stephan
Hallo Wolfgang!
Kommen wir der Sache doch schon ein ganzes Stück näher!
Ich habe den Kernel jetzt auf meiner Suse-Maschiene erstellt. Diese läuft, anders als die Fedora, ohne Device-Mapper. Direkt nach dem Kompilieren habe ich mit rdev das Root device abgefragt. Es kam /dev/hda7 zurück.
Jetzt habe ich eben das Root-FS neu erstellt. Auch habe ich die mtd und mtdblock nodes erstellt. Aber die sind es nicht. Er hängt mit "...unknown-block(3,7)". Und jetzt schau mal nach, über welche MAJOR hda angesprochen wird ;)
Jetzt sag mal, bist du dir sicher das der Befehl "rdev -r <Kernel> "MAJOR,MINOR" richtig ist? Ich habe mal gegoogelt und folgendes entdeckt:
-r Image [Key]
zeigt oder verändert die Einstellungen zum Laden einer RAM-Disk von Diskette. Die gleichen Einstellungen können auch durch die Kernelargumente load_ramdisk, prompt_ramdisk und ramdisk_start auf dem Bootprompt vorgenommen werden. Die Schlüsselzahl wird nach folgender Formel berechnet:
Quelle: http://www.linux-ag.de/linux/LHB/node140.html#SECTION005170000000000000000
Halten wir fest: Der Bootloader taugt nix.
Wenn wir das root-dev im Kernelimage erfolgreich ändern, müsste er gehen. Ich gehe jetzt mal ganz stumpf hin und verpasse "nftla1" die "3,7". Mal sehen was passiert. (Soll natürlich keine endgültige Lösung sein).
Gruß Stephan
EDIT:
Die Variante mit 3,7 funktioniert nicht (wäre auch zu schön gewesen). Damit erscheint nichtmal der lilo-screen. Wir müssen also eine Möglichkeit finden, den Wert im Image zu ändern.
Ach ja: Frohes Weihnachtsfest :)
Jetzt sag mal, bist du dir sicher das der Befehl "rdev -r <Kernel> "MAJOR,MINOR" richtig ist?
Aua, böser Tippfehler. Das heißt -R (Großbuchstabe), das kleine -r
steht tatsächlich für ramdisk (-> man rdev). Sorry!!
When using the rdev command, the root_device parameter might be something like:
/dev/hda1
/dev/sda2
/dev/ida/c0d0p1
One may also specify the device by a comma-separated pair of decimal integers
major,minor.
Frohes Fest,
Wolfgang
Hallo Wolfgang!
Es geht auch "rdev <image> /dev/nftla1", wenn der Eintrag auf dem Host-System vorhanden ist.
Habe nun gerade versehentlich meinen Bootloader verschrottet. Statt des GRUB-Screens kommt nun "LI"... hab ich mich vorhin wohl vertippt.
Ich komme noch auf mein System (Rescue-CD). Wie kann ich den Grub wieder installieren?
Gruß
Ich komme noch auf mein System (Rescue-CD). Wie kann ich den Grub wieder installieren?
Falls vorhanden: grub-install --recheck /dev/<gerät>
Alternativ: interaktiver Modus von grub:
# grub
grub> help
grub> root /dev/nftl<TAB>
grub> kernel /<TAB> <Optionen>
grub> setup (hdX)
grub> quit
<TAB>(Taste) bietet Autocompletion. Achte darauf, daß die map-Datei
von grub korrekt ist (/boot/grub/device.map).
hdX entsprechend dem Eintrag des DOC in der device.map.
Weitere Möglichkeit für interaktiven grub: grub-boot-floppy erstellen
(via Internet downloadbar, oder Image von der Distribution)
Gruß,
Wolfgang
EDIT: falls es um das SuSE-System geht, ignoriere die Verweise auf den DOC ;)
Habs wieder am laufen :)
War gar nicht so einfach (->VolumeManager).
Gut, ich bau die Software nochmal auf den DOC und dann melde ich mich natürlich gleich wieder. So wie es aussieht, benötige ich ja überhaupt keinen Bootloader. Man müsste den Kernel stumpf in eine Binär-Partition packen können....
Okay, bis nachher dann...
Gruß Stephan
JAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A,
100000000 Dank Wolfgang! :) :) :)
Hab das root-device mit "rdev vmlinuz-2.6.9 /dev/nftla1" festgelegt und er geht. :eek:
Super Sache.. jetzt kann ich den Rest in aller Ruhe fertig machen.
Gruß Stephan
Das freut :D
Gruß & erholsame Feiertage :)
Wolfgang
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.