NIC wird nicht unterstützt - Kernelpatch

[flowie]

Hallo da draußen!

Mein aktueller Kernel auf Dedian Sarge: uname -a ergibt 2.6.8-2-686-smp
Der Server ein Dual-XEON von Krenn.

Ein apt-get upgrade zeigt folgendes: (die Source-List ist auf sarge eingestellt)

# apt-get upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut... Fertig
Die folgenden Pakete werden aktualisiert:
initrd-tools kernel-image-2.6.8-2-686-smp kernel-source-2.6.8 libblkid1 libbz2-1.0
libcomerr2 libgnutls11 libgpmg1 libldap-2.2-7 libnss-db libpcre3 libss2 libusb-0.1-4
libuuid1 sysklogd
15 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 51,2MB Archive geholt werden.
Nach dem Auspacken werden 135kB Plattenplatz freigegeben sein.
Möchten Sie fortfahren? [J/n] n

Mein Problem:
Der Server verfügt über zwei NIC's, die auch beide nutzen muss. Die erste macht keine Probleme, aber die zweite ist eine GB-Nic mit Marvell Yukon Chipset/SysKonnect. Soll eine PCI-Express sein.

Ich habe mir das Debian von einem Techniker im Rechenzentrum aufsetzen lassen. Dort musste der Kernel kompiliert und gepatcht werden, weil der standardmäßig diese NIC nicht erkennt.

Frage:
Wenn ich nun obiges apt-get upgrade mit "Y" beantworte, wird dann ein neuer Kernel installiert und die Unterstützung der zweiten NIC ist weg?
An einen Kernel-Patch traue ich mich nicht ran, weil der Server im Produktivbetrieb arbeitet.
Wie erfahre ich ab wann diese NIC durch Sarge unterstützt wird?

Danke für Antworten.

[chimaera]

wenn es der benötigte treiber nicht in den zu installierenden kernel geschaft hat, verlierst du mit diesem update die unterstützung für die entsprechende NIC.

[flowie]

Ja, also wie vermutet.

Bleibt die Frage:
Wie erfahre ich ab wann diese NIC durch Sarge unterstützt wird?

[gms]

bist du dir sicher, daß der Kernel gepatcht wurde ? Vielleicht wurde auch nur ein zusätzliches Modul für diese NIC auf Basis der Kernelsourcen erzeugt.

wenn der Kernel wirklich neu kompiliert und gepatcht wurde, dann solltest du dem Techniker schon einmal erklären, daß es nicht umbedingt schlau ist, für einen selbst gebauten Kernel, die gleiche Versionsbezeichnung zu verwenden.


Gruß
gms

[flowie]

Tja, leider bin ich kein absoluter Profie was Linux angeht. Daher habe ich die Installation auch abgegeben. Allerdings möchte ich die weitre Systempflege schon selbstmachen.

wenn der Kernel wirklich neu kompiliert und gepatcht wurde...

Unter /usr/src gibt es die Verzeichnisse:
kernel-source-2.6.8
DriverInstall
sowie ein Symlink "linux" auf das Sourcen-Verzeichnis.

Unter "DriverInstall" befinden sich die Treiber zum Einbinden in den Kernel.
Ob dies nun ein selbst kompilierter Kernel mit veränderten Sourcen ist oder ein Patch des Standard-Kernels ...

Hier das README aus den DiverInstall-Verzeichnis:

/edit: verschoben nach http://nopaste.debianforum.de/377

Was ich wissen muss ist: Wann kann ich ein "apt-get upgrade" wieder bedenklos laufenlassen?

Ist es nicht so, das der 2.6er-Kernel unsicher ist?

mfg

/edit: bitte an die Forumsregeln halten und zu lange Postings vermeiden, bzw. nach "nopaste" packen
Gruß Savar

[gms]

laut dem README ist genau beides möglich
siehe:
5.1 User Installation Mode
5.2 Patch Generation Mode

Man müßte also wissen, oder herausfinden, welche Methode der Techniker gewählt hat
Was ergibt den "find /usr/src/kernel-source-2.6.8 -name "*.ko" ?

Wenn dieser Befehl mehrere Dateien zurückliefert, liegt der Verdacht nahe, daß der Kernel gepatcht wurde.
Wir könnten aber auch die installierten Dateien, mit den Dateien im deb-Archiv vergleichen
Schau mal ob dieses vorhanden ist "find /var -name "kernel-image-2.6.8-2-686*.deb"
".

Gruß
gms

[gms]

also ich würde vorschlagen, daß wir den Kernel nicht upgraden:

Code: Alles auswählen

echo "kernel-image-2.6.8-2-686-smp  hold" | dpkg --set-selections
echo "kernel-source-2.6.8  hold" | dpkg --set-selections

Nach diesen Kommandos sollte das Upgrade diese zwei Pakete nicht mehr aktualisieren

Gruß
gms

[flowie]

Im DriverInstall-Verzeichnis gib eine eine install.log-Datei

+++ Install mode: User
+++ Driver version: 8.16.2.3 (Mar-30-2005)
+++ Kernel version 2.6.8-2-686-smp
+++ smp_count=1
+++ cpu_number=4
+++ kernel_machine=i686
+++ Architecture: i386
+++ Mismatch!!! Kernel:3.3.5 != gcc:(Debian
+++ Unpack the sources
+++ ====================================
+++ tar xfv sk98lin.tar
2.4/
2.4/h/

...snipp...

+++ Compile the driver
+++ ====================================
make: Entering directory `/usr/src/kernel-source-2.6.8'
CC [M] /tmp/Sk98IaRVKoiCEjjcQdbBqDaWR/all/skge.o
CC [M] /tmp/Sk98IaRVKoiCEjjcQdbBqDaWR/all/sky2.o
CC [M] /tmp/Sk98IaRVKoiCEjjcQdbBqDaWR/all/skethtool.o

...snipp...

Building modules, stage 2.
MODPOST
CC /tmp/Sk98IaRVKoiCEjjcQdbBqDaWR/all/sk98lin.mod.o
LD [M] /tmp/Sk98IaRVKoiCEjjcQdbBqDaWR/all/sk98lin.ko
make: Leaving directory `/usr/src/kernel-source-2.6.8'
Check the driver
====================================

Daraus geht hervor, das wohl der User-Install-Mode 5.1 benutzt wurde.
PS: Mit den obigen find-Befehlen erfolgt in beiden Fällen kein Ergebnis.

Code: Alles auswählen

echo "kernel-image-2.6.8-2-686-smp  hold" | dpkg --set-selections
echo "kernel-source-2.6.8  hold" | dpkg --set-selections 

Bedeuted das, das dann ein "apt-get upgrade" einen Kernel-Update verhindert?

mfg

[gms]

/edit: bitte an die Forumsregeln halten und zu lange Postings vermeiden, bzw. nach "nopaste" packen
Gruß Savar

Ich befürchte du hast das übersehen

Gruß
gms

[flowie]

Sorry, das kannte ich noch nicht. Hab das Zitat gekürzt.

mfg

[gms]

Daraus geht hervor, das wohl der User-Install-Mode 5.1 benutzt wurde.
PS: Mit den obigen find-Befehlen erfolgt in beiden Fällen kein Ergebnis.

Danach solltest du eigentlich den Kernel upgraden können. Auf alle Fälle aber eine Sicherungskopie von dem Modul erstellen.

Code: Alles auswählen

echo "kernel-image-2.6.8-2-686-smp  hold" | dpkg --set-selections
echo "kernel-source-2.6.8  hold" | dpkg --set-selections 

Bedeuted das, das dann ein "apt-get upgrade" einen Kernel-Update verhindert?

Ja, diese Pakete sind dann auf "hold" und werden nicht mehr aktualisiert


Gruß
gms

[flowie]

Danach solltest du eigentlich den Kernel upgraden können. Auf alle Fälle aber eine Sicherungskopie von dem Modul erstellen.

Nur um sicherzugehen: Du meinst, das ich ein "apt-get upgrade" durchführen kann OHNE die beiden Pakete wie angegeben zu sperren?

Ich trau mich nicht so recht...

Wie wird das Modul gesichert? Und wie kann ich die Sicherung restaurieren, wenn das Upgraden mir die 2. NIC "abklemmt"....

[gms]

Nur um sicherzugehen: Du meinst, das ich ein "apt-get upgrade" durchführen kann OHNE die beiden Pakete wie angegeben zu sperren?

Ich trau mich nicht so recht...

Ja, eigentlich spricht alles dafür, daß es funktionieren müßte. Ich rate dir aber jetzt einmal auch davon ab.
Installiere dir irgendwann einen zweiten Kernel, und baue in Ruhe dieses Modul. Wenn das dann funktioniert, bist du auch für die Zukunft gerüstet.

Wie wird das Modul gesichert? Und wie kann ich die Sicherung restaurieren, wenn das Upgraden mir die 2. NIC "abklemmt"....

diese Datei "sk98lin.ko" sollte irgendwo unterhalb von "/lib/modules/`uname -r`" zu finden sein. Kopiere diese einfach an einen sicheren Ort. Beim Einspielen mußt du diese Datei,möglichst wieder an den gleichen Ort, kopieren und ein "depmod -a" ausführen

Gruß
gms

[flowie]

Letztes Posting klingt vernüftig. Habe die Datei gesichert.

...Installiere dir irgendwann einen zweiten Kernel, und baue in Ruhe dieses Modul. Wenn das dann funktioniert, bist du auch für die Zukunft gerüstet.

Tja, ein neues Thema für mich
Zweiten Kernel installieren... kann man den "probeweise" installieren und dann zurückschalten auf den alten? Auch remote?
--> Ist wohl ein Thema für einen neuen Thread. Dazu muss ich mich als Kernel-Laie erst mal schlau machen.
Gibt es irgendwo einen guten Link-Tip bezüglich Kernel-Fragen?

Eine Frage kann ggf. doch noch hier in diesem Thead beantwortet werden: Unter kernel.org finde ich den Kernel 2.6.11.11 Meiner ist aber "nur" 2.6.8-2. Ist ein Kernel Distributionsunabhängig? Könnte ich dann nicht den 2.6.11.11 nehmen? Oder halten die Security-Patches auch den 2.6.8-2 auf den aktuellen Sicherheitsstand?

bye

[gms]

Ist ein Kernel Distributionsunabhängig? Könnte ich dann nicht den 2.6.11.11 nehmen? Oder halten die Security-Patches auch den 2.6.8-2 auf den aktuellen Sicherheitsstand?

Der 2.6.8er Kernel wird jetzt einige Zeit mit (Security-)Patches auf den aktuellen Sicherheitsstand gehalten. Irgendwann kommt aber in Sarge ein neuer 2.6 er Kernel rein. Danach werden dem 2.6.8er wahrscheinlich keine Sicherheitsupdates mehr verpaßt.
Ein Kernel von kernel.org wird mit sehr hoher Wahrscheinlichkeit auf deinem System genause funktionieren, wie der Debianstandardkernel. Die debianspezifischen Änderungen sind nicht sehr aufregend

Gruß
gms

[KBDCALLS]

Welches Modul wird den für die Karte verwendet.

Code: Alles auswählen

 lsmod 

[gms]

lesefaul

Modul ist:
sk98lin.ko

Gruß
gms

[nitronix]

Hi
ich kann bestätigen, dass die PCI-X Version der Yukon GigE Netzwerkkarte nicht von Haus aus funktioniert (bis einschließlich Vanilla 2.6.11.11) und du den Kernel patchen musst. Die nicht PCI-X Version soll wohl auch so funktionieren.
Der Yukon Treiber von http://www.marvell.com funktioniert sehr gut. Der Install-Assistent erstellt einen Patch, falls du selbst ein "Kernel .deb" bauen willst oder wie in deinem Fall ein Modul für einen bereits installieren Kernel. Der Debian Kernel-Source von 2.6.8-2 sollte dann reichen.

Ciao

NitroniX

[flowie]

Was sagst Du dazu nitronix:
Könnte ich jetzt ein "apt-get upgrade" durchführen, wie weiter oben im Thread beschrieben, OHNE wie oben angegeben die beiden Kernel-Pakete zu sperren?

[nitronix]

Nabend,
ja, eine reelle Chance sehe ich.

Bevor du allerdings upgradest würde ich folgendes mit dem jetzigen Kernel testen:
-mach ein Backup von dem sk98lin Modul
-Installiere für deinen "alten" 2.6.8 den passenden Debian Kernel-Source und lade dir den Yukon Treiber runter. Bau dir mit dem Install-Assistenten den Treiber als Modul.
-Das alte Modul entladen und das Neue Modul laden
-Netzwerk testen

Wenn es funktioniert, dann sollte der gleiche Weg auch mit dem neuen Kernel funktionieren.
Sollte es nicht funktionieren, dann hast du das Backup.
Keine Aussage möglich, wenn der Techniker den Treiber in den Kernel mit rein kompiliert hat.

Bei Kernel 2.6.11-k7 aus SID funktioniert der Weg jedenfalls.

Ciao

NitroniX

[flowie]

Möchte noch zu ende berichten:
Ein apt-get upgrade hat mir die 2. NIC abgeklemmt und außerdem den Neustart verhindert. Musste den Support kontaktieren. Server hing beim Booten. Die 2. NIC war nämlich die zum Internet... hatte gedacht, das die nur für die lokale Verbindung zwischen beiden Servern eingesetzt wurde.

Hatte ein wenig Hoffnung, das es doch klappt, aber naja... ich hatte vorgesorgt.
Werde den Treier zu einem späteren Zeitpunkt einrichten.