Lenovo P16v AMD - distro-vragen + booten/lvm encrypt

[cat_byte]

Mijn vraag
Nieuwe laptop en wat ervaring met Linux (deb-mint, arch-manjaro). De nieuwe laptop heb ik zonder OS besteld, dus er zat een lege ssd in. Deze laptop is overigens direct bij Lenovo met Ubuntu erop te bestellen, maar ik ben geen fan van (de commerciële kant van) Ubuntu.

Doel is om er een studie-computer van te maken en dat betekent in mijn geval browsen, lezen, tekstdocumenten typen en veel VM's draaien. Geen dual-boot. 1 daily driver en dat is prima.
Verder wil ik dat niemand aan de haal kan gaan met mijn bestanden, mocht mijn computer gestolen worden.

Relevante software en hardware die ik gebruik
Laptop: Lenovo P16v AMD, om precies te zijn: 21FECTO1WWNL1 . Geen dGPU, ryzen pro 7 cpu.
Bootable USB: 1x met ventoy (fedora 39, ubuntu 22.04 LTS en debian 12.51) en 1x met dd bootable usb gemaakt met alleen image van debian

Vragen
Flatpak vind ik ok, SNAP niet. Arch ga ik voor deze laptop niet doen... toch wat gedoe gehad met updates die dingen kapot maken. Dus stable of semi-rolling is ok. Voorkeur voor debian, 2e fedora en nr 3 is Ubuntu.
PS: ik heb geen behoefte aan discussie over welke distro.. wil er niet teveel tijd aan kwijt zijn, want ik heb het druk zat. DE zal ws. gnome worden. Ik wil gewoon iets dat meteen makkelijk werkt en niet wekelijks uren bezig zijn met mijn OS tweaken.
Mijn vragelijstje

1. Op mijn huidige pc Asus vivobook kan ik de live-versies prima draaien vanaf de USB. Op mijn nieuwe laptop lukt dat alleen bij Fedora en Ubuntu, als ik GRUB-mode gebruik en niet normal mode. Dan zie ik een eeuwig lang zwart scherm en lijkt er niets meer te gebeuren. Hoe kan ik onderzoeken waar dit aan ligt?
2. Als ik in de debian installer voor lvm met encryptie kies, via de 'guided' methode (eerste keer dat ik dit gebruik, dus dacht nu default instellingen te kiezen), dan levert dat een bootloop op. Als ik het goed heb, wordt de boot-partitie niet encrypted maar root (/) wel. Bij het booten zie ik eerst het Lenovo scherm en gaat ie door naar het grub menu. Dan kies ik Debian. Ik zie heel snel 3 regeltjes tekst langsschieten, scherm zwart, reboot. Ook in recovery mode. Installatieproces verloopt zonder foutmeldingen. Ik heb voorkeur voor Debian, dus hoop die goed werkend te krijgen. Hoe kan ik zien wat er mis gaat? Ik heb met rd.break geprobeerd te zien wat er gebeurt, maar de tekst flitst net zo hard voorbij.
3. Als ik de Ubuntu-installatie doorloop met lvm&encryptie gaat het goed met booten. Direct bij het eerste lenovo-scherm moet ik mijn passphrase invoeren voor decryption. Daarna start Ubuntu zonder problemen op. Ik heb alleen een probleem met commerciële keuzes bij Ubuntu (bijv. Snap). Maar ik ga er vanuit dat dit betekent dat de boot-partitie encrypted is? Of zit het ingewikkelder in elkaar? Aan de andere kant worden deze pc's met Ubuntu geleverd, en sommige zaken werken dan out-of-the-box meteen goed. Bijvoorbeeld instellen vingerafdruk. Ook fijn.
4. Ik lees dat het encrypted van /boot veiliger is (er kan niet gekloot worden met kernel), maar het is voor mij geen must. Ik acht de kans kleine dat iemand mijn laptop jat, er wat zooi op zet, en de laptop vervolgens weer aan mij terug bezorgt. Het gaat mij er vooral om dat mijn bestanden at rest veilig zijn igv diefstal. Is het encrypten van /boot dan nog aan te raden? Ik begrijp ook dat je dan namelijk 2x passhrase in moet vullen. 1x voor /boot en 1x voor de root.
5. TPM / Clevis / systemd-cryptenroll: ik probeer dit een beetje te snappen allemaal. Wat is het punt van automatisch decrypten als iemand op de AAN-knop van je laptop kan duwen? Ja, het bespaart extra wachtwoorden invoeren, maar waarom zou je dan nog encrypten?
   En dan komen we bij Ubuntu terug:

   TPM-backed FDE on classic Ubuntu Desktop systems is based on the same architecture as Ubuntu Core, and it shares a number of its design and implementation principles. Namely, the bootloader (shim and GRUB) and kernel assets will be delivered as snap packages (via gadget and kernel snaps), as opposed to being delivered as Debian packages. As such, it is the Snapd agent which will be responsible for managing full disk encryption throughout its lifecycle.

   In 22.04 is het dus de non TPM-versie van full disk encryption die geïnstalleerd wordt. Vanaf. 23.10 gaat het bovenstaande feestje beginnen. Ik denk voor complete n00bs echt wel goed dat het out-of-the-box zo kan werken, maar Snap is er dan niet meer uit te slopen.
6. Secure Boot. Die staat nu uit, wegens het steeds moeten booten van USB. Maar Net als de vraag of je je hele schijf encrypt of niet, hangt dit wellicht samen met de vraag of ik een interessant doel ben. Denk het niet, dus risico is dan wellicht te aanvaarden. Heeft het (behalve dat het om veiligheid gaat) nog verband met TPM en FDE?

[FireDrunk]

1. Zwart scherm kan aan KMS (Kernel Mode Set) liggen, mogelijk moet je in een soort 'safe-gpu' mode booten?

2. Check even of in het BIOS de laptop netjes ingesteld staat op UEFI only, en dat CSM uit staat, mogelijk helpt dat.

3. Doorgaans worden boot (en/of EFI) partities niet geencrypt, want dat maakt het bootproces best complex. Dan moet je namelijk met Grub aan unlocken, en dat gaat wat lastig. Fedora doet het alleen op de root (en swap) voor zover ik weet.

4. Als alleen je / partitie encrypted is, ben je gewoon nog steeds beschermd tegen diefstal. Je bent niet zomaar beschermd tegen malware of rootkits. Daar is Secure Boot in combinatie met een goede security rondom je eigen user account een beter middel tegen. Puur /boot encrypten helpt ook niet tegen alles.

5. Je boot order zit locked in de TPM, waardoor iemand niet zomaar iets anders kan opstarten dan jouw installatie. Als die nog steeds om een password / fingerprint vraagt kan diegene dus niks aanpassen. Bij een SecureBoot systeem kan je ook geen Grub opties veranderen ofzo, dat negeert de kernel (mits goed ingesteld). TPM is ook niet heilig (er zijn wel wat lekken gevonden), maar het is significant beter dan geen encryptie. Het is dus voor nitwits die niet tijdens boot een pw in willen vullen een betere optie dan geen pw.
Veiligste is zonder TPM, en gewoon je password invullen.
Ik zou me niet te druk over snap maken, je kan het prima disablen.

6. Secure Boot en linux zijn geen hele goede vriendjes, maar het kan wel. Secure Boot werkt met keys in het UEFI systeem die bepaalde binaries wel of niet accepteren. Je kan je eigen keys enrollen, waardoor alleen jij kernels kan bouwen die te booten zijn op jouw laptop. Maar dat is _heel_ geavanceerd.
in de basis zorgt Secure Boot in samenwerking met een gelockte UEFI en een signed kernel voor een iets veiliger bootproces, maar het kan ook wat issues geven. Dus pin er niet te hard op vast.

[GarBaGe]

Ik gebruik een dual boot met Windows met Bitlocker, icm Secure Boot, een dedicated TPM module en Ubuntu met FDE.

Persoonlijk vind ik de Full Disk Encryptie veiliger dan de Windows Secure Boot - TPM - BitLocker.
Systeem start van een non-encrypted boot partitie van Ubuntu (met Grub).
Vanaf daar kan ik kiezen om Ubuntu te starten (dan vraagt ie om mijn FDE wachtwoord) OF om Windows te starten.
Voor Windows voer ik dan niets meer in, omdat SecureBoot met TPM reeds het encryptie wachtwoord heeft vrijgegeven.
Ik blijf liever bij klassieke FDE in Linux en stap liever NIET over op een TPM-versie daarvan.

Edit:
Overigens ben ik ook geen fan van Snap of Flatpak.
De klassieke package manager (dpkg) vind ik goed genoeg voor al mijn benodigdheden.
En meerdere simulate package managers maken het voor mij heel onduidelijk om te zien WELKE package manager een bepaalde package beheert.

[ Voor 18% gewijzigd door GarBaGe op 11-03-2024 13:33 ]

[cat_byte]

@FireDrunk dankjewel voor je uitgebreide en leerzame antwoorden.

In mijn geval is het me vooral te doen om bestanden veilig stellen als de laptop kwijtraakt of gestolen is. Het encrypten van /boot / FDE is dan iets minder belangrijk. Ik ben nu deze tutorial over debian 12 via de installer met unencrypted /boot aan het uitvoeren. Voor de liefhebbers is er ook een tutorial voor installatie met FDE in debian.

Klaar met de install (dus /boot niet encrypted). Helaas levert dit exact hetzelfde euvel op.

De situatie:
/boot en efi partitie zijn niet encrypted
/ is wel encrypted
Laptop boot normaal, gaat naar grub-menu, start Debian op. Er verschijnen heel snel wat zaken in beeld, maar dan reboot hij alweer. Er wordt niet gevraagd naar de pass phrase.

Verder kan ik nergens iets van CSM vinden in het UEFI-menu.

Als ik "quiet" verwijder en "nomodeset rd.break" toevoeg, komt er temidden van alle lettertjes tijdens het opstarten ineens tevoorschijn dat ik mijn pass phrase moet intypen. Nu dus uitvogelen hoe ik ervoor ga zorgen dat ik dit gewoon altijd op een nette manier te zien krijg. Laat maar, werk ook niet meer. Eenmalig geluk gehad blijkbaar

[ Voor 2% gewijzigd door cat_byte op 11-03-2024 15:25 . Reden: grub parameters werken toch niet ]

[FireDrunk]

Dat is wel een lastige. Het debug process van dit soort boot issues is per distributie soms verschillend.
Doorgaans zou je via een aantal wijzigingen in de Grub startup procedure (e drukken tijdens het booten in het grub menu) wel een heel eind moeten komen.

Zorg vooral voor veel logging, en post hier de foutmelding(en), dan kunnen we mogelijk beter helpen.

[Hero of Time]

Ik heb een Thinkpad T14 AMD gehad en daar Debian met FDE op draaien zonder problemen. Bij elke keer starten werd er om de passphrase gevraagd en daarmee werd m'n LVM volume unlocked, waar /, /home en swap in stonden.

Nu heb ik een Dell Latitude 5440 en heb hier ook weer Debian met FDE op staan. Er wordt om een passphrase gevraagd, maar doe ik niks dan wordt na een paar seconden dankzij Clevis-TPM m'n disk unlocked. Ik vind het vervelend om elke keer m'n wachtwoord in te voeren.
Bij deze installatie heb ik ook weer /, /home en swap in een encrypted LVM volume.

Ik vind het wel bijzonder dat je Debian reboot net voor/rond het punt dat er om een passphrase gevraagd zou worden. Ik zou gaan denken aan een bepaalde BIOS instelling dat niet helemaal lekker is of dat er bij installatie toch iets niet helemaal goed is gegaan. Werd er tijdens installatie wel om een passphrase gevraagd? Persoonlijk partitioneer ik m'n schijf handmatig.

Wel heb ik eens gehad dat de Debian installer een bug had waarbij LVM+LUKS niet werkte. Maar dat was met een weekly van Testing, de installer voor Debian Stable had geen problemen en heb ik toen ook gebruikt om daarna naar Sid te upgraden.

Wat betreft Secure Boot, die heb ik om 2 redenen uit staan op mijn werklaptop:
1) Ik kan hibernate gebruiken, anders niet. M'n swap is toch encrypted, dus dat is veilig.
2) Met de vorige laptop had ik wel SB aan staan en zag ik constant een melding gelogd worden wanneer ik een VM met Qemu/KVM had draaien. De melding zei ook dat om dit niet meer te zien, SB uit moest. Functioneel merkte ik geen verschil voor m'n VMs.

Mocht je iets met eigen Secure Boot keys willen gaan doen, lees je dan heel goed in. Want de T14 die ik had op m'n vorige werk kon je bricken als je de keys verving. Het systeem was dan onbruikbaar en vereiste een nieuw moederbord. Kijk dus even heel goed of jouw model daar geen last van heeft. Ik hoop dat Lenovo dat ondertussen heeft opgelost.

[cat_byte]

Dank beiden. Het vermoeden is dat er toch iets niet goed is met firmware/drivers voor de integrated gpu. Door "nomodeset" in de grub paramaters toe te voegen gaat het inloggen namelijk wel goed.

Ik moet even kijken hoe ik dit op ga lossen. Een nieuwere kernel proberen wellicht. Punt is dat debian sinds 12/bookworm ook proprietary drivers toevoegt en installeert indien nodig.

Wat betreft secure boot en tpm laat ik het nu even zoals het is. Ben allang blij dat ik iets verder ben. Omdat het zo vroeg tijdens het booten al mis gaat, kan ik juist dit niet in de logs terugvinden. De logs die ik wel vind is van de 2 keer dat ik met nomodeset wel heb kunnen booten. Tijdens de install gaat alles perfect, dus dan geef ik ook pass phrase in.

Ik puzzel nog even verder en laat het wel weten als ik eruit kom. De laptop is geloof ik september 2023 geïntroduceerd. AMD ryzen 7480h met AMD radeon 780M maart 2023. Ik las dat daarvoor minstens de 6.4 kernel nodig is. Dus... ik ga kijken of ik die er netjes in kan zetten en anders toch maar fedora

[Dimitrip]

Heb je firmware-amd-graphics geinstalleerd?

Ik heb een elitebook 835 G7. Weliswaar geen lenovo maar ook een AMD processor.

Voor de tweede installatie (eerste keer was mijn debian na enkele maanden in de soep gedraaid) , heb ik deze blog gevolgd om wat extra amd zaken te installeren.

Misschien helpt het jou ook

https://blog.frehi.be/202...on-a-hp-elitebook-845-g8/

[Hero of Time]

Als firmware ontbreekt voor de GPU, zou het systeem alleen geen beeld moeten geven of de GUI doet het niet en heb je de console om in te loggen. Een reboot zou niet moeten gebeuren, dat moet een andere oorzaak hebben. Dat het met 'nomodeset' wel goed gaat is dan ook bijzonder.

Debian 12 Bookworm zou prima overweg moeten kunnen met de cpu en videokaart. Zolang je idd de firmware geïnstalleerd hebt. Toen ik 1,5 jaar gelezen m'n Zen 4 systeem bouwde moest ik nog eventjes wachten totdat de firmware was bijgewerkt in het package, daarvoor haalde ik die van upstream git. Bij de release van Stable was dat zeker opgelost.

[cat_byte]

Dimitrip schreef op maandag 11 maart 2024 @ 21:16:
Heb je firmware-amd-graphics geinstalleerd?

Ja! Het is echter de versie van 20230210-5. Meest 'recente' stable/backport versie, maar niet recent genoeg voor mijn gpu. Ik zie die niet in de lijst staan. Ik heb wel de backport repo intussen toegevoegd, maar een nieuwere versie komt hiermee niet tevoorschijn.

