Seltsames Prob mit neuer Netzkarte

[Manfred]

Servus miteinander,

die Onboard-Netzkarte von meinem PC ist kaputt. Ich habe deshalb eine neue Netzkarte reingesteckt. Diese wurde auch sofort als eth3 erkannt.

Jetzt ist es aber so, daß bei einem Neustart die Anmeldung als User nach Eingabe des Usernamens und des PW ca. 5 Minuten dauert. Melde ich mich als root an, dann gehts ratzfatz.

Wenn der PC im Suspend to disk ist und ich ihn wieder aufwecke, dann hat er die Einstellungen der Netzkarte verloren. ifconfig zeigt dann nur noch die Einstellungen meiner virtuellen (durch VMWare erstellten) Netzeinstellungen. Ich muß dann /etc/init.d/networking restart eingeben, damit das Netz wieder funktioniert.

Kann mir wer erklären, was ich tun muß, damit das Netz wieder einwandfrei funktioniert?

Wie stelle ich die Bezeichnung eth3 wieder auf eth0 um?

[nepos]

Servus miteinander,

die Onboard-Netzkarte von meinem PC ist kaputt. Ich habe deshalb eine neue Netzkarte reingesteckt. Diese wurde auch sofort als eth3 erkannt.

Was für eine isses denn und welches Modul wird benutzt?

Jetzt ist es aber so, daß bei einem Neustart die Anmeldung als User nach Eingabe des Usernamens und des PW ca. 5 Minuten dauert. Melde ich mich als root an, dann gehts ratzfatz.

Wenn der PC im Suspend to disk ist und ich ihn wieder aufwecke, dann hat er die Einstellungen der Netzkarte verloren. ifconfig zeigt dann nur noch die Einstellungen meiner virtuellen (durch VMWare erstellten) Netzeinstellungen. Ich muß dann /etc/init.d/networking restart eingeben, damit das Netz wieder funktioniert.

Womit machst du Suspend? Hast du da eventuell die Hibernate-Skripten installiert? Muss das Modul für deine neue Karte da eventuell speziell behandelt werden?

Kann mir wer erklären, was ich tun muß, damit das Netz wieder einwandfrei funktioniert?

Wie stelle ich die Bezeichnung eth3 wieder auf eth0 um?

Nun ja, dazu gibts im Forum zig Threads, udev ist hier der schuldige. Schau mal nach /etc/udev/rules.d/z25_persistent-net.rules. Da wird anhand der MAC festgelegt, welche Karte welche Bezeichnung bekommt.

[Manfred]

Die Onboard-Karte ist eine SIS900, die neue Karte ist eine r8169.

Für den supend habe ich kpowersave installiert. Unter der Konfiguration finde ich aber keinerlei Einstellungsmöglichkeiten für die Netzkarte.

Kann ich den Eintrag für die eth3 in /etc/udev/rules.d/z25_persistent-net.rules einfach auf eth0 umstellen und die alten eth-Einträge auf Kommentar setzen?

[Manfred]

Kann ich den Eintrag für die eth3 in /etc/udev/rules.d/z25_persistent-net.rules einfach auf eth0 umstellen und die alten eth-Einträge auf Kommentar setzen?

Das habe ich jetzt einfach mal gemacht. Das Anmelden funktioniert wieder.

Aber beim suspend verliert Debian weiterhin die Einstellungen für eth0.

[rendegast]

addendum nepos

Schau mal nach /etc/udev/rules.d/z25_persistent-net.rules.

Dieses Verzeichnis wird auch in die initrd kopiert, daher bei Änderungen dort auch die initrd neu erstellen.

[sys_op]

@ rendegast
kannst du das bitte noch etwas konkreter definieren. ich habe diese datei z.b. für einen nvidia-chip angepasst (also auf die entsprechende PCI subadresse geändert, da die mac-adresse permanent neu zugewiesen wurde). das müsste ich dann ja auch entsprechend noch was ändern.

[rendegast]

kannst du das bitte noch etwas konkreter definieren.

Wenn Du Deine initrd linkst:

Code: Alles auswählen

ln  -s  /boot/initrd.img-BLA  initrd.img-BLA.cpio.gz

