einfrieren beim updaten und beim Kernel-Purge usw.

Hallo allerseits

Ich habe folgende Probleme.

Ab und zu, beim updaten, friert mir der Rechner ein. Zumeist wegen dem Broadcom WL Treiber, und ab und zu bei Kernel-Updates. Aber auch bei den postinstall-scripten hängt es ab und zu.
Ich vermute daß das irgendwann mal anfing und sich nun sporadisch wiederholt.
Mit dem letzten aktuellen default Kernel (5.13.2.2) ist dies nun schlimmer geworden. Auch dabei crashte , bzw. fror der Rechner ein. Vermutlich beim auflösen der Abhängigkeiten.
Denn wenn ich diesen Kernel beim booten in Grub-Menü auswähle, gibt es eine Kernel-Panic. Eben weil das Update nicht sauber durchlief. Würde ich meinen…

Allerdings bootet der Rechner (einfaches Acer Notebook) dann trotzdem wieder hoch, bzw. startet normal durch, mit dem vorletzten Kernel. Und wenn das einfrieren mitten im Update-Vorrgang war, und ich diese Update
nach dem Reboot wieder anstoße, läuft es an der letzten Stelle weiter. Also das Update wird zum Ende dann doch noch ausgeführt und beendet. Allerdings eben nicht die Sache mit dem Kernel und Broatcom. Das ist irgendwie untergegangen.

An der Stelle muss ich erwähnen daß das mich anfangs verständlicherweise erschrocken hatte, weil ich befürchtete das das System damit geschrottet sei, bzw. nicht mehr starten würde.
Das kenne ich von anderen Distros zuhauf. Wenn dort so etwas in der Art passierte war fast immer Schicht im Schacht, bzw. kaum was zu retten.
Bestes Beispiel Manjaro. Als die Devs. anfingen sich mehr und mehr von der Arch-Basis zu entfernen war jedes Update öfters ein kleines Risiko oder sofort der Gau.

Also an der Stelle ein dickes Lob an die openSUSE Devs. Obwohl diverse crashs bei Updates, startet es immer sauber durch und das Update lässt sich weiter ausführen. Das hatte ich noch nie, und bei keiner Distro. Für mich bis Dato einzigartig.
Sehr solide und sicher. Finde ich absolut klasse. Ebenso die Performance. Auch da gibt es nichts zu meckern.

Ich benutze openSUSE schon länger, bzw. nach ca. 3 Monaten erst, entschloss ich mich dazu hier im Forum zu registrieren. Nach dieser Zeit war mir nämlich klar das ich openSUSE behalten will, bzw. es für sehr lange benutzen möchte. Mache ich immer so. Taugt es was und soll bleiben, dann macht es Sinn sich im entsprechenden Forum anzumelden, bzw. zu registrieren.
Und damit komme ich zum nächsten Problem.
Vor ein paar Monaten führte ich ein " zypper purge-kernels " durch. Denn es waren über ein Dutzend Kernels und Broadcom Treiber vorhanden, welche unnötig Platz belegten.
Dies lief auch sauber durch, damals. Also bis dahin alles fein.
Nur, seit neuem klappt das auch nicht mehr. Der Rechner friert sofort ein.

Ich hatte gedacht daß das eventuell mit dem Secure-Boot zu tun hat. Denn im Yast-Bootloader Tool war dort ein Haken gesetzt. Mit dem Hinweis dies auch im Bios zu aktivieren. Aber das brachte auch nichts. Im Gegenteil. Ich hab es nun im Yast-Bootloader und im Bios deaktiviert.

Updates führe ich stets im Terminal per zypper dup durch. Also Root natürlich.

Software installiere ich allerdings zumeist über Yast-Soaftware. Zum einen ist es bequemer, und zum anderen wegen den ersichtlichen Infos.

Gegenwärtig läuft der vorletzte default Kernel mit dem dazugehörigen Broatcom Wlan Treiber. Das Wlan lässt sich auch ein- und ausschalten, und funktioniert. Wobei ich allerdings Wlan
nicht benutze, sondern ausschließlich Ethernet, sprich per Kabel.

Wenn ich jetzt ein update anstoße, heißt es daß es nichts zu tun gibt. Der letzte default Kernel ist allerdings installiert, aber im Grub Menü an unterster Stelle.

Wie kriege ich den Knoten raus, so das Updates wieder sauber und ohne sporadisches einfrieren funktionieren ??

Wie bekomme ich das Kernel Wirrwarr bereinigt, so das der aktuelle default Kernel sauber startet, ohne Kernel Panic ??

Vielen Dank im voraus und die besten Grüße,
Micha

Hier ging es um ein Lenovosystem.
https://forums.opensuse.org/showthread.php/554495-Lenovo-Thinkpad-E495-System-friert-zufällig-ein/page2
Versuche einmal die Lösung von Willy. Ich denke, er hat auch einen Acer (kein Tumbleweed).

Nee, ich glaube das passt nicht… Er hat ein AMD System.

Ich habe:

  • Aspire A515-55 51DP
  • Intel i5-1035G1
  • Iris Plus Graphics G1

In der Bootoption steht etwas von intel darin.

intel_idle.max_cstate=1"

Das sieht dann ungefähr so aus
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/16b0f013-342f-452b-8bda-xxxxxxxx splash=silent quiet showopts intel_idle.max_cstate=1"

Ich denke, Du kannst die Option

intel_idle.max_cstate=1

beim Booten in Grub eingeben. Das funktioniert nur einmal. Da kann eigentlich nichts weiter passieren.
Versuch macht klug, sagte der Teufel, und setzte sich in die heiße Bratpfanne.

Poste:

cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.13.1-1-default root=UUID=f22a2fa8-fcd5-4e8b-8bf9-246271c63f24 quiet splash resume=UUID=0f1a8c58-9674-4f62-bca2-f3f7fc7ced45 apparmor=0

apparmor=0

Wieso das? Einfach alles was ohne Probleme sich deinstallieren läßt löschen:

zypper se -si apparmor
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                  | Type  | Version     | Arch   | Repository
---+-----------------------+-------+-------------+--------+-----------
i  | apparmor-abstractions | Paket | 2.13.6-1.31 | noarch | OSS
i  | apparmor-parser       | Paket | 2.13.6-1.31 | x86_64 | OSS
i  | apparmor-parser-lang  | Paket | 2.13.6-1.31 | noarch | OSS
i+ | libapparmor1          | Paket | 2.13.6-1.24 | x86_64 | OSS

Die obigen 3 sind wegen Abhängigkeiten zu libvirt…

Kannst auch den service stoppen und disablen.

Entschuldige, aber ich verstehe grade leider nur Bahnhof. :slight_smile:

Ich versteh zB. nicht was das mit dem beschriebenen Problem zu tun hat.

Du meinst vielleicht den apparmor Dienst (Service), über systemd stoppen ?

In der Yast-Dienste-Verwaltung steht nur Manuell und Start zur Auswahl.

Folgende Teile sind installiert:

S  | Name                   | Type   | Version       | Arch   | Repository
---+------------------------+--------+---------------+--------+---------------
i+ | apparmor               | Schema | 20200505-22.1 | x86_64 | Tumbleweed_OSS
i+ | apparmor-abstractions  | Paket  | 3.0.1-8.1     | noarch | Tumbleweed_OSS
i+ | apparmor-parser        | Paket  | 3.0.1-8.1     | x86_64 | Tumbleweed_OSS
i+ | apparmor-parser-lang   | Paket  | 3.0.1-8.1     | noarch | Tumbleweed_OSS
i+ | apparmor-profiles      | Paket  | 3.0.1-8.1     | noarch | Tumbleweed_OSS
i+ | libapparmor1           | Paket  | 3.0.1-8.1     | x86_64 | Tumbleweed_OSS
i+ | patterns-base-apparmor | Paket  | 20200505-22.1 | x86_64 | Tumbleweed_OSS
i+ | yast2-apparmor         | Paket  | 4.4.1-1.1     | noarch | Tumbleweed_OSS


Gibt es bei openSUSE auch das Softwarepaket (RPM) “kernel-default-extra”? Wenn ja, dieses Softwarepaket deinstallieren. Kernel-default-extra und weitere nicht offiziell von Kernel.org unterstützte Kernelmodule können den Linux-Kernel “destabilisieren”. Siehe auch:
https://forums.opensuse.org/showthread.php/555290-Automatische-Signieren-von-Kernel-Modulen?p=3038929#post3038929

Randbemerkung: Bei entsprechender Konfiguration in /etc/zypp/zypp.conf sind händische Aufrufe von “zypper purge-kernels” nicht mehr erforderlich.

Aus SLED15 SP3 (entsprechend für openSUSE umzusetzen):

# more /etc/zypp/zypp.conf|grep -v ^#  |grep -i multi 
multiversion = provides:multiversion(kernel) 
multiversion.kernels = latest,latest-1,running

Kernel-default-extra und weitere nicht offiziell von Kernel.org unterstützte Kernelmodule können den Linux-Kernel “destabilisieren”. Siehe auch:

NE, das sind Module des offiziellen Kernels, die aber in den SUSE kernel nicht mit eingebaut werden…

The standard kernel for both uniprocessor and multiprocessor systems.

This package contains additional modules not supported by SUSE.

Schau dir einfach mal die kernel-Module an…

Damit sollte es keine Probleme geben, der von dir verlinkte Beitrag bezieht sich auch das vergessen der Signatur des Virtualbox-kmps.
Das ist auch als einzelnes kmp zu installieren und ist nicht in kernel-default-extra vorhanden.

Hat also nichts mit den hier vorgestellten Problemen zu tun.

multiversions ist bei openSUSE seit Leap auch Standard.

Entschuldige, aber ich verstehe grade leider nur Bahnhof. :slight_smile:

Ich verstehe

apparmor=0

als Bootparameter nicht, wer hat das eingetragen und warum?

Man kann den apparmor über den systemd-Service starten und stoppen, daher ist mir der obige Eintrag suspekt.
Den würde ich mal löschen.

Ich habe es einmal durchexerziert.

Installierte Kernel suchen:

**erlangen:~ #** zypper se -is kernel 
Loading repository data... 
Reading installed packages... 

S  | Name                        | Type    | Version      | Arch   | Repository 
---+-----------------------------+---------+--------------+--------+------------------------ 
i+ | kernel-default              | package | 5.13.1-1.1   | x86_64 | (System Packages) 
i+ | kernel-default              | package | 5.13.2-1.1   | x86_64 | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-all         | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-amdgpu      | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-ath10k      | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-ath11k      | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-atheros     | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-bluetooth   | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-bnx2        | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-brcm        | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-chelsio     | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-dpaa2       | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-i915        | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-intel       | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-iwlwifi     | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-liquidio    | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-marvell     | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-media       | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-mediatek    | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-mellanox    | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-mwifiex     | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-network     | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-nfp         | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-nvidia      | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-platform    | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-prestera    | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-qcom        | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-qlogic      | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-radeon      | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-realtek     | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-serial      | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-sound       | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-ti          | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-ueagle      | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | kernel-firmware-usb-network | package | 20210716-1.1 | noarch | openSUSE-Tumbleweed-Oss 
i  | purge-kernels-service       | package | 0-8.1        | noarch | openSUSE-Tumbleweed-Oss 
**erlangen:~ #**


Die oben gelisteten Pakete löschen und neu installieren.

@Sauerland

Die überflüssigen apparmor Teile habe ich wie vorgeschlagen gelöscht, und den Service gestoppt.

Der Bootparameter wurde mit der Installation eingetragen. Lief wohl auch die ganze Zeit so. Und wie vorgeschlagen habe ich den grade eben gelöscht.

Bin nun gespannt was beim kommenden Reboot passiert. :wink:

Die überflüssigen apparmor Teile habe ich wie vorgeschlagen gelöscht, und den Service gestoppt.

Nicht nur stoppen, auch disablen…

@karlmistelberger

Das schaut gegenwärtige bei mir wie folgt aus:

Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                        | Type  | Version      | Arch   | Repository
---+-----------------------------+-------+--------------+--------+---------------
i+ | kernel-default              | Paket | 5.13.1-1.1   | x86_64 | (Systempakete)
i+ | kernel-default              | Paket | 5.13.0-1.3   | x86_64 | (Systempakete)
i+ | kernel-default              | Paket | 5.12.13-1.1  | x86_64 | (Systempakete)
i+ | kernel-default              | Paket | 5.12.12-1.1  | x86_64 | (Systempakete)
i+ | kernel-default              | Paket | 5.12.10-1.1  | x86_64 | (Systempakete)
i+ | kernel-default              | Paket | 5.12.9-1.1   | x86_64 | (Systempakete)
i+ | kernel-default              | Paket | 5.12.4-2.1   | x86_64 | (Systempakete)
i+ | kernel-default              | Paket | 5.12.4-1.1   | x86_64 | (Systempakete)
i+ | kernel-default              | Paket | 5.13.2-1.1   | x86_64 | Tumbleweed_OSS
i+ | kernel-firmware-all         | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-amdgpu      | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-ath10k      | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-ath11k      | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-atheros     | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-bluetooth   | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-bnx2        | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-brcm        | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-chelsio     | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-dpaa2       | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-i915        | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-intel       | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-iwlwifi     | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-liquidio    | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-marvell     | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-media       | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-mediatek    | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-mellanox    | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-mwifiex     | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-network     | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-nfp         | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-nvidia      | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-platform    | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-prestera    | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i  | kernel-firmware-qcom        | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-qlogic      | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-radeon      | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-realtek     | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-serial      | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-sound       | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-ti          | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-ueagle      | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | kernel-firmware-usb-network | Paket | 20210716-1.1 | noarch | Tumbleweed_OSS
i+ | purge-kernels-service       | Paket | 0-8.1        | noarch | Tumbleweed_OSS


Und das alles soll ich jetzt löschen und dann neu installieren ?
Viel händische Arbeit, würde ich meinen, oder ?

Ganz ehrlich, ich traue mich nicht. Denn ich befürchte das dann der Super-Gau eintritt und nichts mehr geht. :wink:

Ich dachte es sei vielleicht das einfachste, oder Beste, bis zu den nächsten Kernel-Updates zu warten, und dann nochmal händisch purge-kernels durchzuführen, und sich die Sache damit
zu quasi von alleine erledigt.

Momentan startet ja der vorletzte default Kernel sauber durch und alles läuft stabil. Wenn ich den aktuellen wähle gibt es eine Panic. Kann man noch mit leben, denke ich.

Das Ganze kam ja leider deshalb zustande, weil der Rechner beim updaten eingefroren war.

Und dieses einfrieren beim Update kam schon einige mal vor, was aber bis Dato keine nennenswerte Probleme verursachte.

Allerdings startete der Rechner trotzdem immer sauber durch, und das Update lies sich an der abgebrochenen Stelle dann zu ende führen.
Und das wiederum hat mich stark beeindruckt. Andere Distros sind, bzw. waren dann bei so etwas direkt platt.
Nicht so openSUSE. Denn es läuft ja immer noch stabil und zuverlässig. Ziemlich zähes Luder würde ich mal sagen. :wink:

Klar, wenn das beim Updaten an einer ungünstigen Stelle crasht, dann ist irgendwann der Wurm drin.

Abschließend gestehe ich, daß ich relativ faul bin, und obwohl ich Linux bereits seit etwa 15 Jahren ausschließlich benutze; Also nur Linux und nichts anderes, ich nur bei und aus Fehlern
lerne. Viel lernen musste ich nicht. Deshalb bin ich bis jetzt noch lange kein Linux-Profi. wegduckundschandeübermich :wink:

Naja, purge-kernel-services funktioniert bei dir aber anscheinend gar nicht…

Alle Kernel müssen dann natürlich auch in die Boot-Konfiguration…

Alles, was dort mit “Systempakete” angezeigt wird, gibt es im Tumbleweed Repo nicht mehr.

@Sauerland

und

@karlmistelberger

Ich habe nach deinem Post sofort mal den purge-kernel-service aktiviert und gestartet. Der hat dann auch sofort losgerödelt im Hintergrund und alles bereinigt.
Jetzt schaut es exakt so aus wie bei karlmistelberger, bzw. bei seinem Post. :slight_smile:

Der apparmor Eintrag war ja entfernt wie vorgeschlagen, und hatte offenbar auch keinen Sinn, bzw. hatte nachträglich, nach dem entfernen, auch keinen Einfluss beim reboot.

Der Rechner hat danach dann auch sauber rebootet. Allerdings hatte ich in Grub dennoch den vorletzten default Kernel gewählt. Beim nächsten reboot probiere ich auch mal den aktuellen Kernel.
Vielleicht läuft der ja auch. Und wenn nicht, auch nicht schlimm. Der gegenwärtige Kernel wird ja sicher bald abgelöst und das purgen säubert dann vermutlich die Altlasten.

Ich möchte mich an der Stelle bei allen Helfern herzlichst bedanken. Ihr seit klasse. DANKE ! :slight_smile:

Das hat ganz deutlich wieder gezeigt wie wichtig ein gutes Forum und eine funktionierende sowie hilfreiche Community ist in Sachen Linux. Das wird ja auch oft als eben sehr wichtig hervorgehoben.

Beim stöbern im Netz (das hatte ich gestern mal länger und intensiver getan) stolpert man immer wieder über den Namen “Sauerland”. :slight_smile:
Auch in anderen Foren ist das so.
Warte was der sagt, der weiß es, tue was der sagt, kannst du dich absolut drauf verlassen , kann nix schief gehen… und so weiter. Kann ich nun auch unterstreichen.
Kurz und knapp, aber immer treffend , bzw. passend.
Gut zu wissen IMO.

Ich habe mich nun 100% dazu entschlossen daß openSUSE Tumbleweed weiterhin, und so lange wie nur möglich, auf meinem kleinen täglichen Begleiter (Acer Notebook)
seinen festen Platz hat.
Distro-Hopping mache ich schon lange nicht mehr. Zeitverschwendung und bringt mir nichts. Und dann hat man eh oft nur die Wahl zwischen Forks von Forks und so weiter.
Wie man so schön sagt, ich habe meinen Hafen gefunden. :slight_smile:

Ich finde es sehr wichtig das ein Linux mehr als 5 Devs hat, und schon lange besteht.

Auf meinem kleinen Notebook, welches ich fast täglich nutze, bleibt nun openSUSE fester Bestandteil. Was auch nach reiflicher Überlegung vorher der Plan war. :wink:

Und auf meinem Gaming-Notebook ist Arch Linux fester Bestandteil. Das, u.a. wegen der Hybrid GraKa (Optimus), und dem famosen Optimus-Manager. Läuft bisher immer sauber und so weiter.
Dazu gibt es unter Arch wesentlich mehr Gaming-Gimmicks. Und ich komme mit Arch schon sehr lange gut klar.

Beste Grüße und nochmals vielen Dank an alle Beteiligten Helfer.
Micha

OB Arch oder openSUSE ist eigentlich egal, alles nur Linux.

Und unterscheiden sich auch nur marginal…

@Sauerland

Guten Morgen

Da stimme ich dir zu, das ist mir schon lange klar.

Aber, gibt es etwa auch so etwas wie den Optimus-Manager für openSUSE ?

Mit dem Programm kann man zwischen den Grafikarten (oder eher Chips) bei Hybrid (Optimus) Laptops und Notebooks, bequem umschalten. Lediglich ein ein- und ausloggen ist dann angesagt.

Oder gibt es nur das AFAIK veraltete Bumblebee ?

Eigentlich wollte ich das an anderer Stelle irgendwann mal hier fragen. Aber auf meinem kleinen Bürohengst, wo ja openSUSE drauf ist, ist nur die Intel eigene Grafikeinheit vorhanden. Daher…

Vielen Dank für die ausführliche Rückmeldung. Einen Kernel, der tatsächlich nicht funktioniert kann man immer löschen ohne Schaden anzurichten.