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

[JTH]

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.

Du kannst ja zumindest die naheliegendsten Optionen (hier: CONFIG_NFT_NAT, wegen „a non-empty snat file requires NAT in your kernel“) ausprobieren. Wenn sie nicht helfen, nimmst sie wieder raus.

[fischig]

Ich erinnere mich, dass ich dazumalen außer der originalen auch Info bei LUG Krefeld verwendet hatte. Die letzte Info stammt von 2012.

[fischig]

Bingo!
Von den 25 mit „NFT_“ gegreppten Optionen aus meiner 6.1.74-config (in der 6.1.0-16-amd64 sind's erheblich mehr?) habe ich CONFIG_NFT_MASQ, CONFIG_NFT_REDIR und CONFIG_NFT_NAT fest einkompiliert. shorewall check läuft fehlerfrei durch. Das System routet. Dieser Post ist darüber formuliert.

Ich bedanke mich schon mal ausdrücklich bei allen Helfern!

Auf die Tastatur komme ich immer noch nicht. Bootmeldungen hängen, wie o.a. Hier die letzte config.

[smutbert]

Es geht um die eingebaute Tastatur, oder?

Ich habe etwas gesucht und nur eher vage Hinweise gefunden, dass die über PS2 angeschlossen ist. Stimmt das bzw. könntest du das mit einem der funktionierenden Kernel einmal prüfen? Wenn eudev keinen Strich durch die Rechnung macht, geht das einfach mit

Code: Alles auswählen

$ ls /dev/input/by-path

Hast du schon testweise eine USB-Tastatur angeschlossen und es mit der probiert?

(Es wäre ja immerhin theoretisch möglich, dass das Problem eine andere Ursache hat.)

[fischig]

Hast du schon testweise eine USB-Tastatur angeschlossen und es mit der probiert?

Nein, USB-Tastatur besitze ich gar keine. ich habe eben das hier gemacht:

Code: Alles auswählen

ls /dev/input/by-path

Code: Alles auswählen

6.1.74dm1.1
platform-i8042-serio-0-event-kbd    platform-i8042-serio-1-mouse
platform-i8042-serio-1-event-mouse  platform-pcspkr-event-spkr

4.19.201dm1.3
platform-i8042-serio-0-event-kbd    platform-lis3lv02d-event
platform-i8042-serio-1-event-mouse  platform-pcspkr-event-spkr
platform-i8042-serio-1-mouse

?

[Livingston]

i8042

Das ist der uralte Tastatur-Controller aus Vor-USB-Zeiten und wahrscheinlich über PS/2 realisiert.

Ergebnis am Rande: Im 6.1-Kernel hast Du lis3lv02d rausoptimiert. Das ist ein "Accelerometer" / "Abstürzometer" und misst Fallbewegungen. Wird gerne genutzt, um Festplattenköpfe vor einem (echten) Absturz notzuparken.

[JTH]

Wenn ich dich richtig verstehe, fischig, ist das Problem doch gar nicht die Tastatur selbst, sondern ein scheinbar nicht vollständig durchlaufender Boot oder?

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.

Also du kommst einfach nie zu einem Loginprompt, wo du deine Tastatur überhaupt benutzen könntest? (Die muss also nicht zwangsläufig nonfunktional sein?)

Wenn du allerdings per SSH drauf kommst, verrät vielleicht ein Blick ins dmesg nach dem Boot was hilfreiches? Das von dir erwähnte quirk_usb_early_handoff sollte, meiner Vermutung nach, nicht der Knackpunkt sein.

[fischig]

Also du kommst einfach nie zu einem Loginprompt, wo du deine Tastatur überhaupt benutzen könntest? (Die muss also nicht zwangsläufig nonfunktional sein?)

Genau so! Die dmesg-Meldung poste ich, wenn's wieder möglich ist. Muss jetzt erst mal bisschen was „körperlich" schaffen.
Und bei der australischen Camper-Firma muss ich auch noch „die Hosen runterlassen“, aber sowas von komplett!

[fischig]

So, hier also die dmesg-Ausgabe für 6.1.74dm1.1

Wenn ich darin nach „Keyboard“ greppe kommt:

Code: Alles auswählen

input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4

[fischig]

Ich habe lis3lv02d (indirekt, via X86_PLATFORM_DRIVERS_HP) wieder einkompiliert. Bringt aber keine Besserung. Damit bin ich wieder am Ende meines Lateins.
Könnte ein Vergleich der configs für 6.1.-Standard-Kernel und 6.1.74-Eigenbau helfen? wie könnte der helfen?

[fischig]

Mir kommt der Verdacht, das ist kein Tastatur, sondern ein Bildschirmproblem. Darauf gekommen bin ich, weil Strg+alt+entf funktionierte. Danach habe ich mich mal blind als root eingeloggt und konnte rebooten.
Eine GUI ist nicht installiert.
lspci -nnk:

Code: Alles auswählen

VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 7310] [1002:9809]
	Subsystem: Hewlett-Packard Company Wrestler [Radeon HD 7310] [103c:18d4]

sagt mir kernelmäßig gar nichts.

cat config 6.1.74dm1.2 | grep RADEON:

Code: Alles auswählen

CONFIG_DRM_RADEON=y
# CONFIG_DRM_RADEON_USERPTR is not set
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set

[Livingston]

Für einen Radeon-Treiber-Fehler spricht:

Code: Alles auswählen

[    1.545719] radeon 0000:00:01.0: Direct firmware load for radeon/PALM_pfp.bin failed with error -2
[    1.545737] r600_cp: Failed to load firmware "radeon/PALM_pfp.bin"
[    1.545746] [drm:evergreen_init] *ERROR* Failed to load firmware!

Wenn Du testweise in Lilo mal auf die einfache Textconsole mit 80x25-Auflösung umstellst, lässt sich vielleicht mehr sehen. Ich meine das geht in lilo.conf mit

Code: Alles auswählen

vga=normal

Lilo... ist lange her

NACHTRAG:
Ist das Paket firmware-amd-graphics installiert? Darin ist radeon/PALM_pfp.bin enthalten. Ich stöbere auch gern bei anderen Distris. Gentoo sagt zur Kernel-Config von Radeon: https://wiki.gentoo.org/wiki/Radeon#General

NACHTRAG 2:
Wenn ich schon mal dabei bin: Nach Durchsuchung der dmesg-Ausgabe fand ich noch fehlende Firmware für Realtek und Broadcom. Kannste ja schon mal auf den Merkzettel setzen.

[smutbert]

Außerdem kommt für deine Grafik normalerweise bei aktuellen Kerneln amdgpu als Treiber zum Einsatz, für die Konsole bräuchtest du dazu CONFIG_DRM_AMDGPU und vielleicht auch eine oder mehrere der folgenden: CONFIG_DRM_AMDGPU_CIK, CONFIG_DRM_AMDGPU_SI, CONFIG_DRM_AMDGPU_USERPTR

[Livingston]

@smutbert: Scheint ein etwas älteres Kaliber zu sein, daher wahrscheinlich keine amdgpu sondern die Radeon-Schiene. Insbesondere wird genau fischigs Gerätekombination weiter unten in meinem Link erwähnt: Evergreen -> PALM -> HD7310

[smutbert]

Das ist mir klar, deswegen habe ich etwas gesucht, bevor ich meinen Beitrag geschrieben habe und es erweckt hier [1] den Eindruck als wäre amdgpu schon richtig. (Sicher bin ich mir trotzdem auch nicht und es gibt ja eventuell auch funktionierende Alternativen zu amdgpu.)

[1] https://linux-hardware.org/?id=pci:1002-9809-1025-0690

[fischig]

Code: Alles auswählen

CONFIG_DRM_AMDGPU

Das wäre meine nächste Vermutung gewesen. DER Bestandteil ist namlich nicht einkompiliert. vga=normal zeigt immerhin Wirkung: den von so vielen gefürchteten „schwarzen Bildschirm. Ich sehe gerade, dass lilo jetzt auch in sid nicht mehr angeboten wird. Werd' ich wohl doch nach was anderem Ausschau halten müssen (Kp97s Empfehlung: extlinux). Eigentlich schade. Für „einfache“ Nicht-EFI-Maschinen finde ich lilo nach wie vor am einfachsten. Mal schauen, was amdgpu auf dieser vermaledeiten HP-Maschine bringt.

[smutbert]

Aber versuch zuerst schon die Installation von firmware-amd-graphics, die Livingston vorgeschlagen hat – möglicherweise genügt das ja schon, dass der einkompilierte radeon-Treiber funktioniert.

[fischig]

Aber versuch zuerst schon die Installation von firmware-amd-graphics

Oh, die Info für euch ist mir irgendwie wieder abhanden gekommen: Das Paket ist bereits installiert.

[Livingston]

Nur, um noch mal sicherzugehen: Da das Firmwarepaket firmware-amd-graphics installiert ist, müsste jetzt eine Datei namens /lib/firmware/radeon/PALM_pfp.bin existieren. Befindet sie sich bei Dir am richtigen Platz?
Falls nicht, installiere das Paket bitte noch mal neu.

[fischig]

Ich habe das Ganze jetzt erst mal sukzessive auf daedalus gehoben. firmware-amd-graphics war und ist installiert, ebenso war und ist /lib/firmware/radeon/PALM_pfp.bin vorhanden. Aber einen Prompt habe ich nach wie vor nicht. Z.Z. kompiliere ich zusätzlich

Code: Alles auswählen

CONFIG_DRM_AMDGPU_SI=y
CONFIG_DRM_AMDGPU_CIK=y
CONFIG_DRM_AMDGPU_USERPTR=y

[Livingston]

Tja, ich habe nachgefragt, weil auch ich gerade im Nebel herumstocher. Der Standardpfad für Firmware ist /lib/firmware und der Kernel sucht unterhalb dieses Pfades radeon/PALM_pfp.bin, also zusammengesetzt /lib/firmware/radeon/PALM_pfp.bin.
Nun frage ich mich, wieso der Kernel nicht fündig wird, denn

Code: Alles auswählen

[    1.545719] radeon 0000:00:01.0: Direct firmware load for radeon/PALM_pfp.bin failed with error

steht im direkten Widerspruch zu Deiner Beobachtung, dass diese Firmware-Datei an ihrem Platz sitzt.
Ein Rätsel!
Kann noch jemand etwas dazu mit mehr Kenntnis zum Lademechanismus der Firmware beitragen?

[fischig]

So, das war's wohl. Nach einer abgebrochenen Kompilation heute nacht ist sie heute morgen durchgelaufen. Meine Herren, was hat der compiler mit dem amdgpu-Gedöns lange rumgerödelt! HP-Müll? Brauch' ich das eigentlich? Wie gesagt, es gibt keine GUI und wird auf dem System auch nie eine geben. dmesg meckert nicht mehr über „radeon“ - warum auch immer. Prompt ist wieder da und routen tut's auch! Nochmals Dank an alle, die mitgeholfen haben!

Vielleicht ist das noch von Interesse:

Code: Alles auswählen

# dpkg -i linux-image-6.1.74dm1.2_6.1.74_amd64.deb
[...]
linux-image-6.1.74dm1.2 (6.1.74) wird eingerichtet ...
dkms: autoinstall for kernel 6.1.74dm1.2 was skipped since the kernel headers for this kernel do not seem to be installed.

Die mitkompilierten headers habe ich bisher nie installiert, aber auch noch nie vermisst.

[Livingston]

Hossa! Glückwunsch, fischig
Was man doch mit ein wenig Ausdauer alles hinbekommt.

HP-Müll? Brauch' ich das eigentlich?

Vielleicht... dahinter kann sich alles mögliche verbergen. ACPI-Funktionen für den Klappdeckel, spezielle Tasten und wahrscheinlich Stromsparoptionen. Schaden kann es wohl nicht. Im Zweifelsfall einfach noch mal gemütlich hinterherrecherchieren.

dkms: autoinstall for kernel 6.1.74dm1.2 was skipped since the kernel headers for this kernel do not seem to be installed.[/code]
Die mitkompilierten headers habe ich bisher nie installiert, aber auch noch nie vermisst.

Passt doch ganz hervorragend zu Deinem Minimalkonzept. Auch hier würde ich sagen: Kannst ja noch mal recherchieren, was sich dahinter verbirgt. Wenn Du nichts vermisst, brauchst Du es wohl auch nicht.

[smutbert]

dmesg meckert nicht mehr über „radeon“ - warum auch immer.

Ziemlich sicher, weil radeon jetzt gar nicht mehr zum Einsatz kommt. Die ganze Idee war ja, dass dann statt radeon amdgpu zum Einsatz kommt.

Code: Alles auswählen

[...]
linux-image-6.1.74dm1.2 (6.1.74) wird eingerichtet ...
dkms: autoinstall for kernel 6.1.74dm1.2 was skipped since the kernel headers for this kernel do not seem to be installed.

Die mitkompilierten headers habe ich bisher nie installiert, aber auch noch nie vermisst.

dkms, von dem die Meldung stammt, dient nur dazu automatisiert Kernelmodule zu bauen, die nicht zum offiziellen Kernel gehören (wie zum Beispiel die nvidia-Treiber oder Dateisysteme wie zfs). Damit solche Module gebaut werden können braucht es die zum Kernel passenden Header.
Nachdem du offensichtlich keine derartigen Module nutzt, kannst du dkms getrost deinstallieren.

[fischig]

Was man doch mit ein wenig Ausdauer alles hinbekommt.

Manche nennen' Sturheit.