Re: nach apt-get upgrade nicht mehr bootbar
On 17.05.06 15:09:40, Elias Oltmanns wrote:
> Andreas Pakulat <apaku@gmx.de> wrote:
> > On 16.05.06 23:31:59, Dirk Ullrich wrote:
> >> Wenn Du auf Deiner Maschine nur 2.6.x-Kernel hast mit x >= 14,
> >> würde ich ein initramfs empfehlen + udev. Dann braucht man z.B.
> >> keine andere Hardwareerkennung (discover / kudzu / hotplug)
> >> mehr, und ds Booten geht schneller.
> >
> > Mal ne bloede Frage (ich benutze ja keine initrd's) aber was hat
> > initramfs mit der Hardwareerkennung zu tun und wieso funktioniert
> > dasselbe nicht auch mit initrd?
>
> Early userspace hat natürlich etwas mit Hardwareerkennung zu tun - das
> war schließlich einer der Beweggründe für die Einführung dieser
> Konzepte.
Wobei die "Hardwareerkennung" in der initrd/initramfs sich doch wohl
darauf beschraenkt die notwendigen Module fuers mounten der
root-Partition zu laden. Was keineswegs vergleichbar ist mit dem was
udev oder gar discover&Co leisten.
> > Weiterhin: udev _ist_ hotplug, vor einiger Zeit hat udev hotplug
> > komplett ersetzt und uebernimmt seitdem das automagische laden von
> > Modulen fuer alle Geraete die es findet. Und udev arbeitet definitiv
> > genausogut mit einer initrd statt initramfs.
>
> Der Unterschied zwischen initramfs und initrd ist konzeptioneller Art.
> Die Vorteile, die im laufenden System tmpfs gegenüber einer ramdisk
> bietet, stellt nun initramfs während des Systemstarts zur Verfügung.
Aha.
> Das filesystem des initramfs-Archivs liegt nicht wie bei initrd auf
> einem virruellen Blockdevice, sondern im Cache. Damit ist erstens kein
> einkompilieren irgendwelcher Treibers für Dateisysteme notwendig,
Ich nehme mal an du meinst hier "Einkompilieren" im Sinne von "der
initrd beim Erstellen derselben hinzufuegen". Denn auch bei einer initrd
muss kein FS-Treiber im Kernel einkompiliert sein, ausser der fuer die
initrd. Oder gilt letzteres nicht fuer initramfs?
Andreas
--
Try to value useful qualities in one who loves you.
Reply to: