Hallo Erdie,Erdie wrote:Ich habe keine Lust mein stabil laufendes System in ein unstabil laufenden System zu verwandelt und dafür auch noch Geld zu investieren.
Code: Select all
# more /etc/portage/package.accept_keywords
sys-firmware/intel-microcode
sys-kernel/gentoo-sources
sys-kernel/linux-headers
x11-apps/igt-gpu-tools
app-crypt/ima-evm-utils
games-board/xboard
games-board/polyglot
games-board/stockfish
app-admin/kernel-hardening-checker
games-strategy/wesnoth
Ich persönlich bin auf ~amd64 und habe keine Probleme mit meiner RX 9070 XT festgestellt.Erdie wrote:Laut Recherche soll >= 6.14 stabil sein. Welche Kernelversion würdest Du mir denn empfehlen wenn ich die neue Karte in Betrieb nehme?
Ich werde von Nvida auf AMD migrieren müssen. Es wird also auf Anhieb nicht gehen, sondern ein paar Änderungen nötig sein. Da muss ich mich für einen Kernel entscheiden.
Ne das funktioniert relativ problemfrei, es reicht VIDEO_CARDS+="amgpu radeonsi" und im Kernel DRM_AMDGPU zu aktivieren, zusätzlich hab ich alle Unteroptionen (in menuconfig) aktiviert. Ob noch zusätzliche USEs dafür gebraucht werden weiß ich aktuell nicht mehr, sowas wie vulkan und ähnliches hab ich nicht mehr auf dem Schirm.Erdie wrote:Ausserdem frage ich mich, ob es für die Migrationphase ok ist, erstmal sys-kernel/nvidia-drivers nicht sofort zu entfernen, damit ich bei Problemen schnell zurück kann. Oder blockiert sich das gegenseitig?
Code: Select all
VIDEO_CARDS="amdgpu radeonsi zink"
Code: Select all
sys-kernel/cachyos-sources-6.12.49
media-libs/mesa-25.2.6
Auf welche Kernelversion bist du den genau hochgegangen?Max Steel wrote:
Ich persönlich bin auf ~amd64 und habe keine Probleme mit meiner RX 9070 XT festgestellt.

LLMs wie ChatGPT halluzinieren, wenn sie die Antwort nicht genau wissen und erfinden dann irgendwas. Daher ist das nie eine vertrauenswürdige Quelle.Erdie wrote:Es ist nur so, ich hatte Chatgpt gefragt, ob bei der relativ neuen Karte (Juni 2025) Komplikationen zu erwarten sind und der Kollege Computer wollte mir weißmachen, dass dieses durchaus der Fall ist. Aber man sollt eich von einer Maschine wohl besser nicht kirre machen lassen. Der hat mir auich schon viel Blödsinn erzählt. Aber Coden kann er gut ..
Ich muss ja nicht ungedingt testing komplett demaskieren. Es reicht ja nur eine version, die den Treiberansprüchen genügt und dann so lange warten, bis die von einer stabilen Version überholt wird. Ich werde mal ein Version herauspicken und die schon im Vorfeld vorbereiten und bauen.misterjack wrote: Bei ~amd64 nimmt er ja automatisch den neuesten im Portage verfügbaren. Der größte Unterschied zwischen Testing und Stable ist, dass du wesentlich öfters am Kernel-Aktualisieren bist, wenn man das System regelmäßig aktuell hält.

Warum sollte man das tun? Jedes Minor-Update behebt Fehler, siehe https://www.kernel.org/category/releases.html „After each mainline kernel is released, it is considered "stable." Any bug fixes for a stable kernel are backported from the mainline tree and applied by a designated stable kernel maintainer. There are usually only a few bugfix kernel releases until next mainline kernel becomes available” - die willst du schon mitnehmen.Erdie wrote:Ich muss ja nicht ungedingt testing komplett demaskieren. Es reicht ja nur eine version, die den Treiberansprüchen genügt und dann so lange warten, bis die von einer stabilen Version überholt wird. Ich werde mal ein Version herauspicken und die schon im Vorfeld vorbereiten und bauen.
Das will ich doch tun. Aber für die Migration möchte ich einen neueren Kernel mit akutellen Treibern aus ~. In diesem Fall die neuste Version 6.17.7 Dieser wird in Kürze hoffentlich von stable eingeholt und dann fahre ich auf der stable Schiene weiter. Ich möchte nicht dauerhaft auf ~bleiben. Oder hab ich dich jetzt falsch verstanden?misterjack wrote:Warum sollte man das tun? Jedes Minor-Update behebt Fehler, siehe z.B. https://cdn.kernel.org/pub/linux/kernel ... Log-6.17.7 - die willst du schon mitnehmen.Erdie wrote:Ich muss ja nicht ungedingt testing komplett demaskieren. Es reicht ja nur eine version, die den Treiberansprüchen genügt und dann so lange warten, bis die von einer stabilen Version überholt wird. Ich werde mal ein Version herauspicken und die schon im Vorfeld vorbereiten und bauen.
Hab auch mal einen Blick auf https://www.kernel.org/ – Stable ist in Gentoo Testing und Longterm in Gentoo Stable. Es spricht wirklich nichts dagegen, den aktuellsten Stable Kernel zu nehmen.

