hallo!
hjs
mit apt werkeln geht ja leider auch gar nicht mehr;
wie ich eben mit Schrecken feststellen durfte, kann ich auch nicht mehr vom cdrom lesen: "/dev/hdb is not a valid block device" 
sourcen ziehen ohne direkten Netzwerkzugang ist auch eher schwierig,
ich glaube, es ist Zeit für eine neue HD, damit ich das System unbelastet neu aufsetzen kann und die alten Daten/Einstellungen gegebenenfalls noch parat habe.
Kein parallel Betrieb von Kernel 2.4.31-ct-1 und 2.6.15. möglich, aber mit 2.6.12-ct-1
- vdrjoe
- Geschlossen
-
Zitat
Original von hjs
Faktisch war es ursprünglich der Job von udev , dynamisch bei Sysstart zu erkennen , welche HW installiert ist und dafür die devicenodes zu erstellen ...
Lange Rede , kurzer Sinn :
Im Zweifel würde ich einfach den udev Aufruf kicken und makedev verwendenUdev erstellt nicht nur beim Systemstart, udev erstellt auch danach bei jedem Laden von Treibern mit modprobe die passenden Devices in /dev.
Deshalb halte ich es *nicht* für sinnvoll udev zu canceln, da dann /dev nicht mehr mit /sys consistent ist und device nodes existieren für die kein Treiber geladen ist bzw. Treiber geladen werden und kein Zugriff auf die Hardware möglich ist, da kein device node existiert..
-
Zitat
Original von wirbel
Udev erstellt nicht nur beim Systemstart, udev erstellt auch danach bei jedem Laden von Treibern mit modprobe die passenden Devices in /dev.Es agiert dynamisch - keine Einwände
Zitat
Deshalb halte ich es *nicht* für sinnvoll udev zu canceln, da dann /dev nicht mehr mit /sys consistent ist und device nodes existieren für die kein Treiber geladen ist bzw. Treiber geladen werden und kein Zugriff auf die Hardware möglich ist, da kein device node existiert..Da hab ich allerdings Einwände .
Wenn ich so ungeschickt bin , mit makedev nicht alle Devices , die mein Sys hat an zu legen , dann bin ich selber schuld .
Ob Devices existieren , die nicht benutzt werden , da weder Treiber noch HW vorhanden ist , ist ungefähr so interessant fürs Sys-Geschehen , wie die Existenz oder non Existenz einer beliebigen anderen nicht benutzten Datei .HJS
-
Fürs /sys war auch nie die Rede.
-
"Hotplug/udev" ist doch auch nur die Antwort auf die "Benutzer/User"-Welt.
Mal eben schnell per USB nen Stick ran, schwups ist /dev/sda1 da und plöpp wieder raus,
schwups ist /dev/sda1 weg ...Wenn ich ein statisches System habe, wo alles fest und unverändert ist, bzw.
nur langsam und kontrolliert verändert wird, dann kann ich auch komplett
statisch leben, sogar mit einem Mega-Mono-Kernel ohne ModuleGruss,
Bernd -
nur so zwischendurch
neue Platte habe ich noch nicht, aber schon mal auf der alten herum gefuhrwerkt (habe vorher ein Backup von /etc, /var und /lib gemacht)
kurzentschlossen udev per "apt-get remove udev" vonder Platte gebannt,
den Fehler mit dem Cdrom auf ein wackeliges IDE-Kabel zurückgeführt, d
abei die linuxtv-bvb-treiber verloren ,na ja das hatte "apt-get remove udev" auch mitgeteilt, per "apt-cdrom add" die ct-cd in die sources.list, vorher alles andere auskommentiert und versucht udev neu zu installieren, -> can't find package udev
hjs , wie teile ich @MAKEDEV denn mit, dass es eths erstellen soll?
habe unter /dev/net nur den eintrag "-tun", ich denke da sollten auch ethx stehen?,
modprobe kann ee1000 immer noch nicht finden, lsmod zeigt aber einige geladenen Treiber, in welchem paket steckt udev bzw. wo finde ich das und wie binde ich eine lokale Quelle ein (okay da sollte ich erstmal selber suchen
)Gruß
vdrjoe -
Dann sind wir uns ja alle einig , daß es mit makedev auch statisch funzt - ohne udev .
Was diskutieren wir dann ?
HJS
-
udev ist halt einfach der intelligentere Weg..
-
Zitat
Original von vdrjoe
hjs , wie teile ich @MAKEDEV denn mit, dass es eths erstellen soll?Gar nicht
Die "eths" findeste im LFS unter /etc/sysconfig/network-devices .
Wenn da kein ifconfig.ethx drin is , is Essig mit der config .
Unter Debian sollte das ähnlich aussehen .
Wenn du das Modul mit modprobe nich findest , was sagt den find ?
Biste sicher , daß das Ding überhaupt ee1000 heißt ? Im 2.6er heißt es definitiv e1000 .HJS
-
Zitat
Original von wirbel
udev ist halt einfach der intelligentere Weg..Es ist der dynamische Weg - das ist nicht zwingend intelligenter
HJS
-
ja, das module ist definitiv da, (wie bereits mitgeteilt
) in /lib/modules/2.4.31-ct-1/kernel/drivers/ee1000/ee1000.o
ein "exec $1 auf diese Datei (nehme mal an der midnigtcommander macht soetwas, wenn man F2 drückt) fördert auch eine Meldung des Modules zutage, lsmod zeigt aber trotzdem nichts an, und eths gibt es dann auch nicht.da ein "modprobe eepro" aber zumindest eine Warnug wg. alter ISA-hardware bewirkt, hier also tatsächlich versucht wird einen Treiber zu laden, habe ich aus dem Keller, ne reltek geholt, gegen die EE1000 getauscht, und TARA!!!
![:]](https://www.vdr-portal.de/images/smilies/pleased.gif "Freude")
Rechner ist wieder am Netz; aber ich von meinem ursprünglichen Ziel immer noch entfernt, doch wieder etwas dazugelernt! naja ,warum er die EE00 nicht mehr mag, weiß ich immer noch nicht.Ersteinmal Danke für die vielfältige Unterstützung
Gruß
vdrjoe -
Zitat
Original von vdrjoe
@ hjs Ich bin durchaus deiner Meinung, dass ein Kernel alle wichtigen Treiber fest eincompiliert haben sollte. Mein EE1000-Problem zeigt ganz deutlich warum. btw. Die von mir per lsmod angezeigten Treiber waren wohl alle fest in den Kernel integriert. Kann man diesen Umstand, ob ein Treiber fest im Kernel oder als Modul geladen ist irgendwie ablesen (ausser in der zugehörigen Kernel-config) ?
Ähem - da gab es jemanden , der sagte , man könne einen Kernel monolithisch bauen .
Da war abba nich ich , sondern bernie123
Ich bin nur der Meinung , auf udev verzichten zu können , da auch makedev dynamisch angewendet werden kann und eine Dynamik in diesem Bereich nur einige Nodes einspart - sonst nix .
Wenn du aber festgestellt hast , daß nach Inst des 2.6er Kernels nur noch die in den Kernel des 2.4er eincompilierten Module gestartet wurden UND die Module des 2.4er nicht mal nachgeladen werden können , haste die Ursache des Dilemmas doch gefunden .
Zum Einen gibt es besagte /etc/modules[.conf] - die bei Debian auch woanders liegen/heißen könnte - und die Modulnamen haben wohl mit der Kernelsubversion teilweise ne Namensänderung erfahren .
Zum Anderen sind die Modul Lademechanismen zwischen 2.4er und 2.6er anders und das Überinstallieren des 2.6ers machte die Mechanismen des 2.4ers schlicht unbrauchbar .Um das Prob zu lösen , musste rausfinden , welche Files/Scripte/Init~ überschrieben oder gelöscht wurden ( Option -newer bei find ) und dann findeste den/die Übeltäter .
Scheint mir aber der bessere Weg zu sein , einfach vollends auf den 2.6er zu setzen ...
HJS
-
Zitat
Original von vdrjoe
hjs, okay der Bernie123 wars,
aber es scheint mir grundsätzlich nicht falsch zu sein, einen Kernel mit fest eingebundenen Treibern für die existenziellen Funktionen zu haben, zumindest wenn wann schon 'mal den Compilier bemüht, um neue Plugins oder Treiber zum Laufen zu bringen, welche sich nur mit aktuellen Kernel-Headern ncht fehlerfrei übersetzen lassen.
Tip: zcat /proc/config.gz (bei 2.6er Kernel, wenn aktiviert)
gibt die aktuelle kernelconfig des laufenden Kernels aus, da sieht man dann was y/n/m eingestellt ist.
Meine Philisophie ist: je komplexer das System, desto modularer sollte der Kernel sein,
bei Kernelupdates muss man dann die Module natürlich immer mitkontrollieren usw. aber dafür gibt es ja make oldconfig beim Kernelbacken und man muss sich trotzdem mal ein halbes Stündchen Zeit nehmen per make menuconfig alle Optionen der neuen Kernelversion zu studieren, ob man nicht was anders braucht/will/möchte.
Sicherheitskritische Systeme, wie Firewalls usw. kann man dagegen mit gutem Gewissen mit einem fixen Kernel bestücken und dort am Besten auch gleich die Modulfähigkeit deaktivieren, dann kann sich dort wenigstens kein Kernel-Root-Kit einnisten.Gruss,
Bernd -
Zitat
Original von vdrjoe
hjs, okay der Bernie123 wars,
aber es scheint mir grundsätzlich nicht falsch zu sein, einen Kernel mit fest eingebundenen Treibern für die existenziellen Funktionen zu haben, zumindest wenn wann schon 'mal den Compilier bemüht, um neue Plugins oder Treiber zum Laufen zu bringen, welche sich nur mit aktuellen Kernel-Headern ncht fehlerfrei übersetzen lassen.Gruß
vdrjoeDie Einschränkung mit Modulen im Kernel ist , dass du im Fehlerfall das Modul nich reloaden kannst - ein Reboot also unvermeidlich ist .
ferner wird der Kernel grösser - wobei es keinen Unterschied macht , wenn du nur die Module eincompilierst , die du IMMER benötigst .HJS
-
Was steht dann wie, warum in welcher blacklist Datei?
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!