Nybygge - Raven Ridge - Xubuntuinstallation

Börja med att uppdatera BIOS till senaste versionen. Se till att BIOS är ställt till att boota UEFI och sätt secure boot till "other OS".

Om inte det hjälper prova boota med 'acpi=off'.

Problemet är relaterat till effekthanteringssystemet för hårdvaran. Ubuntu tycker inte om hur ditt moderkort hanterar det. Därför är det bra med senaste versionen av BIOS. Sätter du 'acpi=off' blir du av med sleep/wake/hibernate, C-states, P-states osv. Ingen bra lösning alltså, men det borde låta dig boota.

Frågan är vilken del av hårdvaran som skapar problem. SMIC och PTOS torde ge ledtrådar, men jag lyckas inte googla fram vad de pekar på. Jag hittade inte heller något när jag sökte igenom ACPI-specifikationerna. Å andra sidan är jag svårt onykter och borde egentligen sova...

Kan du spåra vilken hårdvara det är relaterat till bör det gå att hitta lösningar.

En möjlig lösning är som sagt att uppdatera BIOS. En annan lösning är att uppdatera och/eller konfigurera om Linux-kärnan. ACPI är ett lager mellan operativsystemet och BIOS, så istället för att prata direkt med BIOS kommunicerar operativsystemet med ACPI-lagret som i sin tur pratar med BIOS. Därför kan både en BIOS-uppdatering och en uppdatering av kärnan lösa problemet.

I värsta fall behöver du en patchad DSDT för att få allt att funka. Det är en tabell som beskriver hårdvaran för operativsystemet. Det är tyvärr en svår lösning, om du inte hittar någon på forumet med god vana för det som kan hjälpa dig. Förhoppningsvis hittar vi en enklare lösning.

Har du prövat en äldre *buntu, typ 16 eller kanske en annan dist? Testa Debian kanske. Även Arch kan ju vara värt att testa då det inte är en Debianbaserad dist.

Jag kör Debian Sid med egenkompilerad Linux 4.19-rc4 på min 2400G, du vill nog ha minst 4.18 för Raven Ridge. 4.15, som Ubuntu 18.04.1 kommer med, har många problem med Raven Ridge när den ens bootar.

Det du kan göra är att boota med "nomodeset" tills du har installerat en nyare kernel, då är det CPUn som ritar grafiken via UEFI-framebuffern istället.

Det kan se lite olika ut beroende på BIOS men någonstans under CSM brukar det finnas alternativ som "auto", "legacy" eller "UEFI". Sätt det till UEFI.

Testa VT-d på eller av i BIOS.

Sista raden indikerar att det kan vara problem med just KMS (Kernel Mode Set). Edit: Syftar på "sh: can't access tty", vilket kan vara att kärnan inte får access till grafikkortet och därför inte kan öppna en terminal.

KMS är ett sätt för Linux-kärnan att kommunicera direkt med grafikkortet för att sätta rätt upplösning m.m - "nomodeset" stänger av det. Om det hjälper dig boota kan du senare konfigurera kärnan och installera de drivrutiner som behövs, för att få det att funka igen.

När du bootar ska du först få upp en liten Grub bootmeny. Där ska också finnas något alternativ liknande "Grub boot command line", det kan också vara någon knapptryckning för att få upp det - du får googla på hur du gör med just din version (jag minns inte exakt och det där kan se lite annorlunda ut).

Där ska du sen kunna hitta 'GRUB_CMDLINE_LINUX_DEFAULT=' alternativt 'linux boot vmlinuz-yadayada root=UUID=yadayada ro quiet splash". Där lägger du till 'nomodeset' och du kan som sagt även testa 'acpi=off'.

@LaoLao: Se inlägget från @DasIch för en bra beskrivning för hur du aktiverar "nomodeset". Det är mycket riktigt så att det avaktiverar KMS, vilket betyder att grafikkortet fortsätter köra i samma läge som UEFI lämnade det när datorn startade. Du kommer antagligen att köra skärmen i någon låg standardupplösning men det är ju bättre än inget.

När installationen är klar och datorn startar om utan installationsskivan måste du följa instruktionerna igen för det installerade systemet. När den har startat behöver du uppdatera din kernel, till exempel med denna guide: http://ubuntuhandbook.org/index.php/2018/08/how-to-install-li... .

Efter det ska datorn gå att använda som vanligt.

Precis. Om nomodeset fixar problemet, vilket det verkar som att det kan göra, är det bara att bita i det sura äpplet och lära dig konfigurera din egen kärna. Det borde finnas bra guider till det, anpassade för din hårdvara. Om det saknas kan du kolla guider från Gentoo och Arch. De funkar kanske inte rakt av men de ska kunna ge dig en bra uppfattning om vad du håller på med. Exempelvis så kanske du vill använda Ubuntus guide till en egen konfiguration av kärnan men Gentoo eller Arch till inställningarna för din hårdvara.

Skillnaderna är egentligen inte så stora. Det brukar mest handla om var kärnan är placerad och kopplad till systemet. Gäller bara att veta hur det ser ut för din distro. Inställningarna är desto viktigare, men dessa kan du få från vilken distro som helst. Jag rekommenderar bara Gentoo och Arch därför att de har bra guider som brukar vara uppdaterade.

Och apropå uppdateringar av kärnan. Det är verkligen inte så svårt som många tror. Du behöver liksom inte förstå alla inställningar och många inställningar kommer inte påverka dig alls.

Skickades från m.sweclockers.com

Det ska egentligen inte behövas någon konfiguration/kompilering alls, i alla fall Debians kernel är redan kompilerad med rätt parametrar (CONFIG_DRM_AMDGPU=m och CONFIG_DRM_AMD_DC_DCN1_0=y) så skulle ju tippa på att Ubuntu kör med dem påslagna också. Ska alltså vara så enkelt som att bara installera 4.18 från PPA.

Linux 4.19-rc1 och senare har löst problemet jag hade innan med att GPUn kunde hänga sig vid boot så det kan vara något att kika på när man känner sig mer bekväm med att byta kernel.

Är det skillnad på 2400G & 2200G ? Jag har kört en 2200G med Opensuse Tumbleweed ett tag, och det har varit smärtfritt sedan dom uppdaterade till 4.16, även om prestandan har ökat märkbart i nyare kernel versioner.

Kolla i den här tråden https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1032693-ryzen-2200g-still-not-reliable-in-4-18rc2-when-will-it-work
Verkar vara en del strul med både 2200G & 2400G som är relaterade till moderkorts bios.