Discover/Gnome Software refreshen in der Form von Packagekit immer nach dem ersten Login nach reboot alle Repo-Daten, und können je nach CPU/Internetverbindung Zypper für 30 bis 60 Sekunden blockieren. Also nicht nur, wenn du da aktiv was machst. Wenn dich das stört, Auto Updates ausschalten.
Beiträge von Scytale
-
-
Nicht hilfreicher Kommentar:
Ich würde TPM2 Verschlüsselung nochmal reifen lassen, das ist überall noch im "ganz neu und experimental" Status, und ganz abgesehen davon je nach Kriterium, einfach keine FDE, weil alle ab Hardwarehersteller bis Regierungsbehörden Zugang zu den Verschlüsselungsphrasen im TPM Chip haben.
-
Ich verstehe jetzt nicht, was du in der globalen SSH Config für ein Problem lösen willst, weil in #2 steht ja schon die Lösung.
Speichere die Verbindungsoptionen für eine spezifische SSH Verbindung und fertig ist der Lack.
-
Technisch gesehen sagt dir die Terminal-Ausgabe ganz genau, was das Problem ist, nämlich dass die Verschlüsselungstypen des Clients nicht die Anforderungen des Servers erfüllen. "Normalerweise" geschieht das Aushandeln automatisch, es sei denn es wird auf Client oder Serverseite -manuell- definiert. Deswegen wie in Post #2 die SSH Konfig des Clients prüfen, oder halt die Serverseite anpassen, so wie es für dich Sinn ergibt.
-
Naja, wenn du wirklich Suspend to Disk meinst, dann muss halt einmal der Speicherinhalt auf Platte geschrieben werden, und dann beim Weiterführen der Sitzung wieder von Platte in den Ram geladen werden. Das dauert bei den heutigen RAM Größen länger als ein Kaltstart.
S4 ergibt nur Sinn, wenn du deine Sitzung über einen langen Zeitraum erhalten willst, während das Notebook nicht am Strom ist. Mit S3 entlädt ein Gerät langsam. Und weil das ein eher seltener Fall ist, geht da der Support langsam zurück. Deswegen ist S4 verhältnismäßig unzuverlässig und fehleranfällig. Ich würd einfach bei S3 bleiben, wenn das bei deiner Maschine geht.
-
Dann bist du mehr oder weniger auf dich alleine gestellt. Du kannst gerne den Kampf gegen Windmühlen machen, aber der S4 Hibernate State ist äußerst wackelig, und ergibt heutzutage technisch keinen Sinn mehr. Benutze einfach S3 oder mach nen ordentlichen Shtudown.
-
Das nicht, wenn ich mich aber neu gewöhnen muss, dann spielt die Distro keine Rolle mehr.
Du warst heute alt, als du Linux und open source verstanden hast

Butter bei die Fisch, genau aus dem Grund haben Linux Profis kaum YAST benutzt, weil txt Dateien viel einfacher und schneller zu bedienen sind als YAST.
Alleinstellungsmerkmal ist imho Tumbleweed und btrfs+snapper. Das gibts so nirgends. Spiral Linux kommt nahe, aber das kopiert die btrfs/snapper Konfiguration von openSUSE unter Debian.
Aber ja, im Grunde ist es ab einem bestimmten Kompetenzgrad völlig egal, welche Linux Distro du nutzt.
-
Nur zur Begriffsklärung, gehts hier um Hibernate oder Suspend?
-
Zunächst erscheint für ca. 20 - 30 s ein leerer Bildschirm, anschließend einige Zeilen mit Einstellungen des Grub- Menüs im Text-Modus.
Ich tipp mal drauf, dass das EFI in diesen 20-30 Sekunden die RAM Riegel auf Fehler checkt. "POST" des RAMs, bzw. je nach Motherboard unterschiedlicher Featurename, aber deaktivierbar. GRUB, bzw. die systemd logs bekommen diese Startverzögerung technisch bedingt nicht mit, weil noch nicht am laufen. Dieses Feature ist i.d.R. immer angestellt ab Werk, bisher bei unter 16 gig RAM fällt es kaum auf, aber bei 32 oder 64 gig oder mehr schlägt das aber auf einmal mit 2-4 Minuten drauf.
-
Wir tappen da jetzt im dunkeln, weil wir keine konkreten Fehlermeldungen haben, dass kann jetzt alles sein von kaputtem Update hin zu Festplatte voll, Dateisystem beschädigt usw.
Normalerweise sollten dir in den Standard-Installationseinstellungen von openSUSE btrfs Snapshots zum Booten angezeigt werden, die bei 99% aller Softwarefehler den Rollback auf einen funktionierenden Stand ermöglichen sollte. Hast du openSUSE nicht mit btrfs installiert und wenn nein, warum?
Anonsten 08/15 Reparatur:
Mit irgendeinem Live-Iso (bspw. Ubuntu) prüfen ob das System vollständig von einem USB bootet. Wenn dein System nicht vollverschlüsselt ist, kannst du mit einer weiteren USB-Festplatte/Stick an dieser Stelle deine persönlichen Daten sichern. Wenn die Hardware soweit läuft, einen openSUSE Installationsstick erstellen, gerne auch direkt openSUSE 16.0 und drüber installieren.
Alternativ kannst du auch versuchen, mit einem alten 15.6 image eine Reperatur-Installation zu machen (wenn es die Option noch im Installer gibt).