Ja, sobald 6.17.8 rauskommt, ist es nicht sinnvoll, auf 6.17.7 zu bleiben. Wie gesagt, da werden Bugfixes ausgespielt, möchtest du dann wirklich auf einer verbuggten Version stehen bleiben? Daher am besten 6.17 demaskieren und die Updates mitnehmen. Und da 6.18 LTS werden soll, ist es sowieso ratsam, auch auf diesen zu wechseln. Auf dem kannst du dann bleiben.Erdie wrote:Oder hab ich dich jetzt falsch verstanden?
So möchte ich das auch machen. Solange den ~ Schiene unter 6.18 bleibt, und diese nicht überholt, folge ich den Updates um final auf 6.18 zu kommen.misterjack wrote:Ja, sobald 6.17.8 rauskommt, ist es nicht sinnvoll, auf 6.17.7 zu bleiben. Wie gesagt, da werden Bugfixes ausgespielt, möchtest du dann wirklich auf einer verbuggten Version stehen bleiben? Daher am besten 6.17 demaskieren und die Updates mitnehmen. Und da 6.18 LTS werden soll, ist es sowieso ratsam, auch auf diesen zu wechseln. Auf dem kannst du dann bleiben.Erdie wrote:Oder hab ich dich jetzt falsch verstanden?
Wenn du uefi zum starten von grub nutzt könnte es an einer unpassenden video module konfiguration liegen.Erdie wrote:Ich habe die neue Karte jetzt am Laufen. Geht bis jetzt gut. Ein Problem habe ich noch: Ich kann das Grub Menü nicht sehen. Das ist schwarz. Hat jemand eine Idee, woran das liegen kann?
Code: Select all
insmod all_video
Bei einem multimonitor Setup mit unterschiedlichen Auflösungen kann es auch sinnvoll sein die größe vorzugeben:firefly wrote:In meiner grub.cfg habe ich folgene insmod zeile drinn (global, aka außerhalb eines menuentry)Erdie wrote:Ich habe die neue Karte jetzt am Laufen. Geht bis jetzt gut. Ein Problem habe ich noch: Ich kann das Grub Menü nicht sehen. Das ist schwarz. Hat jemand eine Idee, woran das liegen kann?Code: Select all
insmod all_video
Code: Select all
set gfxmode="1920x1080x24"Code: Select all
insmod gfxtermCode: Select all
set gfxmode="1920x1080x24"
insmod all_video
insmod gfxterm
loadfont unicodeCode: Select all
insmod all_video
Korrekt. uEFI benötigt eine GPT Partitionstabelle, eine EFI System Partition (ef00) auf dem ein FAT32 mit den *.efi Bootfiles liegt (grub stage0) und einen Eintrag in den efi bootmgr (efibootmgr)Erdie wrote:Meine Vermutung ist, dass es am legacy boot liegt. Irgendwann muss ich ohnehin auf EFI umstellen. Da führt wohl nichts dran vorbei. Wenn ich das mache, ist es doch auch notwenig auf GPT umzusteigen, ist das richtig?
Code: Select all
Boot0002* gentoo HD(1,GPT,12345678-abcd-efgh-ijkl-9abcdefghijk,0x800,0x32000)/\EFI\GENTOO\GRUBX64.EFISoweit ich weiß hat AMD ein Problem bekommen und einen DP->HDMI Converter aufs Board gepackt, da das HDMI-"Forum" denen verbot den für HDMI nötigen Code direkt in den quelloffenen Treiber auszuliefern, soweit ich das mal gelesen habe.Erdie wrote:Mir ist noch eine Idee gekommen: Kann es sein, dass die Graka zum Bootzeitpunkt erst auf Displayport ausgibt und erst später auf HDMI umschaltet? Leider hat mein Monitor keine Displayport und ich kann das daher nicht testen, es sei denn, Ich kauf mir einen neuen Monitor, was ich eh mal vorhatte.
Ja, das UEFI Bios kann ich sehen. Mein Vermutung ist, dass die Grafikkarte in der frühen Boot Phase alles aus dem DP ausgibt und ich es daher nicht sehen kann. Ich wollte mir ohnehin einen neuen Monitor kaufen. Ich überlege jetzt, das sofort zu tun und dann hätte ich den ultimativen Test. Sollte es so bleiben wie jetzt kann man damit arbeiten aber eben ohne grub/boot Text. Auf die Dauer ist das Grütze. Ich habe nur zur Zeit keine Lust im System am offenen Herzen zu operieren (umstellen auf EFI/GTP). Sowas mache ich lieber im Urlaub wenn ich die Zeit habe zu reparieren für denn Fall das was schief geht. Meine Begeisterung hält sich in Grenzen aber irgendwann muss ich da wohl ran.Max Steel wrote:bekommst du denn ein Display wenn du ins Bios gehst?

Daher denke ich, dass die Ausgabe bereits auf dem HDMI Ausgang gestartet wird, aber dass aufgrund von Auflösungsänderungen und die damit verbundene Umstellung einfach der Bildschirm und der Converter zu lange benötigen. Oder anders gesagt, wenn du auf Grub eine Taste drückst und damit den Timeout verhinderst, kommt dann ein Output?Erdie wrote:Ja, das UEFI Bios kann ich sehen. Mein Vermutung ist, dass die Grafikkarte in der frühen Boot Phase alles aus dem DP ausgibt und ich es daher nicht sehen kann. Ich wollte mir ohnehin einen neuen Monitor kaufen. Ich überlege jetzt, das sofort zu tun und dann hätte ich den ultimativen Test. Sollte es so bleiben wie jetzt kann man damit arbeiten aber eben ohne grub/boot Text. Auf die Dauer ist das Grütze. Ich habe nur zur Zeit keine Lust im System am offenen Herzen zu operieren (umstellen auf EFI/GTP). Sowas mache ich lieber im Urlaub wenn ich die Zeit habe zu reparieren für denn Fall das was schief geht. Meine Begeisterung hält sich in Grenzen aber irgendwann muss ich da wohl ran.
Sieht cool aus, tickt alle Boxen die ich auf so ein Display als Voraussetzung hätte.Erdie wrote:Meine engere Auswahl ist der AMSUNG Odyssey Neo G70C S43CG700NU
https://www.alternate.de/SAMSUNG/Odysse ... ct/1906159
falls jemand eine Meinung dazu hat immer her damit.
UEFI muss das gleiche machen was auch ein bootmanager machen muss, wenn er einen Kernel starten soll der ein externes CPIO als initramfs benötigt:Max Steel wrote:[...] wie ess dann aber mit einer eventuell nötigen initramfs funktioniert, hab ich inzwischen vergessen. [...]
Code: Select all
# efibootmgr -c -d /dev/nvme0n1 -L "Gentoo" -l "\EFI\example\bzImage.efi" -u "root=/dev/nvme0n1p3Code: Select all
# efibootmgr -c -d /dev/nvme0n1 -L "Gentoo" -l "\EFI\example\bzImage.efi" -u "root=/dev/nvme0n1p3 initrd=\EFI\example\initramfs.CPIO"Code: Select all
Processor type and features --->
[*] Built-in kernel command line
(root=PARTUUID=6979eed7-ffaf-425e-8ac7-2832f6d15e0a ro loglevel=8 lsm.debug quiet hardened_usercopy=1 page_alloc.shuffle=1 pti=on slub_debug=ZF hash_pointers=always)
[*] Built-in command line overrides boot loader argumentsSieht cool aus, tickt alle Boxen die ich auf so ein Display als Voraussetzung hätte.Max Steel wrote:Meine engere Auswahl ist der AMSUNG Odyssey Neo G70C S43CG700NU
https://www.alternate.de/SAMSUNG/Odysse ... ct/1906159
falls jemand eine Meinung dazu hat immer her damit.

Sehr komisch. Als nächstes könnte es an 2 weiteren Dingen liegen die mir so einfallen.Erdie wrote:Also wenn ich grub mit ESC stoppe kommt trotzdem nix.
Geht mir genauso. Ich hab zum einen aus Platzgründen und da ich auf meiner ursprünglichen GTX 1080 Performanceprobleme befürchtete, zuletzt "nur" ein 32" 1440p Monitor gekauft. (Die RX 9070 XT kam später)Erdie wrote:Den Monitor habe ich schon extra in 43" genommen, Bei 4k wird sonst alles zu klein. 43" sind so die größten 16x9 die man so kriegen kann. Ich hasse es nämlich wenn man upscaling machen kann. Für mich ist das ein Widerspruch, dann kann man gleich einen Monitor mit kleinerer Auflösung nehmen.