Anfängerfragen - Linux Neuling? Hier ist der richtige Platz für deine Fragen (2)

  • Ersteller Gelöschtes Mitglied 45455
  • Erstellt am
Ist es möglich die 5% für den Super-User freigehaltenen Speicher, die bei "mkfs.ext4" reserviert werden, nachträglich zu editieren oder muss ich das Dateisystem neu anlegen mit "mkfs.ext4 -m0"?

€: Hat sich erledigt. Das Kommando ist:

sudo tune2fs -m 0 /dev/sdx
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ist es möglich die 5% für den Super-User freigehaltenen Speicher, die bei "mkfs.ext4" reserviert werden, nachträglich zu editieren oder muss ich das Dateisystem neu anlegen mit "mkfs.ext4 -m0"?

€: Hat sich erledigt. Das Kommando ist:

sudo tune2fs -m 0 /dev/sdx
Das hatte ich bisher noch nicht gelesen. Interessant https://wiki.archlinux.org/title/Ext4#Reserved_blocks
Wieso will man aber den reservierten Speicher entfernen? Zu wenig Restspeicher?
 
Yepp, ich habe auf meinen HDD's plötzlich einige hundert Gigabyte vermisst und habe den Wert auf 1% reduziert. Das sind Archiv-Platten, allzuviel tut sich da nicht.
 
Nach einer fixen Google Suche nach kernel "5.4" 82574l gabs nen paar interessante Treffer.
Ich habe jetzt nur quer gelesen, würde allerdings eher davon ausgehen das es irgendwie ab 5.4.11 funktioniert, aber sauber erst ab Kernel 5.5.
Der e1000e Treiber der dafür zuständig zeichnet war anfangs etwas hakelig.

Danke Dir. Hab die Karte nun auf Verdacht mal hergenommen und siehe da, läuft problemlos.
Da Mint 20.x ja auf Ubuntu 20.04 LTS basiert und den Kernel 5.4.0 weiterhin nutzt, hatte ich etwas Angst, aber die Karte wird anstandslos erkannt.
Ich schreibe gerade diesen Post von meinem Linux Knecht. Intel weiß schon, wie man Linux ordentlich supportet und die Karte ist ja wirklich nicht neu oder zickig.

Bildschirmfoto vom 2021-07-12 16-09-33.png

Treiber ist der vermutete e1000e, ja ...

Ob ich dem Mint jetzt auch den Kernel 5.11 verpasse, ich weiß noch nicht ...

Bildschirmfoto vom 2021-07-12 16-30-47.png

aber die restliche Hardware würde mich in diese Richtung nötigen.

Bildschirmfoto vom 2021-07-12 16-29-59.png

Teste ich die Tage nach nem Snapshot mal aus. Evtl läuft dann auch die Realtek RTL8125 schon sauber mit.
Beitrag automatisch zusammengeführt:

Edit:

Wechsel auf Kernel 5.11 spontan und da man dank Kernelverwaltung mehrere Installieren und übers Grub Menü fleißig springen kann, hab ich mich auf die schnelle getraut.

RTL8125 wird mit Treiber r8169 supportet und läuft soweit erstmal.

