Andreas Vögele schrieb: > Marco Simon schreibt: > > >> Andreas Vögele schrieb: >> >>> Marco Simon schreibt: >>> >>> Ich denke nicht, dass etwas fehlt, sondern dass die initrd beim >>> Wechsel des Root-Dateisystems von der RAM-Disk zum Dateisystem auf der >>> Festplatte etwas falsch macht. >>> >>> >> In wiefern ist denn die initrd daran überhaupt noch beteiligt ? Es >> ist doch so, dass der Bootloader den Kernel läd, dann die Ramdisk, >> dort das linuxrc-Script anstößt (das dann halt irgendwas macht, >> z.B. Module nachladen), danach wird die initrd dann um- oder >> demounted und das root-fs gemountet. D.h. die initrd kann doch da >> gar nichts mehr falsch machen, da es eine Frage des Bootmanagers ist >> - oder ? >> > > Nein, das ist keine Frage des Bootmanagers. Der Kernel verwendet > zuerst ein Dateisystem in der RAM-Disk als Root-Dateisystem. linuxrc > muss das eigentliche Root-Dateisystem mounten und danach auf dieses > Root-Dateisystem umschalten. Suche in linuxrc bzw. dem Quelltext, > falls linuxrc ein ausführbares Programm sein sollte, mal nach > pivot_root bzw. /proc/sys/kernel/real-root-dev. Ich nehme an, dass > direkt vor oder nach dieser Stelle etwas schief läuft; zum Beispiel > beim Mounten des eigentlichen Root-Dateisystems oder danach beim > erneuten Mounten von /dev. > Ok, das ändert die ganze Situation dann ein wenig. Denn damit das die initrd sich aktiv um das mounten des zukünftigen Systems kümmer muss, hatte ich bisher nicht gerechnet. Nach dem was ich bisher gelesen hatte - wirkte es immer so, als hätte die initrd selbst aktiv mit dem mounten seines Nachfolgers wenig zu tun. Offensichtlich missverstanden. Evtl. ist das schlicht die Info die mir Fehlt um das Problem nachvollziehen zu können. Ok - nochmal eine "dumme" Rückfrage: Wenn die initrd ohnehin für das mounten verantwortlich ist - Warum versucht dann der Kernel überhaupt noch das (erreichbare) root-fs zu mounten - und meckert dann, das er das nicht kann ? > >>> Möglicherweise hast Du beim Erzeugen der initrd einen falschen Pfad >>> angegeben. Vielleicht klappt es mit /dev/mapper/lvm_main-lv_root >>> anstelle von /dev/lvm_main/lv_root. >>> >>> >> Welche Pfad meinst du, den ich falsch angegeben haben könnte ? >> > > Den Pfad, der in linuxrc verwendet wird, um das eigentliche > Root-Dateisystem zu mounten, bevor pivot_root aufgerufen wird. > > Unterstützt Dein Kernel devfs? Verwendet die initrd devfs? > nein - weder noch. > >>> Abgesehen davon würde ich auf Marcs Rat hören und das Root-Dateisystem >>> nicht mit LVM verwalten. Das macht nur Probleme, falls die initrd mal >>> beschädigt werden sollte und die Kernelmodule für LVM nicht geladen >>> werden können. Ich spreche da aus eigener Erfahrung :-) >>> >>> >> Ich hab seit ca. 4 Jahren mehere Server auf LVM laufen (inkl root). >> Hatte dabei praktisch auch noch nie solche Probleme wie hier >> beschrieben gehabt. Dort konnte das root immer direkt vom Kernel >> gemountet werden. Ich hab eueren Hinweis zur Kenntniss genommen - >> komme aber in diesem Fall nicht um root auf lvm herum. Abgesehen >> davon möchte ich gern verstehen, _was_ hier nicht so läuft, wie ich >> es erwartet hatte ;) >> > > Wenn die Dokumentation des Programms, das Du zum Erstellen der > RAM-Disk verwendet hast, nicht ausreicht, wird Dir nichts anderes > übrig bleiben, als einen Blick in linuxrc zu werfen. Anders > ausgedrückt: RTFS :-) > Die linuxrc ist nicht das Problem ;) Die kenne ich ja - und hab sie ja auch schon selbst um den testmount und ls von /dev/lvm_main/lv_root ergänzt. Erstellt habe ich die initrd ursprünglich mit lvmcreate_initrd - was auch auf den anderen Systemen imho bisher immer ausgereicht hat. Einen mount des designierten root-fs oder pivot_root gibt es in dieser intrd nicht, und gab es auch nie. Was mich allerdings noch verwundert: Wenn die initrd sich aktiv um das mounten ihres Nachfolgers kümmern muss... ... warum kann ich dann problemlos mit der gleichen initrd und dem gleichen Kernel booten, wenn ich dem Kernel nur /dev/hda2 als root= übergebe ?? Die initrd kümmert sich ja dann genausowenig um das mounten des Nachfolgers. Würde das nicht deiner Aussage wiederprechen ? btw: Hast du interesse diese Punkte mit mir außerhalb der Liste zu diskutieren und nur die Ergebnisse wieder hier einzubringen ?
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature