Eth0 muss nach jedem Neustart neu geladen werden.

[Thats_me]

So. Eins ist nun absolut sicher.

Artix schmeißt nach jedem Neustart meinen eth0 Treiber raus!
Scheint wohl wirklich ein Kernelproblem zu sein, wie Roberto schrieb?

Erst wenn ich ihn neu lade, bekomme ich Internet. Falls erwünscht, kann ich den kompetten Verlauf hier posten, was ich gemacht habe und tun musste, ist aber lang und viel. Ich bin mir sicher, dass der eth0 Treiber fehlt.

Der Tipp funktioniert leider nicht, obwohl es installiert ist.
Die Option -t finde ich übrigens nicht https://manpages.debian.org/buster/initramfs-tools/update-initramfs.8.en.html

xmg:[me]:~$ sudo update-initramfs -v -t -u
[sudo] Passwort für me: 
sudo: update-initramfs: Befehl nicht gefunden
xmg:[me]:~$

xmg:[me]:~$ pacman -Qi initramfs
Name                    : mkinitcpio
Version                  : 34-2
Beschreibung            : Modular initramfs image creation utility
Architektur              : any
URL                      : https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio
Lizenzen                : GPL
Gruppen                  : Nichts
Stellt bereit            : initramfs
Hängt ab von            : awk  mkinitcpio-busybox>=1.19.4-2  kmod
                         >=2.23  libarchive  coreutils  bash
                          binutils  diffutils  findutils  grep
                          filesystem>=2011.10-1  zstd  udev
Optionale Abhängigkeiten : gzip: Use gzip compression for the initramfs image
                          [Installiert]
                          xz: Use lzma or xz compression for the initramfs
                          image [Installiert]
                          bzip2: Use bzip2 compression for the initramfs image
                          [Installiert]
                          lzop: Use lzo compression for the initramfs image
                          lz4: Use lz4 compression for the initramfs image
                          [Installiert]
                          mkinitcpio-nfs-utils: Support for root filesystem on
                          NFS
Benötigt von            : linux  linux-lts  mkinitcpio-openswap
Optional für            : Nichts
In Konflikt mit          : Nichts
Ersetzt                  : Nichts
Installationsgröße      : 121,01 KiB
Packer                  : Artix Build Bot <jenkins@artixlinux.org>
Erstellt am              : Do 08 Dez 2022 23:57:42 CET
Installiert am          : Fr 06 Jan 2023 13:46:38 CET
Installationsgrund      : Ausdrücklich installiert
Installations-Skript    : Ja
Verifiziert durch        : Signatur

xmg:[me]:~$

-----
Hat das Rauswerfen des Treibers, bzw. das nicht speichern was mit dem hier zu tun?
https://forum.artixlinux.org/index.php/topic,2035.0.html

Und welche Rolle spielt mkinitcpio? Manchmal musste man das auch "updaten" oder neu erstellen (bitte korrekten Begriff ersetzen).Ich weiß nur nicht mehr in welchen Fällen.

Oder werden da Symlinks gesetzt beim Aufruf des Treibers und die funktionieren nicht?
Ich habe ja keine Ahnung, wie der Ablauf ist, dass die Module geladen werden und von wo.
https://forum.artixlinux.org/index.php/topic,4842.msg31018.html#msg31018


Danke vorab TM

[gosia]

Hallo Thats_me,

Die Option -t finde ich übrigens nicht

ok, das nehme ich reumütig auf meine Kappe, da habe ich wohl zu alte Notizen gehabt. Aber warum update-initramfs nicht gefunden wird

obwohl es installiert ist

verstehe ich nicht. Was sagt denn

locate update-initramfs

Ich bin mir sicher, dass der eth0 Treiber fehlt.

Dann poste bitte mal die Ausgabe von

lsmod | grep r816

hatten wir schon mal, glaube ich jedenfalls, kann aber nicht schaden.
Und wenn Du schon mal dabei bist, auch die Ausgabe von

ls -l /var/lib/connman

vielleicht ist was mit den dort befindlichen Konfigurationen (=settings) nicht in Ordnung. Allerdings würden die Symptome dann etwas anders aussehen, aber irgendwo müssen wir ja diese endlose Geschichte beginnen aufzudrösseln.