Mijn kernel is intussen geüpdated naar 6.6.13, maar dat heeft helaas niet uitgemaakt.
Ik heb de blog doorgenomen! Goede informatie, maar heeft helaas niet geholpen.

Het is zeker iets met de gpu firmware/drivers. nomodeset maakt dus alles uit. CPU amd ryzen 7 pro 7840 hs is in mei 2023 uitgebracht. iGPU Radeon 780M (Phoenix) in januari 2023. Dat zou geen probleem moeten zijn, zou je denken...

Goed, met wat pijn en moeite zie ik dat het mis loopt bij het laden firmwarebestanden. Bij gebrek aan logs (tenminste, ik weet niet waar ik deze vandaan haal) overgetypt:

code:

amdgpu 0000:c4:00.0: amdgpu Fetched VBIOS from VFCT
amdgpu: ATOM BIOS: 113-PHXGENERIC-001
amdgpu 0000:c4:00.0: firmware: direct-loading firmware amdgpu/psp_13_0_4_toc.bin
amdgpu 0000:c4:00.0: firmware: direct-loading firmware amdgpu/psp_13_0_4_ta.bin
amdgpu 0000:c4:00.0: firmware: direct-loading firmware amdgpu/dcn_3_1_4_dmcub.bin
amdgpu 0000:c4:00.0: firmware: direct-loading firmware amdgpu/gc_11_01_1_pfp.bin
amdgpu 0000:c4:00.0: firmware: direct-loading firmware amdgpu/gc_11_01_1_me.bin
amdgpu 0000:c4:00.0: firmware: direct-loading firmware amdgpu/gc_11_01_1_rlc.bin
amdgpu 0000:c4:00.0: firmware: direct-loading firmware amdgpu/gc_11_01_1_mec.bin
[drm] VCN(0) encode/decode are now enabled in VM mode
amdgpu 0000:c4:00.0: firmware: direct-loading firmware amdgpu/vcn_4_0_2.bin
amdgpu 0000:c4:00.0: firmware: [drm:jpeg_v4_0_early_init [amdgpu]] JPEG decode is enabled in VM mode
amdgpu 0000:c4:00.0: firmware: failed to load amdgpu/gc_11_01_1_mes_2.bin (-2)
amdgpu 0000:c4:00.0: Direct firmware load for amdgpu/gc_11_01_1_mes_2.bin failed with error -2
[drm] try to fall back to amdgpu/gc_11_0_1_mes.bin
amdgpu 0000:c4:00.0: firmware: direct-loading firmware amdgpu/gc_11_0_1_mes.bin
amdgpu 0000:c4:00.0: firmware: direct-loading firmware amdgpu/gc_11_0_1_mes1.bin

Hier eindigt het en reboot de laptop.


gc_11_01_1_mes_2.bin staat inderdaad niet in /lib/firmware/amdgpu. Het is evenmin onderdeel van het pakket firmware-amd-graphics, dus ik zal het ergens anders vandaan moeten halen

Zou het kunnen dat dit een bug is? De bron van firmware voor de meeste debian-based distro's zal bij git.kernel.org zijn.

Daar is een heel riedeltje amdgpu GC-firmware bestanden te vinden. Ze zijn echter allemaal in hetzelfde formaat dat afwijkt van wat mijn laptop probeert te laden:
gc_11_0_1_xxx.extensie
gc_11_0_2_xxx.extensie
gc_11_0_3_xxx. extensie
etcetera.

Maar dus niet zoals in mijn foutmelding:
gc_11_01_1_mes_2.bin
Dat lijkt op een verkeerde verwijzing. Maar in welk bestand worden de bestanden die geladen worden genoemd? Waar komt dat vandaan? (als in: van Debian, of moet ik dit ergens anders dumpen?) Er zijn meer bestanden die geladen worden met die gc_11_01... maar als ik zoek op de pc, bestaan deze niet.

Kijkend naar de git kan ik me voorstellen dat het één van deze zou moeten zijn:
gc_11_0_2_mes_2.bin

Nergens zijn de bestanden te vinden die mijn laptop wil laden.Die "01" erin kan ik nergens teruginvnden op internet. De git lijkt me een aardige referentie van welke er bestaan. Iemand die weet hoe ik de puzzel verder kan oplossen? Aangezien het toch al kapot is, zou ik de bestandsnamen kunnen wijzigen, maar dat is wel erg houtje-touwtje

[ Voor 29% gewijzigd door cat_byte op 12-03-2024 01:14 ]

[cat_byte]

Al draaiend in mijn bed bedacht ik ineens het volgende: al deze firmwarebestanden probeert mijn laptop te laten vóór ik mijn passphrase heb ingevuld. Als ze op dat moment echt moeten worden geladen vanuit /lib/firmware, gaat dat niet. Die is namelijk encrypted. Logischerwijs zou je dan denken dat eerst de prompt moet komen voor de pass phrase.

Ik probeer er achter te komen hoe dit proces gaat bij booten, maar kom voorlopig nog niet veel verder.

[Hero of Time]

Firmware wordt geladen door de kernel wanneer deze daadwerkelijk aan het werk gaat. Dat kan pas na het unlocken van het file system. Voordat dit gebeurt, wordt er de initram geladen. Wanneer je een kernel update krijgt, wordt deze nieuw gemaakt voor de nieuwe kernel. Hier wordt dan ook firmware toegevoegd, want het is immers niet zeker of dit nodig is om te kunnen starten. Dat is waarom je deze meldingen ziet, terwijl /var/lib/firmware nog niet beschikbaar is.

De melding over niet kunnen laden van firmware komt vaker voor en wil niet zeggen dat er ook echt een probleem is. Je kan nieuwere firmware van git halen en deze in de juiste firmware map zetten. Daarna draai je 'update-initramfs -u' om de huidige bij te werken zodat de nieuwe firmware daar ook aanwezig is.

Maar ik verwacht niet dat het ontbreken van firmware voor je GPU een reboot zou veroorzaken.

[cat_byte]

Dank voor je uitleg. In mijn geval wordt er echter wel een poging gedaan om firmware te laden, zonder dat ik word gevraagd de pass phrase in te typen. Dat is voor mij een mysterie, en ik vind het alles behalve logisch.

De laatste relevante bestanden uit de git halen + initram update heb ik al geprobeerd, en werkt niet, want: er is nog een ander probleem (los van dat ik dus niet om een pass phrase wordt gevraagd): de bestandnamen van de firmware bestaan helemaal niet. Niet op mijn computer, niet in de git, en sowieso niet te vinden op internet. Mijn laptop probeert dus iets te laden wat niet bestaat. Vandaar mijn vraag waar dit vandaan komt en kan melden, want het lijkt me een bug?!

Alleen als ik nomodeset toevoeg, gaat het booten wel goed. Ik word dan wel gevraagd om de pass phrase. Geen "nomodeset" = gegarandeerd een reboot loop. Dus mijn boerenverstand zegt dat het toch iets te maken heeft met de firmware die niet correct laadt. Maar of de oorzaak is, dat het niet-bestaande bestanden zijn, of dat er ergens iets in de luks-decrypt installinge niet goed is? Geen idee werkelijk.

Overigens is dit een andere dan deze melding dan die je vaker ziet in linux: "possibly missing firmware". in dit geval is het "failed to load". De inhoud van initramfs heb ik trouwens ook nog bekeken. Daar stond onder andere in:

code:

usr/lib/firmware/amdgpu/gc_11_0_0_imu.bin
usr/lib/firmware/amdgpu/gc_11_0_0_me.bin
usr/lib/firmware/amdgpu/gc_11_0_0_mec.bin
usr/lib/firmware/amdgpu/gc_11_0_0_mes.bin
usr/lib/firmware/amdgpu/gc_11_0_0_mes1.bin
usr/lib/firmware/amdgpu/gc_11_0_0_pfp.bin
usr/lib/firmware/amdgpu/gc_11_0_0_rlc.bin
usr/lib/firmware/amdgpu/gc_11_0_1_imu.bin
usr/lib/firmware/amdgpu/gc_11_0_1_me.bin
usr/lib/firmware/amdgpu/gc_11_0_1_mec.bin
usr/lib/firmware/amdgpu/gc_11_0_1_mes.bin
usr/lib/firmware/amdgpu/gc_11_0_1_mes1.bin
usr/lib/firmware/amdgpu/gc_11_0_1_pfp.bin
usr/lib/firmware/amdgpu/gc_11_0_1_rlc.bin
usr/lib/firmware/amdgpu/gc_11_0_2_imu.bin
usr/lib/firmware/amdgpu/gc_11_0_2_me.bin
usr/lib/firmware/amdgpu/gc_11_0_2_mec.bin
usr/lib/firmware/amdgpu/gc_11_0_2_mes.bin
usr/lib/firmware/amdgpu/gc_11_0_2_mes1.bin
usr/lib/firmware/amdgpu/gc_11_0_2_pfp.bin
usr/lib/firmware/amdgpu/gc_11_0_2_rlc.bin

Kortom: niets met gc_11_01_xxxxx . Welk proces bepaalt welke firmware-bestanden moeten worden geladen?

[cat_byte]

Ok, toch nóg eens geprobeerd: alle amdgpu 500 en nog wat firmwarebestanden uit de laatste kernel firmware git in mijn firmware map gezet, en nieuwe initram gemaakt. HIJ.START.OP! Nu maar hopen dat het niet op een andere manier gedonder gaat opleveren dat ik gloedjenieuwe firmware heb. Hier gaat de vlag uit hoor!!!

[Hero of Time]

cat_byte schreef op dinsdag 12 maart 2024 @ 20:26:
Dank voor je uitleg. In mijn geval wordt er echter wel een poging gedaan om firmware te laden, zonder dat ik word gevraagd de pass phrase in te typen. Dat is voor mij een mysterie, en ik vind het alles behalve logisch.

Niet echt. Tijdens het starten worden er al wat modules geladen voor je hardware die in de initramfs zitten. Daar is ook firmware bij nodig.

[...]

Kortom: niets met gc_11_01_xxxxx . Welk proces bepaalt welke firmware-bestanden moeten worden geladen?

Dat is onderdeel van het laden van de module voor hardware. Als ik in mijn log kijk van tijdens het starten, zie ik ook dat er wat mist, maar er is niks aan de hand verders, het werkt prima.

code:

Feb 27 17:45:37 tohru kernel: amdgpu 0000:03:00.0: firmware: direct-loading firmware amdgpu/vcn_4_0_0.bin
Feb 27 17:45:37 tohru kernel: amdgpu 0000:03:00.0: [drm:jpeg_v4_0_early_init [amdgpu]] JPEG decode is enabled in VM mode
Feb 27 17:45:37 tohru kernel: amdgpu 0000:03:00.0: firmware: failed to load amdgpu/gc_11_0_0_mes_2.bin (-2)
Feb 27 17:45:37 tohru kernel: firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
Feb 27 17:45:37 tohru kernel: amdgpu 0000:03:00.0: firmware: failed to load amdgpu/gc_11_0_0_mes_2.bin (-2)
Feb 27 17:45:37 tohru kernel: amdgpu 0000:03:00.0: Direct firmware load for amdgpu/gc_11_0_0_mes_2.bin failed with error -2
Feb 27 17:45:37 tohru kernel: [drm] try to fall back to amdgpu/gc_11_0_0_mes.bin
Feb 27 17:45:37 tohru kernel: amdgpu 0000:03:00.0: firmware: direct-loading firmware amdgpu/gc_11_0_0_mes.bin

Zolang het wat kan laden, is het op zich prima.

Goed om te zien dat je nu wat hebt dat werkt en geen probleem lijkt te geven. Je kan gelukkig weinig slopen hiermee. En bij een update van het firmware package zal het wat je er bij hebt gezet en niet in het package zit gewoon blijven.