debian stretch: System friert ein bei grafischer Benutzeranmeldung - Display schwarz

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
worclsep
Beiträge: 4
Registriert: 21.04.2018 10:38:12

debian stretch: System friert ein bei grafischer Benutzeranmeldung - Display schwarz

Beitrag von worclsep » 23.04.2018 15:49:34

(Systemdetails folgen weiter unten.)

Neuinstallation von Stretch Mate auf Notebook (Netbook) lässt sich nicht im grafischen Nutzermodus starten. Beim Boot kommt nach einigen schnell durchlaufenden Systemmeldungen erwartungsgemäß zunächst der Mauszeiger, der sich per Touchpad bewegen lässt, und dann der Anmeldebildschirm. Dort kann ich Benutzer und Passwort eintragen. Allerdings bleibt für die vollständige Eingabe nicht genügend Zeit, da der Monitor sehr schnell schwarz wird. Danach können dann zufallsbedingt folgende verschiedene Situationen eintreten:
1) Der Monitor bleibt schwaz, System ist eingefroren.
2) Der Anmeldebildschirm kommt nach wenigen Sekunden zurück, es lässt sich aber nichts eintragen, Mauszeiger ist unbeweglich, System ist eingefroren.
3) Der Anmeldebildschirm kommt zurück, Eintrag lässt sich zu Ende bringen, login lässt sich anklicken,
3a) bei falschem Passwort kommt der Anmeldebildschirm wieder zurück mit dem entsprechenden Hinweis, Neueingabe möglich, lässt sich beliebig oft mit falschem Passwort wiederholen;
3b) bei Eingabe des korrekten Passwortes wird der Bildschirm schwarz, System ist eingefroren.
4) Benutzer und Passwort lassen sich normal eingeben, System startet wie erwartet im grafischen Benutzermodus.

Boot mit der nomodeset-Option bringt keine Veränderung.

Leider tritt die Variante 4) extrem selten ein; es kann Tage dauern und zig bis hunderte(?) Versuche, bis es zufällig mal wieder gelingt. Die gesamte Konstellation lasse ich dabei unverändert.

In den Fällen, in denen der Monitor schwarz ist (er ist dabei nicht aus, ein nicht blinkener Cursor ist oben links zu sehen, alledings bin ich nicht sicher, ob das in allen Varianten immer so ist), lässt sich nicht per CTRL/ALT/Fn auf ein anderes tty umschalten. Das System lässt sich dann nur noch gewaltsam mit dem Power-Knopf ausschalten. Im Fall der Variante 4) lässt sich das System normal benutzen bis auf folgende Besonderheiten, sofern ich mich korrekt erinnere (?):
I) Falls das System durch die Energieverwaltung in den idle-modus geht (Bildschirm aus), ist es nicht mehr zurück zu bringen und friert somit komplett ein.
II) Umschalten per CTRL/ALT/Fn schlägt auch fehl, System friert ein; dabei erinnere ich mich jetzt nicht mehr genau, ob das System bereits beim ersten Umschalten z.B. nach F6 oder erst beim Zurückschalten nach F7 eingefroren ist, meine aber, dass es schon beim ersten Umschalten so war.

Glücklicherweise lässt sich das System per Grub jederzeit im Rescue-Modus starten :). Ein Instandsetzen sollte also hoffentlich möglich sein. Allerdings bin ich hier dringend auf Eure Hilfe angewiesen und bitte um Unterstützung. Ich weiß nicht so recht, wo ich sinnvollerweise ansetzen soll. Mein Kenntnisstand geht hier mit Sicherheit nicht tief genug. Für jeden Hinweis und jede Möglichkeit wäre ich dankbar.

Momentan läuft das System per seltenem Zufall mal wieder im grafischen Benutzer-Modus. Diesen Beitrag verfasse ich daher mit genau diesem System. Das möchte ich gerne so weit wie möglich erst mal beibehalten, da ich so die Ergebnisse aus irgendwelchen Systemmeldungen etc. sehr viel einfacher hierher übertragen kann.

Der Rechner hat ein auf dem eingebauten 64GB Flash-Speicher vorinstalliertes Win10, welches ich da dauerhaft belassen will. Installiert habe ich Debian Mate auf einen schnellen USB-Stick am USB 3.0 Anschluss per desktop live+nonfree von einem zweiten usb-Stick. Das live-System hat im Gegensatz zum installierten System auf Anhieb funktioniert. Als sich die Probleme mit dem installierten System zeigten, habe ich testweise auch Debian Gnome auf einem weiteren USB-Stick installiert, in der vagen Hoffnung, dass dessen Displaymanager gdm vielleicht einen Unterschied zu lightdm machen könnte. Leider ließ sich aber auch Gnome nur im Rescue-Modus starten.

Vielleicht sollte ich vorsichtshalber noch erwähnen, dass ich zunächst etwas Schwierigkeiten mit EFI hatte, da dies meine erste EFI-Installation ist. Da ich es aber hinbekommen habe, dass das System überhaupt startet, würde ich vermuten, dass das beschriebene Problem damit nichts zu tun haben sollte, aber wer weiß...


Hier nun einige Infos zum System (lshw -short):
pastebin/?mode=view&s=40285
[


cpu and display:
pastebin/?mode=view&s=40286



VGA

Code: Alles auswählen

 root@NB-AKOYA-hp:/# lspci -nnk | grep -i VGA -A2
00:02.0 VGA compatible controller [0300]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Configuration Registers [8086:22b0] (rev 36)
	Subsystem: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Configuration Registers [8086:7270]
	Kernel driver in use: i915  
Debian-Release

Code: Alles auswählen

root@NB-AKOYA-hp:/# lsb_release -a 
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.4 (stretch)
Release:	9.4
Codename:	stretch   

Display-Manager

Code: Alles auswählen

 root@NB-AKOYA-hp:/# systemctl status display-manager
● lightdm.service - Light Display Manager
   Loaded: loaded (/lib/systemd/system/lightdm.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-04-20 02:12:15 CEST; 3 days ago
     Docs: man:lightdm(1)
  Process: 636 ExecStartPre=/bin/sh -c [ "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/lightdm" ] (code=exited, status=0/SUCCESS)
 Main PID: 641 (lightdm)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/lightdm.service
           ├─641 /usr/sbin/lightdm
           └─648 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

Apr 20 02:12:15 NB-AKOYA-hp systemd[1]: Starting Light Display Manager...
Apr 20 02:12:15 NB-AKOYA-hp systemd[1]: Started Light Display Manager.
Apr 20 02:12:21 NB-AKOYA-hp lightdm[676]: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0)
Apr 20 04:12:42 NB-AKOYA-hp lightdm[719]: pam_unix(lightdm:session): session opened for user hpk1 by (uid=0)
(END)
  

Fehlermeldungen (aktuell laufendes System)
pastebin/?mode=view&s=40287



efibootmgr

Code: Alles auswählen

 root@NB-AKOYA-hp:/# efibootmgr
BootCurrent: 0004
Timeout: 2 seconds
BootOrder: 0004,0002,0003,0000,0001
Boot0000* Windows Boot Manager
Boot0001* UEFI: Built-in EFI Shell
Boot0002* UEFI: Generic STORAGE DEVICE 0272, Partition 1
Boot0003* UEFI: VerbatimSTORE N GO 1.01, Partition 1
Boot0004* debian  

lsblk (debian mate ist auf sda installiert, sdb ist Installationsmedium, WIN10 auf mmcblk0)

Code: Alles auswählen

  root@NB-AKOYA-hp:/# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda            8:0    1 59,5G  0 disk 
├─sda1         8:1    1  512M  0 part /boot/efi
├─sda2         8:2    1   19G  0 part /
├─sda3         8:3    1  3,9G  0 part [SWAP]
└─sda4         8:4    1 36,1G  0 part /home
sdb            8:16   1 14,9G  0 disk 
├─sdb1         8:17   1  2,2G  0 part /media/hpk1/d-live nf 9.3.0 ma amd64
└─sdb2         8:18   1  416K  0 part 
mmcblk0      179:0    0 58,2G  0 disk 
├─mmcblk0p1  179:1    0  100M  0 part 
├─mmcblk0p2  179:2    0   16M  0 part 
├─mmcblk0p3  179:3    0 57,2G  0 part 
└─mmcblk0p4  179:4    0  999M  0 part 
mmcblk0boot0 179:256  0    4M  1 disk 
mmcblk0boot1 179:512  0    4M  1 disk 
mmcblk0rpmb  179:768  0    4M  0 disk 


P.S.: Ich hoffe, dass es so o.k. ist, die nicht so langen Ausgaben hier direkt als Code zu posten und nur die etwas längeren in der NoPaste Variante. Falls nicht ... :hail:

Oder war ich vielleicht sogar zu vorsichtig und hätte doch die etwas längeren Ausgaben auch noch direkt posten sollen? (sind ja nicht wirklich sehr lang)

BenutzerGa4gooPh

Re: debian stretch: System friert ein bei grafischer Benutzeranmeldung - Display schwarz

Beitrag von BenutzerGa4gooPh » 24.04.2018 17:01:30

Na hallo im DF und herzlichen Glückwunsch zur einer aussagefähigen Thread-Eröffnung (Formate passen so) und zur gelungenen Installation. Bezüglich der Boards mit Atom-CPUs kann es einige Probleme geben, 32-Bit-UEFI-BIOS usw. https://www.heise.de/ct/hotline/Linux-I ... 56886.html (Z8500 unten, evtl. umschaltbar)
sda sieht wohlproportioniert äh -partitioniert aus.

Speziell gefunden habe ich das:
As a recommendation, you should disable EHCI and C-States in the BIOS as the older kernel version in debian stable does not handle c-states well and the ehci drivers are buggy.
https://www.reddit.com/r/debian/comment ... by_debian/

Versuche zuerst das und wenn kein Erfolg, boote Testing/Buster oder Ubuntu als Live-ISO auf USB-Stick "gebrannt". Wenn das funktioniert, installiere Testing/Buster oder intstalliere zu Stretch Backport-Kernel:
https://backports.debian.org/

Bezüglich WLAN erweitere deine Quellenliste um contrib und nonfree https://wiki.debianforum.de/Sources.list
und installiere

Code: Alles auswählen

su -
apt update
apt upgrade
apt install intel-microcode
apt install firmware-iwlwifi
Debianfirmware-iwlwifi und Debianintel-microcode eventuell aus Backports, wenn Du Stretch mit Backport-Kernel nutzen kannst/willst.

Edit:
Debianintel-microcode als Allererstes installieren/testen, vielleicht hilft das schon. Ein aktuelles BIOS kann auch nicht schaden. Gnome oder KDE ist bei deinen Grafikproblemen und dem Prozessor wohl nicht so ratsam, Mate ist schon okay.

Auf Suspend-Modi musst du vielleicht (bei schlechter ACPI-Unterstützung) verzichten, schalte dafür den Bildschirm nach 5 Minuten Idle aus (Energieeinstellungen).
Wenn Grafik Und WLAN funktionieren kannst du aber mal ACPI-S-States posten:

Code: Alles auswählen

journalctl -b | grep supports
bei mir: Apr 24 07:44:36 laptop kernel: ACPI: (supports S0 S3 S4 S5)
S3, commonly referred to as Standby, Sleep, or Suspend to RAM (STR): RAM remains powered.
S4, Hibernation or Suspend to Disk: All content of the main memory is saved to non-volatile memory such as a hard drive, and the system is powered down.
https://en.wikipedia.org/wiki/Advanced_ ... wer_states
Von Sound-Problemen entsprechender Atom-Boards unter Linux habe ich auch (flüchtig) gelesen. Aber du hast erst mal wichtigere Probleme zu lösen. :wink:

worclsep
Beiträge: 4
Registriert: 21.04.2018 10:38:12

Re: debian stretch: System friert ein bei grafischer Benutzeranmeldung - Display schwarz

Beitrag von worclsep » 25.04.2018 02:08:26

Jana66 hat geschrieben: ↑ zum Beitrag ↑
24.04.2018 17:01:30
Na hallo im DF und herzlichen Glückwunsch zur einer aussagefähigen Thread-Eröffnung (Formate passen so) und zur gelungenen Installation. Bezüglich der Boards mit Atom-CPUs kann es einige Probleme geben, 32-Bit-UEFI-BIOS usw. https://www.heise.de/ct/hotline/Linux-I ... 56886.html (Z8500 unten, evtl. umschaltbar)
Danke für die Antwort und den freundlichen Empfang. Und auch für die Links. Dass es überhaupt ein 32-Bit-UEFI auf einem 64-Bit-System gibt, war mir nicht bekannt.

edit: habe gerade entdeckt, dass es in den Repositories für das installierte System auch ein grub-efi-ia32 gibt. Keine Ahnung, wie das evtl. einzusetzen wäre?

Ich vermute/hoffe ja, dass mich das in diesem Falle nicht betrifft und dass ich die grundsätzliche Hürde des Bootloaders bereits genommen habe, ohne mich znächst auch nur ansatzweise damit auszukennen. Wie erwähnt, meine erste EFI-Installation. Wahrscheinlich Anfängerglück :wink: .

Zur Installation habe ich als erstes im UEFI-Setup das secureboot ausgeschaltet, dann den USB-Stick mit dem Live-/Installations-System in der Bootreihenfolge an die erste Stelle gesetzt. Das bootete sowohl zum Installieren als auch zum Ausprobieren auf Anhieb problemlos. Lief im Live-Modus auch soweit ganz gut, so dass ich es dann auf einen zweiten USB-Stick installiert habe. Möglicherweise habe ich während der Installation etwas falsch gemacht, denn das installierte System wollte nach Abschluss der Installation zunächst nicht booten (Boot-Reihenfolge natürlich angepasst). Nach erneutem Start des Live-Systems habe ich mich dann von diesem per chroot in das gerade installierte System begeben, die auf dem selben USB-Stick befindliche EFI-Partition auf /boot/efi eingehängt und grub-install /dev/sda(USB-Stick, auf den ich installiert hatte) und update-grub ausgeführt. Danach lässt sich Debian immer starten, wobei der Rescue-Mode immer geht, der grafische Benutzermodus aber nur mit den beschriebenen Problemen, auf jeden Fall aber mindestens bis zum ersten Erscheinen des grafischen Anmeldebildschirms. Wenn ich den Bootvorgang richtig verstanden habe (aber sicher bin ich mir da nicht :roll: ), sollte an diesem Punkt der Bootloader bereits an das System übergeben haben, richtig? Da das System Zufalls-abhängig gelegentlich korrekt hochfährt, sollte doch eigentlich alles, was benötigt wird, vorhanden sein, bloß vielleicht nicht immer zum richtigen Zeitpunkt in der richtigen Reihenfolge. (Ich kann hier mangels entsprechender Kenntnis nur spekulieren.) Wie könnte man dies herausfinden und ggf korrigieren?

Ich hatte übrigens von einer LIVE+NONFREE variante installiert. Intel-microcode und die passende wifi-Firmware sind daher bereits installiert. wifi funktioniert auch - gehe darüber auf mein Netzwerk . Das System läuft jetzt stabil seit dem letzten, zufällig erfolgreichen Boot in den grafischen Benutzermodus seit über 5 Tagen und auch diesen Beitrag verfasse ich damit . Wenn es immer so hochfahren würde, wäre ja schon mal viel gewonnen. Erst mal lasse ich es noch eine kurze Zeit in diesem Zustand weiterlaufen, falls noch irgendein Vorschlag kommen sollte, was man vielleicht in diesem Status analysieren sollte. Im Moment sind Touchpad und Touchscreen etwas umständlich, gehen aber zur Not. Sound lasse ich jetzt erst mal außen vor.

Und hier noch weitere Infos:


Info zum Mainboard/BIOS:

Code: Alles auswählen

  root@NB-AKOYA-hp:/# sudo dmidecode -t0 
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: American Megatrends Inc.
	Version: 5.11
	Release Date: 02/27/2017
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 4224 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 5.11
 
CPU

Code: Alles auswählen

 root@NB-AKOYA-hp:/# lscpu
Architektur:           x86_64
CPU Operationsmodus:   32-bit, 64-bit
Byte-Reihenfolge:      Little Endian
CPU(s):                4
Liste der Online-CPU(s):0-3
Thread(s) pro Kern:    1
Kern(e) pro Socket:    4
Sockel:                1
NUMA-Knoten:           1
Anbieterkennung:       GenuineIntel
Prozessorfamilie:      6
Modell:                76
Modellname:            Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
Stepping:              4
CPU MHz:               841.728
Maximale Taktfrequenz der CPU:1920,0000
Minimale Taktfrequenz der CPU:480,0000
BogoMIPS:              2880.00
Virtualisierung:       VT-x
L1d Cache:             24K
L1i Cache:             32K
L2 Cache:              1024K
NUMA-Knoten0 CPU(s):   0-3
Markierungen:          fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb kaiser tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat
  
journalctl -b | grep supports

Code: Alles auswählen

  root@NB-AKOYA-hp:/# journalctl -b | grep supports
Apr 20 02:12:07 NB-AKOYA-hp kernel: mce: CPU supports 6 MCE banks
Apr 20 02:12:07 NB-AKOYA-hp kernel: ACPI: (supports S0 S4 S5)
Apr 20 02:12:07 NB-AKOYA-hp kernel: acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
Apr 20 02:12:09 NB-AKOYA-hp kernel: [drm] Driver supports precise vblank timestamp query.
Apr 20 02:12:15 NB-AKOYA-hp NetworkManager[477]: <info>  [1524183135.8558] device (wlp1s0): driver supports Access Point (AP) mode
Apr 20 02:12:16 NB-AKOYA-hp NetworkManager[477]: <info>  [1524183136.8860] sup-iface[0x55d7f7140f20,wlp1s0]: supports 5 scan SSIDs
Apr 20 04:12:35 NB-AKOYA-hp NetworkManager[477]: <info>  [1524190355.5717] sup-iface[0x55d7f7140f20,wlp1s0]: supports 5 scan SSIDs
 
lsmod
http://nopaste.debianforum.de/40290

Vielleicht lässt sich ja daraus noch etwas mehr herausfinden. Bitte helft mir. Ich fische da ziemlich im Trüben :roll:

BenutzerGa4gooPh

Re: debian stretch: System friert ein bei grafischer Benutzeranmeldung - Display schwarz

Beitrag von BenutzerGa4gooPh » 25.04.2018 07:46:30

worclsep hat geschrieben: ↑ zum Beitrag ↑
25.04.2018 02:08:26
Apr 20 02:12:07 NB-AKOYA-hp kernel: ACPI: (supports S0 S4 S5)
S3 - Suspend to RAM (Bereitschaft) wird also nicht unterstützt. Zumindest nicht mit dem aktuell verwendeten Kernel. Würgaround:
Jana66 hat geschrieben: ↑ zum Beitrag ↑
24.04.2018 17:01:30
... schalte dafür den Bildschirm nach 5 Minuten Idle aus (Energieeinstellungen).
Zu deiner UEFI-Installation:
worclsep hat geschrieben: ↑ zum Beitrag ↑
25.04.2018 02:08:26
Nach erneutem Start des Live-Systems habe ich mich dann von diesem per chroot in das gerade installierte System begeben, die auf dem selben USB-Stick befindliche EFI-Partition auf /boot/efi eingehängt und grub-install /dev/sda(USB-Stick, auf den ich installiert hatte) und update-grub ausgeführt.
Da hast du während der Installation was falsch gemacht. Der Installer lässt (im grafischen Modus, manuelle Partitionierung) die Angabe der bereits von Windows angelegten EFI-Systempartition (ESP) und einen entsprechenden Einhängepunkt /boot/efi zu. Eine explizite Angabe zum Ort des Bootloaders (/dev/sda) ist eigentlich nicht erforderlich. Aber ich kenne nicht jedes BIOS und du hast dir zu helfen gewusst (chroot etc). :THX: Ein 32-Bit-UEFI benötigst du nicht, das Gerät bootet und deine Grafikfehler liegen nicht daran.
worclsep hat geschrieben: ↑ zum Beitrag ↑
25.04.2018 02:08:26
Ich hatte übrigens von einer LIVE+NONFREE variante installiert.
Hhmm, einige Forenteilnehmer hatten nach Installation damit damit schon Pakete gefehlt, ist wohl mehr zur "Ansicht" (Live-ISO) gedacht. Installiere besser damit
https://cdimage.debian.org/cdimage/unof ... 4/iso-dvd/
oder noch besser per netinstall:
https://cdimage.debian.org/cdimage/unof ... 64/iso-cd/

Hast du das mal geprüft:
Jana66 hat geschrieben: ↑ zum Beitrag ↑
24.04.2018 17:01:30
As a recommendation, you should disable EHCI and C-States in the BIOS as the older kernel version in debian stable does not handle c-states well and the ehci drivers are buggy.
https://www.reddit.com/r/debian/comment ... by_debian/

Ansonsten habe ich alles gesagt, z. B. wegen des obigen Zitats vorgeschlagen:
Jana66 hat geschrieben: ↑ zum Beitrag ↑
24.04.2018 17:01:30
... installiere [upgrade auf] Testing/Buster oder installiere zu Stretch Backport-Kernel:
https://backports.debian.org/
Sporadisch auftretende Fehler in einem aktuell funktionierenden System wird kein Fremder remote finden können. Also mache/prüfe das Gesagte! :wink:
(Da Windows offenbar stabil läuft, gehe ich nicht von Hardware-Fehler aus. Überhitzung in Linux hast du wohl auch keine.)

Bezüglich Netzwerk habe ich in deinem nopaste iwlwifi-Lade-Fehler gesehen (könnte normal sein, dass versucht wird, mehrere Firmware auzuprobieren) allerdings auch dhclient-Fehler. Deshalb mein Hinweis auf Installation von iwlwifi.

Code: Alles auswählen

Apr 20 06:35:50 NB-AKOYA-hp dhclient[2187]: Failed to get interface index: No such device
Wenn aber alles alles läuft, wurde das später mit entsprechendem Journaleintrag (Netzwerkmanager?) korrigiert.

worclsep
Beiträge: 4
Registriert: 21.04.2018 10:38:12

Re: debian stretch: System friert ein bei grafischer Benutzeranmeldung - Display schwarz

Beitrag von worclsep » 25.04.2018 21:36:58

Jana66 hat geschrieben: ↑ zum Beitrag ↑
25.04.2018 07:46:30
S3 - Suspend to RAM (Bereitschaft) wird also nicht unterstützt. Zumindest nicht mit dem aktuell verwendeten Kernel. Würgaround:

... schalte dafür den Bildschirm nach 5 Minuten Idle aus (Energieeinstellungen).
Mit dem Energiemanagement stimmt so einiges noch nicht. Z.B. behauptet das System, dass kein Akku vorhanden sei und zeigt entsprechend auch keine Einstellmöglichkeiten dazu an. Ich habe die Einstellungen für den Netzbetrieb so geändert, dass der Rechner bei Leerlauf "Nie" in den Energiesparmodus geht. Die Monitor-Helligkeit lässt sich gut per Tastatur einstellen und in der untersten Stufe ganz aus- und auch wieder anschalten. Beim Schließen des Deckels hatte ich bisher "Bildschirm abdunkeln" eingestellt, was zunächst keine Probleme bereitete. Heute habe ich alledings bemerkt, dass der Bildschirm danach nur ganz widerwillig wieder anzukriegen war. Irgendwie ging es dann nach einiger Zeit durch blindes Ausprobieren diverser Tastenkombinationen. Ich kann nicht sagen, welche Kombination letzt Endes funktioniert hat, aber ich habe die Vermutung, dass CTRL/ALT/DEL dazu beigetragen haben könnte. Habe jetzt "Beim Schließen des Deckels" auf "Nichts machen" eingestellt. Mal sehen, wie es damit aussieht.


Jana66 hat geschrieben: ↑ zum Beitrag ↑
25.04.2018 07:46:30
Zu deiner UEFI-Installation:
worclsep hat geschrieben: ↑ zum Beitrag ↑
25.04.2018 02:08:26
Nach erneutem Start des Live-Systems habe ich mich dann von diesem per chroot in das gerade installierte System begeben, die auf dem selben USB-Stick befindliche EFI-Partition auf /boot/efi eingehängt und grub-install /dev/sda(USB-Stick, auf den ich installiert hatte) und update-grub ausgeführt.
Da hast du während der Installation was falsch gemacht. Der Installer lässt (im grafischen Modus, manuelle Partitionierung) die Angabe der bereits von Windows angelegten EFI-Systempartition (ESP) und einen entsprechenden Einhängepunkt /boot/efi zu. Eine explizite Angabe zum Ort des Bootloaders (/dev/sda) ist eigentlich nicht erforderlich.
Ja, vermutlich habe ich da etwas falsch oder zumindest anders gemacht, als es das Installationsprogramm vorgesehen hatte. Entsprechend meiner Absicht, analog zu meiner althergebrachten Art der Installation zu verfahren, bei der ich den Grub Bootloader in den MBR eines beliebigen (auch externen) zweiten Datenträgers installiert habe und diesen dann entsprechend im BIOS in die gewünschte Prioritätsreihenfolge gesetzt und auf diese Art die erste Festplatte vollkommen unverändert gelassen habe. Ich glaube (glauben heißt aber nicht wissen), dass es jetzt analog aufgesetzt ist, nur dass es eben nicht der jeweilige MBR sondern die entsprechende EFI-Partition ist, in der sich der Bootloader befindet. In diese Thematik muss ich mich wohl noch ein wenig mehr einarbeiten.


Jana66 hat geschrieben: ↑ zum Beitrag ↑
25.04.2018 07:46:30
Ein 32-Bit-UEFI benötigst du nicht, das Gerät bootet und deine Grafikfehler liegen nicht daran.
Das hatte ich ja auch vermutet. Danke für die Bestätigung.


Jana66 hat geschrieben: ↑ zum Beitrag ↑
25.04.2018 07:46:30
worclsep hat geschrieben: ↑ zum Beitrag ↑
25.04.2018 02:08:26
Ich hatte übrigens von einer LIVE+NONFREE variante installiert.
Hhmm, einige Forenteilnehmer hatten nach Installation damit damit schon Pakete gefehlt, ...
8O Echt jetzt? Essentielle Pakete, deren Fehlen einen so schwerwiegenden Fehler wie ein nicht bootendes System verursachen können?? Das sollte doch schon länger mal aufgefallen und mittlerweile behoben sein. Aber, wer weiß, nichts ist unmöglich...


Jana66 hat geschrieben: ↑ zum Beitrag ↑
25.04.2018 07:46:30
Installiere besser damit
https://cdimage.debian.org/cdimage/unof ... 4/iso-dvd/
oder noch besser per netinstall:
https://cdimage.debian.org/cdimage/unof ... 64/iso-cd/
Die von Dir genannten alternativen Installationsquellen sind in meinem Fall beide etwas ungeeignet wegen meines sehr bescheidenen Internetanschlusses. Variante 1 ist nochmals erheblich umfangreicher als das, was ich benutzt habe (von der gleichen Quelle übrigens https://cdimage.debian.org/cdimage/unof ... so-hybrid/), und das dauert schon viele Stunden - eine Nacht reicht nicht -, bis das heruntergeladen ist. Und Variante 2 macht mit diesem Internetanschluss auch keinen rechten Spaß. Wenn tatsächlich etwas Grundlegendes fehlen sollte, würde ich lieber versuchen, dieses nachzuinstallieren. Gibt es da evtl. eine komplette Paketliste, gegen die man halbwegs vernünftig abgleichen könnte? Oder welche Pakete waren das denn in den von Dir erwähnten Fällen?


Jana66 hat geschrieben: ↑ zum Beitrag ↑
25.04.2018 07:46:30
Hast du das mal geprüft:
Jana66 hat geschrieben: ↑ zum Beitrag ↑
24.04.2018 17:01:30
As a recommendation, you should disable EHCI and C-States in the BIOS as the older kernel version in debian stable does not handle c-states well and the ehci drivers are buggy.
https://www.reddit.com/r/debian/comment ... by_debian/
Damit konnte ich mich bisher noch nicht richtig beschäftigen. Mir waren noch nicht mal die Begriffe geläufig. Habe mich nur gerade eben mal ganz kurz versucht zu orientieren. Dabei bin ich stutzig geworden bei dem Begriff c-states, der wohl mit Änderungen von Spannungspegeln am Prozessor verbunden ist. Mir kam nämlich bereits unabhängig davon der Verdacht, dass vielleicht während des Bootvorganges bei irgendwelchen Komponenten die Versorgungsspannung kurzfristig in die Knie gehen könnte, wodurch diese dann meistens gerade eben nicht mehr funktionieren. Ich hatte nämlich schon vor einiger Zeit festgestellt, dass die elektrische Leistungsversorgung etwas schwach zu sein scheint, da eine externe HDD, nur über die USB-Schnittstelle gepowert, gar nicht angelaufen ist. Ich weiß nicht, ob z.B. die zusätzlichen USB-Sticks während des Hochfahrens kurzfristig zu viel Strom ziehen? Alles wilde Spekulationen, ich weiß. Aber mal im Hinterkopf behalten.

Ob sich an den Einstellungen im UEFI-Bios (oder wie immer sich das jetzt nennt) eine Einstellmöglichkeit für EHCI und/oder c-states befindet, kann ich noch nicht sagen, da ich das System noch nicht wieder ausgeschaltet und neu zu starten versucht habe (es läuft immer noch so schön - klar, irgendwann muss ich es mal neustarten). Gibt es denn ein Tool, mit dem diese Einstellungen im UEFI-Bios aus dem laufenden System heraus überprüft und evtl. modifiziert werden können?


Jana66 hat geschrieben: ↑ zum Beitrag ↑
24.04.2018 17:01:30
... installiere [upgrade auf] Testing/Buster oder installiere zu Stretch Backport-Kernel:
https://backports.debian.org/
Hier bin ich hin- und hergerissen. Einerseits könnte das Problem mit neuen/neuesten Versionen von was-auch-immer behoben sein, zufällig oder gezielt. Im letzteren Fall hätte man schon irgendwo mal was von einer Analyse und Zwischenlösung lesen müssen. Andererseits halte ich es nicht für eine sinnvolle Vorgehensweise zur Lösung eines noch nicht ausreichend analysierten Problems in die Testphase einer Neuentwicklung einzusteigen, die selbst noch eigene Probleme hervorbringen kann. Erst wenn sonst gar nichts mehr geht.


Jana66 hat geschrieben: ↑ zum Beitrag ↑
24.04.2018 17:01:30
(Da Windows offenbar stabil läuft, gehe ich nicht von Hardware-Fehler aus. Überhitzung in Linux hast du wohl auch keine.)
korrekt.


Jana66 hat geschrieben: ↑ zum Beitrag ↑
24.04.2018 17:01:30
Bezüglich Netzwerk habe ich in deinem nopaste iwlwifi-Lade-Fehler gesehen (könnte normal sein, dass versucht wird, mehrere Firmware auzuprobieren)
genau so ist es. Es werden von dem passenden Treiber offenbar verschiedene Unterversionen ausprobiert, bis die richtige direkt nach der letzten wifi-Fehlermeldung gefunden ist. Alles o.k. in diesem Punkt.



Nochmals vielen Dank für Deine Anregungen. Vielleicht fällt Dir oder jemand anderem noch was ein. Spannend einerseits 8) , aber irgendwo auch frustrierend, wenn man nicht so recht weiterkommt :roll: .

worclsep
Beiträge: 4
Registriert: 21.04.2018 10:38:12

Re: debian stretch: System friert ein bei grafischer Benutzeranmeldung - Display schwarz

Beitrag von worclsep » 26.04.2018 15:13:20

Da das System im Rescue-Mode (Runlevel-1) jederzeit startet, habe ich mir überlegt, den Fehler vielleicht gezielt einzukreisen zu können, indem ich von da aus schrittweise in höhere Runlevels wechsele und dabei immer weitere Funktionen zuschalte, bis der Fehler auftritt. Das System müsste ich dann leider doch mal neu starten :( . Wenn ich das richtig sehe, sind die Runlevel 2 bis 5 bei debian von Hause aus identisch eingestellt. Normal läuft runlevel 5. Wo kann ich das überhaupt voreinstellen? Lt. DebianWiki soll das in /etc/inittab der Fall sein. Diese Datei scheint aber auf meinem System nicht vorhanden zu sein. Folgende Übersicht erhalte ich mit

sysv-rc-conf
[image]gallery/image/1738[/image]


Um anzufangen würde ich rc2.d bis rc4.d schrittweise auffüllen und dann aus dem Runlevel-1 mit init_2, init_3 etc. bis init_5 jeweils weitere Funktionen gruppenweise zuschalten. Ich könnte somit also 3 Vorstufen vor Runlevel-5 testen, wo ja der Fehler auf jeden Fall zu erwarten wäre. Welche Gruppierungen sollte ich sinnvollerweise zusammenstellen?. Oder anders gefragt, wo würde man weniger, und wo eher die Ursache des Problems vermuten?

Irgendwelche Kommentare, Warnungen, Ergänzungen, sonstige Vorschläge? Was haltet Ihr davon?

BenutzerGa4gooPh

Re: debian stretch: System friert ein bei grafischer Benutzeranmeldung - Display schwarz

Beitrag von BenutzerGa4gooPh » 26.04.2018 18:01:14

worclsep hat geschrieben: ↑ zum Beitrag ↑
25.04.2018 21:36:58
Mit dem Energiemanagement stimmt so einiges noch nicht. Z.B. behauptet das System, dass kein Akku vorhanden sei und zeigt entsprechend auch keine Einstellmöglichkeiten dazu an.
...
Oder anders gefragt, wo würde man weniger, und wo eher die Ursache des Problems vermuten?
Mangelhafter ACPI-Support oder Fehlen von Debianlaptop-mode-tools ?
Ein Backport-Kernel (tut nicht weh) könnte ACPI verbessern. Dazu iwlwifi und intel-microcode aus Backports.
CPU aus 2016: https://ark.intel.com/de/products/93361 ... o-1_92-GHz
Debian Stretch Freeze 11/016, Full Freeze in 02/2017: https://wiki.debian.org/DebianStretch
Ob die CPU noch zu 100% eingeflossen ist???

Aber mache dein aufwändiges Runlevel-Ding und hoffentlich kannst du differierende Meldungen des Journals selber auswerten. Ich hätte ja nach mehrfachen Hinweisen wenigstens entsprechende BIOS-Einstellungen nachgesehen, unklare Bedeutungen im Internet recherchiert. Viel Erfolg mit Runlevels, deren Differenz-Logs und absehbar langen Postings. Hoffentlich findest du dafür Leser, deren Vorschläge du absehbar nicht mal testest.

Thread-Analyse:
Neues Netbook mit Win10 und billiger Atom-CPU (viel Spaß mit ressourcenhungrigem Web-Browser) gekauft - ohne Nachfrage/Recherche bezüglich Linux-Erfahrungen anderer.
Offenbar nicht gewollte Nutzung/Auslastung des schlechten (wohl besonders billigen?) Internetzugangs für eine komplette Debian-ISO bzw. Netzinstallation.
Geiz ist angeblich geil - verbraucht jedoch unnötige Lebenszeit, die eigene und leider auch die anderer - meine ab sofort nicht mehr. Und Fotos/Screenshots werde ich mir schon gar nicht anschauen bzw. auswerten (dazu wesentliches kopieren) - du willst laut deinen Posts nicht mal Datenvolumen für eigene Probleme (Neuinstallation mit netinstall oder Komplett-Iso) kaufen/verwenden.
Ein Download kann auch mal eine Nacht dauern, Wiederholfunktion mit wget: https://wiki.ubuntuusers.de/wget/

Effizienzfrage: Was ist nach unseren langen Texten und deren zeitaufwändiger Auswertung beiderseits außer Änderung der Displayhelligkeit passiert?

Bin dann mal weg hier, gibt Sinnvolleres als deine geplanten Differenz-Logs zu lesen, die du offensichtlich durch andere auswerten lassen willst, musst, Vorschläge für wahrscheinlich zeitsparende Lösungen eh nicht probierst. Alles bleibt beim Alten - ist anzunehmen (Lebenserfahrung und Statistik).

Antworten