System: Kernel: 5.11.0-22-generic x86_64 bits: 64 compiler: N/A Desktop: Cinnamon 4.8.6
wm: muffin dm: LightDM Distro: Linux Mint 20.1 Ulyssa base: Ubuntu 20.04 focal
Machine: Type: Desktop System: ASUS product: N/A v: N/A serial: <filter>
Mobo: ASUSTeK model: TUF GAMING B550-PRO v: Rev X.0x serial: <filter>
BIOS: American Megatrends v: 2404 date: 06/21/2021
Battery: Device-1: hidpp_battery_0 model: Logitech M705 serial: <filter> charge: 65%
status: Discharging
Device-2: hidpp_battery_1 model: Logitech MK700 serial: <filter>
charge: 70% (should be ignored) status: Discharging
CPU: Topology: Quad Core model: AMD Ryzen 3 2200G with Radeon Vega Graphics bits: 64
type: MCP arch: Zen L2 cache: 2048 KiB
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 28000
Speed: 1479 MHz min/max: 1600/3500 MHz Core speeds (MHz): 1: 1479 2: 3700 3: 1644
4: 1644
Graphics: Device-1: AMD Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series]
vendor: ASUSTeK driver: amdgpu v: kernel bus ID: 09:00.0 chip ID: 1002:15dd
Display: x11 server: X.Org 1.20.9 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa
resolution: 1920x1080~144Hz
OpenGL: renderer: AMD RAVEN (DRM 3.40.0 5.11.0-22-generic LLVM 11.0.0)
v: 4.6 Mesa 20.2.6 direct render: Yes
Audio: Device-1: AMD Raven/Raven2/Fenghuang HDMI/DP Audio vendor: ASUSTeK
driver: snd_hda_intel v: kernel bus ID: 09:00.1 chip ID: 1002:15de
Device-2: AMD Family 17h HD Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel
bus ID: 09:00.6 chip ID: 1022:15e3
Sound Server: ALSA v: k5.11.0-22-generic
Network: Device-1: Intel 82574L Gigabit Network driver: e1000e v: kernel port: e000
bus ID: 06:00.0 chip ID: 8086:10d3
IF: enp6s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Device-2: Realtek RTL8125 2.5GbE vendor: ASUSTeK driver: r8169 v: kernel port: d000
bus ID: 08:00.0 chip ID: 10ec:8125

IF: enp8s0 state: down mac: <filter>
Drives: Local Storage: total: 232.89 GiB used: 11.07 GiB (4.8%)
ID-1: /dev/sda vendor: Samsung model: SSD 840 EVO 250GB size: 232.89 GiB
speed: 6.0 Gb/s serial: <filter>
Partition: ID-1: / size: 103.49 GiB used: 11.07 GiB (10.7%) fs: ext4 dev: /dev/sda5
USB: Hub: 1-0:1 info: Full speed (or root) Hub ports: 10 rev: 2.0 chip ID: 1d6b:0002
Device-1: 1-6:2 info: ASUSTek AURA LED Controller type: <vendor specific>
driver: hid-generic,usbhid rev: 2.0 chip ID: 0b05:1939
Hub: 1-7:3 info: Genesys Logic 4-port hub ports: 4 rev: 2.0 chip ID: 05e3:0610
Device-2: 1-9:4 info: Kingston Flash Drive 2 GB [ICIDU 2 GB] type: Mass Storage
driver: usb-storage rev: 2.0 chip ID: 13fe:1e00
Device-3: 1-10:5 info: Logitech Unifying Receiver type: Keyboard,Mouse,HID
driver: logitech-djreceiver,usbhid rev: 2.0 chip ID: 046d:c52b
Hub: 2-0:1 info: Full speed (or root) Hub ports: 4 rev: 3.1 chip ID: 1d6b:0003
Hub: 3-0:1 info: Full speed (or root) Hub ports: 4 rev: 2.0 chip ID: 1d6b:0002
Hub: 4-0:1 info: Full speed (or root) Hub ports: 4 rev: 3.1 chip ID: 1d6b:0003
Hub: 5-0:1 info: Full speed (or root) Hub ports: 1 rev: 2.0 chip ID: 1d6b:0002
Hub: 6-0:1 info: Full speed (or root) Hub ports: 1 rev: 3.1 chip ID: 1d6b:0003
Sensors: System Temperatures: cpu: 43.4 C mobo: N/A gpu: amdgpu temp: 43 C
Fan Speeds (RPM): N/A
Repos: No active apt repos in: /etc/apt/sources.list
Active apt repos in: /etc/apt/sources.list.d/official-dbgsym-repositories.list
1: deb http: //ddebs.ubuntu.com focal main restricted universe multiverse
2: deb http: //ddebs.ubuntu.com focal-updates main restricted universe multiverse
Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list
1: deb http: //mirror.netcologne.de/linuxmint/packages ulyssa main upstream import backport
2: deb http: //mirror.kamp.de/ubuntu focal main restricted universe multiverse
3: deb http: //mirror.kamp.de/ubuntu focal-updates main restricted universe multiverse
4: deb http: //mirror.kamp.de/ubuntu focal-backports main restricted universe multiverse
5: deb http: //security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
6: deb http: //archive.canonical.com/ubuntu/ focal partner
Active apt repos in: /etc/apt/sources.list.d/official-source-repositories.list
1: deb-src http: //mirror.netcologne.de/linuxmint/packages ulyssa main upstream import backport
2: deb-src http: //mirror.kamp.de/ubuntu focal main restricted universe multiverse
3: deb-src http: //mirror.kamp.de/ubuntu focal-updates main restricted universe multiverse
4: deb-src http: //mirror.kamp.de/ubuntu focal-backports main restricted universe multiverse
5: deb-src http: //security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
6: deb-src http: //archive.canonical.com/ubuntu/ focal partner
Info: Processes: 229 Uptime: 3m Memory: 29.36 GiB used: 875.1 MiB (2.9%) Init: systemd v: 245
runlevel: 5 Compilers: gcc: 9.3.0 alt: 9 Client: Unknown python3.8 client inxi: 3.0.38
 