kannst du das Archiv "betreten".
In initrd.img-BLA.cpio.gz/etc/udev/rules.d/ befinden sich die Dateien aus /etc/udev/rules.d/.

Nach Änderungen in /etc/udev/rules.d/ wäre dann wohl ein

Code: Alles auswählen

update-initramfs  -u  -k all

angebracht, um Ostereier zu vermeiden.

[Manfred]

Soll ich jetzt

Code: Alles auswählen

update-initramfs  -u  -k all 

ausführen?

So ganz versteh ich deine Erklärung nicht. Weil ich ja gar keine Änderungen in /etc/udev/rules.d/ durchgeführt habe.

[rendegast]

Weil ich ja gar keine Änderungen in /etc/udev/rules.d/ durchgeführt habe.

oben hast Du geschrieben:

Das habe ich jetzt einfach mal gemacht.

[Manfred]

Jetzt verstehe ich, was du meinst.

Demnach muß ich jetzt also

Code: Alles auswählen

update-initramfs  -u  -k all 

ausführen?

Da kommt folgende Fehlermeldung

Code: Alles auswählen

 update-initramfs  -u  -k all
update-initramfs: Generating /boot/initrd.img-2.6.18-4-k7
/boot/initrd.img-2.6.18-4-amd64 does not exist. Cannot update.

Was ich absolut nicht verstehe. Denn der 2.6.18-4-k7 ist mein Kernel.

[rendegast]

Die Meldung bezieht sich auf

/boot/initrd.img-2.6.18-4-amd64

Bei Verwendung des Tools 'update-initramfs' mit dem Schalter '-u' muß die initrd schon vorhanden sein,
und in /var/lib/initramfs-tools/ mit richtiger Checksumme verzeichnet.

Um eine neue zu erstellen, verwende den Schalter '-c'.

[Manfred]

Das funktioniert leider auch nicht

Code: Alles auswählen

update-initramfs  -c  -k all
Cannot create version 2.6.18-4-k7: already exists
update-initramfs: Generating /boot/initrd.img-2.6.18-4-amd64
Cannot find /lib/modules/2.6.18-4-amd64
update-initramfs: failed for /boot/initrd.img-2.6.18-4-amd64 

Ich versteh nicht, warum da immer nach dem /boot/initrd.img-2.6.18-4-amd64 gesucht wird.

[rendegast]

Ich versteh nicht, warum da immer nach dem /boot/initrd.img-2.6.18-4-amd64 gesucht wird.

Ich jetzt auch nicht, der kernel muß wohl mal installiert gewesen sein,
normalerweise wird bei Deinstallation ein 'update-grub' ausgeführt, danach sind die Einträge darauf in /boot/grub/menu.lst verschwunden.

Liegt noch ein vmlinuz-2.6.18-4-amd64 in /boot herum? Da ja auch das Modul-Verzeichnis fehlt

Cannot find /lib/modules/2.6.18-4-amd64

wäre das noch ein unnützer Rest, den kannst Du löschen.
Danach sicherheitshalber nochmal 'update-grub' ausführen, um die /boot/grub/menu.lst zu reinigen.
Danach läuft dann auch 'update-initramfs' ohne Fehlermeldung durch.


Ist aber alles nebensächlich, denn eine neue initrd für Deinen k7-Kernel wurde schon beim ersten Durchlauf erstellt:

update-initramfs: Generating /boot/initrd.img-2.6.18-4-k7

Ausflug beendet und zurück zur Netzwerkkarte

[Manfred]

Code: Alles auswählen

Ich versteh nicht, warum da immer nach dem /boot/initrd.img-2.6.18-4-amd64 gesucht wird.

Ich jetzt auch nicht, der kernel muß wohl mal installiert gewesen sein,
normalerweise wird bei Deinstallation ein 'update-grub' ausgeführt, danach sind die Einträge darauf in /boot/grub/menu.lst verschwunden.

Da steht nur folgendes drin:

Code: Alles auswählen

## ## End Default Options ##

title		Debian GNU/Linux, kernel 2.6.18-4-k7
root		(hd0,0)
kernel		/vmlinuz-2.6.18-4-k7 root=/dev/hda4 ro 
initrd		/initrd.img-2.6.18-4-k7
savedefault

title		Debian GNU/Linux, kernel 2.6.18-4-k7 (recovery mode)
root		(hd0,0)
kernel		/vmlinuz-2.6.18-4-k7 root=/dev/hda4 ro single
initrd		/initrd.img-2.6.18-4-k7
savedefault

title		Debian GNU/Linux, kernel memtest86
root		(hd0,0)
kernel		/memtest86.bin

### END DEBIAN AUTOMAGIC KERNELS LIST 

Liegt noch ein vmlinuz-2.6.18-4-amd64 in /boot herum? Da ja auch das Modul-Verzeichnis fehlt

Nein

Cannot find /lib/modules/2.6.18-4-amd64

wäre das noch ein unnützer Rest, den kannst Du löschen.

Auch das gibt es nicht.

Danach sicherheitshalber nochmal 'update-grub' ausführen, um die /boot/grub/menu.lst zu reinigen.

Habe ich jetzt gemacht

Code: Alles auswählen

update-grub
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /vmlinuz-2.6.18-4-k7
Found kernel: /memtest86.bin
Updating /boot/grub/menu.lst ... done
 

Danach läuft dann auch 'update-initramfs' ohne Fehlermeldung durch.

Leider nicht ganz

Code: Alles auswählen

 update-initramfs  -u  -k all
update-initramfs: Generating /boot/initrd.img-2.6.18-4-k7
/boot/initrd.img-2.6.18-4-amd64 has been altered. Cannot update. 

Ist aber alles nebensächlich, denn eine neue initrd für Deinen k7-Kernel wurde schon beim ersten Durchlauf erstellt:

update-initramfs: Generating /boot/initrd.img-2.6.18-4-k7

Ausflug beendet und zurück zur Netzwerkkarte

Wie ich schon geschrieben habe, funktioniert es nun beim Neustart, aber beim Start aus suspend to disk muß ich weiterhin

Code: Alles auswählen

 /etc/init.d/networking restart 

eingeben

[rendegast]

/boot/initrd.img-2.6.18-4-amd64 has been altered. Cannot update.

Existiert dann noch eine obsolete /var/lib/initramfs-tools/2.6.18-4-amd64 ?

[Manfred]

/boot/initrd.img-2.6.18-4-amd64 has been altered. Cannot update.

Existiert dann noch eine obsolete /var/lib/initramfs-tools/2.6.18-4-amd64 ?

Ja

Soll ich die löschen?

[rendegast]

Ja

[Manfred]

OK, hab ich jetzt gemacht.

Danach habe ich nochmal update-grub und update-initramfs -u -k all ausgeführt.

Beides lief ohne Fehler durch. Jetzt werde ich meinen PC mal in den Tiefschlaf versetzen und wieder aufwecken.

Ergebnis kommt gleich

[Manfred]

Das Aufwecken funktioniert leider noch nicht

ping nach dem Aufwecken bringt

Code: Alles auswählen

connect: Network is unreachable 

Ich mach dann

Code: Alles auswählen

/etc/init.d/networking restart
* /etc/network/options is deprecated (see README.Debian of netbase).
Setting up IP spoofing protection...done (rp_filter).
Reconfiguring network interfaces...SIOCDELRT: No such process
done.
 

Danach funktioniert das Netz wieder

[rendegast]

nepos hat es schon angesprochen:

Womit machst du Suspend? Hast du da eventuell die Hibernate-Skripten installiert? Muss das Modul für deine neue Karte da eventuell speziell behandelt werden?

Die hibernate-Skripte kapseln den reinen suspend-Vorgang, um vor und nach dem suspend entsprechende Aktionen (Module ent-/neuladen, Programme beenden/neustarten) automatisiert durchzuführen.

[Manfred]

Mit hibernate und so habe ich ziemlich viel ausprobiert, bis ich das Richtige gefunden hatte.

Jetzt arbeite ich mit kpowersave.

Kann natürlich schon sein, daß da irgendwo noch was schlummert. Aber wie finde ich das heraus?

[Manfred]

Mal nach oben schieb