Devuan, Router, Eigenbaukern 6.1, NAT, NFT_MASQ, NFT_NAT, amdgpu (gelöst)

[fischig]

Ich bin immer noch beschäftigt mit dem hier bereits vorgestellten Problem.
Ich habe eine Maschine, die ich hinter dem DSL-Router als Devuan-Router benutze. Ich bin mittlerweile zurück auf einem beowulf-backup (vgl.bar Debian Buster). Es wird kein initrd.img benutzt. Als firewall ist shorewall installiert, weiterhin hostapd. Ein damals aktueller 4.19er Eigenbau-Kernel (4.19.201) tut auf der Maschine, was sie tun soll. Beim neu kompilierten Kernel 6.1 (6.1.60) (kompiliert mit der config für den 4.19) bleiben die Boot-Meldungen hängen (letzte Meldung ist irgegndwas mit „quirk_usb_early_handoff“), aber offenbar läuft der Bootvorgang weiter, die Netzwerkkarten werden konfiguriert, ich kann mich via ssh einloggen und in beide Richtungen (lan/DSL-Router, Internet) mit Namen, nicht nur IPs, pingen. Per Tastatur einloggen kann ich mich nicht. Von einem Client aus erreiche ich das Internet nicht. Ich stelle mal folgende Ausgaben: ip a, route -n, shorewall check, außerdem die configs sowohl für 4.19 als auch 6.1 nach nopaste, in der Hoffnung jemand kann mir weiterhelfen, wie ich den Kernel 6.1. auf dem Router zum Laufen bekomme.

config 4.19: pastebin/?mode=view&s=42079
config 6.1: pastebin/?mode=view&s=42080
Ausgaben 4.19: pastebin/?mode=view&s=42081
Ausgaben 6.1: pastebin/?mode=view&s=42082

[Livingston]

Beim neu kompilierten Kernel 6.1 (6.1.60) (kompiliert mit der config für den 4.19) bleiben die Boot-Meldungen hängen...

Dazu fällt mir spontan nur ein, dass Du Glück hast, überhaupt so weit zu kommen. Die Kernel-Versionen sind kilometerweit Jahre voneinander entfernt. Ganze Blöcke in der Config können verschoben sein, alte Bereiche sind teilweise ausgemustert, neue und notwendige gar nicht berücksichtigt. Ich kann mir kaum vorstellen, dass das gutgeht.
Bei einer evolutionären Weiterentwicklung der Config zwischen kleineren Versionssprüngen hättest Du u.U. nachverfolgen können, wo Probleme auftauchen, aber in diesem Fall steht wohl eher ein kompletter Neuaufbau an.

Die Frage, ob der Routerhersteller evtl. eigene Module oder Patches abseits der Hauptentwicklungslinie von kernel.org voraussetzt, steht zusätzlich auch noch im Raum.

[fischig]

Ich kann mir nicht vorstellen, dass da viel fehlt. es ist ja nicht mehr als ein Grundsystem + shorewall, drei NICs und hostapd. Ich müsste nur wissen was. Ich kann natürlich noch mal versuchen alle LTS-Versionen da-zwichen durchzuhoppen - aber was könnte das bringen? Die Maschine ist ein HP Pavillion DM-1.

[Livingston]

Ein HP Pavillion DM-1, kein klassischer Router -> Das ist doch schon mal gut, dann ist zumindest das zweite Problem (Extra-Module, Patches) vom Tisch.

Was das andere Problem angeht: Wenn man schon beim Kompilieren erfassen könnte, wo sich die alte Config nicht in den neuen Kernel einfügt, könnte man sich vielleicht das Springen durch die Vorgängerversionen ersparen. Ich schaue mich auch mal mit nach Debug-Optionen um.

Ich muss gestehen, dass ich schon lange keine Kernel-Config mehr von Grund auf neu gebaut habe. Allenfalls habe ich in den letzten 10 Jahren mal ein paar zusätzliche Gerätetreiber aktiviert, um exotische Hardware lauffähig zu machen. Das Herausnehmen von Optionen aus den Innereien dieses komplexen Ungeheuers ist mir aber ein wenig unheimlich geworden.
Wird bestimmt spannend, mal sehen, was dabei rauskommt.

[fischig]

„Eigentlich“ fand ich das gar nicht so schwer, solange es im wesentlichen nur um ein einfaches Grundsystem ging. Einmal mit defconfig (inclusive devtmpfs) kompiliert und dann kann man ein einfaches Grundsystem mit eigebauter HD zum Laufen bringen und ausbauen. So habe ich das vor ca. 15 Jahren angefangen und mit den aktualisierten Eigenbau-Kernen laufen immer noch alle aktuellen Linuxe, sowohl Debian als auch Devuan. Mit einer Ausnahme: Am Fernsehrechner, mit dem ich mich so wenig wie möglich beschäftigen will, läuft halt seit jessie Standard-Debian mit systemd. Dem als Nicht-ITler einen selbst gebauten Kernel zu verpassen habe ich aufgegeben. So was in der Richtung könnte dem Poettering ja auch vorgeschwebt haben.
Vielleicht hängt's auch am vermaledeiten shorewall. Mit der im nopaste geposteten Fehlermeldung weiß ich aber nichts anzufangen. Und auf shorewall möchte ich auf einer Router-Maschine ungern verzichten. Paketfilter händisch zu konfigurieren traue ich mir nicht zu.

Der Plan war: eine aktuelle Kernel-Version zu bauen und danach das Devuan-System zu aktualisieren. Ich probier jetzt vielleicht mal den anderen Weg: Ich bring' das beowulf-System auf daedalus und versuche dann den passenden Kern zu bauen. Ein backup des laufenden beowulf habe ich. Aber die Zeit wird langsam knapp.
Gestern Abend habe ich die nach 4.19. noch verfügbare nächste longterm-Version (5.4.) kompiliert. Mal schauen ob's tut.

[TRex]

Dem als Nicht-ITler einen selbst gebauten Kernel zu verpassen habe ich aufgegeben. So was in der Richtung könnte dem Poettering ja auch vorgeschwebt haben.

Niemand hat was davon, dir den Eigenbau zu vermiesen. Es ist nur Arbeit...

Aber mal was ganz absurdes: hast du mal versucht, den Kernel mit der Standardkonfiguration zu bauen und zu booten? Oder weißt du bereits, dass der irgendwas besonderes braucht? Eigentlich musst du ja nicht einmal bauen, du könntest auch den Kernel von debian sid/backports verwenden (deb runterladen und installieren).

[fischig]

du könntest auch den Kernel von debian sid/backports verwenden (deb runterladen und installieren).

Das dürfte einfach sein. Aber dann im aktuellen Fall vielleicht doch eher den Devuan-Standard-Kernel für daedalus. (eudev/udev!)

edit:
Hmmm, Standard-Kernel für daedalus per apt installiert, keine Abhängigkeitskonflikte erkennbar. Aber das hier:

Code: Alles auswählen

I: The initramfs will attempt to resume from /dev/sda1
I: (UUID=a4f15ed4-7e0f-48e4-9a76-446a48aa6fe2)
I: Set the RESUME variable to override this.
/etc/kernel/postinst.d/zz-runlilo:
Warning: LBA32 addressing assumed
/dev/mapper/control: open failed: No such device
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.155 (2018-12-18) and kernel driver (unknown version).

Bootloader ist lilo. In fstab stehen keine UUIDs (schafft lilo nicht, soweit ich weiß). sda1 sollte swap sein. Ausführung von lilo spricht nur Warnung, keine Fehler aus. Keine Ahnung was ein device-mapper ist. Begriff „map“ kann ich nicht übersetzen, kann wohl alles mögliche bedeuten. Deepl hilft mir da nicht.

edit2: Kern bootet und Maschine routet.

[TRex]

edit2: Kern bootet und Maschine routet.

Dann weißt du nun immerhin, dass es nur an veralteten Bestandteilen deiner Config liegt.

[rhHeini]

Keine Ahnung was ein device-mapper ist. Begriff „map“ kann ich nicht übersetzen, kann wohl alles mögliche bedeuten.

In /dev/mapper liegen z.B. die Verweise auf LVM-Logische Volumes und entschlüsselte luks-Container. Auszug aus meinem Devuan Daedalus mit Vollverschlüsselung und LVM:

Code: Alles auswählen

nvme0n1p8_crypt
vgDsys-1_root
vgDsys-2_swap 

[fischig]

Und wie checkte ich jetzt

Code: Alles auswählen

that device-mapper is available in the kernel.

?

[smutbert]

Der device mapper wird bei dir eher irrelevant sein, ohne lvm, raid oder verschlüsselung.

Entweder ist im Kernel keine Unterstützung dafür (CONFIG_BLK_DEV_DM) vorhanden oder es hat einfach jemand/etwas vergessen die Gerätedatei (/dev/mapper/control) anzulegen (bei dir kommt dafür wohl hauptsächlich eudev (?) in Frage).

[fischig]

(bei dir kommt dafür wohl hauptsächlich eudev (?) in Frage)

Dachte ich mir schon, dass das ungeliebte Teil da seine schmutzigen Finger im Spiel hat, egal, ob's nun eudev oder udev heißt.
Das sollte vorhanden sein; config-6.1.0-16-amd64:

Code: Alles auswählen

CONFIG_BLK_DEV_DM_BUILTIN=y
CONFIG_BLK_DEV_DM=m

Keine Ahnung ob's geladen wird. Bei lsmod taucht's nicht auf. Laden via modprobe lässt sich's nicht.

Der device mapper wird bei dir eher irrelevant sein

Kann ich also beim jetzigen Stand der Dinge erstmal zurückstellen - richtig?

[Livingston]

Kann ich also beim jetzigen Stand der Dinge erstmal zurückstellen - richtig?

Wenn Du ohne devicemapper auskommst (also ohne Plattenverschlüsselung, RAID und LVM) brauchst Du den nicht.
eudev ist übrigens ein fork von udev. eudev wird völlig unabhängig von systemd weiterentwickelt. In Devuan ist udev nur noch ein Metapaket, dass eudev nach sich zieht.

[fischig]

eudev ist übrigens ein fork von udev. eudev wird völlig unabhängig von systemd weiterentwickelt.

Ich weiß, aber so wenig man udev in Debian benötigt, so wenig benötigt man eudev in Devuan. OK, es mag komplexe Umgebungen geben, in denen der Admin ohne eines der beiden verrückt werden mag. In einfacheren Umgebungen halte ich es für überflüssig, um nicht zu sagen störend.
Aber darum will ich nicht streiten. Ich lass es zumindest so lange, bis ich einen eigenen funktionierenden Kern habe, im System. Danach kann man weiter sehen.

[smutbert]

Ja, ich denke der devicemapper steht auf der Prioritätenliste aktuell ziemlich weit unten und hat mit dem eigentlichen Problem nichts zu tun.


Vorausgesetzt ich habe die aktuelle Situation überhaupt richtig verstanden?
Der selbst kompilierte Kernel 6.1 läuft grundsätzlich, aber einige Dinge funktionieren damit nicht richtig:

1. die lokale Anmeldung über Bildschirm und Tastatur geht nicht (im Gegensatz zur Anmeldung über ssh)
2. die Routerei funktioniert auch nicht richtig

Auch wenn es wahrscheinlich auch nichts mit dem Hauptproblem zu tun hat, würde es mich interessieren, was 1. genau bedeutet. Funktioniert die Tastatur überhaupt nicht oder kannst du zumindest mit <Strg>+<Alt>+<F1-F10> zwischen den Textkonsolen hin- und herschalten?

Zu 2. hast du gesagt, dass die Clients das Internet nicht erreichen. Untereinander erreichen sich die Clients aber schon?
Die Meldung legt die Vermutung nahe, dass shorewall meint, der kernel würde NAT und/oder iptables nicht unterstützen:

Code: Alles auswählen

ERROR: a non-empty snat file requires NAT in your kernel and iptables /etc/shorewall/snat (line 12)

Ich habe von shorewall keine Ahnung, aber was steht denn in der »/etc/shorewall/snat«?

[fischig]

Ich denke, du hast mich 100pro zutreffend interpretiert.

was steht denn in der »/etc/shorewall/snat«?

Steht im nopaste.

Tastatur funktioniert gar nicht. +<Alt>+ sollte überflüssig sein, keine GUI, ebensowenig wie X, installiert.
Per ssh kann ich nicht nur den Debian-Router, sondern die clients können sich untereinander per ssh erreichen (Eigenbau 6.1.60).

edit:
nat und iptabels sind einkompiliert. Es gibt allerdings Kernel-Bestandteile, die diese Bezeichner ebenfalls enthalten, und die nicht kompiliert sind. Aber weder in dem (funktionierenden) 4.19er noch in dem 6.1er Eigenbau.

[Livingston]

ERROR: a non-empty snat file requires NAT in your kernel and iptables /etc/shorewall/snat (line 12)

Das sieht verschärft danach aus, als müsste der Kernel überzeugt werden, NAT und Forwarding zu erlauben.
Was sagt denn

Code: Alles auswählen

# cat /proc/sys/net/ipv4/ip_forward

Wenn da 0 rauskommt, muss man es aktivieren:

Code: Alles auswählen

echo "1" > /proc/sys/net/ipv4/ip_forward

Sollte /proc/sys/net/ipv4/ip_forward selbst gar nicht vorhanden sein, fehlt wohl was in der Config und der Kernel stellt deshalb diesen Schalter nicht zur Verfügung. Kann sein, dass shorewall diese Einstellung üblicherweise vornimmt, aber wenn die Datei in /proc gar nicht existieren sollte, beißt sich shorewall natürlich die Zähne aus.

ERGÄNZUNG: /proc/sys/net/ipv4/ip_forward wird durch den Config-Eintrag CONFIG_IP_ADVANCED_ROUTER=y ermöglicht. Laut pastebin ist der vorhanden. Vielleicht fehlen aber noch ein paar Abhängigkeiten, damit der Schalter wirksam wird.

[fischig]

/proc/sys/net/ipv4/ip_forward wird durch den Config-Eintrag CONFIG_IP_ADVANCED_ROUTER=y ermöglicht. Laut pastebin ist der vorhanden.

Korrekt. und

Code: Alles auswählen

# cat /proc/sys/net/ipv4/ip_forward

liefert auch die 1.

[smutbert]

Fast dasselbe wie Livingston hätte ich auch geschrieben...

Steht im nopaste.

Ah, die Zeilen habe ich übersehen.

Ich gehe dann am ehesten davon aus, dass es eigentlich nur an shorewall scheitert. Am ehesten hilft es wohl verdächtige Konfigurationsoptionen zwischen dem Standarddebiankernel und deinem selbst kompilierten Kernel (beides 6.1) zu vergleichen. Das hat ein bisschen was von der Suche nach der Nadel im Heuhaufen.

Gestoßen bin ich bis jetzt nur auf CONFIG_IP6_NF_TARGET_MASQUERADE, das bei deiner Konfiguration nicht aktiviert ist. Ich gehe zwar davon aus, dass du ipv4 verwendest, aber shorewall könnte die nichtvorhandene ipv6-NAT-Unterstützung als komplett fehlende NAT-Unterstützung interpretieren.
(Ist etwas weit hergeholt, aber das einzige was ich bis jetzt gefunden habe.)

[fischig]

Gestoßen bin ich bis jetzt nur auf CONFIG_IP6_NF_TARGET_MASQUERADE, das bei deiner Konfiguration nicht aktiviert ist.

Das wäre ein möglicher Fehler. Ab wann gibt es diese Option? in meiner config 6.1.60 ist die gar nicht aufgeführt, wohl aber in der für den Devuan-Standard 6.1.0-16-amd64.
Macht das Sinn, die Quellen für aktuelle Version 6.1.74 bei kernel.org nur für diese mögliche Fehlerbehebung zu holen? Eine aktuelle config mit allen verfügbaren Optionen kriege ich da ja erst mal nicht.

Hey!, das ging ja einfach. config-6.1.60 als .config nach /usr/src/linux-6.1.74 kopiert und schon bot mir make menuconfig die fehlende Option an. Schau'n mer mal, was rauskommt. Etwas verändert gegenüber dem Standardkern habe ich's:

Code: Alles auswählen

<*>   ip6tables NAT support  
<*>     MASQUERADE target support

edit:
Das war leider ein Fehlversuch. Alles wie gehabt.

[Livingston]

Wie ist das eigentlich mit dem iptables-Unterbau? Ist oder wird das Ganze nicht umgestellt auf nftables?
Kann das so weit gehen, dass eine alte Kernel-Config in Sachen Netzwerkerei gar nicht mehr zu neueren Kerneln kompatibel ist?

[smutbert]

iptables wird in den neueren Kerneln über nftables umgesetzt und die zugehörigen Kerneloptionen sind soweit ich das sehe bei fischig alle aktiviert. Ob es trotzdem dazu kommen kann, dass es mit iptables nicht mehr funktioniert, weiß ich allerdings nicht.

Bei fischig jedenfalls scheitert es wohl an der Zusammenarbeit von Kernel und shorewall, aber ich habe momentan auch keine brauchbare Idee wie wir der Sache auf die Spur kommen könnten.

[fischig]

Wir sollten ncht vergessen, dass ich nicht an die Tastatur komme.

[JTH]

Wir sollten ncht vergessen, dass ich nicht an die Tastatur komme.

Du machst es dir mit dem System ja (unfreiwillig) wieder extra leicht

Am ehesten hilft es wohl verdächtige Konfigurationsoptionen zwischen dem Standarddebiankernel und deinem selbst kompilierten Kernel (beides 6.1) zu vergleichen.

in meiner config 6.1.60 ist die gar nicht aufgeführt, wohl aber in der für den Devuan-Standard 6.1.0-16-amd64.
Macht das Sinn, die Quellen für aktuelle Version 6.1.74 bei kernel.org nur für diese mögliche Fehlerbehebung zu holen? Eine aktuelle config mit allen verfügbaren Optionen kriege ich da ja erst mal nicht.

Ich find es für dich hier auch am zielführendsten, die Konfiguration eines funktionierenden Kernels mit deiner eigenen zu vergleichen – möglichst auf der gleichen Kernelversion. Alles andere ist doch eher fröhliches Optionenraten.

Du musst dir dafür ja nicht die Kernelquellen noch von einer zusätzlichen Quelle besorgen. Wenn der „Devuan-Standard 6.1.0-16-amd64“ tut, was du erwartest, nimm dessen Config.

Shorewalls Auflistung nötiger Kerneloptionen ist leider überholt („This article is unmaintained.“).

Nur ganz kurz in deine config-6.1.60 reingeguckt: Ich kann mir vorstellen, dass du CONFIG_NFT_NAT und verwandte aktivieren musst. iptables (wovon Shorewall spricht) ist, meine ich, inzwischen größtenteils nur ein Kompatibilitätsaufsatz zu nftables – entsprechend könnte es bei dir an den ungesetzten CONFIG_NFT_* scheitern. (Wie die Lottozahlen – ohne Gewähr )

[fischig]

dass du CONFIG_NFT_NAT und verwandte aktivieren musst

Daran hatte ich von Anfang an auch gedacht, aber das ist ein Haufen Zeug, von dem ich vieles vielleicht nicht brauche, aber alles aktivieren muss, wenn's nicht zu einem „fröhlichen Optionenraten“ ausarten soll. Sinn der Sache ist ja eigentlich, einen möglichst schlanken Kernel zu bauen.

Gibt's eigentlich was Adäquates zu shorewall, möglichst mit deutschsprachiger Literatur? Shorewall ist ja doch wohl „überabgehangen“/tot.