viele Grüsse gosia

PS. Aber der Dienst connmand läuft ordentlich?

[Thats_me]

Vielen Dank gosia.

ok, das nehme ich reumütig auf meine Kappe, da habe ich wohl zu alte Notizen gehabt.

Ich bin so froh, dass du mir immer so hilfst. Das ist ja eh stressig genug
Zudem liegt es ja nicht an dem versehentlichen t, sondern daran, dass ich es nicht schaffe initramfs zu installieren, bzw. es aus unerfindlichen Gründen nicht läuft.
Dann doch dieses mkinitcpio nehmen?

xmg:[me]:~$ pacman -Qi initramfs
   Name                    : mkinitcpio


Ich habe alle erforderlichen Abhängigkeiten gecheckt.
Staat awk ist bei mir allerdings gawk installiert.
Im der Vergangenheit war schon mal was mit diesem awk. Das gibt es aber nicht in den Repos.
awk gehörte zu einem AUR damals.
---------------

Hier die gewünschte Ausgabe:

xmg:[me]:~$ locate update-initramfs
xmg:[me]:~$ sudo locate update-initramfs
[sudo] Passwort für me: 
xmg:[me]:~$

Dann poste bitte mal die Ausgabe von
lsmod | grep r816

Der wird natürlich gefunden, da ich ihn heute nach dem Neustart ja wieder geladen habe und seither wieder online bin
----------

Dann also doch mal, was nach einem Neustart abgeht. Heute Morgen nach Neustart kein Internet.
Ok, ich gehe da etwas chaotisch vor, aber ich denke das ist nicht das Problem.
Hier der Ablauf

xmg:[me]:~$ connmanctl technologies
Error: The name net.connman was not provided by any .service files
xmg:[me]:~$

xmg:[me]:~$ rc-status
Runlevel: default
 dbus                                                  [  started 00:01:30 (0) ]
 NetworkManager                                                    [ inactive  ]
 netmount                                                          [ scheduled ]
 syslog-ng                                             [  started 00:01:29 (0) ]
 acpid                                                 [  started 00:01:29 (0) ]
 cronie                                                [  started 00:01:29 (0) ]
 cupsd                                                 [  started 00:01:29 (0) ]
 lightdm                                               [  started 00:01:29 (0) ]
 ntpd                                                  [  started 00:01:29 (0) ]
 local                                                             [  started  ]
 agetty.tty2                                           [  started 00:01:28 (0) ]
 agetty.tty6                                           [  started 00:01:28 (0) ]
 agetty.tty4                                           [  started 00:01:28 (0) ]
 agetty.tty5                                           [  started 00:01:28 (0) ]
 agetty.tty3                                           [  started 00:01:28 (0) ]
 agetty.tty1                                           [  started 00:01:28 (0) ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed/wanted
 avahi-daemon                                          [  started 00:01:29 (0) ]
Dynamic Runlevel: manual
 openrc-settingsd                                                  [  started  ]
xmg:[me]:~$

xmg:[me]:~$ lsmod | grep r816
xmg:[me]:~$

-> wenn keine Ausgabe -> bedeutet nicht geladen.

xmg:[me]:~$ sudo rc-update delete NetworkManager
 * service NetworkManager removed from runlevel default
xmg:[me]:~$

Hatte ich zwar zuvor schon gemacht, aber egal, jetzt ist er weg.

xmg:[me]:~$ sudo rc-update add connmand
[sudo] Passwort für me: 
 * service connmand added to runlevel default
xmg:[me]:~$

xmg:[me]:~$ sudo modprobe -v r8169
insmod /lib/modules/5.15.82-1-lts/kernel/drivers/net/phy/libphy.ko.zst 
insmod /lib/modules/5.15.82-1-lts/kernel/drivers/net/phy/mdio_devres.ko.zst 
insmod /lib/modules/5.15.82-1-lts/kernel/drivers/net/phy/realtek.ko.zst 
insmod /lib/modules/5.15.82-1-lts/kernel/drivers/net/ethernet/realtek/r8169.ko.zst 
xmg:[me]:~$

xmg:[me]:~$ sudo update-initramfs -v -t -u
bash: update-initramfs: Kommando nicht gefunden.
xmg:[me]:~$ sudo pacman -S initramfs
Warnung: mkinitcpio-34-2 ist aktuell -- Reinstalliere
Abhängigkeiten werden aufgelöst ...
Nach in Konflikt stehenden Paketen wird gesucht ...

xmg:[me]:~$ update-initramfs -v -t -u
bash: update-initramfs: Kommando nicht gefunden.
xmg:[me]:~$

xmg:[me]:~$ connmanctl state
Error: The name net.connman was not provided by any .service files
xmg:[me]:~$ sudo rc-service connmand start
 * Executing: /usr/lib/openrc/sh/openrc-run.sh /usr/lib/openrc/sh/openrc-run.sh /etc/init.d/connmand start
 * Starting connmand ...
 * supervise-daemon: fopen `/var/run/supervise-connmand.pid': No such file or directory
 * Detaching to start `/usr/bin/connmand'                                 [ ok ]
xmg:[me]:~$

zur Sicherheit nochmal

xmg:[me]:~$ lsmod | grep r816
r8169                 106496  0
mdio_devres            16384  1 r8169
libphy                159744  3 r8169,mdio_devres,realtek
xmg:[me]:~$

Voila Internet ging

[Daemon]

Da wir beide die gleichen bzw. sehr ähnliche Notebooks haben, ich aber davon ausgehe bzw. gesehen habe dass es zumindest die gleiche Netzwerkkarte ist, und ich auch Probleme mit Netzwerk und Artix hatte, sage ich es so wie es ist: Die beiden vertragen sich nicht, und es wird wohl dauern, falls überhaupt jemals, bis die beiden harmonieren. 
Was ich mich dabei nur frage: Wir sind doch nicht die einzigen mit der Netzwerkkarte. Haben andere keine Probleme damit?
Falls nein, muss es ja noch an was anderem liegen. Mainboard, Bios, keine Ahnung ....

[Thats_me]

Da wir beide die gleichen bzw. sehr ähnliche Notebooks haben, ich aber davon ausgehe bzw. gesehen habe dass es zumindest die gleiche Netzwerkkarte ist, und ich auch Probleme mit Netzwerk und Artix hatte, sage ich es so wie es ist: Die beiden vertragen sich nicht, und es wird wohl dauern, falls überhaupt jemals, bis die beiden harmonieren.
Was ich mich dabei nur frage: Wir sind doch nicht die einzigen mit der Netzwerkkarte. Haben andere keine Probleme damit?
Falls nein, muss es ja noch an was anderem liegen. Mainboard, Bios, keine Ahnung ....

Sieht so aus. Ich wollte zu Siduction wechseln, bzw. das mal ausprobieren. Aber das erkennt die Efi Partition nicht und will die Efi Partition formatieren, bzw. sogar die gesamte FP. Calamares akzeptiert nur eine Größe von 300 MB, was man zwar umgehen kann, aber trotzdem nur installieren kann, wenn man zulässt, dass /boot/efi neu formatiert wird.

Ne, das ist mir zu heiß. Lösung wurde noch keine gefunden. Naja auch eine kleine Odysee

Aber mal sehen, vielleicht bekomme ich das noch hin, dass eth0 Treiber gespeichert wird. Zuvor gab es ja auch keine Probs. wird wohl an einem älteren Update liegen. Da ging es nämlich los.
Vielleicht sollte ich mal einen anderen Kernel testen. Nicht den lts

[Thats_me]

Ich sollte wohl mal im Artix Forum nachfragen.
Aber im Deutschen Teil hagelt es nicht gerade viel Hilfe.

Und auf Englisch traue ich mir das komplexe Thema nicht zu.

[gosia]

Hallo Thats_me,

ich gehe da etwas chaotisch vor

da möchte ich nicht widersprechen
Was mir auffällt:

sudo rc-service connmand start

 * Executing: /usr/lib/openrc/sh/openrc-run.sh /usr/lib/openrc/sh/openrc-run.sh /etc/init.d/connmand start

es sieht so aus, als ob dein connman nicht automatisch startet. Bei mir kommt da

connmand: WARNING: command has already been started

Hast Du nach

sudo rc-update add connmand

auch neu gebootet?

Dann doch dieses mkinitcpio nehmen?

ja, das geht.
https://wiki.artixlinux.org/Main/Migration#Update_the_bootloader_and_the_kernel_initramfs
Ich habe update-initramfs, das gehört zu den initramfs-tools, aber kann sein, dass ich das von früher her oder selbst compiliert habe.

lsmod | grep r816

-> wenn keine Ausgabe -> bedeutet nicht geladen.

Ja.

sudo modprobe -v r8169

von Hand nachladen funktioniert also. Kann es sein, dass r8169 geblacklistet ist, warum auch immer? Und warum startet dein connman nicht automatisch? Das sind so die Fragen, die mich im Moment bewegen. Mal sehen, ob ich was dazu finde. Das "von-Hand-nachladen" kannst Du ja per autostart als Workaround benutzen, ist aber keine Lösung.
Dann noch die Nachfrage, Du benutzt doch Artix nicht erst seit gestern oder heute, hat es denn schon mal funktioniert, vor einem halben Jahr oder wann immer?

viele Grüsse gosia

PS. die letzte Frage hast du schon beantwortet, wie ich gerade sehe. Hm. Kernelproblem? Ich habe 5.15.82-1-lts, aber eine andere Netzwerkkarte und als Treiber tg3. Werde mich mal umsehen, ob ich einen Rechner auftreibe, der den Treiber r8169 braucht.

[Thats_me]

Einen schönen guten Morgen/Mittag gosia!

Ich habe das Problem behoben *juhuuu*.Blacklist war das Stichwort. Da schaute ich dann nochmal nach.

da möchte ich nicht widersprechen

lol, ich auch nicht   Es gibt eben Menschen die gehen unnötige Umwege in ihrem Linuxleben *g*
Wenn sie Glück haben finden sie eine treue geduldige Gefährtin, die ihnen  den rechten Weg weist

Und ja, es hatte alles "jahrelang" funktioniert, sonst hätte ich euch längst damit geplagt. *rotwerd*
Ich meine, es begann mit einem Update des nm, so Anfang Dez., da müsste ich nachschauen.
Ich hatte ja erst meinen Provider in Verdacht und merkte erst Ende Dez. dass es an Artix liegt.

Hast Du nach

sudo rc-update add connmand

auch neu gebootet?

Einmal ja, das andere mal nicht. Sorry. Ich erinnere mich, dass ich dann in der main.conf beim Eintrag

DefaultAutoConnectTechnologies =

das # raus genommen hatte. Und nun startet connman auch automatisch. Sorry, dass ich das nicht erwähnte. Vor lauter Sucherei und eigener Recherche, habe ich das vergessen.

Geladen werden soll nun ja doch der alte/bisherige r8169 (Statt r8168 von daemon)
Mit dem Neuen hatte es ja auch nicht funktioniert.
Ich habe in der bash_history nachgeschaut. Ich hatte beim Wechsel zum ursprünglichen r8169 vergessen ein

sudo modprobe -r r8168

zu machen.

In /usr/lib/modprobe.d/ stand vor dem heutigen Booten nämlich eine r8168.conf und dort blacklist r8169. Klar, dass dann der r8169 nicht automatisch geladen wird. Jedenfalls habe ich dort den blacklist-Eintrag mal gelöscht. Die ganze Datei zu löschen traute ich mich nicht.

Dann habe ich vor einem erneuten Boot modprobe -r r8168 nachgeholt und nochmal gebootet.

Was mich jedoch irritiert. Trotzdem steht in /usr/lib/modprobe.d/ noch die r8168.conf Die ist zwar leer, da ich das blacklist ja zuvor gelöscht habe.
Die Blacklist, bzw. die r8168.conf muss man demnach anscheinend manuell entfernen? Ich hätte gedacht, durch modprobe -r r8168 werden alle Einträge dieses Moduls gelöscht.

Ich bin jedenfalls erleichtert.

Herzlichen Dank!!

[gosia]

Hallo Thats_me,
schön zu hören, dass es jetzt funktioniert. Ich hoffe, morgen auch noch

Ich hätte gedacht, durch modprobe -r r8168 werden alle Einträge dieses Moduls gelöscht.

nicht dass ich wüsste. IMHO musst Du da schon selbst Hand anlegen, aber eine leere Datei in /usr/lib/modprobe.d/ dürfte so oder so keine Rolle spielen. Aber sei einfach mutig, lösche sie und Du merkst was passiert. Lässt sich ja problemlos wieder herstellen.

viele Grüsse gosia

[Thats_me]

Guten Morgen gosia,

Ich hoffe, morgen auch noch

Bis jetzt ja. Ich habe auch heraus gefunden wie ich connman dazu bringe meine DNS-Server zu verwenden und nicht immer raus zu werfen.

leere Datei in /usr/lib/modprobe.d/ dürfte so oder so keine Rolle spielen. Aber sei einfach mutig, lösche sie und Du merkst was passiert. Lässt sich ja problemlos wieder herstellen

Ja ich weiß, möönsch TM, überleg doch mal, wenn diese Datei leer ist, ist es ja klar, dass man sie löschen kann.  Stimmt. In dem Fall hätte es mir klar sein können, da es ein Modul ist das ja weg soll und man Module explizit laden kann und diese in der Bibliothek vorhanden sind.

Beim Löschen bin ich lieber vorsichtig. Das wird ja auch allgemein geraten. Mal bin ich anscheinend zu mutig -Rs beim nm

In der wiki steht:

pacman -Rs <Paketname> Wie oben, zusätzlich werden alle abhängige Pakete gesucht und mit entfernt, falls diese nicht von einer anderen Anwendung gebraucht werden.

Gedanke: Klingt nicht nach etwas Gefährlichem. NetworkManager soll ja komplett weg, weil er sich mit connman nicht verträgt. Was noch gebraucht wird, bleibt ja bestehen.

Dann wieder nicht mutig genug. r8168.conf
Mein Gedanke war/ist.
Es gibt ja unzählige leere Dateien und Verzeichnisse, sowie 0 Byte Dateien. Auch Dateien wo alles mit # kommentiert ist und quasi Vorlagen sind. Wenn da nichts auskommentiert wird, steht da im Grunde auch nichts drin, denn es wird ja nichts ausgeführt, wenn da ein # davor steht.
Es wird Gründe haben, dass manches vom System angelegt wird. Könnte ja sein, dass nach denen irgend wann gesucht wird, sie aber nicht neu angelegt werden, sondern ein Prozess einfach abbricht, wenn nichts gefunden wird.
Ich bin ja kein Programmierer.

[gosia]

Hallo Thats_me,

Mal bin ich anscheinend zu mutig

Klingt nicht nach etwas Gefährlichem

Das ist vielleicht auch wahr, und ich bin in dem Fall zu ängstlich. Sowas ist eine subjektive Entscheidung. Ich mag es eben lieber in kleinen Schritten und wenn es erstmal reicht, dass der Dienst angehalten wird, dann begnüge ich mich vorab damit.
Also lass dich nicht durch mich irre machen. Hauptsache ist, dass Du weisst, was Du tust und warum, es nachvollziehen und notfalls rückgängig machen kannst. Da dies alles für dich zutrifft ist es doch gut.

viele Grüsse gosia

[Thats_me]

Ach Leuts, es ist zum Verzweifeln.

Nun ging es einige Tage mit Umstieg auf connman gut.
Jetzt fängt es wieder an zu zicken.
Dauernd Ausfälle. Paketloss, langsames Netzwerk und NW nicht erreichbar.
Im Sekundentakt.

Also zum Check, ob es mit MX und Networkmanager anders ist.

Siehe da, das selbe. Und wieder, es klapp mit W-Lan einwandfrei.

Meine Schlussfolgerung. Beide Distris haben Probleme mit Realtek 

Man man, worauf man beim Kauf alles achten muss.
Echt keine Lust nur per W-lan unterwegs zu sein. Auch wenn das Risko eines Hacks bei mir in der Gegen wohl eher gering ist.

[Thats_me]

Auf Empfehlung habe ich den dkms aus dem AUR installiert.
Der funktioniert auch nicht wirjklich gut.

Ping mit LAN

xmg:[me]:~$ ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) Bytes an Daten.
64 Bytes von 192.168.5.1: icmp_seq=3 ttl=64 Zeit=1.30 ms
64 Bytes von 192.168.5.1: icmp_seq=4 ttl=64 Zeit=1.10 ms
64 Bytes von 192.168.5.1: icmp_seq=6 ttl=64 Zeit=1.28 ms
64 Bytes von 192.168.5.1: icmp_seq=7 ttl=64 Zeit=1.08 ms
64 Bytes von 192.168.5.1: icmp_seq=14 ttl=64 Zeit=0.855 ms
64 Bytes von 192.168.5.1: icmp_seq=17 ttl=64 Zeit=1.18 ms
64 Bytes von 192.168.5.1: icmp_seq=18 ttl=64 Zeit=1.05 ms
64 Bytes von 192.168.5.1: icmp_seq=19 ttl=64 Zeit=1.35 ms
^C
--- 192.168.5.1 ping-Statistik ---
20 Pakete übertragen, 8 empfangen, 60% packet loss, time 19174ms
rtt min/avg/max/mdev = 0.855/1.151/1.351/0.151 ms

Ping mit W-lan

xmg:[me]:~$ ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) Bytes an Daten.
64 Bytes von 192.168.5.1: icmp_seq=1 ttl=64 Zeit=74.6 ms
64 Bytes von 192.168.5.1: icmp_seq=2 ttl=64 Zeit=98.5 ms
64 Bytes von 192.168.5.1: icmp_seq=3 ttl=64 Zeit=0.771 ms
64 Bytes von 192.168.5.1: icmp_seq=4 ttl=64 Zeit=0.771 ms
^C
--- 192.168.5.1 ping-Statistik ---
4 Pakete übertragen, 4 empfangen, 0% packet loss, time 3028ms
rtt min/avg/max/mdev = 0.771/43.678/98.549/43.733 ms
xmg:[me]:~$

[gosia]

Hallo Thats_me,

Meine Schlussfolgerung. Beide Distris haben Probleme mit Realtek

hilft dir nicht weiter, trotzdem muss ich dieser Schlussfolgerung widersprechen. Schon deshalb, weil meine Ausstattung so aussieht

Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  driver: r8169

und ich habe weder mit Artix noch mit MX irgendwelche Probleme.
Meine Schlussfolgerung: Der Hase liegt irgendwo anders im Pfeffer, fragt sich nur wo? Router, Provider, Kabel, Anschlüsse, Einstellungen, was weiss ich?

viele Grüsse gosia

[Thats_me]

Huhu Gosia.

Hallo Thats_me,hilft dir nicht weiter, trotzdem muss ich dieser Schlussfolgerung widersprechen. Schon deshalb, weil meine Ausstattung so aussieht

Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  driver: r8169

und ich habe weder mit Artix noch mit MX irgendwelche Probleme.
Meine Schlussfolgerung: Der Hase liegt irgendwo anders im Pfeffer, fragt sich nur wo? Router, Provider, Kabel, Anschlüsse, was weiss ich?

viele Grüsse gosia

Es gibt wohl eine neue Bios Version. Aber da ich noch Garantie habe und eine kostenlose Gerneralüberholung, will ich das Update von xmg machen lassen. Das ist im Service mit drin.

Ich habe jeweils sogar extra mit Provider als DNS versucht, da ja mein alternativer theoretisch auch bremsen könnte.
Dumme Frage, wie teste ich am besten, ob es am Provider liegt?
Die Speedtests sind meistens ok.
Nur per LAN verliert er halt Pakete. Ich wüsste jetzt nicht, dass ich etwas falsch konfiguriert hätte.

Wobi connman ja etwas speziell ist und einen eigenen DNS hat. So ganz kapiere ich das nicht.
Ich habe mir diese Notiz gemacht und dort meine eigenen DNS eingetragen.

connman hat eigenen DNS server und ändert immer die resolv.conf.
Eigenen Nameserver in /etc/resolv.conf eintragen
Änderung connman verhindern
sudo chattr +i /etc/resolv.conf

Wenn Nameserver wieder geändert werden sollen
chattr -i /etc/resolv.conf und mit nano bearbeiten.
Danach wieder sperren mit chattr +i /etc/resolv.conf

Ich habe keine Idee, warum W-lan funktioniert und LAN nicht.