Zuletzt bearbeitet:
Hallo zusammen,
in letzter Zeit habe mich mit Verschlüsselungen mittels 'cryptsetup' auseinandergesetzt. Ich habe einen Teil meiner Datenträger verschlüsselt und neben der Passphrase noch eine Keyfile in den Luks-Header hinzugefügt und das in 'crypttab' vermerkt. Diese Konstruktion macht die tägliche Handhabe sehr umgänglich.
Nun möchte ich auch mein Hauptsystem verschlüsseln und finde dazu auch viele Anleitungen (Arch + Btrfs). Ziel ist aber, neben der Passphrase, ebenfalls eine Keyfile auf einem USB-Stick zu halten, die das Starten des Systems zu einem Selbstläufer macht. Leider finde ich dazu wenig konkretes. Als Idee aufgegriffen habe ich noch den Luks-Header selbst auf einem USB-Stick zu halten. Ist das sinniger bzw. überhaupt umsetzbar wie ich mir das vorstelle?
Im übrigen reicht es völlig dass die Root-Partition verschlüsselt wird, über /boot/efi und den Kernel mache ich mir wenig Sorgen.
 
Edit:

Wechsel auf Kernel 5.11 spontan und da man dank Kernelverwaltung mehrere Installieren und übers Grub Menü fleißig springen kann, hab ich mich auf die schnelle getraut.

RTL8125 wird mit Treiber r8169 supportet und läuft soweit erstmal.
Da Einiges an Software mit Kernel 5.11 so richtig nicht will (vorallem Virtualbox) und auch 5.8 manchmal Probleme hat, bin ich auf 5.4 und den folgenden Workaround zurückgefallen.


Funktioniert mit aktuellem Mint 20.2 und neuestem Kernel 5.4.0.80 soweit sehr gut.
 

Anhänge

  • Bildschirmfoto vom 2021-07-21 19-23-11.png
    Bildschirmfoto vom 2021-07-21 19-23-11.png
    64,3 KB · Aufrufe: 72
Moin zusammen,
kurze Frage, deren eindeutige Beantwortung mit einer schnellen Recherche nicht zustande kam.
Bei mir läuft grade ein kleiner PC für kleinere Aufgaben im Netzwerk.
Als Host-Betriebssystem läuft Ubuntu Server 21.04, alle Aufgaben laufen einzeln per Docker (Portainer, Homebridge, Octoprint, Pihole).

Jetzt die Frage:
Kann ich neben Docker auch „normale“ VMs laufen lassen, oder ist das VT-x in der CPU durch Docker belegt?

Und eine Frage weiter: Könnte dann die Hardwarebeschleunigung der Intel Grafik an eine VM durchgeschleift werden?
Ich dachte da an VMware (oder QEMU -> Empfehlungen?).

Danke schon mal :)
 
Hallo. Docker verwendet keine Hardwarevirtualisierung.
Ob der GPU-Passtrough funktioniert kommt auf deine Kombination aus exakter Hardware und der gewählten Virtualisierungslösung an. Also je nach CPU, hast du da schon eine andere Auswahl von in Frage kommenden Hypervisors. Genau Details zur Kompatibilität kenne ich da jetzt aber nicht für jede IGP. Würde einfach mal suchen nach
"CPU-Modell + PCIe passthrough/GPU passthrough".
Meistens sind kommerzielle Lösungen wie z.B. ESXi schneller, was die Unterstützung aktueller Hardware angeht. Komfortabler ist es dort auch. Bei Lösungen wie z.V. Proxmox ist das etwas umständlicher zu bewerkstelligen und dauert etwas länger, aber dafür ist die Bedienung im Allgemeinen (IMHO) angenehmer.
 
Besten Dank!
Das hilft mir schon mal sehr :)

Neuinstallation auf Proxmox will ich erstmal vermeiden.
Stattdessen jetzt erstmal Cockpit samt dem VM Addon installiert. Gibt noch Zugriffsprobleme auf eine Windows Iso mangels Rechten, aber das bekomme ich die Tage bestimmt hin :)
 
Also aus erfahrung heraus , weil ich seit Jahren VMWare Player unter Windows genutzt habe und viele VMs damit betrieben habe.

Seit ich Win17/win10 langsam den produktiven Kram auf Linux rüberschiebe, bin ich mehr und mehr bei Virtualbox gelandet. Sicherlich spielt Hardware eine Rolle, aber VMWare zickte unter Linux gerne mit der Hardware rum, verlangte mehr Ressourcen als Vbox und lief bescheidener.

Ich hab mir sogar die Arbeit gemacht und alle VM neu unter Virtualbox aufzubauen. Irgendwie alles problemloser.

Was 3D angeht, soll VMWare besser sein, aber viel 3D Lastige Sachen wie Games lasse ich nicht in VMs laufen. Oft reicht der Standard SVGA Modus aus.

Was GPU Passthrough angeht, würde ich an ne etablierte Grafikkarte gehen. Intel GMA und Nachfolger sehe ich da eher problematisch, wenn auch weit verbreitet. Ne Nvidia, passiv aka GT210, 120 wird da problemloser sein als PCIe Ressource freizugeben.
 
ich habe endlich mal meinen homeserver von einer einzelnen WD green auf ein ZFS mirror mit hitachi enterprise platten umgestellt.

laeuft soweit ganz gut, allerdings sind zugriffe mit diesen platten deutlich zu hoeren. und die gibts alle paar sekunden. (alle ~5 sekunden macht es 0.5 sekunden lang 'chrrrt')
ob das vorher auch so war weiss ich nicht, die WD green war generell nicht zu hoeren.

1) kommt das vom zfs oder eine meiner anwendungen?
2) wie kann ich herausfinden ob das read- oder write operationen sind? (zpool iostat gibt deutlich mehr read als write an, aber man weiss ja nie)

im falle von read wuerde ich es mit einem L2ARC cache SSD versuchen. write cache auf nur eine SSD und ohne power loss schutz ist mir zu heikel.
Beitrag automatisch zusammengeführt:

EDIT:
laut iotop scheint wohl txg_sync der uebeltaeter zu sein. also write durch zfs selbst. :(
 
Zuletzt bearbeitet:
Ich kann nur aus der Erfahrung heraus ( kein Linux - ZFS sondern FreeNAS) sagen, dass ZFS viele Schreibzugriffe hat, sich regelmäßig selbst prüft und optimiert und auch entsprechend viel auf dem Platten macht. Andererseits kann man in FreeNas bzw openBSD mit ZFS viele Optimierungen vornehmen, was Platten und Systemzugriffe angeht.
Inwieweit Linux solche Optimierungen bietet, kA

PS: ZFS als Filesystem mit extrem vielen Zugriffen sollte unbedingt mit ECC Ram betrieben werden.
Ansonsten hat man im schlimmsten Fall Müll auf der Platte, der nicht so schnell auffällt und ohne vernünftige Backupstrategie wird es dann eng.
Ein gekipptes Bit ist selten, aber im schlimmsten Fall versaut es dir wichtige Daten für immer. Gerade weil ZFS viel im RAM macht und weil es eben permanent prüft und verifiziert.
 
ECC ram ist vorhanden. trotzdem danke fuer den hinweis. :)

soweit ich das verstanden habe schreibt txg_sync den cache auf die platte. also u.a. das journal und damit nichts was ich deaktivieren kann oder laenger verzoegern moechte.
 
Mein Mint 20.2. mag irgendwie onboardLan nicht.
Board gewechselt, weil sich andere Hardware ergeben hat, jetzt wird nicht mal der olle 1GbE RealtekT 8111H erkannt.

Nach welchem Treiber muss ich in der Console händisch suchen, um das onboard Lan zum laufen zu überreden?

