Notiz Jetzt verfügbar: ASRock DeskMini A300 für Ryzen-APUs ab 145 Euro
- Ersteller Volker
- Erstellt am
- Zur Notiz: Jetzt verfügbar: ASRock DeskMini A300 für Ryzen-APUs ab 145 Euro
fanaticmd
Commander
- Registriert
- März 2019
- Beiträge
- 2.616
@Ratz_Fatz Danke für den Tipp, manches mal hat man ja doch ein Brett vorm Kopf... Via Google neu aufrufen hat ja schließlich geklappt. Habe jetzt einfach mal alles an Browserdaten gelöscht und nun geht’s auch via Lesezeichen wieder
Mittelspecht
Lt. Junior Grade
- Registriert
- Aug. 2019
- Beiträge
- 316
Colindo schrieb:
Was meinst du wie blöd ich geschaut habe
Es ist tatsächlich so, dass Netflix (in Full HD) nur läuft, wenn zusätzlich zum Displayport Kabel, welches als natives Kabel am Monitor ausgewählt ist, das VGA Kabel verbunden ist.
Ich vermute, dass das irgendwas mit dem Handshake der beim Abspielen von HDCP Inhalten stattfindet, zu tun hat.
Zuletzt bearbeitet:
Mittelspecht schrieb:Was meinst du wie blöd ich geschaut habe
Es ist tatsächlich so, dass Netflix (in Full HD) nur läuft, wenn zusätzlich zum Displayport Kabel, welches als natives Kabel am Monitor ausgewählt ist, das VGA Kabel verbunden ist.
Ich vermute, dass das irgendwas mit dem Handshake der beim Abspielen von HDCP Inhalten stattfindet, zu tun hat.
Vielleicht wird so etwas wie ein "HDCP bypass" gemacht(Link). Gibt aber auch wohl HDMI-Splitter die das machen können(Link).
@Ratz_Fatz: Ich habe eben mal wieder mit dem A300 rumgebastelt.
Regards, Bigfoot29
- IOMMU OFF iommu=soft vs. "AMD-Vi: AMD IOMMUv2 functionality not available on this system"
Inhaltlich korrekt. Es gibt kein IOMMU v2. Das wird aber benötigt, um HBA-Features nutzen zu können. - "ACPI=off"
Warum willst Du das eigentlich? Damit deaktivierst Du quasi sämtliche Autokonfigurationsmöglichkeiten moderner Computersysteme?
Regards, Bigfoot29
GIGU
Lieutenant
- Registriert
- Juli 2005
- Beiträge
- 754
Meines heute abgeholt, Schweizer Lieferant. (Leider fehlt noch der ArbeitsspeicherMemorie schrieb:
, und ich kenne niemanden mit ddr 4 in der nähe ) aber ich habe Bios 3.5 drauf. Somit ist alles in Ordnung mit meinem 3400g .Alles zusammengebaut und jetzt muss ich bis Montag auf meinen Arbeitsspeicher warten.
Weil mir der komplette PC eine Zeitlang unter Linux(Debian Testing, Fedora30/31 und Ubuntu 19.10) richtig Probleme bereitet hat(ein Link). Man könnte sagen, dass es von einer unausgereiften Distri, Treiber oder sonstiges kommt, aber da es dann Distri übergreifend MCE Probleme gab wollte ich gerne schauen, ob diese auch ohne ACPI bestehen.Bigfoot29 schrieb:
Des weiteren sind warum auch immer shimx64 Eintrage, die im Bios vorhanden waren verschwunden, nachdem ich eine Sata SSD absteckt, mit der anderen Windows10(MBR) Upgrade gemacht und dann wieder angeschlossen habe(hier).
Da ich ein Asus H110 m-STX mit Intel CPU noch habe, kann ich dort ganz gut nachvollziehen, was von den Problemen in etwa von der Distri kommt und was nicht. Dort ist ein ähnliches Setup. ACPI=off bootet einwandfrei und die Probleme die ich mit diesem AMD System hatte, hatte ich mit zwei verschiedenen Intel System nicht.
Im Moment läuft es mit Debian Testing ganz gut. Generell hatte ich nicht vor ACPI komplett zu deaktivieren. Aber ich habe die folgenden Bootparameter gesetzt und werde wohl auch vorerst dabei bleiben(auch USB hat mir Probleme bereitet deswegen auf "-1" und ivrs_ioapic(Link)):
Code:
acpi=strict pci=nocrs amd_iommu=soft fsck.mode=force fsck.repair=yes mem_encrypt=off ivrs_ioapic[5]=00:14.0 ivrs_ioapic[6]=00:00.2 usbcore.autosuspend=-1
Code:
dmesg -x -l crit,warn,err
kern :warn : [ 0.000000] secureboot: Secure boot could not be determined (mode 0)
kern :err : [ 0.578681] ACPI: _CRS returned 0
kern :err : [ 0.578726] ACPI: _CRS returned 0
kern :err : [ 0.578763] ACPI: _CRS returned 0
kern :err : [ 0.578813] ACPI: _CRS returned 0
kern :err : [ 0.578857] ACPI: _CRS returned 0
kern :err : [ 0.578891] ACPI: _CRS returned 0
kern :err : [ 0.578925] ACPI: _CRS returned 0
kern :err : [ 0.578959] ACPI: _CRS returned 0
kern :err : [ 1.165775] pci 0000:00:00.2: AMD-Vi: Unable to write to IOMMU perf counter.
kern :warn : [ 1.165858] pci 0000:00:00.2: can't derive routing for PCI INT A
kern :warn : [ 1.165860] pci 0000:00:00.2: PCI INT A: not connected
kern :warn : [ 1.168975] PPR NX GT IA GA PC GA_vAPIC
kern :err : [ 15.019736] sp5100-tco sp5100-tco: Watchdog hardware is disabledIch hatte gehofft, dass Asrock die Agesa Updates usw. schneller veröffentlicht, da war ich mit dem Asus Board wohl zu verwöhnt. Das andere Asrock H270 Mainboard erhält ja auch nach zwei Jahren keine Bios Updates mehr. Wir werden sehen, wie das beim A300 gehandhabt wird.
Für die bestehenden Probleme musst ich halt schauen, welche Lösung für mich am besten funktioniert.
Aaaalso...
Probier mal eins:
Installier mal ein Ubuntu 19.04 auf einem USB-Stick. Keine Korrekturen, keine Kernel-Parameter. Das läuft alles out of the box. Ich habe lediglich mit 19.10 das Problem, dass der X-Server nicht sauber hochfährt, wenn Kernel 5.3 bootet. Mit 5.0 (kommt von 19.04 und bleibt beim Upgrade auf 19.10 als Fallback in Grub bestehen) läuft.
Du ziehst Dir mehr oder weniger mit jedem Parameter neue Probleme zu, die Du dann mit dem darauffolgenden Parameter wieder versuchst, hinzubiegen. In (X)Ubuntu 19.04 lief aber alles schon out-of-the-box korrekt. - Ganz ohne extra Hilfsmittel.
(Bis auf den Kernel-Kotz "WARNING: CPU: 7 PID: 433 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1380 dcn_bw_update_from_pplib+0x8d/0x2d0 [amdgpu]" )
Was das "vergessen" der UEFI-Einträge angeht: Das habe ich mit einem Asus-Brett auch. Ist - leider - das normale Verhalten und hat nix mit der AMD-APU zu tun. Man muss nach dem Wieder-Anstecken die Einträge neu im UEFI hinterlegen. Keine Ahnung, ob/wie man das statisch ablegen kann.
Anderes Thema:
"Power-On nach AC loss" gibt es. Kann man problemlos aktivieren und funktioniert. Theoretisch sollte auch ein "USB-On" funktionieren. Aber besser ist da die Lösung mit der Master-Slave-Schaltdose. Kostet nur wenige Euro und schaltet das Netzteil des A300 komplett ab. - Spart Strom.
Regards, Bigfoot29
Probier mal eins:
Installier mal ein Ubuntu 19.04 auf einem USB-Stick. Keine Korrekturen, keine Kernel-Parameter. Das läuft alles out of the box. Ich habe lediglich mit 19.10 das Problem, dass der X-Server nicht sauber hochfährt, wenn Kernel 5.3 bootet. Mit 5.0 (kommt von 19.04 und bleibt beim Upgrade auf 19.10 als Fallback in Grub bestehen) läuft.
Du ziehst Dir mehr oder weniger mit jedem Parameter neue Probleme zu, die Du dann mit dem darauffolgenden Parameter wieder versuchst, hinzubiegen. In (X)Ubuntu 19.04 lief aber alles schon out-of-the-box korrekt. - Ganz ohne extra Hilfsmittel.
(Bis auf den Kernel-Kotz "WARNING: CPU: 7 PID: 433 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1380 dcn_bw_update_from_pplib+0x8d/0x2d0 [amdgpu]" )
Was das "vergessen" der UEFI-Einträge angeht: Das habe ich mit einem Asus-Brett auch. Ist - leider - das normale Verhalten und hat nix mit der AMD-APU zu tun. Man muss nach dem Wieder-Anstecken die Einträge neu im UEFI hinterlegen. Keine Ahnung, ob/wie man das statisch ablegen kann.
Anderes Thema:
"Power-On nach AC loss" gibt es. Kann man problemlos aktivieren und funktioniert. Theoretisch sollte auch ein "USB-On" funktionieren. Aber besser ist da die Lösung mit der Master-Slave-Schaltdose. Kostet nur wenige Euro und schaltet das Netzteil des A300 komplett ab. - Spart Strom.
Regards, Bigfoot29
Zuletzt bearbeitet:
@Bigfoot29
Die Probleme, die ich mit den Distris hatte, bestanden alle ohne Bootparameter und wurde ohne immer schlimmer(CSM-Modus war eigentlich immer an).
Testen kann ich es mit Ubuntu 19.04. Ich werde aber bei Debian Testing bleiben, soweit läuft es besser als zuvor ohne Bootparameter. Ubuntu 19.04 war ja auch schon auf einer SSD drauf, ich habe dann nur ein upgrade auf Ubuntu 19.10 gemacht.
Mit shim war es kein reines vergessen, ich musste shim-signed unter Debian komplett neu installieren, es war nicht mehr da!
Außerdem hatte ich doch beim Asrock A300 doch schon eine SSD mal entfernt, da wurden keine Einträge gelöscht, auch nicht, nachdem das Bios zurückgesetzt wurde. Dann wurde shim korrekt eingelesen und alles war wie vorher. Jetzt geht überhaupt nichts mehr mit shim.
Generell bin ich froh darüber, dass es jetzt läuft,"acpi=strict" usw. kann ich ja immer noch ändern.
Was ich nicht verstehe. Warum lädt "acpi=off" zusammen mit "mitigations=off"(aber nur 1 Kern, wenn CSM aktiviert ist)? Ohne "mitigations=off" lädt "acpi=off" überhaupt nicht. Mitigations dient doch dem Schutz, deswegen ist es mir unverständlich was das mit acpi zu tun hat.
Ich habe heute nochmal das Bios komplett gelöscht, SSDs abgesteckt und nur UEFI Modus zugelassen. Damit werden dann mit "mitigations=off" und "acpi=off" alle Kerne geladen. Nur "acpi=off" macht immer ein KernelPanic mit SMP Nopti.
Egal, was ich jedenfalls im UEFI(only) Modus festgestellt habe. Damit habe ich die USB Probleme scheinbar nicht mehr. Sowas hier:
Es gab da ja noch einen Bug im fTPM. Der erst als Linux Bug abgestempelt wurde und dann wohl doch ein Bios Bug war(Link).
Die HDMI Probleme unter Linux bin ich ja mit dem Displayport nach HDMI Adapter umgangen, damit sind die Kerneleinträge nicht mehr da.
Ich meine mit Problemen bei den Ryzen bin ich ja nicht alleine, irgendwelche Probleme muss AMD ja gehabt haben. Meine beiden 2200G und B350/B450 Mainboards waren ja richtig schlimm, sowohl unter Linux, als auch unter Windows.
Es ist auch schwierig, wenn jemand anderes das nachvollziehen soll und er die Probleme nicht hatte. Jetzt läuft es und ich bin vorerst zufrieden.
Die Probleme, die ich mit den Distris hatte, bestanden alle ohne Bootparameter und wurde ohne immer schlimmer(CSM-Modus war eigentlich immer an).
Testen kann ich es mit Ubuntu 19.04. Ich werde aber bei Debian Testing bleiben, soweit läuft es besser als zuvor ohne Bootparameter. Ubuntu 19.04 war ja auch schon auf einer SSD drauf, ich habe dann nur ein upgrade auf Ubuntu 19.10 gemacht.
Mit shim war es kein reines vergessen, ich musste shim-signed unter Debian komplett neu installieren, es war nicht mehr da!
Außerdem hatte ich doch beim Asrock A300 doch schon eine SSD mal entfernt, da wurden keine Einträge gelöscht, auch nicht, nachdem das Bios zurückgesetzt wurde. Dann wurde shim korrekt eingelesen und alles war wie vorher. Jetzt geht überhaupt nichts mehr mit shim.
Generell bin ich froh darüber, dass es jetzt läuft,"acpi=strict" usw. kann ich ja immer noch ändern.
Was ich nicht verstehe. Warum lädt "acpi=off" zusammen mit "mitigations=off"(aber nur 1 Kern, wenn CSM aktiviert ist)? Ohne "mitigations=off" lädt "acpi=off" überhaupt nicht. Mitigations dient doch dem Schutz, deswegen ist es mir unverständlich was das mit acpi zu tun hat.
Ich habe heute nochmal das Bios komplett gelöscht, SSDs abgesteckt und nur UEFI Modus zugelassen. Damit werden dann mit "mitigations=off" und "acpi=off" alle Kerne geladen. Nur "acpi=off" macht immer ein KernelPanic mit SMP Nopti.
Egal, was ich jedenfalls im UEFI(only) Modus festgestellt habe. Damit habe ich die USB Probleme scheinbar nicht mehr. Sowas hier:
Code:
...
kern :err : [ 2.197644] usb 1-3.2: device descriptor read/all, error -32
kern :err : [ 42.723844] usb 3-1: device descriptor read/64, error -71
...Es gab da ja noch einen Bug im fTPM. Der erst als Linux Bug abgestempelt wurde und dann wohl doch ein Bios Bug war(Link).
Code:
kern :err : [ 19.213910] tpm_crb MSFT0101:00: can't request region for resource [mem 0xdc56e000-0xdc571fff]
kern :warn : [ 19.214615] tpm_crb: probe of MSFT0101:00 failed with error -16Die HDMI Probleme unter Linux bin ich ja mit dem Displayport nach HDMI Adapter umgangen, damit sind die Kerneleinträge nicht mehr da.
Ich meine mit Problemen bei den Ryzen bin ich ja nicht alleine, irgendwelche Probleme muss AMD ja gehabt haben. Meine beiden 2200G und B350/B450 Mainboards waren ja richtig schlimm, sowohl unter Linux, als auch unter Windows.
Es ist auch schwierig, wenn jemand anderes das nachvollziehen soll und er die Probleme nicht hatte. Jetzt läuft es und ich bin vorerst zufrieden.
Zuletzt bearbeitet:
Hi. Ich will Dir auch gar nicht unterstellen, dass die Probleme "nur in Deinem Kopf" bestehen. Dennoch sind manche Sachen hausgemacht.
SHIM brauchst Du eigentlich nie. Gerade mit dem CSM-Mode macht der wenig Sinn. (Wird übrigens tatsächlich bei Updates deinstalliert, wenn das OS merkt, dass nicht "secure" gebootet wurde. - Ist also kein Bug.)
Das Signieren von Boot-Komponenten ist eine Baustelle, die noch lange nicht vollumfänglich in jeder Config sauber läuft. Gleiches gilt für das TPM, welches man in normalen Umgebungen nicht benötigt.
Außerdem: Einerseits aktivierst Du SHIM/Secure Boot, andererseits deaktivierst Du die Security-Patches. Das ist für mich nicht unbedingt schlüssig. Die Performance bei AMD-Systemen sinkt dadurch sogut wie überhaupt nicht. Die wirklich leistungsfressenden Patches sollten lediglich bei Intel-Prozessoren nötig (und auch nur dort automatisch aktiv) sein. Aber das ist nur eine Vermutung.
Bzgl. des "Vergessens": Wie gesagt: Nachvollziehen kann ich das nur bei einem Arch-Linux (Antergos, e.o.L.) und einem Asus-Board. Beim A300 hatte ich das auch noch nie. Hab da aber auch noch nie ohne ursprüngliche Boot-Platte gebootet, ohne ohnehin das System komplett neu aufzustricken.
Regards, Bigfoot29
PS: Ganz andere Baustelle: Der Kernel 5.3 funktioniert, wenn ich einen anderen Desktop als XFCE verwende. Bei mir lief testweise OpenBox (mit "compton", sowohl im OGL- als auch im X-Modus als compositing Manager) problemlos. Also zickt etwas in XFCE4.
SHIM brauchst Du eigentlich nie. Gerade mit dem CSM-Mode macht der wenig Sinn. (Wird übrigens tatsächlich bei Updates deinstalliert, wenn das OS merkt, dass nicht "secure" gebootet wurde. - Ist also kein Bug.)
Das Signieren von Boot-Komponenten ist eine Baustelle, die noch lange nicht vollumfänglich in jeder Config sauber läuft. Gleiches gilt für das TPM, welches man in normalen Umgebungen nicht benötigt.
Außerdem: Einerseits aktivierst Du SHIM/Secure Boot, andererseits deaktivierst Du die Security-Patches. Das ist für mich nicht unbedingt schlüssig. Die Performance bei AMD-Systemen sinkt dadurch sogut wie überhaupt nicht. Die wirklich leistungsfressenden Patches sollten lediglich bei Intel-Prozessoren nötig (und auch nur dort automatisch aktiv) sein. Aber das ist nur eine Vermutung.
Bzgl. des "Vergessens": Wie gesagt: Nachvollziehen kann ich das nur bei einem Arch-Linux (Antergos, e.o.L.) und einem Asus-Board. Beim A300 hatte ich das auch noch nie. Hab da aber auch noch nie ohne ursprüngliche Boot-Platte gebootet, ohne ohnehin das System komplett neu aufzustricken.
Regards, Bigfoot29
PS: Ganz andere Baustelle: Der Kernel 5.3 funktioniert, wenn ich einen anderen Desktop als XFCE verwende. Bei mir lief testweise OpenBox (mit "compton", sowohl im OGL- als auch im X-Modus als compositing Manager) problemlos. Also zickt etwas in XFCE4.
Die mitigation=off habe ich mit abgesteckten SSDs per USB-Live-Stick getestet. Verwende ich sonst nicht, die Geschwindigkeit wäre mir auch nicht so wichtig.
AMD Bugs sind doch vorhanden und teilweise gefixt, die direkt von AMD veröffentlichten Bugs. TPM(fTPM) hat doch eine Relevanz, schreibt doch auch Microsoft.
Also ich mal meine SSD im Uefi Modus mit Windows neu installieren wollte, hat sich Windows auch direkt die TCG Opal 2.0 Verschlüsselung gekrallt. Nicht, dass ich es gewollt hätte, nein einfach so. Bemerkt habe ich es erst, als ich ein SecureErase der SSD machen wollte. Zum Glück hat Crucial die passende Lösung um ein "Psid revert" zu machen.
Was macht denn XFCE nicht? Lädt der Kernel?
Ich habe Xubuntu mit Kernel 5.3 laden können, aber nur nachdem ich ein "nomodeset" eingefügt habe als Bootparameter. Ansonsten erhalte ich in jedem Fall einen grünen Bildschirm.
Edit
Ich habe im Bios versucht Sata zu deaktivieren. Einmal unter "Speicherkonfigurationen" und dann unter "Erweitert\AMD CBS\FCH Common Options\Sata Configuration Options" auf "disable".
Die erste Einstellung bleibt auf "disable", die zweite aktiviert sich von alleine auf "Auto".
Kann es sein, dass gewissen Einstellungen in Bios trotz Deaktivierung aktiviert bleiben?
Vielleicht geht das auch einfach nicht, weil die Ryzen Socs sind und alles in der CPU(USB/Sata usw.) vorhanden ist.
AMD Bugs sind doch vorhanden und teilweise gefixt, die direkt von AMD veröffentlichten Bugs. TPM(fTPM) hat doch eine Relevanz, schreibt doch auch Microsoft.
Also ich mal meine SSD im Uefi Modus mit Windows neu installieren wollte, hat sich Windows auch direkt die TCG Opal 2.0 Verschlüsselung gekrallt. Nicht, dass ich es gewollt hätte, nein einfach so. Bemerkt habe ich es erst, als ich ein SecureErase der SSD machen wollte. Zum Glück hat Crucial die passende Lösung um ein "Psid revert" zu machen.
Code:
grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected
/sys/devices/system/cpu/vulnerabilities/l1tf:
Not affected
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
grep bugs /proc/cpuinfo
bugs : sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bugs : sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bugs : sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bugs : sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypassWas macht denn XFCE nicht? Lädt der Kernel?
Ich habe Xubuntu mit Kernel 5.3 laden können, aber nur nachdem ich ein "nomodeset" eingefügt habe als Bootparameter. Ansonsten erhalte ich in jedem Fall einen grünen Bildschirm.
Edit
Ich habe im Bios versucht Sata zu deaktivieren. Einmal unter "Speicherkonfigurationen" und dann unter "Erweitert\AMD CBS\FCH Common Options\Sata Configuration Options" auf "disable".
Die erste Einstellung bleibt auf "disable", die zweite aktiviert sich von alleine auf "Auto".
Kann es sein, dass gewissen Einstellungen in Bios trotz Deaktivierung aktiviert bleiben?
Vielleicht geht das auch einfach nicht, weil die Ryzen Socs sind und alles in der CPU(USB/Sata usw.) vorhanden ist.
Zuletzt bearbeitet:
Das TPM ist ein Hilfsmittel für Firmen-PCs. Dort hat es eine gewisse Berechtigung. Für Heim-Computer ist es derzeit kaum sinnvoll. Letztlich hilft es vor allem Firmen, sicherzustellen, dass man ihre Software nicht mehr umgehen kann. Videostreams, Lizenzen, ... letztlich alles, was mit Verschlüsselung zu tun hat. Das TPM kann gesicherte Schlüssel erzeugen und den privaten Teil - solange es nicht verbuggt ist wie bei Intel derzeit - geheim halten. (Daher die sinnvolle Nutzung im Firmenumfeld.)
Die Frage ist: Wozu musst Du deine private Festplatte OPAL-verschlüsseln? Oder überhaupt an Deine Plattform binden? Sobald das TPM nämlich hinüber ist (z.B. Mainboard-Defekt) und Du die Wiederherstellungsdaten nicht lokal vorhanden hast, ist die Platte im Eimer. Über die Tatsache, dass man die TPM-Daten auch bei Microsoft speichern lassen kann, sag ich mal nix. (Wer kommt auf so einen sicherheitstechnisch hahnebüchenen Albtraum?!)
Das TPM ist also - für Privatpersonen - nur für Microsoft relevant.
Bugs: Ich bleibe dabei, dass die Mitigations bei AMD-Prozessoren an bleiben, da sie eh sinnvoll aktiviert werden (bis mich jemand eines Besseren belehrt ^^). Klar hat AMD auch ein paar Bugs. Schreibe ich ja auch. Aber die Behebung der Probleme zieht im Vergleich zu den Intel-Prozessoren - wieder afaik - deutlich weniger Ressourcen. Es ist schlicht weniger betroffen.
XFCE: Der Kernel und das restliche Basis-System lädt immer. Ich kann auch in die Konsole und dort quasi alles tun. Aber sobald ich mich als User auf der GUI anmelde, hängt sich der "Bildschirm auf". Aktuelle Workarounds: Nutzung von Kernel 5.0 (dann auch mit XFCE) oder 5.3 (dann mit z.B. OpenBox als Window-Manager, nicht mehr XFCE).
Regards, Bigfoot29
PS: Klar KANN man das TPM auch im Privatumfeld sinnvoll nutzen. Der signierte Boot-Prozess hilft gegen manche Trojaner. Aber nachdem UEFI Bug-sicherheitstechnisch eh offen ist wie eine Scheune, bringt das auch nicht mehr viel, wenn ein Bösewicht ohnehin schon auf dem System ist.
Die Frage ist: Wozu musst Du deine private Festplatte OPAL-verschlüsseln? Oder überhaupt an Deine Plattform binden? Sobald das TPM nämlich hinüber ist (z.B. Mainboard-Defekt) und Du die Wiederherstellungsdaten nicht lokal vorhanden hast, ist die Platte im Eimer. Über die Tatsache, dass man die TPM-Daten auch bei Microsoft speichern lassen kann, sag ich mal nix. (Wer kommt auf so einen sicherheitstechnisch hahnebüchenen Albtraum?!)
Das TPM ist also - für Privatpersonen - nur für Microsoft relevant.
Bugs: Ich bleibe dabei, dass die Mitigations bei AMD-Prozessoren an bleiben, da sie eh sinnvoll aktiviert werden (bis mich jemand eines Besseren belehrt ^^). Klar hat AMD auch ein paar Bugs. Schreibe ich ja auch. Aber die Behebung der Probleme zieht im Vergleich zu den Intel-Prozessoren - wieder afaik - deutlich weniger Ressourcen. Es ist schlicht weniger betroffen.
XFCE: Der Kernel und das restliche Basis-System lädt immer. Ich kann auch in die Konsole und dort quasi alles tun. Aber sobald ich mich als User auf der GUI anmelde, hängt sich der "Bildschirm auf". Aktuelle Workarounds: Nutzung von Kernel 5.0 (dann auch mit XFCE) oder 5.3 (dann mit z.B. OpenBox als Window-Manager, nicht mehr XFCE).
Regards, Bigfoot29
PS: Klar KANN man das TPM auch im Privatumfeld sinnvoll nutzen. Der signierte Boot-Prozess hilft gegen manche Trojaner. Aber nachdem UEFI Bug-sicherheitstechnisch eh offen ist wie eine Scheune, bringt das auch nicht mehr viel, wenn ein Bösewicht ohnehin schon auf dem System ist.
Hat jemand zufällig das original ASRock USB 2 Erweiterungskit und weiß noch mit welcher Größe die beiliegenden zwei Schrauben angegeben waren ?
Ich habe gerade für einen Kollegen einen A300 zusammengebaut und er hat die andere Erweiterung die hier schon mal im Thread erwähnt wurde gekauft, allerdings hat diese ja keine Schrauben beiliegen.
Meiner Meinung nach müssten das M2 oder M2,5 Schrauben gewesen sein.
In der Anleitung des A300 gibt es leider keine Angabe.
Ich habe gerade für einen Kollegen einen A300 zusammengebaut und er hat die andere Erweiterung die hier schon mal im Thread erwähnt wurde gekauft, allerdings hat diese ja keine Schrauben beiliegen.
Meiner Meinung nach müssten das M2 oder M2,5 Schrauben gewesen sein.
In der Anleitung des A300 gibt es leider keine Angabe.
Bigfoot29 schrieb:
Ich habe nichts gegenteiliges behauptet. Wer sich die TGC Verschlüsselung gekrallt hat, habe ich oben geschrieben. Für heute habe ich genug. ^^ Aber ein paar Berichte zu den UEFI Bugs lese ich mir noch durch.
Griffin89 schrieb:
Ich hab die Schraube locker...nein, losgeschraubt und mit dem Messschieber gemessen. Bei mir ist es eine M2,5, ich habe allerdings nicht das "original" Kit von Asrock.
Ich bin mir absolut sicher, dass die Schrauben entweder beim USB2-Kit oder der Box selbst dabei waren. 2 schwarze Senkkopf-Schrauben, die eben mit dem Gehäusedeckel abschließen... Nachmessen kann ich es aber nicht. - Keine Schublehre. Ggf. mal beim Händler nachfragen... :S
Regards, Bigfoot29
Regards, Bigfoot29
Übrigens zu VGA und Netflix von hier. Weil ich mit Xubuntu 19.10 USB LiveStick und dem 3200G nur einen greenscreen erhalten habe, habe ich mal wieder geschaut woran das liegen könnte. Ich habe dann einfach den Bildschirm ausgeschaltet und zusätzlich zum DP nach HDMI-Adapter ein VGA Kabel am Asrock A300 und Monitor angeschlossen. Danach den Bildschirm eingeschaltet und konnte so den greenscreen umgehen.
Damit kann ich zwischen der VGA und DP(HDMI) Ausgabe an einem Bildschirm wechseln.
Die Bildartefakte die ich sehen kann bleiben dennoch bestehen, verschwinden vorübergehend, wenn man Fenster bewegt.
Damit kann ich zwischen der VGA und DP(HDMI) Ausgabe an einem Bildschirm wechseln.
Die Bildartefakte die ich sehen kann bleiben dennoch bestehen, verschwinden vorübergehend, wenn man Fenster bewegt.
Anhänge
Zuletzt bearbeitet:
