sqeenz UUID und eigener Kernel

[BrianFFM]

Hallo alle

nachdem ich mein System auf sqeenze hochgefahren habe hat er mich gefragt ob er UUID verwenden soll .. Jo und soweit so gut., Ich habe einen eigenen Vanilla Kernel, dessen .config schon einige Jahre immer weiter überlebt und vererbt wird.

Nun habe ich das Problem, dass plötzlich meine Swap Partition nicht mehr erkannt wird. beim Nachforschen habe ich gesehen dass unter /dev alle meine Devices fehlen sda sda1 sda2 usw .. google hat ne menge dazu ... unter /dev/disks sollte was sein, nur das gibt es bei mir auch nicht.

ich bin sicher, das es mit dem Kernel zu tun hat. denn mit dem Debian Standard kernel funzt es .. hat jemand eine Idee.

liebe Grüße, Brian

[guennid]

Überprüf mal das Modul evdev (CONFIG_INPUT_EVDEV). Daran hat's bei mir gelegen. Siehe hier

[BrianFFM]

danke für die Antwort ..

CONFIG_INPUT_EVDEV=y

scheint es nicht zu sein

ich habe gelesen das der File initrd beim Boot dazu unbedingt nötig ist .. was ist denn da dran ?? ich habe einen vanilla lernel der keine Module laden kann sondern alles fest drin hat

[guennid]

Tja, viel weiter weiß ich dann auch nicht. udev geprüft, wie von cosmac angegeben?
Was die initrd angeht: eine initrd.img brauchst du nicht, wenn bestimmte Module, die beim Booten benötigt werden, fest im kernel sind. Frag mich jetzt nicht, welche genau das sind, darum habe ich bei meiner config vor Jahren das letzte Mal gekümmert. ALLES brauchst du übrigens auch bei einem vanilla kernel nicht fest einzukompilieren.

Grüße, Günther

[BrianFFM]

jo schon klar dass nicht alles fest einkompiliert werden muss .. ich will nur das der kernel nicht in der lage ist nachträglich module zu laden .. da die kiste im Inet steht und das ein sicherheits-risiko wäre ..

[cosmac]

hi,

auf so einem wohldefinierten System bringt der UUID-Trick wenig. Wenn du wie gewohnt direkt die Devices beim Bootloader und in /etc/fstab einträgst, sollte es wieder laufen. Soweit ich weiss, funktioniert die Auflösung UUID->Device nur mit initrd, weil das zu komplex ist, um es in den Kernel einzubauen. Es muss für das root-Device aber passieren, bevor der normale Userspace zur Verfügung steht...

OT, weil es in diesem speziellen Fall nicht lohnt:
Als Kompromiss könnte man das root-Device direkt eintragen und den Rest per UUID in die fstab. Andererseits haben module und initrd nichts miteinander zu tun, man kann das eine, das andere oder beides haben. Ich behaupte mal, die UUID->Device-Auflösung ist eine der ganz wenigen sinnvollen Anwendungen der initrd :mrgreen:

Edit:
Fehlende Devices könnten daran liegen, dass einzelne Kernel-Schnittstellen zu alt sind für die udev-Version aus squeeze. Hauptverdächtig ist CONFIG_SYSFS_DEPRECATED, das sollte jetzt =n sein.

Mittelfristig würde ich auf devtmpfs umstellen. Damit wird /dev vom Kernel dynamisch erzeugt und die Devices dadrin passen immer genau zur vorhandenen Hardware und den Treibern -- und zwar ohne udev und ohne statisches /dev. udev wird dann nur noch für Rechte und Gruppen gebraucht, die je nach Distribution unterschiedlich sind. Das kann auf einem Server aber auch durch ein paar Zeilen in /etc/rc.local geregelt werden.

Die evdev-Geschichte ist direkt tragisch: das Modul ist doch eher für Mäuse und Tastaturen zuständig und nicht an allem schuld ;)