Ausschnitt aus der Sysinfo im Anhang.
 

Anhänge

  • Bildschirmfoto vom 2021-09-06 19-51-35.png
    Bildschirmfoto vom 2021-09-06 19-51-35.png
    14,2 KB · Aufrufe: 49
jetzt wird nicht mal der olle 1GbE RealtekT 8111H erkannt.
Habe gerade ein Dejavu... war das nicht hier erst vor ein paar Wochen wo jemand sich beschwert hat, das Ubuntu diesen Chip nicht erkennt?
Oder war das in einem anderen Forum? Oder verwechsel ich den Chip gerade?

Der Chip scheint jedenfalls nicht ganz unproblematisch zu sein:
 
Habe gerade ein Dejavu... war das nicht hier erst vor ein paar Wochen wo jemand sich beschwert hat, das Ubuntu diesen Chip nicht erkennt?
Das war ich und da war es der 2,5GbE der RTL8125, der mit dem Standard Kernel 5.4.0 von Linux Mint nicht wollte. Nur mit Kernel 5.11. geht weas, aber dann streikt Virtualbox und andere Software gerne.

Ich werde gleich mal ein

Code:
sudo apt install r8168-dkms

versuchen und dann weiter sehen ...
 
Ich lasse hier für die amdgpu User mal die Warnung da:
Kernel 5.14.3 lief nicht bei mir mit 6900XT auf Kubuntu 20.04

Augenscheinlich fliegt beim initialisieren von amdgpu irgendwas gehörig ausseinander. (journalctl -b --list-boots und dann journalctl -b --boot=Nummer aus Liste)

Der Recovery Mode über Grub führte dann zum Desktop, natürlich fehlte hier die Hälfte der Treiber, beispielsweise mit ohne LM-Sensors drehen meine Lüfter ganz schön am Rad :d

Während ich mir Gedanken machte woran das wohl liegen würde, habe ich https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942684 gefunden. Scheinbar ist ein Patch schon eingetütet, 5.14.4 sollte es tun nehme ich an.
Bis dahin bin ich wieder auf 5.13.13 zurück. Damit zockt es sich wunderbar.
glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: AMD (0x1002)
Device: AMD Radeon RX 6900 XT (SIENNA_CICHLID, DRM 3.41.0, 5.13.13-051313-generic, LLVM 12.0.1) (0x73bf)
Version: 21.3.0
Accelerated: yes
Video memory: 16384MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
VBO free memory - total: 15546 MB, largest block: 15546 MB
VBO free aux. memory - total: 16295 MB, largest block: 16295 MB
Texture free memory - total: 15546 MB, largest block: 15546 MB
Texture free aux. memory - total: 16295 MB, largest block: 16295 MB
Renderbuffer free memory - total: 15546 MB, largest block: 15546 MB
Renderbuffer free aux. memory - total: 16295 MB, largest block: 16295 MB
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 16384 MB
Total available memory: 32752 MB
Currently available dedicated video memory: 15546 MB
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 6900 XT (SIENNA_CICHLID, DRM 3.41.0, 5.13.13-051313-generic, LLVM 12.0.1)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 21.3.0-devel (git-ca92a0d 2021-09-14 focal-oibaf-ppa)
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.3.0-devel (git-ca92a0d 2021-09-14 focal-oibaf-ppa)
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.3.0-devel (git-ca92a0d 2021-09-14 focal-oibaf-ppa)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
 
Zuletzt bearbeitet:
Seit einiger Zeit habe ich das Problem mit meinem Manjaro, dass sich der Desktop (KDE), bzw. schon der Anmeldebildschirm, nach einem Standby manchmal nicht wiederherstellt. Der Monitor bleibt schwarz mit einem beweglichen Mauszeiger. Über Alt+F2 (glaube die wars) komme ich zwar über die Konsole wieder an den Rechner, aber die grafische Oberfläche lässt sich nicht wiederherstellen. Nur ein Neustart schafft letztlich Abhilfe, das ist aber auf Dauer recht lästig. Was ich so gefunden habe ist, dass das wohl ein bekannter Fehler bzgl. Arch+Nvidia ist. Einen kausalen Zusammenhang konnte ich nicht ermitteln, es scheint einfach zufällig in 1/3 der Fälle zu passieren. Hat jemand damit Erfahrung oder Ideen?
 
Xorg oder Wayland? Mit Wayland macht die Kombi KDE+Nvidia tatsächlich noch paar Probleme.
 
Ich denke Xorg. Mit Wayland habe ich mich bisher nicht aktiv auseinandergesetzt. Wie finde ich das auf die Schnelle raus?
 
Beim Anmelden kann man das meist auswählen.
Oder vielleicht mal die laufenden Prozesse anschauen mit htop oder "ps afx | grep xorg", bin mir aber grad nicht sicher ob der Prozess wirklich xorg heisst.
 
Nein, kann ich nicht.
Ich meine mich auch zu erinnern, dass der porträtiere Treiber von nvidia das nicht zulässt, aber ich mag mich irren. Seis drum, auch htop führt unter /usr/bin/sddm Xorg und x11 auf, insofern dürfte es sich um Xorg handeln.
 
Bash:
loginctl show-session $(loginctl | grep $(whoami) | awk '{print $1}') -p Type
...oder...
Bash:
echo $XDG_SESSION_TYPE
 
Ich lasse hier für die amdgpu User mal die Warnung da:
Kernel 5.14.3 lief nicht bei mir mit 6900XT auf Kubuntu 20.04

Augenscheinlich fliegt beim initialisieren von amdgpu irgendwas gehörig ausseinander. (journalctl -b --list-boots und dann journalctl -b --boot=Nummer aus Liste)

Der Recovery Mode über Grub führte dann zum Desktop, natürlich fehlte hier die Hälfte der Treiber, beispielsweise mit ohne LM-Sensors drehen meine Lüfter ganz schön am Rad :d

Während ich mir Gedanken machte woran das wohl liegen würde, habe ich https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942684 gefunden. Scheinbar ist ein Patch schon eingetütet, 5.14.4 sollte es tun nehme ich an.
Bis dahin bin ich wieder auf 5.13.13 zurück. Damit zockt es sich wunderbar.
glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: AMD (0x1002)
Device: AMD Radeon RX 6900 XT (SIENNA_CICHLID, DRM 3.41.0, 5.13.13-051313-generic, LLVM 12.0.1) (0x73bf)
Version: 21.3.0
Accelerated: yes
Video memory: 16384MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
VBO free memory - total: 15546 MB, largest block: 15546 MB
VBO free aux. memory - total: 16295 MB, largest block: 16295 MB
Texture free memory - total: 15546 MB, largest block: 15546 MB
Texture free aux. memory - total: 16295 MB, largest block: 16295 MB
Renderbuffer free memory - total: 15546 MB, largest block: 15546 MB
Renderbuffer free aux. memory - total: 16295 MB, largest block: 16295 MB
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 16384 MB
Total available memory: 32752 MB
Currently available dedicated video memory: 15546 MB
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 6900 XT (SIENNA_CICHLID, DRM 3.41.0, 5.13.13-051313-generic, LLVM 12.0.1)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 21.3.0-devel (git-ca92a0d 2021-09-14 focal-oibaf-ppa)
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.3.0-devel (git-ca92a0d 2021-09-14 focal-oibaf-ppa)
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.3.0-devel (git-ca92a0d 2021-09-14 focal-oibaf-ppa)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
Da ist noch irgendwas anderes im Argen. Weder Kernel 5.14.4 noch 5.14.5 booten hier gescheit.
Laut Bugtracker im obigen Zitat ist jetzt standarmäßig CONFIG_UBSAN_TRAP mit im Kernel kompiliert, welcher zu Debugzwecken wohl den kompletten Kernel bei Warnings abwürgt.

Ich muss mir dringend mal anschauen wie man aktuelle Kernel baut...
 
hm.. wenn X11 dann bin ich erstmal ratlos.

Hier gibts noch ein paar Anhaltspunkte bzgl. Troubleshooting Hibernate: https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate

Danke, da habe ich mich auch schon durchgearbeitet. Es gibt mehrere die das Problem haben, es hat mit einer bestimmten Treiberversion von nV angefangen (glaube 450). Ich verstehe vorallem nicht, warum ich auch manuell nicht die grafische Oberfläche wiederherstellen kann, nur durch einen Neustart.
 
FYI:
5.14.7 tut es wieder!
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh