Könnte aber sein.
Wäre aber nicht Software bedingt!
Win händelt Korrekturen anders als Linux.
Hallo Besucher, der Thread wurde 34k mal aufgerufen und enthält 231 Antworten
letzter Beitrag von c64doc am
-
-
Kannst du das bitte näher erläutern? Du meint bei solchem instabilen Hochfahren, so wie ich es heute erlebt habe, können auch Daten kaputt gehen?
-
Nein. Kaputt geht nix.
Aber das Handling von Fehlern (welche dauernd passieren) ist bei Win und Linux verschieden.
Was genau das ausmacht....frag mich nicht.
Zum testen, mach noch eine weitere Dist drauf und teste.
Sorry, mehr kann ich nicht sagen
-
Ok, kein Problem, danke trotzdem.
-
Oft ist die GUI schuld.
Weil das Grundsystem (Linux) immer stabil läuft.
-
Kannst du das bitte näher erläutern? Du meint bei solchem instabilen Hochfahren, so wie ich es heute erlebt habe, können auch Daten kaputt gehen?
Wenn die Hardware OK war hatte ich bisher weder bei Linux noch bei Windows Datenverluste.
Schau mal in die Logfiles (nicht nur die Ausgabe von 'dmesg') ob da was zu finden ist. Die meisten sind unter '/var/log' zu finden. Interessant bei Problemen mit X11, also dem Desktop sind die Logs die mit 'Xorg' anfangen. Ansonsten noch 'syslog' und 'kern.log'
-
Schwierig, wenn das System nichtmal bootet!
-
Dann könnte man immer noch mit einem Live-Stick ran. Das ist ja das schöne an Log-files. Solange man die Platte irgendwie fehlerfrei ausgelesen bekommt, braucht man keine hochkomplizierten Werkzeuge, um sich das anzusehen.
-
Ich meinte, den Log zu lesen!
Wenn nicht gebootet wird, gibts auch keinen Log
-
JA, und ich meinte, vom Live-Stick booten. Irgendwie muss das System ja auf den Rechner gekommen sein, und viele Distris bieten eine Live-Version dafür an, die dann zumeist auch läuft. Und von der aus kann man sich die Logs auf der Platte ansehen.
[Edit:] Ich präzisiere das nochmal, was ich meine: Irgendwann lief das System ja mal. Und dass es einfach überhaupt keinen Zucker macht, glaube ich nicht. Also gibt's Logs.
-
Gebootet wird ja bis zum Desktop, nur kann ich dann weder ein Programm öffnen noch in einer Konsole wechseln. Das einzige was ich jetzt beim Überfliegen gefunden habe ist solch ein Eintrag im syslog. Laut Internet sprechen einige von random hard locks mit Ryzen Vega GPUs, kann natürlich sein dass die Fehler da noch nicht ganz ausgemerzt sind.
Aug 1 07:16:28 thelab kernel: [ 28.656106] amdgpu 0000:04:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00040010
Aug 1 07:16:28 thelab kernel: [ 28.656108] amdgpu 0000:04:00.0: MORE_FAULTS: 0x0
Aug 1 07:16:28 thelab kernel: [ 28.656111] amdgpu 0000:04:00.0: WALKER_ERROR: 0x0
Aug 1 07:16:28 thelab kernel: [ 28.656113] amdgpu 0000:04:00.0: PERMISSION_FAULTS: 0x1
Aug 1 07:16:28 thelab kernel: [ 28.656115] amdgpu 0000:04:00.0: MAPPING_ERROR: 0x0
Aug 1 07:16:28 thelab kernel: [ 28.656117] amdgpu 0000:04:00.0: RW: 0x1
Aug 1 07:16:28 thelab kernel: [ 28.656148] amdgpu 0000:04:00.0: [mmhub0] no-retry page fault (src_id:0 ring:8 vmid:0 pasid:0, for process pid 0 thread pid 0)
Aug 1 07:16:28 thelab kernel: [ 28.656151] amdgpu 0000:04:00.0: in page starting at address 0x0000000000000000 from client 18
Aug 1 07:16:28 thelab kernel: [ 28.656154] amdgpu 0000:04:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00040010
Aug 1 07:16:28 thelab kernel: [ 28.656156] amdgpu 0000:04:00.0: MORE_FAULTS: 0x0
Aug 1 07:16:28 thelab kernel: [ 28.656158] amdgpu 0000:04:00.0: WALKER_ERROR: 0x0
Aug 1 07:16:28 thelab kernel: [ 28.656160] amdgpu 0000:04:00.0: PERMISSION_FAULTS: 0x1
Aug 1 07:16:28 thelab kernel: [ 28.656163] amdgpu 0000:04:00.0: MAPPING_ERROR: 0x0
Aug 1 07:16:28 thelab kernel: [ 28.656165] amdgpu 0000:04:00.0: RW: 0x1
Aug 1 07:16:28 thelab kernel: [ 28.656196] amdgpu 0000:04:00.0: [mmhub0] no-retry page fault (src_id:0 ring:8 vmid:0 pasid:0, for process pid 0 thread pid 0)
Aug 1 07:16:28 thelab kernel: [ 28.656199] amdgpu 0000:04:00.0: in page starting at address 0x0000000000000000 from client 18
Aug 1 07:16:28 thelab kernel: [ 28.656201] amdgpu 0000:04:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00040010
Aug 1 07:16:28 thelab kernel: [ 28.656203] amdgpu 0000:04:00.0: MORE_FAULTS: 0x0
Aug 1 07:16:28 thelab kernel: [ 28.656206] amdgpu 0000:04:00.0: WALKER_ERROR: 0x0
Aug 1 07:16:28 thelab kernel: [ 28.656208] amdgpu 0000:04:00.0: PERMISSION_FAULTS: 0x1
Aug 1 07:16:28 thelab kernel: [ 28.656210] amdgpu 0000:04:00.0: MAPPING_ERROR: 0x0
Aug 1 07:16:28 thelab kernel: [ 28.656212] amdgpu 0000:04:00.0: RW: 0x1
Aug 1 07:16:28 thelab kernel: [ 28.656244] amdgpu 0000:04:00.0: [mmhub0] no-retry page fault (src_id:0 ring:8 vmid:0 pasid:0, for process pid 0 thread pid 0)
-
Du könntest dir auch die aktuellsten Grafiktreiber installieren. Dazu brauchst du allerdings eine Fremdquelle.
- sudo add-apt-repository ppa:oibaf/graphics-drivers
einbinden, dann bist du tagesaktuell.
-
Danke, werde ich gleich mal probieren.
-
Heute keine Probleme mit der GUI gehabt. Man muss ja auch mal was Positives berichten, in einer Welt die von Negativschlagzeilen moniert ist und man daher schnell glauben kann, dass viel mehr Schlechtes als Gutes passiert.
-
Heute keine Probleme mit der GUI gehabt.
Das ist immer am 1. eines Monats! Da klappt alles.
-
Es ist der 02.08. ...
-
Es ist der 02.08. ...
Und schon wieder einen Bug gefunden!
-
Es ist der 02.08. ...
Und schon wieder einen Bug gefunden!
-
So, ich habe ihn zum Laufen bekommen
In der Konfigdatei /etc/sane.d/epson2.conf habe ich das net autodiscovery durch net <meine ScannerIP> ersetzt und nun kann Sane auch mit dem Scanner arbeiten. Muss ich nur noch im DHCP Server dafür sorgen, dass der Scanner immer dieselbe IP bekommt.
Na das was ja einfach
Ist ja toll, wenn es jemand wie Du und ich ist, der nach etwas Internet Recherche sowas zum Laufen kriegen, in dem man in Config Dateien rumfummelt/frickelt.
Aber genau DAS ist das Problem, dass es für einen DAU unzumutbar ist.
-
kriegen, in dem man in Config Dateien rumfummelt/frickelt.
Nicht standardmäßig unterstützte (alte) Hardware unter Windows ist weniger Gefrickel?
