* Joerg Rossdeutscher: > Ja, das scheint derzeit work-in-progress zu sein. Deswegen hatte ich mir > auch alternativ yaird installiert, aber auch dort scheint ein > vergleichbarer Wurm drin zu sein.
Ich habe danach nochmal getestet: Für meine Konfiguration tut auch yaird. Unklar ist mir dennoch, warum die initrd-tools nicht mehr anerkannt werden: Wenn sie für bestimmte Konfigurationen reproduzierbar Fehler generieren würden, wäre das ja verständlich, aber IMHO nur, wenn yaird und die initramfs-tools dies nicht täten. > Ich habe mir jetzt noch mal den vanilla vorgenommen. Alle Module für das > Board, ATA, SCSI und die beiden SATAs, ext2, ext3 und xfs habe ich fest > einkompiliert. Geht als Würgaround natürlich immer. Mir geht es aber ums Prinzip; die initrd-Erstellung hat korrekt zu funktionieren. Hintergrund: Angenommen, ein Boot-Device raucht ab, etwa ein SCSI-Adapter. Dann ist von einer Live-CD aus eine initrd mit dem Modul für das Ersatzgerät viel schneller erstellt als ein neuer Kernel, wenn man den Treiber fest eincompiliert hatte. > Leider wird es so nichts mit dem geplanten Bugreport, da ich keinerlei > brauchbare Informationen zum Bau einer laufenden initrd geben kann. > "Geht nicht, aber anders" ist einfach zu dünn. Nun ja, wenn Du Deine Konfiguration angibst und einen Bugreport schreibst à la »Damit tut initramfs nicht«, wissen dessen die Autoren wenigstens, daß es vorgekommen ist. Sonst erfahren sie es ja nicht. Ich überlege, ob auch ein Bug gegen linux-source-2.6.14 einen Sinn hätte, in dem Sinne, initrd-tools wieder zu akzeptieren. Grüße, Andreas -- You have an unusual magnetic personality. Don't walk too close to metal objects which are not fastened down. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
