initrd rauswerfen

[guennid]

Bevor ich lange rumprobiere: Kann mir jemand sagen, was alles ich in der kernel-config zum etch standard-kernel (2.6.18 ) abschalten muss, um selbigen ohne initrd neu zu kompilieren?

Grüße, Günther

[Spasswolf]

Es ist nicht so sehr eine Frage, was du abschaltest, als eine Frage was du fest in den Kernel kompilierst, damit der auch bootet.
Du musst den Treiber für den Controller, an dem deine /-Platte hängt fest einbinden (und dazu auch den IDE oder SCSI Support), sowie dein /-Dateisystem.

[guennid]

Das ist mir klar, aber in der config des standard-kernels ist die initrd halt drin und ich möchte wissen, welche Module ich wo rauskicken muss, damit der kernel läuft. soweit ich mich erinnere, ist es mit

Code: Alles auswählen

CONFIG_BLK_DEV_INITRD

nicht getan.

Grüße, Günther

[Spasswolf]

Rauskicken muss du gar nichts, mein momentaner Kernel bootet ohne Initramdisk hat aber CONFIG_BLK_DEV_INITRD=y in der .config, weil ich das wohl übersehen habe.

[finupsen]

welchen vorteil hat man denn dadurch ?

Ich hab das bis vor ca. 2 jahren auch immer gemacht. Einen unterschied zu jetzt (mit initrd und kernelmodule)
kann ich nicht feststellen. Mein debian fühlt sich immer noch gleich an

Die zeit der 1,44MB-Disketten sind auch vorbei ... also, warum ?

[Spasswolf]

Also ich war immer zu faul mich mit dem Bauen einer Initramdisk auseinanderzusetzen.

[guennid]

Ich mag kein udev, das Teil bringt mir nichts und macht nur Probleme. udev wirst du aber beim standard-kernel nicht los, weil dieser initrd verlangt, was widerum udev verlangt. Ist so ein bißchen wie bei win

Grüße, Günther

[finupsen]

Also ich war immer zu faul mich mit dem Bauen einer Initramdisk auseinanderzusetzen.

ja, stimmt. Dazu wäre ich auch zu faul. Deswegen lasse ich mir die bauen, mit "make-kpkg --initrd ... "...

[guennid]

Rauskicken muss du gar nichts, mein momentaner Kernel bootet ohne Initramdisk

Und bei der Installation verlangt er keine initramfs-tools?

Grüße, Günther

[Spasswolf]

Ich hab den auch Kernel nicht mit "make-kpkg --initrd" kompiliert, sondern nur mit "make-kpkg".

[cosmac]

hi,

Ich mag kein udev, das Teil bringt mir nichts und macht nur Probleme.

meine Worte

udev wirst du aber beim standard-kernel nicht los, weil dieser initrd verlangt, was widerum udev verlangt.

nicht direkt, der Standard-Kernel braucht eine initrd. Die wird normal
von initramfs-tools gebaut. Das hängt von udev ab. Man kann die
initrd aber auch von yaird bauen lassen und yaird braucht kein udev.

[finupsen]

ok, also dann hätten wir jetzt 2 argumente:

1. faulheit
2. Ist so ein bißchen wie bei win

Gibt es noch andere argumente ?

Nochmal die frage:
Welchen vorteile verschaffe ich mir, wenn ich: 1. sämtliche benötigten module
fest in das kernel einbaue und 2. wenn ich auf initrd und udev verzichte ?

BTW: bitte nicht als geflame verstehen, ich will das wirklich wissen

[guennid]

Man kann die initrd aber auch von yaird bauen lassen

Das weiß ich.
Herr hilf! Ich brauche keine initrd und ich brauche schon gar kein udev

Welchen vorteile verschaffe ich mir, wenn ich: 1. sämtliche benötigten module
fest in den kernel einbaue

Das ist hier eigentlich nicht das Problem

und 2. wenn ich auf ... udev verzichte

Schont deine Nerven

Im Ernst: noch nie Probleme wegen udev gehabt? Ei, dann würd' ich doch dabei bleiben. Man muss ja nicht ohne leben.
udev bringt es fertig, dass USB-Sticks, die jahrelang ohne udev funktioniert haben, mit udev nicht mehr funktionieren. Es kann dir deine Netzwerkkonfiguration durcheinanderbringen. Such mal mit Stichwort udev. Da kriegst du eine Menge Beispiele, was das Teil alles vermurksen kann. "Kann" wohlgemerkt!

Grüße, Günther

edit:
@Spasswolf: OK dann check ich das mal mit dem controller, IDE und SCSI und lass die initrd-Option bei der Kompilation einfach weg. Wir werden sehen.

[cosmac]

Günther, ich bin ganz deiner Meinung. yaird hab' ich nur erwähnt,
weil du auf die Paket-Abhängigkeiten geschimpft hast. Natürlich
wollen wir beide kein udev und natürlich brauchen wir keine initrd
und meine Kernel laufen auch ohne.

Laß doch einfach den initrd-Support raus und gut ist.

Vor allem kommt es doch auf die Anwendung an. Wenn ein System
möglichst auf jeder Hardware laufen soll, ist eine initrd die Lösung.
Dann werden genau die passenden Module nachgeladen und man
hat ein flexibles System mit kleinem Kernel. Daß udev (noch) nicht
alle Hardware kennt, nimmt man dabei in Kauf.

Ganz anders sieht's aus, wenn ich einen ganz bestimmten Rechner
optimieren will oder aus anderen Gründen einen speziellen Kernel
bauen will. Dann kann ich gleich die zum Booten nötigen Module fest
einbauen. Eine initrd ist dann schlicht unnötig.

Wenn ich dann noch alle für den Rechner nötigen Module fest einbaue,
kann ich den kompletten Modul-Mechanismus weglassen. Dann kann
ein Root-Kit keine Module nachladen. Ich glaub allerdings nicht, daß
das viel hilft. Module von Hand zu laden hilft aber bei der Fehlersuche.

Mit einem Kernel ohne initrd (oder einer mit yaird gebauten) kann
man dann frei entscheiden, ob man udev installieren will oder nicht.
Gnome- oder KDE-Benutzer mögen es wohl, daß ein Icon erscheint
wenn man ein USB-Gerät ansteckt - meinetwegen. Mir ist ein
"mount /dev/sda1 /mnt" lieber, das funktioniert wenigstens.

Ich kenne keine Funktion von udev, die mir irgendwie helfen könnte.
Warum sollte ich also eine zusätzliche Fehlerquelle einbauen?

[guennid]

Mir ist ein
"mount /dev/sda1 /mnt" lieber, das funktioniert wenigstens.

Ich kenne keine Funktion von udev, die mir irgendwie helfen könnte.
Warum sollte ich also eine zusätzliche Fehlerquelle einbauen?

Da sind wir Brüder im Geiste

Du hast doch meinen Stoßseufzer "Herr hilf" hoffentlich nicht als Kritik aufgefasst?
Ich werd's bei Gelegenheit so machen, wie von dir und Spasswolf beschrieben. Auf meinen eigenen Rechnern verwende ich sowieso einen von Grund auf selbst aufgebauten kernel. Der hier soll auf anderer Leut Maschinen laufen. Dafür habe ich keine Zeit, den kernel gründlich durchzukomponieren, und ebensowenig für das dann zu erwartende udev-Geeiere. Deswegen: Standard, aber ohne initrd.

Grüße, Günther

[finupsen]

Also fassen wir zusammen: Die frage, ob udev oder nicht, ist eine ideologische frage, oder anders, mir entstehen
keinerlei nachteile, wenn ich udev benutze, ausser das es manchmal nicht funktionieren könnte (mittlerweile selten,
tendenziell wirds besser) und das, wenn ich ein usbstick einstöpsel, ein icon auf meinem desktop erscheint

fazit: wenn es nicht unbedingt nötig ist, die initrd und udev so lassen, wie es ist ... (IMHO)

edit: Diese fazit muss neu überdacht werden, sollte doch noch ein totschlag-argument folgen

[Athlux]

Gnome- oder KDE-Benutzer mögen es wohl, daß ein Icon erscheint
wenn man ein USB-Gerät ansteckt - meinetwegen. Mir ist ein
"mount /dev/sda1 /mnt" lieber, das funktioniert wenigstens.

Dafür ist aber nicht udev sondern hal zuständig. Wenn man hal nicht installiert kommen auch keine Icons auf den Desktop wenn man das Device anstöpselt.

Meine Probleme beginnen da eher mit hal.

Ich kenne keine Funktion von udev, die mir irgendwie helfen könnte.
Warum sollte ich also eine zusätzliche Fehlerquelle einbauen?

Das ist eine gute Frage.

Ich habe auch lange kein udev auf meinem Rechner installiert.

Die Skripte sind nicht grad benutzerfreundlich. Ansonsten gab es früher mal Probleme mit dem nvdia Treiber. udev benennt auch eventuelle Netzwerk-Interfaces um. Aber das ist auch kein Problem, dass man nicht durch das Editieren einer Textdatei beseitigen kann.

udev ist bei mir nur installiert, weil der dann beim Einstecken meiner USB-Platte erkennt welche es ist (Ich habe 2 Stück) und dann entsprechend das jeweilige Backup startet.

Das könnte man eventuell auch anders lösen, von daher sind die Vorteile für mich eigentlich auch mininmal.
Aber jedem seine eigene Entscheidung. Aber wie schon gesagt für die Icons im Dateimanager ist hal zuständig und nicht udev.

[cosmac]

hi,

aber funktioniert hal ohne udev oder wie bekommt hal das mit?
Doch nicht etwa mit dem alten hotplug? Oder noch schlimmer,
mit einer dritten Technik?

Oder ist hotplug etwa noch aktuell? Damit könnte man ganz
einfach eigene (z.B.) Backup-Scripte bauen.

udev benennt auch eventuelle Netzwerk-Interfaces um. Aber das ist auch kein Problem, dass man nicht durch das Editieren einer Textdatei beseitigen kann.

Na klar kann man alles reparieren, aber wie wär's, wenn man
es garnicht erst kaputt macht?
Ich bleib' dabei, der udev-Aufwand steht in keinem Verhältnis zum
Nutzen. Das erinnert mich an eine alte chinesische Bauernregel:
Computer lösen Probleme, die wir ohne sie garnicht hätten.

[shevegen]

Ich mag kein udev, das Teil bringt mir nichts und macht nur Probleme.

Da scheinst du nicht der einzige zu sein... was auf diversen IRC Channels ab und zu über udev geflucht wird ist unglaublich

Manchmal fragt man sich, ob Affen in der Kernelentwicklung die Entscheidungen treffen.

[Athlux]

Wenn man in die Abhängikeiten schaut dann sieht man das hal auf udev aufsetzt.

Ansonsten hat jeder Automatismus natürlich seine Fehler. Glücklicherweise wird man weder zu hal und udev gezwungen.

Wobei es schon seine Vorteile hat wenn man einfach einen USB-Stick einstecken kann und gleich alles im Dateimanager erscheint. Sehr praktisch auch dann wenn mehrere Leute mit dem Stick kommen weil sie etwas interessantes auf dem Notebook gesehen haben, dass sie jetzt auch unbedingt haben wollen. Wenn man da mal 10 Sticks die alle unterschiedlich partitioniert sind nacheinander an den Rechner steckt wünscht man sich was automatisiertes.

[crazyed]

Ich will auch meinen Vorkriegs-VW-Käfer mit dem nicht synchronisierten Getriebe wieder haben...

