Servus allerseits Seit ein paar Tagen bin ich dabei, von Windows 7 auf Debian umzusteigen. Mein Problem ist, dass Debian mir einfriert. Da hilft nur noch ein langes Drücken der PowerTaste. Manchmal sind es 15 Minuten, manchmal Stunden. Der Rekord, bei dem ich am Stück arbeiten konnte, waren so um die 10 Stunden. Dabei spielt es keine Rolle, ob nur der leere Desktop zu sehen ist, ob ich nur einen Browser offen habe und etwas lese, oder ob mehrere Programme am Laufen sind. Den TaskManager habe ich natürlich stets im Blickfeld: aber keinerlei Besonderheiten. Auch ein Stresstest mit stressapptest brachte den Rechner nicht aus dem Takt. Derselbe PC läuft aber auf Windows 7 schon seit 2 Jahren ohne Auffälligkeiten. Hat jemand von Euch einen Tipp?
> Hat jemand von Euch einen Tipp? Ja > Derselbe PC läuft aber auf Windows 7 schon seit 2 Jahren ohne > Auffälligkeiten. Hau dir n Win10 drauf und sei damit glücklich. Ich habe es auch seit Anfang des Jahres und bin genauso zufrieden wie unter Win7; an die etwas andere Struktur gewöhnt man sich sehr schnell. Wenn du den PC als Arbeitsgrät siehst, muss es funktionieren, ohne große Fummelei wie es bei unixoiden Systemen sehr oft der Fall ist. Für einen Medien-PC für Internet und Musik reicht ein Ubuntu/Lubuntu locker aus, habe ich auch, macht was es soll. Dienstlich nutze ich jedoch ein Win10.
Ja, der PC ist für mich ein Arbeitsgerät und damit verdiene ich meine Brötchen. Gerade deshalb würde ich gerne auf Linux umsteigen. Und auch, weil auf allen meine Servern Debian installiert ist. Der Umzug hat auch problemlos geklappt. Ich konnte sogar problemlos meinen physikalischen Rechner als einen virtuellen einrichten, damit der Umzug nicht alzu brutal ausfiel. Aber diese ewige Einfriererei ... so kann ich nicht arbeiten.
Hast Du schon "Ctrl-Alt-Backspace" probiert, um den X-Server "abzuschießen", dann solltest Du auf der Kommandozeile beim Login laden. Nächster Schritt sind dann die Logbücher....
@von Skyper Z.Zt. habe ich wieder die Win7 Harddisk auf dem Rechner. "Ctrl-Alt-Backspace" kannte ich nicht, werde es also beim naechsten Versuch probieren. Aber ich glaube nicht, dass der Rechner auch nur mit der Wimper zucken wird. Die Log-Dateien habe mir angeschaut. Dabei war mir nur eine Meldung mit TCS_DEADLINE Bug aufgefallen. Den habe ich aber mit der Installation von intel-microcode behoben.
Eventuell kannst du mit den SysRq keys das System wieder von den toten zurückholen, und dann mit dmesg nachsehen, was schief lief. Mit sysrq hab ich schon einige tote Systeme doch noch zum Reden gebracht. Muss man an aber eventuell erst aktivieren (vor dem crash!): "echo 1 > /proc/sys/kernel/sysrq" https://en.wikipedia.org/wiki/Magic_SysRq_key Andere dinge, die man probieren könnte: * Mit einem anderen System per SSH einlogen, und "dmesg -w" eingeben. Wenn man glück hat, schafft es es vielleicht noch das relevante Ereignis zu übertragen, wenn es anfängt zu hängen. Muss aber nicht. Ich hab einen Laptop, wo der WLan Treiber manchmal abstürzt, und früher alles einfror, da ging das natürlich nicht. * Falls du Seriell oder UART hast, eventuell in der kernel/boot komandozeile "console=" auf dieses setzen, und daran einen anderen PC anschlissen, und die Ausgaben ansehen. Eventuell dann das kernel consolen loglevel hochsetzen.
Hast Du evtl. neue Hardware verbaut, Debian ist sehr langsam, was neue Hardwaretreiber betrifft. Probier mal Ubuntu bzw. Xubuntu (aber bitte die LTS-Versionen), die sind da besser.
könnte dieses Problem am Linux Kernel sein: https://howto.lintel.in/freezing-intels-bay-trail-socs-cushioned-patch/ https://forum.manjaro.org/t/intel-bay-trail-freezes-the-linux-kernel/1931 https://bugzilla.kernel.org/show_bug.cgi?id=109051
Ingo Less schrieb: > Wenn du den PC als Arbeitsgrät siehst, muss es funktionieren, ohne große > Fummelei wie es bei unixoiden Systemen sehr oft der Fall ist. Selten so einen Unsinn über "unixoiden Systeme" gelesen. Alle heutigen großen Linuxdistributionen sind in kürzester Zeit eingerichtet und lauffähig. Da braucht man nichts groß zu Fummeln. Mein Arbeitskollege hat vor einem Jahr ein neues Notebook mit Windows 10 bekommen. Seit dem hat er täglich mindestens zwei Bluescreens. Die IT hat schon mehrfach das System neu aufgesetzt, verschiedenste Windowsupdates ausprobiert und auch der Hersteller des Systems weis keine Lösung. Windows 10 hier als die Lösung aller Stabilitätsprobleme zu loben ist vollkommen unangemessen. Alle Betriebssysteme haben hier und dort so Ihre Problemchen welche je nach Hardware auftreten, aber im Allgemeinen laufen heutige Betriebssysteme stabil. In fast allen Fällen ist es ein Hardwareproblem, welches unter einem anderen BS nur nicht in Erscheinung tritt. Kann gut sein, dass der Rechner mit Win10 genau die gleichen Abstürze zeigt. Erster Test wäre, ob das System nach dem Absturz noch per SSH erreichbar ist, dann kommt man mit "dmesg" weiter. MagicSysReq kann auch funktionieren, wenn aber die Grafik abschmiert dann hilft das auch nicht. (Dann sollte aber SSH gehen) Strg+Alt+Backspace ist heute bei fast allen Linuxen standardmäßig deaktiviert.
Hatte öfter mal Probleme mit VIA Chipsätzen. Hab ein Mainboard mit VIA IDE-Controller. Auch dauernd hängengeblieben, IDE disabled. Brauch ich nicht. Problem weg. NVIDIA Grafik ist auch problematisch. AMD und Intel scheinen besser zu sein.
Hatte schon einige Systeme mit Windows 10 und noch nicht eins hatte einen bluescreen... Bei Linux is aber immer irgendwas...
Eine einfache Methode, an eine Textkonsole zu kommen, bieten die
Tastenkombinationen
Strg-Alt-F2 bis Strg-Alt-F6
Man kann sich dort normal einloggen, sofern das System noch läuft.
Zum Desktop zurück kommt man mit
Strg-Alt-F7
Diese Tastenkombinationen sind standardmäßig aktiviert.
:
Bearbeitet durch User
Ingo Less schrieb: > Wenn du den PC als Arbeitsgrät siehst, muss es funktionieren Darum Linux/BSD Mehmet K. schrieb: > Ja, der PC ist für mich ein Arbeitsgerät und damit verdiene ich meine > Brötchen. Gerade deshalb würde ich gerne auf Linux umsteigen. Vernünftige Entscheidung. Mehmet K. schrieb: > Der Umzug hat auch problemlos geklappt. Ich konnte sogar problemlos > meinen physikalischen Rechner als einen virtuellen einrichten VMWare Workstation macht als Host sehr viele Probleme. Da frieren schonmal VMs ein, unabhängig vom OS. Solche Probleme habe ich mit KVM noch nie gehabt.
Mehmet K. schrieb: > Mein Problem ist, dass Debian mir einfriert. Was bedeutet das genau? - Mauszeiger reagiert nicht mehr? - Tastatur (NumLock/CapsLock) reagieren nicht mehr? - xload/top/... frieren ein?
roland schrieb: > Hatte öfter mal Probleme mit VIA Chipsätzen. > Hab ein Mainboard mit VIA IDE-Controller. > Auch dauernd hängengeblieben, IDE disabled. > Brauch ich nicht. Problem weg. Ja, VIA war Dreck, ist aber schon fast zwei Jahrzehnte her. Gibt ausser AMD und Intel nichts anderes mehr. > NVIDIA Grafik ist auch problematisch. > AMD und Intel scheinen besser zu sein. Kann ich nicht bestätigen. Die Nvidia-Treiber laufen unter Linux einwandfrei und das auch mit den neuesten Modellen (hab ne RTX2070). Der Intel-Kram dagegen zickt gerne rum, wenn etwas 3D gefordert wird. Da klemmen dann irgendwelche Queues, viel Grafik geht dann nicht mehr. Zum Ausgangsproblem: Wenn der PC auch nicht mehr pingt, gabs entweder eine fatale Kernel-Panic oder die HW hats ganz zerlegt. Dass das reproduzierbar scheint ist gut, sollte dann auch im Text-Mode passieren. Leider ist es nicht ganz so einfach, das Crashlog zu bekommen, wenn das Ding einfriert. Am einfachsten mit der Ausgabe über RS232, wenn das Board noch so was hat. Ansonsten kann man das Kernellogging direkt auf die VGA-Konsole bekommen (und den Konsolen-Screen-Saver abdrehen...). Hab das mit systemd aber noch nie versucht.
Skyper schrieb: > Hast Du schon "Ctrl-Alt-Backspace" probiert, um den X-Server > "abzuschießen", dann solltest Du auf der Kommandozeile beim Login laden. Die Möglichkeit ist per Default abgeschaltet, weil jemand mal versehentlich(!) diese Tastenkombination erwischt hat und einen wichtigen(?) Text verloren hat. In /etc/default/keyboard kann man das reparieren (sollte man immer gleich nach der Installation machen)
1 | XKBOPTIONS="terminate:ctrl_alt_bksp" |
DPA schrieb: > * Falls du Seriell oder UART hast, eventuell in der kernel/boot > komandozeile "console=" auf dieses setzen, und daran einen anderen PC > anschlissen, und die Ausgaben ansehen. Eventuell dann das kernel > consolen loglevel hochsetzen. Das geht auch per Netzwerk (Kabel, nicht WLAN).
1 | netconsole=[+][src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr] |
2 | where |
3 | + if present, enable extended console support |
4 | src-port source for UDP packets (defaults to 6665) |
5 | src-ip source IP to use (interface address) |
6 | dev network interface (eth0) |
7 | tgt-port port for logging agent (6666) |
8 | tgt-ip IP address for logging agent |
9 | tgt-macaddr ethernet MAC address for logging agent (broadcast) |
Der entscheidende Vorteil von beiden Methoden: die Meldungen kommen direkt vom Kernel, ohne Umweg über syslog oder Dateien oder noch komplizierteres ;) Es geht also auch noch, wenn keine neuen Prozesse mehr gestartet werden können und kein Dateisystem mehr funktioniert.
Uhu U. schrieb: > Eine einfache Methode, an eine Textkonsole zu kommen, bieten die > Tastenkombinationen > > Strg-Alt-F2 bis Strg-Alt-F6 > > Man kann sich dort normal einloggen, sofern das System noch läuft. und dann mal a) top b) dmesg c) tail -f /var/log/syslog anschauen
Ich habe jetzt wieder den Debian aktiviert. Dieser ist auf einer NVMe-SSD installiert, weshalb ein Wechsel etwas mühsam ist. Eine SSH-Verbindung wäre z.Zt. nicht möglich, weil ich umgezogen bin und mein Arbeitszimmer noch nicht so recht eingerichtet ist. Ich werde hier über meine Erfolge/Misserfolge berichten. Und vielen Danke für all die guten Tipps.
Testweise im BIOS alles abschalten was mit Energiesparen zu tun hat. Und BIOS auf defaults setzen.
Da war ich mal kurz in der Küche. Zurück am Schreibtisch musste ich
festellen, dass alles wieder eingefroren war.
Auch SysRq und Ctrl-Backspace liesen den Rechner unberührt.
("echo 1 > /proc/sys/kernel/sysrq" hatte ich vorher ausgeführt).
Als ich wieder lange auf die PowerTaste drücken wollte, fiel mir auf,
dass die HD-LED aktiv var. Ich habe sie mehrere Minuten beoachtet; es
scheint, dass der Rechner doch nicht ganz tot ist. Also müsste ich mich
mit SSH an den Patienten andocken können. Aber das kann ich z.Zt. nicht.
Vielleicht naechste Woche.
Könnte es sein, dass nur der Desktop abgeschmiert ist, der Rest aber
noch funktioniert?
Um 08:19:02 ist der Vermerk "Xorg: page allocation failure"
Beiliegen syslog des heutigen Tages. Wäre nett, wenn jemand, der davon
etwas mehr versteht als ich, einen Blick darauf werfen könnte.
Danke!
:
Bearbeitet durch User
Der scheint ein HW Problem zu haben: Jan 23 08:18:35 debian kernel: [ 1951.808226] rcu: INFO: rcu_sched self-detected stall on CPU Was hast Du für eine Graphikkarte im System?
Ich benutze die Intel Onboard-GK der Mainboard ASUS PRIME Z270-K Die Auflösung: 2560 x 1440 https://www.asus.com/us/Motherboards/PRIME-Z270-K/specifications/ Z.Zt. bin ich wieder mit Win7 unterwegs :(
:
Bearbeitet durch User
Andreas M. schrieb: > Selten so einen Unsinn über "unixoiden Systeme" gelesen. Alle heutigen > großen Linuxdistributionen sind in kürzester Zeit eingerichtet und > lauffähig. Da braucht man nichts groß zu Fummeln. > > Mein Arbeitskollege hat vor einem Jahr ein neues Notebook mit Windows 10 > bekommen. > [...] Was soll denn dieser Whataboutism hier? Bringt das irgend jemanden weiter? Der TE hat nun mal faktisch ein Problem mit einem Debian das ihm ständig einfriert. Da hilfts auch keinem dass der Schwager eines ehemaligen Kollegen gelegentlich mal Bluescreens unter Windows hatte. Mehmet K. schrieb: > Könnte es sein, dass nur der Desktop abgeschmiert ist, der Rest aber > noch funktioniert? Eventuell. Hast du mal versucht mit STRG-ALT-F(1-7) in ein anderes tty zu wechseln? Du solltest da auf eine Textkonsole kommen und dmesg und den ganzen Krempel ausführen können. Im Prinzip fallen mir auch nur die bereits genannten Lösungen ein: - Wechseln auf anderes tty - abschießen von xorg mittels STRG-ALT-BACKSPACE (muss unter Debian anscheinend erst freigeschalten werden, kannte ich so nicht) - ssh von anderem Rechner - eventuell ssh bevor das Problem auftritt und dann warten Aber ganz ehrlich? Diese Möglichkeiten zielen alle darauf ab irgendwie an Diagnosedaten ran zu kommen. Das ist zwar wichtig, gelöst ist dein Problem dadurch aber nicht. Ich würde mal, rein aus Interesse, ein anderes Linux ausprobieren. Irgendwas ohne Debian-Unterbau. Vielleicht ein Fedora oder ein Manjaro (Arch mit komfortablem Installer und netten Gimmicks) Wär mal interessant ob's da auch auftritt. Debian ist halt eher konservativ (lies: altbacken) und dann haben die noch ihren Spleen bzgl. proprietärem Zeugs.
Le X. schrieb: > Eventuell. > Hast du mal versucht mit Alles schon versucht. Negativ. Le X. schrieb: > Vielleicht ein Fedora oder ein Manjaro Mit diesem Gedanken spiele ich auch schon seit ein paar Tagen. Aber: - Debian kenne ich seit Jahren schon etwas - In diesen Wechsel von Windows 7 habe ich schon sehr viel Zeit investiert Le X. schrieb: > Wär mal interessant ob's da auch auftritt. Okay, nur um das zu testen ... warum auch nicht.
Mehmet K. schrieb: > Le X. schrieb: >> Eventuell. >> Hast du mal versucht mit > > Alles schon versucht. Negativ. das "billigste" immer zuerst: mach' mal ein BIOS-Update. Dein aktuelles scheint erheblich angestaubt zu sein... https://dlcdnets.asus.com/pub/ASUS/mb/LGA1151/PRIME_Z270-K/PRIME-Z270-K-ASUS-1207.zip
Mehmet K. schrieb: > es scheint, dass der Rechner doch nicht ganz tot ist. Also müsste ich > mich mit SSH an den Patienten andocken können. Das musst du rechtzeitig machen. Sobald auf dem Desktop nichts mehr geht bekommst keine neue ssh Verbindung mehr. > Könnte es sein, dass nur der Desktop abgeschmiert ist, der Rest aber > noch funktioniert? Alle Programme (bis auf ein kaputtes) funktionieren noch, nur extrem(!) langsam, aber sie bekommen keinen weiteren Speicher mehr. Etwas neues kann deshalb erst recht nicht gestartet werden, auch nicht auf den Textkonsolen. Wenn man aber z.B. htop rechtzeitig startet, müsste das noch funktionieren und man müsste sehen können, wer da soviel Speicher verbraucht. Das Umschalten auf eine Textkonsole kann aber ein paar Minuten dauern. Deshalb würde ich als erstes ein htop in einem xterm mitlaufen lassen. Das funktioniert aber nicht für jede Art von Speicherverbrauch. Treiber brauchen "besseren" Speicher als normale Programme, z.B. ein großes zusammenhängendes Stück. Der networkmanager versucht pausenlos das WLAN zu scannen. Wenn dabei jedesmal neuer Speicher verbraucht wird? Vielleicht läuft ein tmpfs voll. Oder ein virtuelles Filesystem innerhalb von vmware, von dem der Gast glaubt, es wäre ein echtes. Oder vmware macht ständig copy-on-write. Solchen Speicher kann man evt. nicht einmal auslagern. Es scheint eher so etwas zu sein, als dass z.B. Firefox sich wegen kaputtem Javascript aufbläht, swap scheint es ja reichlich zu geben.
Ich hatte das selbe Problem das das System komplett einfrohr, allerdings nur bei einem selbstgesvhriebenen ruby-gtk Programm. dmseg zeigte auch bei mir ein "stall on CPU". Eine Suche im Netz zeigte mir, dass auch andere mit frühen Ryzen-Prozessoren das Problem hatten. Da ich meinen vor kurzen erst gekauft hatte, tauschte ich ihn darauf hin um. Mit dem neuen Prozessor trat das Problem seltener auf und ich konnte noch nachvollziehen, das jetzt irgendwo im X-server der Speicher volllief. Es wurde eine endlose malloc-Schleife aufgerufen. Den Grund dafür konnte ich nicht finden, da mir der Code eine Nummer zu undurchsichig ist. Mit einer Aktuallisierung des Systems war das Problem irgendwann von selbst verschwunden. Ich verwende debian testing.
Jan L. schrieb: > das "billigste" immer zuerst ... Ich hätte schwören können, dies vor ein paar Wochen gemacht zu haben. "dmidecode -s bios-version" ist aber anderer Meinung: nicht 1207 sondern 0610 ist meine Version. Danke für den Hinweis; werde es sobald als möglich updaten. Z.Zt. habe ich aber den Tipp von Andreas B. in die Tat umgesetzt und Bullseye installiert. Ich lass das mal zusammen mit htop laufen und schaue, ob es wieder passiert. Erst dann mache den Bios-Update. Sonst wissen wir ja nicht, wem wir die mögliche Heilung zu verdanken haben.
Le X. schrieb: > Andreas M. schrieb: >> Selten so einen Unsinn über "unixoiden Systeme" gelesen. Alle heutigen >> großen Linuxdistributionen sind in kürzester Zeit eingerichtet und >> lauffähig. Da braucht man nichts groß zu Fummeln. >> >> Mein Arbeitskollege hat vor einem Jahr ein neues Notebook mit Windows 10 >> bekommen. >> [...] > > Was soll denn dieser Whataboutism hier? > Bringt das irgend jemanden weiter? Es bringt vor allem die Erkenntnis das Windows nicht die Lösung aller Probleme ist und das Linux wesentlich weniger kompliziert ist als von Dir behauptet. Aber das wolltest Du ja nicht hören. Mehmet hat doch klar gemacht, das er gerne Linux benutzen möchte. > Da hilfts auch keinem dass der Schwager eines ehemaligen Kollegen > gelegentlich mal Bluescreens unter Windows hatte. Was Du alles weist. Kleiner Tip: es ist mein Vorgesetzer, bei dem in so ziemlich jedem Meeting das Windows 10 abschmiert. Passt aber vermutlich auch nicht in Dein Weltbild. Wie wäre es wenn Du statt Behauptungen und Vermutungen anzustellen dem TO lieber bei seinem Problem hilfst. > [...] Du musst auch nicht die Aussagen von allen anderen nochmal wiederholen. Das bringt niemanden weiter und bläht die Diskussion nur sinnlos auf. Zum Thema: Ich denke der eigentliche Fehler hängt damit zusammen (aus dem syslog): Jan 23 08:19:02 debian kernel: [ 1979.064781] Xorg: page allocation failure: order:0, mode:0x6204d2(GFP_HIGHUSER|__GFP_RETRY_MAYFAIL|__GFP_RECLAIMABLE), nodemask=(null) Kurz darauf läuft der oom-killer an. Sehr merkwürdig. Eventuell bekommt die Grafik nicht mehr den RAM den sie benötigt? Waren zu dem Zeitpunkt VMs aktiv und wenn ja wie viele? VM Hypervisoren sperren zuweilen die Speicherseiten im RAM so das der nur noch den Gastsystemen zur Verfügung steht und auch nicht mehr ausgelagert werden kann. VM-Ware würde ich wenn möglich nicht benutzen. Am besten KVM/QEMU oder wenn es nicht anders geht VirtualBox. Bei VM Ware weis keiner was die im System anstellt, da der Quellcode nicht frei ist (Deswegen ist dein Kernel auch "tainted", kein Kernel-Entwickler wird sich jemals dem Problem annehmen) Teste doch mal ob der Absturz auch eintritt wenn Du VM-Ware nicht lädst, am besten vollständig deinstallieren. VirtualBox sollte mit dem VMWare Images ohne Probleme umgehen können.
Andreas M. schrieb: > das Linux wesentlich weniger kompliziert ist als von > Dir behauptet. Du musst mich mit jemandem verwechseln.
Irgendwie vermisse ich hier einen Verweis auf memtest... Linux Systeme haben numal die Angewohnheit, allen zur Verfügung stehenden Speicher zu nutzen (Dateisystempuffer). Wenn irgendwo "weiter hinten" im Ram was kaputt ist, kann es sein dass das unter Windows nicht weiter auffällt, unter Linux aber die seltsamsten Verhaltensweisen auftreten. Hatte ich hier selbst: Win 10 hatte nie Probleme, da niemals mehr als ~30GB RAM verwendet wurden. Linux ist auf dem selben Rechner regelmäßig abgeschmiert (auf unterschiedlichste Arten) weil es einfach die ganzen 64GB genutzt hat. Einmal MemTest86, RAM Riegel tauschen und alles war wieder gut... Zumindest vorerst - inzwischen sind alle vier Riegel getauscht und es ist wirklich gut (war wohl Montagsware).
mh schrieb: > Irgendwie vermisse ich hier einen Verweis auf memtest... Ich habe das schon öfter mal angeworfen – gefunden hat es nie was… Vor längerer Zeit hat bei mir ein ausgelutschtes Netzteil zu sporadischen Fehlern geführt: der gcc phantasierte Syntaxfehler, wo keine waren. Nach dem Austausch des Netzteils war der Spuk vorbei.
Uhu U. schrieb: > Ich habe das schon öfter mal angeworfen – gefunden hat es nie was… Wenn das Ram nicht defekt ist, findet das auch nichts. Oder umgekehrt: Wenn das mal 24 Stunden ohne gefundene Fehler durchgelaufen ist, ist es äusserst unwahrscheinich, daß der Rechner wg. fehlerhaftem Ram abstürzt. Oliver
Oliver S. schrieb: > Wenn das Ram nicht defekt ist, findet das auch nichts. Oh, das ist eine gänzlich neue Erkenntnis… Was ich eigentlich sagen wollte: RAM-Fehler sind ziemlich selten. Mehmet sollte mal die Netzteilspannungen überprüfen – Unterspannungen führen gerne zu den lustigsten Effekten, die man durchaus auch einem weichen RAM-Riegel zutrauen könnte.
:
Bearbeitet durch User
Le X. schrieb: > Andreas M. schrieb: >> das Linux wesentlich weniger kompliziert ist als von >> Dir behauptet. > Du musst mich mit jemandem verwechseln. Stimmt, da habe ich mich vertan. Tut mir leid!
Kleiner Zwischenbericht: seit 5 Stunden läuft Debian-Bullseye ohne ... ich will das Wort weder schreiben, noch es aussprechen, noch daran denken. Toy toy toy und knock on wood. Das einzige, was nicht läuft ist der VMware-Player. Aber an den hiesigen Reaktionen entnehme ich, dass das eh nicht die beste Wahl war.
Auch wenn das jetzt unanständig klingt, aber bei mir läuft Oracle VM virtualbox sowohl unter Mint 19.3 als auch unter Debian bullseye ohne Probleme.
Mehmet K. schrieb: > Ich benutze die Intel Onboard-GK der Mainboard ASUS PRIME Z270-K Ja dann...könnte das evtl. helfen: Editiere als root /etc/initramfs-tools/modules und schreibe als letztes einfach eine Zeile mit i915 rein. Und danach (auch als root) "update-initramfs -u -k all" ausführen, neu booten und abwarten...
Andreas M. schrieb: > Ingo Less schrieb: >> Wenn du den PC als Arbeitsgrät siehst, muss es funktionieren, ohne große >> Fummelei wie es bei unixoiden Systemen sehr oft der Fall ist. > > Selten so einen Unsinn über "unixoiden Systeme" gelesen. Alle heutigen > großen Linuxdistributionen sind in kürzester Zeit eingerichtet und > lauffähig. Da braucht man nichts groß zu Fummeln. > > Mein Arbeitskollege hat vor einem Jahr ein neues Notebook mit Windows 10 > bekommen. Seit dem hat er täglich mindestens zwei Bluescreens. Die IT > hat schon mehrfach das System neu aufgesetzt, verschiedenste > Windowsupdates ausprobiert und auch der Hersteller des Systems weis > keine Lösung. > > Windows 10 hier als die Lösung aller Stabilitätsprobleme zu loben ist > vollkommen unangemessen. Alle Betriebssysteme haben hier und dort so > Ihre Problemchen welche je nach Hardware auftreten, aber im Allgemeinen > laufen heutige Betriebssysteme stabil. > > In fast allen Fällen ist es ein Hardwareproblem, welches unter einem > anderen BS nur nicht in Erscheinung tritt. Kann gut sein, dass der > Rechner mit Win10 genau die gleichen Abstürze zeigt. > > Erster Test wäre, ob das System nach dem Absturz noch per SSH erreichbar > ist, dann kommt man mit "dmesg" weiter. MagicSysReq kann auch > funktionieren, wenn aber die Grafik abschmiert dann hilft das auch > nicht. (Dann sollte aber SSH gehen) Strg+Alt+Backspace ist heute bei > fast allen Linuxen standardmäßig deaktiviert. Gebe dir vollkomen Recht! nicht bei Linux distri. Ich bin bei Linux seit etwa 6-7 Jahre umgestiegen und bis her vollkomen zufrieden! Bin mit Ubuntu Mint angefangen, kurz danach habe ich mit Arch Linux probiert und seit dem nicht mehr von Arch Linux weg gegangen. @ von Mehmet K. (mkmk) Meine meine Empfehlung, du solltest aber Schrittweise in Linux umsteigen. Gruß. Martin
Habe mich vor paar Tage einen Dell Laptop 7280 i7 Touch LCD und... zugelegt, gleich Arch Linux installiert. Alles funktioniert wie Butter!
Mehmet K. schrieb: > Das einzige, was nicht läuft ist der VMware-Player. Aber an den hiesigen > Reaktionen entnehme ich, dass das eh nicht die beste Wahl war. Wenn nur am VMware-Player hängt, schaue mal dieses Video: https://www.youtube.com/watch?v=14D6T5DIr9o Da geht es aber um Virtualbox und Arch Linux (geht aber bei jede Linux distri.), funktioniert echt Fehler frei, ich habe es selber mit eine CAD Software getestet. Gruß. Martin
einfach auf ein vernünftiges Betriebsystem umsteigen. Windows 10 läuft stabil z.B.
Der Rechner lief jetzt die ganze Nacht. Keine Probleme. Und auch in syslog sind die Fehlermeldungen, mit denen ich nichts anzufangen wusste, verschwunden. Jetzt sind dort nur noch 2 Meckereien, die ich aber wohl alleine hinkriegen werde. Sonst weiss ich ja, wo ich nachfragen muss :) Mit dem Bios-Update warte ich vorsichtshalber noch ein paar Tage. Nochmals allen ein herzliches Dankeschön: habe viel dazugelernt und bin heilfroh, dass all meine Investionen nicht umsonst waren.
:
Bearbeitet durch User
jeder gast schrieb: > einfach auf ein vernünftiges Betriebsystem umsteigen. Es soll auch Leute geben die wollen mit den PC arbeiten statt daddeln.
Martin schrieb: > Alles funktioniert wie Butter! Heißt das, dass es nicht quietscht und kracht, wenn du in deinen Laptop beißt?
Andreas M. schrieb: > Ingo Less schrieb: >> Wenn du den PC als Arbeitsgrät siehst, muss es funktionieren, ohne große >> Fummelei wie es bei unixoiden Systemen sehr oft der Fall ist. > > Selten so einen Unsinn über "unixoiden Systeme" gelesen. Alle heutigen > großen Linuxdistributionen sind in kürzester Zeit eingerichtet und > lauffähig. Da braucht man nichts groß zu Fummeln. Lauffähig heist ja nicht "frei von Einfrierungen" .... Laptop und Linux ist immer noch problematisch, egal was hier für Unsinn erklärt wird.
Pyramidenanspitzer schrieb: > Laptop und Linux ist immer noch problematisch, egal was hier für Unsinn > erklärt wird. also ich kann nicht klagen, 4 Laptops (3x Lenovo,1x Samsung), no problems
Pyramidenanspitzer schrieb: > Laptop und Linux ist immer noch problematisch, egal was hier für Unsinn > erklärt wird. Nö, bis jetzt habe ich noch alle ohne Macken zum laufen bekommen (diverse Lenovos, Sony). Nachhilfe brauchten da in der Vergangenheit nur Sony Notebooks. Ob das heute noch so ist, weiß ich nicht. Trotzdem würde ich immer nur Lenovo, Thinkpads und Dell kaufen. Hier ist man vor Überraschungen geschützt. Die laufen immer.
Und da wäre ich wieder :( Kleines Resümee: Debian 10 liess meinen Rechner sehr oft einfrieren. Andreas B. machte den Vorschlag, ich solle doch mal "Debian testing" (also Debian 11) aufspielen. Was ich auch tat. Und siehe da, alles lief wie geschmiert. Dem Benutzer "von Jan L" war aufgefallen, dass mein Bios alles andere als aktuell war. Und nach 2 Tage habe ich das Bios auf den aktuellen Stand gebracht. "Never touch a running system." Sehr wahre Worte. Zuerst Windows 7 gestartet: keine Problme. Dann Debian gestartet: keine Probleme. Also ab in die Küche um frischen Kaffee aufzusetzen. Bei meiner Rückkehr war alles wieder eingefroren und ich musste den Rechner reseten. Diesmal wechselte ich gleich auf eine Konsole ... und da war ein Stakkato an Fehlermeldungen, dass ein Lesen nicht möglich war. Ctrl-S: Fehlanzeige. Ich schoss ein Foto in der Hoffnung, so vielleich was zu erhaschen: unmöglich. Ohne ins Detail zu gehen: Ich habe mir von der Debian-Seite das ISO von Bullseye geholt. Wohl war mir nicht dabei, denn sie war vom 01.12.2019; also nicht sehr aktuell. Und bei meinem funktionierenden Bullseye war mir aufgefallen, dass jeden Tag ein upgrade stattfand. Die Installation lief bis und mit "cleaning installation" durch. Bei der Installtion von GRUB wurde der Bildschirm schwarz. Ein überdimensionaler und funktionierender Maus-Zeiger war alles, was mir blieb. Hin und wieder blinkte der Bildschirm kurz in weiss. Das wars. Auch hier will ich nicht ins Detail gehen. Um die Frage zu klären, ob die Probleme von meinem Rechner oder von Debian stammen, habe ich Arch installiert (@LeX Danke für den Tipp mit Manjaro). Die Installation verlief problemlos. Ebenso das System-Update. Ich habe den Rechner wieder die ganze Nacht laufen lassen: alles bestens. Ich habe mich dazu entschlossen, mit Windows 7 solange weiterzumachen, bis die Installations-Disk von Bullseye aktuallisiert wird. Dann will ich es nochmals versuchen. Und wenns dann immer noch nicht klappt, muss ich halt den Rechner erneuern. Ein Wechsel zu Arch oder einem anderen Linux kommt für mich nicht in Frage; denn auf all meinen Servern ist Debian insalliert. So geistig fitt bin ich nun auch wieder nicht, als dass ich das handhaben könnte.
BIOS wieder zurück setzen ist keine Option? Gerade mal geschaut, gibt es noch alles: https://www.asus.com/us/Motherboards/PRIME-Z270-A/HelpDesk_BIOS/
:
Bearbeitet durch User
Natürlich wäre dies eine Option. Aber ich bin dermassen meiner Arbeit hinterher, dass ich dafür einfach keine Zeit mehr habe. Ich werde hier berichten, wenn's 'was neues gibt.
Mehmet K. schrieb: > Und wenns dann immer noch nicht klappt, muss > ich halt den Rechner erneuern. Es gibt PCs, das wirds mit Linux einfach nichts. Hab so ein kleines i5-Fertig-System von HP. Da frierts auch immer spontan ohne Kernelmeldung nach ein paar Minuten ein, egal ob rohe Console oder X. Liegt auch nicht daran, dass ich nicht wüsste, wie man das debugged ;) Der ganze übliche Kram (ACPI, etc.) hilft nichts. Habs dann aufgegeben...
Mehmet K. schrieb: > Und wenns dann immer noch nicht klappt, muss ich halt den Rechner erneuern. Hast du mal nach den Netzteilspannungen gesehen? Die werden üblicherweise im BIOS angezeigt. Beitrag "Re: Debian 10 friert ein"
:
Bearbeitet durch User
Angehängte Dateien:
-
DSC_0047s.jpg
110 KB -
DSC_0048s.jpg
98 KB
Uhu U. schrieb: > Die werden üblicherweise im BIOS angezeigt. Ich hatte Deinen vorhergehenden Beitrag schon zur Kenntnis genommen. Nur dachte ich mir: wie stellt er sich dass vor? Dass ich mit dem Multimeter auf der Mainboard herumstochere? :) Wie Du der Tatsache entnehmen kannst, dass ich von diesen Bios-Einstellung nichts wusste, habe ich keinerlei Uebertacktungen etc. vorgenommen. Beiliegen die Werte.
Mehmet K. schrieb: > Beiliegen die Werte. Die scheinen in Ordnung zu sein… Ich hatte vor einiger Zeit Probleme mit einem ausgelutschten Netzteil. U.a. zeigte der gcc Syntaxfehler, wo keine waren. Nachdem ich das schon vorsorglich angeschaffte Reservenetzteil eingebaut hatte, war der Spuk vorbei. Der Speichertest hatte keine Fehler gefunden.
:
Bearbeitet durch User
Mehmet K. schrieb: > Um die Frage zu klären, ob die Probleme von meinem Rechner oder von > Debian stammen, habe ich Arch installiert (@LeX Danke für den Tipp mit > Manjaro). > Die Installation verlief problemlos. Ebenso das System-Update. Ich habe > den Rechner wieder die ganze Nacht laufen lassen: alles bestens Manjaro hat übrigens ein sehr praktisches Feature zum Kernel austauschen. Irgendwo in den Einstellungen gibts eine GUI wo du mit zwei Klicks lustig zwischen verschiedenen Kernels hin- und her wechseln kannst. Vielleicht wähost du da mal probehalber den Kernel aus den dein Debian verwendet und schaust ob das Problem dann auftritt. So kannst du die Fehlerquelle eingrenzen. Den PC austauschen würde mir im Traum nicht einfallen. Du willst ja mit deinem System arbeiten, nicht für oder an ihm. Wenn Debian nicht will: es gibt auch andre hübsche Töchter.
Le X. schrieb: > Irgendwo in den Einstellungen gibts eine GUI wo du mit zwei Klicks > lustig zwischen verschiedenen Kernels hin- und her wechseln kannst. Wenn Du mich dorthin lotsen würdest, wo ich diese zwei Klicks zu plazieren habe: sehr gerne. Ansonst, wie ich weiter oben schon erwähnt habe, hat sich bei mir wegen diesem Debian-Exkurs soviel Arbeit angesammelt, dass ich z.Zt. unmöglich auf dieser Try-and-Error-Baustelle weiter arbeiten kann.
Mehmet K. schrieb: > Ansonst, wie ich weiter oben schon erwähnt > habe, hat sich bei mir wegen diesem Debian-Exkurs soviel Arbeit > angesammelt, dass ich z.Zt. unmöglich auf dieser Try-and-Error-Baustelle > weiter arbeiten kann. Mit dem alten BIOS ging es ja. Das kannst Du ohne Trial und Error erreichen.
Uhu U. schrieb: > Martin schrieb: >> Alles funktioniert wie Butter! > > Heißt das, dass es nicht quietscht und kracht, wenn du in deinen Laptop > beißt? Ich wollte auch schon fragen, wie denn Butter "funktioniert". Pyramidenanspitzer schrieb: > Laptop und Linux ist immer noch problematisch, egal was hier für Unsinn > erklärt wird. Ich nutze seit 15 Jahren täglich Linux auf verschiedenen Laptops. Früher gab es die eine oder andere Hürde, in der Regel durch kaputte Hardware, für die nur in den Windows-Treibern Work-Arounds eingebaut sind. Die Dinger sind dann aber eh Mist, weil der Work-Around dann meistens nicht im Standard-Treiber von Windows enthalten ist, sondern in einer Spezial-Version vom Geräte-Hersteller. Sobald der keinen Bock mehr hat, seinen Sondertreiber zu aktualisieren, ist man dann nur noch mit veralteten Treibern unterwegs. Das einzige, was wirklich nervig war, war NVidia "Optimus".
:
Bearbeitet durch User
Ich möchte ein kurzes Feedback geben: Vor ein paar Wochen fand ich wieder die Zeit dafür, mich mit meinem geplanten Umzug zu beschaeftigen; und diesmal klappte es, ohne dass ein Sandkorn seinen Weg ins Getriebe fand. Und seit ca. 1 Monat benutze ich ausschliesslich Debian (Bullseye) und bin rundum zufrieden. Der einzige Fehler, der mir unterlief, war der, dass ich dem Verzeichnis var nicht eine eigene Partitition spendiert habe. Und als dann eine nachtraegliche Driver-Installation in die Hose ging und syslog die gesamten root-Partitition in Beschlag nahm, hatte ich im ersten Moment das Gefühl, ein deja-vu zu erleben. Aber mit all den Hilfsmitteln, die einem unter Linux zur Verfügung stehen (und damit meine ich jetzt nicht nur die Tools, sondern auch die Community) kann man solche Patzer sehr schnell wieder ausbügeln. Wegen 3 Programmen musste ich aber Windows 7 auf einer VM installieren. Und zwar VMware Player, weil die Graphik-Unterstützung von VirtualBox für eines der Programme nicht ausreichte.
Mehmet K. schrieb: > Ich möchte ein kurzes Feedback geben Danke für das Feedback! Frage wäre noch (weil nur 3 Windowsprgs): ging nichts mit Wine?
rbx schrieb: > ging nichts mit Wine? Obwohl ich schon erstaunt war, was ich mit Wine so alles zum Laufen brachte: diese 3 Programme zaehlten leider nicht dazu.
Mehmet K. schrieb: > Wegen 3 Programmen musste ich aber Windows 7 auf einer VM installieren. > Und zwar VMware Player, weil die Graphik-Unterstützung von VirtualBox > für eines der Programme nicht ausreichte. Anstatt VirtualBox hätte ich erst einmal KVM+QEMU mit dem Virtual Machine Manager versucht. Dazu einfach folgendes Paket installieren: apt install virt-manager Auf dem Desktop hast du dann eine Virtuelle Maschinenverwaltung als Anwendung im "Startmenü". Das ist der Virt-Manager, eine GUI für KVM+Qemu und mit Virtualbox ungefähr vergleichbar. Auf dem Gastsystem, also Windows, solltest du dann noch den QXL Grafiktreiber installieren. Am besten dazu einfach das ganze SPICE Paket unter Windows installieren, der hat den dabei und bringt noch ein paar andere nützliche Sachen mit. Wie bpsw. Copy & Paste zwischen dem Host und Gastsystem. https://www.spice-space.org/ Siehe dazu auch folgendes Video: https://www.youtube.com/watch?v=24rfzSDVfBA Bei Virt-Manager werden im Prinzip auch extra Windowstreiber installiert. Der Unterschied ist nur, dass die bei Windows schon standardmäßig mitgeliefert werden und nicht separat installiert werden müssen. Da gibt es wohl ein Übereinkommen mit Microsoft und VMWare. Bei Virtualbox gibt es hierfür die Guest Additions die man dann auf dem Windows Gastsystem installieren soll. https://www.virtualbox.org/manual/ch04.html Der Grund ist hierfür ganz einfach und wohl auch der Grund, warum die 3 Anwendungen bei dir in der Virtualbox nicht liefen. Windows kennt normalerweise nicht die simuliertere Grafikkarte der Virtual Machine. Also wird ein einfacher VESA Standardtreiber installiert, der geradeso das allernötigste kann. Also 2d und Auflösungen bis vielleicht 1024x768. Will man mehr, muss man wie bei echter Hardware auch, einen Treiber für die virtualisierte Grafikkarte auf dem Windows Gastsystem installieren. Für VMWare liefert Windows diese Treiber wie bereits gesagt schon mit. Bei KVM+QEMU und Virtualbox muss man sie händisch nachinstallieren. Macht man das, dann sollte auch 3d ordentlich funktionieren und schon funktionieren ein paar Dutzend weitere Anwendungen in der Gastumgebung, die vorher ohne diese Treiberunterstützung nicht liefen.
Nano schrieb: > Bei Virt-Manager werden im Prinzip auch extra Windowstreiber > installiert. > Der Unterschied ist nur, dass die bei Windows schon standardmäßig > mitgeliefert werden und nicht separat installiert werden müssen. > Da gibt es wohl ein Übereinkommen mit Microsoft und VMWare. Sry, sollte heißen: "Bei VMWare werden im Prinzip auch extra Windowstreiber installiert".
KVM+QEMU + VirtManager hat gegenüber Virtualbox übrigens noch den Vorteil, dass man daran auch richtige USB Hardware anschließen kann. Falls der Rechner VirtualI/O unterstützt. Die USB Hardware wird dazu direkt an das Gastsystem durchgereicht. Der Haken ist lediglich, dass sie dann immer angeschlossen bleiben sollte, wenn man das Gastsystem in der VM startet. Denn sonst weigert sich der Virtmanager das Gastsystem zu starten, wenn das USB Device fehlt, aber erwartet wird.
Nano, danke für den Tipp. Werde bei Gelegenheit versuchen, ihn in die Tat umzusetzen. Zur Zeit muss ich aber wieder etwas "schaffe, schaffe, Haeusle baue"
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.