Skip to content

MSI B650 Tomahawk WiFi

Allgemeine Diskussionen
  • Ich spekuliere schon länger damit, auf die AM5 Plattform von AMD zu wechseln. Wirklich attraktiv war die eigentlich für mich nicht. Warum? Ich setze heute eigentlich nur noch auf AMD CPUs mit eingebauter GPU. Somit ist mir die PCIe Schnittstelle ziemlich egal. Dann könnte man noch PCIe 5.0 für die NVMe Riegel wichtig finden. Für das was ich damit mache, langt aber auch PCIe 4.0. In den Rechner sollte nur die CPU mit eingebauter GPU, ausreichend Speicher (für mich sehr wichtig) und ein NVMe Riegel (500GB).

    Nach reichlicher Überlegung, lesen von vielen Testberichten und recherchieren der Daten der eingesetzten Komponenten, habe ich mich für folgende Komponenten entschieden.

    • MSI B650 Tomahawk WiFi
    • AMD CPU Ryzen 5 8600G w/ Radeon 760M Graphics
    • 64GB Corsair DIMM DDR5-5200 (2*32GB)

    So sah das dann heute morgen zum Frühstück bei mir aus 😉

    20240420_083823_ergebnis.jpg

    Das war meine erste CPU mit diesem LGA Sockel, vorher hatte AMD ja immer auf den PGA Sockel gesetzt. Die Konkurrenz Intel nutzt ja schon lange LGA. Also mal kurz ein Video zur Montage angesehen, man will ja nichts falsch machen und zusammengebaut. Ist kinderleicht. Danach mein altes Testsystem zerlegt und das neue Mainboard eingebaut.

    Auf dem alten Testsystem lief ein Manjaro mit KDE Plasma 6. Diesen NVMe Riegel habe ich ins neue System verbaut und einfach mal gestartet. Beim ersten Start des Systems, mal schnell ins BIOS geschaut.

    20240420_105236_ergebnis.jpg

    Ok, sah soweit gut aus. Reset und nach Eingabe meines Passwortes kam irgendso eine Meldung die aussagte, das das Betriebssystem nicht gestartet werden kann wegen Secure Boot Das ist doch dieser Mist, wo M$ irgendwas signieren muss, damit ein Linux startet!? Braucht kein Mensch 🙂

    Also Secure Boot ausgeschaltet. Danach startete das System sauber durch.

    20240420_110432_ergebnis.jpg

    Da standen erst mal 177 Updates und warteten auf eine Installation. Schnell alles aktualisiert. Geschaut, das alles lief. WiFi verlangte nach dem Passwort, eingegeben und fertig. Auf dem Board ist WiFi 6E verbaut. Soweit keine akuten Probleme festgestellt.

    Was blieb noch? Ich mag es, wenn das BIOS schön aktuell ist, gerade bei neuen CPUs kommen da doch schon mal Anpassungen und Änderungen. Somit lud ich mir die aktuelle Version herunter.

    Die aktuelle Version war zu diesem Zeitpunkt die Version 7D75v1E vom 21.02.2024 Ab auf den USB Stick und mal über das BIOS installiert. Auch das war wieder kinderleicht. Danach ein Reboot und so steht der Rechner jetzt hier.

    20240420_123437_ergebnis.jpg

    Nein, ich halte einen Wechsel von einer guten AM4 Plattform auf eine AM5 Plattform nicht für notwendig. Das sollte man sich also gut überlegen. Eine meiner wichtigsten Überlegungen dazu war, ich habe nur einen Monitor Anschluss an meinem jetzigen AMD System.

    453f38ed-811e-4493-bd26-91299431b743-grafik.png

    Das läuft auf einem MSI MPG X570 Gaming Plus und der hat nur einen HDMI Anschluss. Das neue System hat einen HDMI und einen DisplayPort Anschluss. Für Linux User gab es ja die Tage einen interessanten Bericht dazu.

    Mein nächstes System sollte also unbedingt einen DisplayPort haben, man weiß ja nicht wo die Entwicklung mit dem HDMI Treiber noch so hingeht.

    Fazit

    Einrichtung und Inbetriebnahme ging erstaunlich gut. Ich hatte mir mehr Problemen gerechnet, aber es gab so gut wie gar keines. Secure Boot zählt nicht, das kann man ja ausschalten. Jetzt die nächsten Tage mal mein altes System auf das Neue transferieren.

  • Wie schon geschrieben, war einer meiner Hauptgründe zu wechseln, der zweite Monitoranschluss. Dann wollen wir das mal testen. Ich habe hier noch einen etwas älteren Monitor rumliegen sollte reichen für einen schnellen Test.

    Mittels HDMI im laufenden Betrieb angesteckt. Das Plasma 6 erkennt den Monitor einwandfrei.

    Screenshot_20240421_173235.png

    Und hier wofür ich das vermutlich benutzen möchte.

    20240421_092909.jpg

    Klappt soweit einwandfrei 🤓

  • F FrankM hat am 29. Apr. 2024, 19:03 auf dieses Thema verwiesen
  • F FrankM hat am 1. Mai 2024, 08:33 auf dieses Thema verwiesen
  • Ich baue seit vielen Jahren immer mal wieder neue Boards zusammen. Seit dem ich denken kann, fast immer MSI Boards. Ich habe noch nie so viel Ärger mit einem Board gehabt, wie mit diesem 😞

    Den Anfang machten merkwürdige USB Probleme. Zusammenhang könnte das Flashen eines neuen BIOS gewesen sein. Habe dann viel rum gefummelt und dann gelesen, das ein Reset des CMOS helfen soll.

    Das habe ich gemacht, danach waren die USB Probleme weg. Aber ein Hauptproblem blieb bestehen. Der Standby Modus ging nicht mehr. Am Anfang ging er mal, aber nach dem ich ein neues BIOS geflasht hatte, war Ende. Leider half auch ein Flashen eines älteren BIOS nicht.

    Heute dann mal zur Sicherheit ein anderes Betriebssystem installiert. Ein Fedora 40 mit Plasma 6 hat dasselbe Ergebnis!?

    Ich habe jetzt ein neues Board einer anderen Firma bestellt, ich werde berichten.

  • F FrankM hat am 13. Mai 2024, 20:09 auf dieses Thema verwiesen
  • Hallo @FrankM, die Sache mit dem Standby habe ich zwar auch, aber das Problem hab ich sowohl bei meinem aktuell neu zusammengebauten Rechner (seit knapp einer Woche mit dem "MSI MAG B650 TOMAHAWK"), aber auch an meinem Rechner aus 2016 mit einen "Asus Maximus Hero VIII".

    Ich hatte mal geschaut, welche USB-Geräte ich alle entfernen muss, damit der Rechner über z.B. ein systemctl suspend in den Sleep geht. Hat sich rausgestellt, dass (glaube ich, ist schon ein paar Tage her) ein USB-Hub das Problem verursacht.

    Hattest du schon mal geschaut, welche Geräte per USB dranhängen, und ob es vielleicht ein Gerät gibt, welches das Problem erzeugt? Ein Workaround, welchen ich bei meinem alten Rechner genutzt hatte, war dieser:

    echo XHC > /proc/acpi/wakeup
    

    Damit ging der Rechner ohne Probleme in den Schlaf, hatte sich aber nicht mehr über die USB-Geräte wecken lassen. Dann musste man normal den Power-Button drücken.

  • @kiwilog Danke für die Antwort.

    Ich habe mittlerweile ein ASUS Rog Strix B650E-F Gaming Wifi. Auch dieses Board hatte Probleme. Ich habe dann den RAM ausgetauscht und jetzt funktioniert es. Das MSI Board liegt hier aber noch, so das ich deinen Tipp da mal testen kann. Das wartet aber noch auf einen AMD Ryzen 9000 🙂

    Als Fazit, die AM5 Plattform scheint sehr empfindlich zu sein.

  • F FrankM hat am 14. Aug. 2024, 13:47 auf dieses Thema verwiesen

