Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Anfängerfragen - Linux Neuling? Hier ist der richtige Platz für deine Fragen (2)
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"?
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.
Treiber ist der vermutete e1000e, ja ...
Ob ich dem Mint jetzt auch den Kernel 5.11 verpasse, ich weiß noch nicht ...
aber die restliche Hardware würde mich in diese Richtung nötigen.
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.
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.
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?).
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.
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.
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?
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:
Hallo, ich betreibe zuhause eine NextcloudPi-Installation (MSI Cubi mit Ubuntu Desktop und Virtualbox) und durch Zufall bin ich vor einiger Zeit auf Proxmox gestoßen. Gern würde ich die vorhandene Nextcloud-VM auf auf gleicher Hardware, wegen der Vorteile aber unter Proxmox laufen lassen. Ich...
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 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
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
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?
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.
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
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...
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.
habe vor paar Tagen mal einen Ausflug in die Linux Gamingwelt gewagt und bin bisher davon sehr angetan. Spezieller Grund ist bisher das Spiel Assassin's Creed: Odyssey. Das läuft unter Linux mit DXVK einfach großartig im Vergleich zu Windows 10 mit dem gammeligen D3D11-Renderer. Verwende einen R7 5800X + RX6800 XT, das ganze läuft mit Lutris. Grafikkarte hängt über Displayport an einem ASUS MG279Q Bildschirm mit einer Default Freesync-Range von 35-90Hz. In Windows 10 verwende ich eine Range von 56-144Hz die man ganz einfach mit Hilfe von CRU ändern kann. Diese Freesync-Range würde ich auch gerne unter Linux verwenden. Aktuell bin ich gezwungen das Game mit einem Framelimit von 87fps zu spielen damit ich nicht in die 90Hz mit Vsync laufe (erhöhter Input-Lag). Weiß einer einen Weg wie ich meine Freesync-Range unter Linux anpassen kann? Ich habe schon probiert die EDID unter Windows 10 mit der geänderten Range in eine .bin zu extrahieren und diese .bin dann vor dem Boot in der Command-Line von meinem Ubuntu 20.04 LTS einzubinden.
Einfach so ein EDID laden ist ggf. nicht zielführend. Dein Monitor schickt ja normalerweise kein anderes EDID wenn du Linux bootest. Es ist eher wahrscheinlich, das Linux mit dem EDID anders umgeht. Dann bewirkt es natürlich auch nichts, wenn du das gleiche EDID von Windows exportiert erzwingst.
Ich würde mir eher mal die XServer-Einstellungen angucken, und ggf. mal versuchen manuell entsprechende Modelines zu laden.