Nee, mal im Ernst. udev, hal & z.B. /etc/init.d/modules sind eingerichtet worden damit banale Sachen automatisch eingebunden werden. Daß es bei zig-tausend verschiedenen Hartware-Kombinationen mal hier und da zu Schwierigkeiten kommen kann ist doch verständlich.
Da ich grade an einem Gentoo sitze hier mal ein Auszug aus der /etc/udev/udev.conf

# Implictly blacklist the modules listed in modules.autoload
# so that udev (with coldplugging) does not load them
# but /etc/init.d/modules will do later.
# This can guarantee correct load order needed for
# some subsystems (like alsa, v4l, dvb, ...).
# It should be generally safe.

Also kommt es schon auf die Reihenfolge der zu ladenden Module/Hartware an, ob auch die Dienste erfolgreich eingebunden werden. Was nützt es die Netzwerkverbindung zu starten bevor die Netzwerkkarte eingebunden wurde...

Leider hab' ich solche Probleme nicht, auch bootet mein Kernel mit initramfs, keine initrd mehr nötig. Was mich viel mehr nervt ist, daß ich mich durch den Kernelkram kämpfen muss um nachzusehen ob für meine Hartware Neuerungen enthalten sind. Ich bau meine Kernel immer selbst.

[guennid]

Sehr praktisch auch dann wenn mehrere Leute mit dem Stick kommen

Dagegen kann ich nicht anstinken, weswegen ich das Gespann + KDE auf meinen Bibliotheksrechnern auch laufen lasse, aber auch nur da

Grüße, Günther

[storm]

Es ist mir immer noch absolut unerklärlich, warum ihr/so viele andere Leute auf udev rumhacken. devfs ist ein toter Ast, udev ist die Entwicklung, die fortgeführt wird. Gründe gibt es genug und udev ist die konsequente Umsetzung davon. Wird udev mit der richtigen Konfiguration geliefert (bei debian und anderen aktiven Distris eigentlich mittlerweile der Fall), läuft der ohne jeglichen Eingriff im Hintergrund. Wer trotzdem eigene Anpassungen machen möchte, sollte die Doku lesen - das trifft aber auf fast jede Software zu, die komplexer als netstat (nur als Beispiel *g) ist.
Hier läuft die Software seit den Anfängen, natürlich hat es ein paar fiese Punkte gegeben, bei welchen man arge Zweifel bekommen hat (etwa die Syntax-Umstellung der Konfiguration). Aber die Kontrolle über devices und ihr Zusammenspiel mit kernel/treiber, die man in die Hand bekommen hat, möchte ich nicht mehr missen.

Initrd? Auch so ein veralteter Kram, den eigentlich keiner weiter braucht. Mir fällt i.A. nur splashscreen ein, dass initrd vorraussetzt, aber das ist Spielkram (und in Zukunft wird der Zwang auch mal wegfallen). Und das Installations- bzw. Distri-Kernel sowas (noch) haben müssen, ist klar. Bei der immer weiter steigenden Rechenleistung wird irgendwann mal der Wunsch aufkommen, gleich bei der Installation eines Systems einen fertig angepassten Kernel zu erstellen, zielgenau auf die vorhanden Hardware abgestimmt. Prinzipiell könnte man das jetzt schon machen, die Grundlagen existieren schon (zB udev). Es mangelt noch an der korrekten Erkennung bzw. Unterstützung von Hardware.

ciao, storm

[KBDCALLS]

Naja devfs gibts es schon längere Zeit nicht mehr im Kernel . Das ist schon seit 2.6.13 rausgeflogen , wenn ich micht nicht irre. Und das udev nicht ganz astrein war läßt sich auch nicht bestreiten. Stellenweise wars so das es komplete verworfen worden ist, und man einfach von einer Vorversion aus weitergemacht hat.

[guennid]

@storm
Du musst dich darüber nicht aufregen.
Das Problem ist einfach, dass das Teil für mich wahrscheinlich viel zu gut ist.
Also beruhig dich, mit udev ist alles in Ordnung. Ich bin es, der zum Doktor muss.

Grüße, Günther