4/5

5. Juni 2024, 15:42


  • 0 Stimmen
    1 Beiträge
    0 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    2 Beiträge
    176 Aufrufe
    Ich habe ja im obigen Beispiel, den gesamten Ordner von der Postgres Installation gesichert. backup_pfad_postgres="/home/pguser/db-data" Ich habe dann mal ein wenig in der Dokumentation gelesen und das hier gefunden. https://www.postgresql.org/docs/current/app-pgdump.html Einfach den Ordner zu sichern, ist ja bei jeder Datenbank ein gewisses Risiko. Die Konsistenz der Daten ist nicht gesichert. Darum gibt es bei den Datenbanken auch immer Tools, mit denen man die Daten sichern kann. In der Doku steht folgendes. pg_dump — extract a PostgreSQL database into a script file or other archive file Aber wichtiger ist das hier. pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers). Das macht also konsistente Backups. Wichtig noch zu wissen ist folgendes. pg_dump only dumps a single database. To back up an entire cluster, or to back up global objects that are common to all databases in a cluster (such as roles and tablespaces), use pg_dumpall. Ok, das scheint gut geeignet zu sein, um die Datenbank zu sichern. Aber, wie? Auf meinen Eingangsbeitrag kam es zu folgendem Dialog auf Mastodon. https://nrw.social/deck/@nebucatnetzer@social.linux.pizza/114132208440509237 Das war der Anstoß sich mit dem Thema zu beschäftigen. Und ich hatte dann folgende Lösung. podman exec -it postgres pg_dump -U postgres -f /var/lib/postgresql/data/dump.txt Ok, was mache ich hier? Wir führen einen Befehl vom Host aus gesehen, im Container aus. podman exec -it postgres Der Teil führt den folgenden Befehl im Container aus. pg_dump -U postgres -f /var/lib/postgresql/data/dump.txt pg_dump - Das Tool fürs Backup -U postgres - Der Befehl wird als User postgres ausgeführt -f /var/lib/postgresql/data/dump.txt - Das Dump File wird im Data Ordner abgelegt, den haben wir ja persistent auf dem Host. Somit kann ich das jetzt einfach in mein Backup Script einbauen und brauchen nicht mehr den ganzen Ordner zu kopieren, sondern nur noch das Dump File. Ich werde diese Änderungen in das obige Script einbauen.
  • Restic v0.16.5 released

    Restic restic linux 1. Juli 2024, 20:07
    0 Stimmen
    1 Beiträge
    139 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    2 Beiträge
    246 Aufrufe
    Ich möchte hier aber auch nicht unterschlagen, dass viele der Neuerungen bei meiner Installation nicht funktionieren. Hauptsächlich Funktionen im Zusammenhang mit der neuen Teams Funktion. Da ich schon sehr lange Nextcloud nutze, kenne ich das von den 0.0er Versionen. Da braucht es erst mal ein paar Updates, bis das fehlerfrei funktioniert.
  • 0 Stimmen
    25 Beiträge
    5k Aufrufe
    Hallo @wooshell , erst mal sehr schade das Du so einen Stress mit dem Board hast. Ich habe das jetzt schon Monate laufen, übrigens ohne einen Kühler. Ok, wird ordentlich warm aber ich hasse Lüfter Ich kann leider nicht so richtig erkennen, wo dein Problem liegt. Wie groß ist dein Speicher? Ist der in der Liste der unterstützen RAM Riegel? Das habe ich verbaut. RAM: Corsair Vengeance SODIMM 32GB (2x16GB) DDR4 2400MHz CL16 https://www.corsair.com/de/de/Kategorien/Produkte/Arbeitsspeicher/VENGEANCE-DDR4-SODIMM/p/CMSX32GX4M2A2400C16 Aus dem Bauch heraus, würde ich auf RAM tippen.
  • 0 Stimmen
    1 Beiträge
    1k Aufrufe
    Niemand hat geantwortet
  • Passkeys

    Linux linux passkeys 26. Mai 2023, 06:39
    0 Stimmen
    2 Beiträge
    249 Aufrufe
    Passend dazu aus dem Bitwarden Blog https://bitwarden.com/blog/bitwarden-passkey-management/
  • LUKS verschlüsselte Platte mounten

    Linux linux 1. Mai 2020, 11:45
    1
    0 Stimmen
    2 Beiträge
    1k Aufrufe
    So, jetzt das ganze noch einen Ticken komplizierter Ich habe ja heute, für eine Neuinstallation von Ubuntu 20.04 Focal eine zweite NVMe SSD eingebaut. Meinen Bericht zu dem Thema findet ihr hier. Aber, darum soll es jetzt hier nicht gehen. Wir haben jetzt zwei verschlüsselte Ubuntu NVMe SSD Riegel im System. Jetzt klappt die ganze Sache da oben nicht mehr. Es kommt immer einen Fehlermeldung. unbekannter Dateisystemtyp „LVM2_member“. Ok, kurz googlen und dann findet man heraus, das es nicht klappen kann, weil beide LVM Gruppen, den selben Namen benutzen. root@frank-MS-7C37:/mnt/crypthome/root# vgdisplay --- Volume group --- VG Name vgubuntu2 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size <464,53 GiB PE Size 4,00 MiB Total PE 118919 Alloc PE / Size 118919 / <464,53 GiB Free PE / Size 0 / 0 VG UUID lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A --- Volume group --- VG Name vgubuntu System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size <475,71 GiB PE Size 4,00 MiB Total PE 121781 Alloc PE / Size 121781 / <475,71 GiB Free PE / Size 0 / 0 VG UUID jRYTXL-zjpY-lYr6-KODT-u0LJ-9fYf-YVDna7 Hier oben sieht man das schon mit geändertem Namen. Der VG Name muss unterschiedlich sein. Auch dafür gibt es ein Tool. root@frank-MS-7C37:/mnt/crypthome/root# vgrename --help vgrename - Rename a volume group Rename a VG. vgrename VG VG_new [ COMMON_OPTIONS ] Rename a VG by specifying the VG UUID. vgrename String VG_new [ COMMON_OPTIONS ] Common options for command: [ -A|--autobackup y|n ] [ -f|--force ] [ --reportformat basic|json ] Common options for lvm: [ -d|--debug ] [ -h|--help ] [ -q|--quiet ] [ -v|--verbose ] [ -y|--yes ] [ -t|--test ] [ --commandprofile String ] [ --config String ] [ --driverloaded y|n ] [ --nolocking ] [ --lockopt String ] [ --longhelp ] [ --profile String ] [ --version ] Use --longhelp to show all options and advanced commands. Das muss dann so aussehen! vgrename lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A vgubuntu2 ACHTUNG Es kann zu Datenverlust kommen, also wie immer, Hirn einschalten! Ich weiß, das die erste eingebaute Platte mit der Nummer /dev/nvme0n1 geführt wird. Die zweite, heute verbaute, hört dann auf den Namen /dev/nvme1n1. Die darf ich nicht anpacken, weil sonst das System nicht mehr startet. /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1 # /boot was on /dev/nvme1n1p2 during installation UUID=178c7e51-a1d7-4ead-bbdf-a956eb7b754f /boot ext4 defaults 0 2 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=7416-4553 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgubuntu-swap_1 none swap sw 0 0 Jo, wenn jetzt die Partition /dev/mapper/vgubuntu2-root / anstatt /dev/mapper/vgubuntu-root / heißt läuft nichts mehr. Nur um das zu verdeutlichen, auch das könnte man problemlos reparieren. Aber, ich möchte nur warnen!! Nachdem die Änderung durchgeführt wurde, habe ich den Rechner neugestartet. Puuh, Glück gehabt, richtige NVMe SSD erwischt Festplatte /dev/mapper/vgubuntu2-root: 463,58 GiB, 497754832896 Bytes, 972177408 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Nun können wir die Platte ganz normal, wie oben beschrieben, mounten. Nun kann ich noch ein paar Dinge kopieren