BUG? Kernel Schrott ausgeliefert? 4.12.14-lp150.12.19.2
Aus unbekannten Gründen wurde wohl ein Test-Kernel (kernel-default-4.12.14-lp150.12.19.2) im OSS-Update ausgeliefert. Dieser Kernel läuft auf einigen Plattformen *NICHT*. Der Fehler ist *WIEDERHOLBAR* durch deinst., reboot, installation, reboot. Nach Quelle sollte das nur ein Test-Kernel sein und nicht im OSS liegen: https://pkgs.org/download/kernel-default-devel Der Kernel bleibt beim booten des Kernels bei BTRFS hängen. Booten ist nur mit älterem Kernel 150.12.16 möglich, dann entweder die 12.19. entfernen oder den Bootmanager erst einmal auf die 12.16. stellen. Kann wer das Verhalten bestätigen? Tschö' Sue -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 9. Oktober 2018, 18:54:35 CEST schrieb Sandre Useres:
Aus unbekannten Gründen wurde wohl ein Test-Kernel (kernel-default-4.12.14-lp150.12.19.2) im OSS-Update ausgeliefert.
Dieser Kernel läuft auf einigen Plattformen *NICHT*. Der Fehler ist *WIEDERHOLBAR* durch deinst., reboot, installation, reboot.
Nach Quelle sollte das nur ein Test-Kernel sein und nicht im OSS liegen: https://pkgs.org/download/kernel-default-devel
Der Kernel bleibt beim booten des Kernels bei BTRFS hängen.
Booten ist nur mit älterem Kernel 150.12.16 möglich, dann entweder die 12.19. entfernen oder den Bootmanager erst einmal auf die 12.16. stellen.
Kann wer das Verhalten bestätigen?
Tschö' Sue
Ist schon bei mehreren Usern aufgetreten..... Bugreport erstellt? Und pkgs.org zeigt nur an, das der im Update-Test-Repo lag, was mir schon seit Tagen bekannt ist. Und dies Repo ist zum testen, bevor Pakete ins Update Repo kommen......... Also nichts mit Test-Kernel!!!!! Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, den 09.10.2018, 18:54 +0200 schrieb Sandre Useres:
Der Kernel bleibt beim booten des Kernels bei BTRFS hängen.
Booten ist nur mit älterem Kernel 150.12.16 möglich, dann entweder die 12.19. entfernen oder den Bootmanager erst einmal auf die 12.16. stellen.
Kann wer das Verhalten bestätigen?
Kann ich bestätigen. Wobei ich gar kein Btrfs einsetze, sondern komplett XFS. Die letzten Meldungen bevor es nicht weitergeht: [ TIME ] Timed out waiting for device dev-sda3.device. [DEPEND] Dependency failed for Resume from hibernation using device /dev/sda3 [ OK ] Reached target Local File Systems (Pre). [ OK ] Reached target Local File Systems. [ OK ] Reached target System Initialization. [ OK ] Reached target Basic System. [ *** ] A start job is running for dev-disk-by\x2duuid-009fd208\x2d... (gekürzt) Und da steht er und steht er. -- MfG Richi
Am Dienstag, 9. Oktober 2018, 18:54:35 CEST schrieb Sandre Useres:
Aus unbekannten Gründen wurde wohl ein Test-Kernel (kernel-default-4.12.14-lp150.12.19.2) im OSS-Update ausgeliefert.
Dieser Kernel läuft auf einigen Plattformen *NICHT*. Der Fehler ist *WIEDERHOLBAR* durch deinst., reboot, installation, reboot.
Nach Quelle sollte das nur ein Test-Kernel sein und nicht im OSS liegen: https://pkgs.org/download/kernel-default-devel
Der Kernel bleibt beim booten des Kernels bei BTRFS hängen.
Booten ist nur mit älterem Kernel 150.12.16 möglich, dann entweder die 12.19. entfernen oder den Bootmanager erst einmal auf die 12.16. stellen.
Kann wer das Verhalten bestätigen?
Bei mir läuft der auf 2 Geräten, und auf beiden ohne probleme. Ich hab allerdings auch weder BTRFS noch XFS im einsatz. Cheers MH -- Mathias Homann Senior Systems Engineer, IT Consultant. IT Trainer Mathias.Homann@openSUSE.org http://www.tuxonline.tech gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Bei mir läuft der auf 2 Geräten, und auf beiden ohne probleme. Ich hab allerdings auch weder BTRFS noch XFS im einsatz.
Korrektur: jetzt sind's zwei rechner und zwei VMs. Alle ohne BTRFS oder XFS und alle ohne Probleme. Cheers MH -- Mathias Homann Senior Systems Engineer, IT Consultant. IT Trainer Mathias.Homann@openSUSE.org http://www.tuxonline.tech gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Am Dienstag, 9. Oktober 2018, 18:54:35 CEST schrieb Sandre Useres:
Aus unbekannten Gründen wurde wohl ein Test-Kernel (kernel-default-4.12.14-lp150.12.19.2) im OSS-Update ausgeliefert.
Dieser Kernel läuft auf einigen Plattformen *NICHT*. Der Fehler ist *WIEDERHOLBAR* durch deinst., reboot, installation, reboot.
Moin, moin, hab das "routinemäßig" "eingespielt" ich hab' hier kein Probleme Frank p.s. ... wenn ich vom allmorgentliche absturz (4., 5. Minute) von akonadi absehe, aber den hatte ich vorher schon d.o. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.10.18 um 18:54 schrieb Sandre Useres:
Aus unbekannten Gründen wurde wohl ein Test-Kernel (kernel-default-4.12.14-lp150.12.19.2) im OSS-Update ausgeliefert.
Dieser Kernel läuft auf einigen Plattformen *NICHT*. Der Fehler ist *WIEDERHOLBAR* durch deinst., reboot, installation, reboot.
Nach Quelle sollte das nur ein Test-Kernel sein und nicht im OSS liegen: https://pkgs.org/download/kernel-default-devel
Der Kernel bleibt beim booten des Kernels bei BTRFS hängen.
Booten ist nur mit älterem Kernel 150.12.16 möglich, dann entweder die 12.19. entfernen oder den Bootmanager erst einmal auf die 12.16. stellen.
Kann wer das Verhalten bestätigen?
Tschö' Sue
Guten Morgen, bei mir läuft Alles problemlos und ich verwende auch für das root-Verzeichnis BTRFS Oskar -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Mittwoch, 10. Oktober 2018, 08:24:21 CEST schrieb Oskar Schüßler:
Am 09.10.18 um 18:54 schrieb Sandre Useres:
Aus unbekannten Gründen wurde wohl ein Test-Kernel (kernel-default-4.12.14-lp150.12.19.2) im OSS-Update ausgeliefert.
Dieser Kernel läuft auf einigen Plattformen *NICHT*. Der Fehler ist *WIEDERHOLBAR* durch deinst., reboot, installation, reboot.
Nach Quelle sollte das nur ein Test-Kernel sein und nicht im OSS liegen: https://pkgs.org/download/kernel-default-devel
Der Kernel bleibt beim booten des Kernels bei BTRFS hängen.
Booten ist nur mit älterem Kernel 150.12.16 möglich, dann entweder die 12.19. entfernen oder den Bootmanager erst einmal auf die 12.16. stellen.
Kann wer das Verhalten bestätigen?
Tschö' Sue
Guten Morgen,
bei mir läuft Alles problemlos und ich verwende auch für das root-Verzeichnis BTRFS
Oskar
Hatte das Problem hier auch in einer Virtualbox Installation. Hier hat geholfen, alle virtualbox-guest Pakete zu deinstallieren. Falls es keine Virtuelle Maschine ist, mal versuchen, das virtualbox-host-kmp zu löschen? Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.10.2018 um 18:54 schrieb Sandre Useres:
Aus unbekannten Gründen wurde wohl ein Test-Kernel (kernel-default-4.12.14-lp150.12.19.2) im OSS-Update ausgeliefert. Dieser Kernel läuft auf einigen Plattformen *NICHT*. Der Fehler ist *WIEDERHOLBAR* durch deinst., reboot, installation, reboot.
Scheinbar hängt es tatsächlich an den Paketen * virtualbox-guest-tools * virtualbox-host-kmp-default Einmal mit dem alten .16. gebootet beide entfernt, mkinitrd und grup.conf von Hand neu ghemacht und der Rechner bootet wieder mit der .19. Ein erneutes zypper dup -l hat dann diese Pakete wieder neu installiert, und der Rechner bootet trotzdem wieder normal mit dem aktuellen Kernel. Allerdings zeigt der Plymoth lustige Effekte anstatt des Bootbildes und poweroff schaltet die Maschine nicht ab, reboot klemmt auch. :-( Also nochmal die vbox Pakete entfernt und im zypper geblockt: zypper al virtualbox-guest-tools virtualbox-host-kmp-default Bach neustart läuft die Maschine wieder normal, poweroff und reboot funktionieren ebenfalls wieder. Das Problem ist damit im Virtualbox verortet, scheinbar gibt es da eine inkompatible Schnitstelle o.ä. Für mich ist das Problem damit gelöst. Tschö. Sue -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, den 11.10.2018, 15:56 +0200 schrieb suse:
n' Abend
Das Problem ist damit im Virtualbox verortet, scheinbar gibt es da eine inkompatible Schnitstelle o.ä.
Und wenn der Rechner weder als Host für einen Virtualbox dient, noch die Installation in einer Virtualbox läuft, und dieser Kernel trotzdem spinnt? Dumme Sache, gelle? -- MfG Maik Messner
Am 11.10.2018 um 18:52 schrieb Maik Messner:
Am Donnerstag, den 11.10.2018, 15:56 +0200 schrieb suse:
n' Abend
Das Problem ist damit im Virtualbox verortet, scheinbar gibt es da eine inkompatible Schnitstelle o.ä.
Und wenn der Rechner weder als Host für einen Virtualbox dient, noch die Installation in einer Virtualbox läuft, und dieser Kernel trotzdem spinnt? Dumme Sache, gelle?
Allerdings. Wahrscheinlich ist das backporting von was auch immer in den (mittlerweile steinalten) 4.12er Kernel doch nicht der Weisheit letzter Schluss -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Manfred Kreisl schrieb am 11.10.18 um 19:12:
Am 11.10.2018 um 18:52 schrieb Maik Messner:
Am Donnerstag, den 11.10.2018, 15:56 +0200 schrieb suse:
n' Abend
Das Problem ist damit im Virtualbox verortet, scheinbar gibt es da eine inkompatible Schnitstelle o.ä.
Und wenn der Rechner weder als Host für einen Virtualbox dient, noch die Installation in einer Virtualbox läuft, und dieser Kernel trotzdem spinnt? Dumme Sache, gelle?
Allerdings. Wahrscheinlich ist das backporting von was auch immer in den (mittlerweile steinalten) 4.12er Kernel doch nicht der Weisheit letzter Schluss
Seit wann ist ein 15 Monat alter Kernel Stein bzw. Uralt? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Der neuere kernel-default-4.12.14-lp150.12.22.1.x86_64 funktioniert wieder komplett mit den Virtualbox-Modulen. Nach aufheben der Locks (zypper rl ..), einspielen, mkinitrd und grub.conf. bootet es mit der .22., hat funktionierendes Netzwerk und Grafik. Halt&Reboot auch OK. Danke DEV! Tschö' Sue Am 11.10.2018 um 15:56 schrieb suse:
Am 09.10.2018 um 18:54 schrieb Sandre Useres:
Aus unbekannten Gründen wurde wohl ein Test-Kernel (kernel-default-4.12.14-lp150.12.19.2) im OSS-Update ausgeliefert. Dieser Kernel läuft auf einigen Plattformen *NICHT*. Der Fehler ist *WIEDERHOLBAR* durch deinst., reboot, installation, reboot.
Scheinbar hängt es tatsächlich an den Paketen * virtualbox-guest-tools * virtualbox-host-kmp-default
Einmal mit dem alten .16. gebootet beide entfernt, mkinitrd und grup.conf von Hand neu ghemacht und der Rechner bootet wieder mit der .19.
Ein erneutes zypper dup -l hat dann diese Pakete wieder neu installiert, und der Rechner bootet trotzdem wieder normal mit dem aktuellen Kernel.
Allerdings zeigt der Plymoth lustige Effekte anstatt des Bootbildes und poweroff schaltet die Maschine nicht ab, reboot klemmt auch. :-(
Also nochmal die vbox Pakete entfernt und im zypper geblockt:
zypper al virtualbox-guest-tools virtualbox-host-kmp-default
Bach neustart läuft die Maschine wieder normal, poweroff und reboot funktionieren ebenfalls wieder.
Das Problem ist damit im Virtualbox verortet, scheinbar gibt es da eine inkompatible Schnitstelle o.ä.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 16. Oktober 2018, 10:18:44 CEST schrieb suse:
Der neuere kernel-default-4.12.14-lp150.12.22.1.x86_64 funktioniert wieder komplett mit den Virtualbox-Modulen.
Nach aufheben der Locks (zypper rl ..), einspielen, mkinitrd und grub.conf. bootet es mit der .22., hat funktionierendes Netzwerk und Grafik. Halt&Reboot auch OK.
Danke DEV!
Tschö' Sue
bei meinem Notebook 8Samsung mit Nvidia) ist nun mit einspielen des 22er Kernels der GAU perfekt. Der 22er funktioniert genauso wenig wie der 19er. Nun ist aber im Boot-Menü nur noch der 19er und 22er vorhanden. An den funktionierenden 16er komme ich nicht mehr ran. Booten von lepa 15 CD und mount --bind, chroot etc. bringt mich in den consolen mode in dem ich Yast starten kann. Doch in dem konsolenbasierten Yast finde ich die Option nicht, wie ich bei einem Paket auch die Version auswählen kann. Im grafischen Yast könnte ich (wie ich an meinem Hauptsystem sehe) das Kernelpaket anwählen und über Version den Haken an den 16er Kernel machen. Geht das in der ncurses Version nicht? Dann stehe ich noch vor dem Problem des Netzwerkes. Das Notebook geht per WLAN ins Netz. Wie schalte ich das ein, wenn ich mit einem Rettungssystem boote, mittels chroot auf mein System wechsel, keine Grafik und keine Network-Manager läuft? Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Herbert, Am Dienstag, 16. Oktober 2018, 12:29:07 CEST schrieb Herbert Albert:
... Im grafischen Yast könnte ich (wie ich an meinem Hauptsystem sehe) das Kernelpaket anwählen und über Version den Haken an den 16er Kernel machen. Geht das in der ncurses Version nicht?
Im konsonenbasierenden yast gibt es den Punkt "Anzeigen" mit dem Unterpunkt "Versionen". Hier kann das "x" auf die entsprechende Version gesetzt werden, die installiert werden soll. Tschüß Carsten -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 16. Oktober 2018, 12:46:52 CEST schrieb Carsten Grebehem:
Hallo Herbert,
Am Dienstag, 16. Oktober 2018, 12:29:07 CEST schrieb
Herbert Albert:
... Im grafischen Yast könnte ich (wie ich an meinem Hauptsystem sehe) das Kernelpaket anwählen und über Version den Haken an den 16er Kernel machen. Geht das in der ncurses Version nicht?
Im konsonenbasierenden yast gibt es den Punkt "Anzeigen" mit dem Unterpunkt "Versionen". Hier kann das "x" auf die entsprechende Version gesetzt werden, die installiert werden soll.
Tschüß
Carsten Ok, hab's gefunden.
Doch nur mit Hilfe von Knoppix komme ich hier weiter. Ach ist SuSE kompliziert geworden. WLAN läuft standardmäßig mit dem NetworkManager, der aber nur mit GUI. Stecke ich ein LAN-Kabel an ist die Schnittstelle mit wired nicht eingerichtet. Also weg mit der Suse DVD und her mit Knoppix, WLAN eingerichtet, chroot, Yast, kernel-devault, kernel-devel, etc, also alles was 2x mit der 16er Version vorhanden ist hinzugefügt. Dann vor den booten in Yast-Bootloader den 16er eingetragen und gebootet. Zitter, zitter .... Funktioniert Doch warum so kompliziert? Ist wohl mancher User bei so was überfordert. Frage noch: Wie halte ich den 16er Kernel dauerhaft, zumindest als Rückfalllösung? Anscheinend werden immer nur 2 Versionen nach einem Update vorgehalten, der alte und der neue. Da ich seit leap den PackeKit (oder wie der heißt: Systemaktualisierung) im system tray verwende, auf SuSE vertraue, verliere ich leicht den Überblick, wenn ein neuer Kernel installiert wird. In Yast kann ich nicht angeben, das der Kernel zwar aktualisiert werden darf, aber der letzte funktionierende (hier der 16er) trozdem gehalten wird. Also, wie hier vorgehen? Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Herbert, Am Dienstag, 16. Oktober 2018, 15:16:45 CEST schrieb Herbert Albert: [...]
In Yast kann ich nicht angeben, das der Kernel zwar aktualisiert werden darf, aber der letzte funktionierende (hier der 16er) trozdem gehalten wird. [...]
In der Datei /etc/zypp/zypp.conf gibt es die Möglichkeit, die Anzahl der auf der Maschine zu behaltenden Kernel zu verändern. In der Zeile "multiversions" könnte z.B. multiversion=provides:multiversion(kernel) stehen. Die genaue Beschreibung dazu steht darüber. Weiter unten in der Datei gibt es den Punkt multiversion.kernels=latest,latest-1,running mit Hilfe der Beschreibung darüber kannst Du entweder eine exakte Kernelversion mit Komma davor anhängen, oder Du könntest die Anzahl der Kernels erhöhen, in dem Du z.B. ,latest-2,latest-3 anhängst (in diesem Fall bleiben vier Kernel auf der Maschinen). [START Exkurs] Wenn zu jedem Kernel die Quellen, die devel-Pakete, ... installiert sind, wird bei z.B. 4 Kernels die Festplatte sehr schnell voll. [STOP Exkurs] Tschüß Carsten -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Carsten, Am Dienstag, 16. Oktober 2018, 15:50:37 CEST schrieb Carsten Grebehem:
Hallo Herbert,
Am Dienstag, 16. Oktober 2018, 15:16:45 CEST schrieb Herbert Albert: [...]
In Yast kann ich nicht angeben, das der Kernel zwar aktualisiert werden darf, aber der letzte funktionierende (hier der 16er) trozdem gehalten wird.
[...]
In der Datei /etc/zypp/zypp.conf gibt es die Möglichkeit, die Anzahl der auf der Maschine zu behaltenden Kernel zu verändern.
In der Zeile "multiversions" könnte z.B.
multiversion=provides:multiversion(kernel)
stehen. Die genaue Beschreibung dazu steht darüber.
steht bei mir.
Weiter unten in der Datei gibt es den Punkt
multiversion.kernels=latest,latest-1,running
mit Hilfe der Beschreibung darüber kannst Du entweder eine exakte Kernelversion mit Komma davor anhängen, oder Du könntest die Anzahl der Kernels erhöhen, in dem Du z.B. ,latest-2,latest-3 anhängst (in diesem Fall bleiben vier Kernel auf der Maschinen).
Im Moment steht da multiversion.kernels = latest,latest-1,running Könnte das dann auch heißen multiversion.kernels = latest,latest-1,4.12.14-lp150.12.16,running oder geht das so nicht.
[START Exkurs] Wenn zu jedem Kernel die Quellen, die devel-Pakete, ... installiert sind, wird bei z.B. 4 Kernels die Festplatte sehr schnell voll. [STOP Exkurs]
habe ich auf dem Notebook durch SuSE bei der Installation auswählen lassen.
Tschüß
Carsten
Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 16. Oktober 2018, 16:07:55 CEST schrieb Herbert Albert:
Hallo Carsten,
Am Dienstag, 16. Oktober 2018, 15:50:37 CEST schrieb Carsten Grebehem:
Hallo Herbert,
Am Dienstag, 16. Oktober 2018, 15:16:45 CEST schrieb Herbert Albert: [...]
In Yast kann ich nicht angeben, das der Kernel zwar aktualisiert werden darf, aber der letzte funktionierende (hier der 16er) trozdem gehalten wird.
[...]
In der Datei /etc/zypp/zypp.conf gibt es die Möglichkeit, die Anzahl der auf der Maschine zu behaltenden Kernel zu verändern.
In der Zeile "multiversions" könnte z.B.
multiversion=provides:multiversion(kernel)
stehen. Die genaue Beschreibung dazu steht darüber.
steht bei mir.
Weiter unten in der Datei gibt es den Punkt
multiversion.kernels=latest,latest-1,running
mit Hilfe der Beschreibung darüber kannst Du entweder eine exakte Kernelversion mit Komma davor anhängen, oder Du könntest die Anzahl der Kernels erhöhen, in dem Du z.B. ,latest-2,latest-3 anhängst (in diesem Fall bleiben vier Kernel auf der Maschinen).
Im Moment steht da multiversion.kernels = latest,latest-1,running
Könnte das dann auch heißen
multiversion.kernels = latest,latest-1,4.12.14-lp150.12.16,running
oder geht das so nicht.
[START Exkurs] Wenn zu jedem Kernel die Quellen, die devel-Pakete, ... installiert sind, wird bei z.B. 4 Kernels die Festplatte sehr schnell voll. [STOP Exkurs]
habe ich auf dem Notebook durch SuSE bei der Installation auswählen lassen.
Tschüß
Carsten
Gruß
Herbert
Nur mal als Info: Du kannst auch mit zypper die Version installieren, die du möchtest, entweder mit zypper in -f kernel-default-Version oder mit zypper in --oldpackage kernel-default-Version: zypper in -f kernel-default-4.12.14-lp150.12.16.1 Loading repository data... Reading installed packages... Forcing installation of 'kernel-default-4.12.14-lp150.12.16.1.x86_64' from repository 'openSUSE-Leap-15.0-Update'. Resolving package dependencies... The following NEW package is going to be installed: kernel-default-4.12.14-lp150.12.16.1 1 new package to install. Overall download size: 56.0 MiB. Already cached: 0 B. After the operation, additional 298.8 MiB will be used. Continue? [y/n/...? shows all options] (y): n Oder: zypper in --oldpackage kernel-default-4.12.14-lp150.12.16.1 Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: kernel-default-4.12.14-lp150.12.16.1 1 new package to install. Overall download size: 56.0 MiB. Already cached: 0 B. After the operation, additional 298.8 MiB will be used. Continue? [y/n/...? shows all options] (y): n Die Versionen kann man sich vorher mit zypper se -s kernel-default anzeigen lassen....... Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Stephan, Am Dienstag, 16. Oktober 2018, 17:42:49 CEST schrieb Stephan Hemeier: [...]
Nur mal als Info: Du kannst auch mit zypper die Version installieren, die du möchtest, entweder mit zypper in -f kernel-default-Version oder mit zypper in --oldpackage kernel-default-Version:
zypper in -f kernel-default-4.12.14-lp150.12.16.1 Loading repository data... Reading installed packages... Forcing installation of 'kernel-default-4.12.14-lp150.12.16.1.x86_64' from repository 'openSUSE-Leap-15.0-Update'. Resolving package dependencies...
The following NEW package is going to be installed: kernel-default-4.12.14-lp150.12.16.1
1 new package to install. Overall download size: 56.0 MiB. Already cached: 0 B. After the operation, additional 298.8 MiB will be used. Continue? [y/n/...? shows all options] (y): n
Oder:
zypper in --oldpackage kernel-default-4.12.14-lp150.12.16.1 Loading repository data... Reading installed packages... Resolving package dependencies...
The following NEW package is going to be installed: kernel-default-4.12.14-lp150.12.16.1
1 new package to install. Overall download size: 56.0 MiB. Already cached: 0 B. After the operation, additional 298.8 MiB will be used. Continue? [y/n/...? shows all options] (y): n
Die Versionen kann man sich vorher mit zypper se -s kernel-default anzeigen lassen.......
Stephan
ist soweit klar, doch mein Problem ist eher, wenn wieder durch eine Update unbeabsichtigt, d.h., durch Unachtsamkeit, mir ein neuer Kernel installiert wird, dieser wieder nicht funktioniert (irgendwann muss ja mal ein funktionierender kommen, oder?) und mir dabei der funktionierende gelöscht wird. Dann kann ich wieder nicht booten und brauche Fremdhilfe (Knoppix). ich möchte die neuen Kernel schon immer wieder probieren um zu sehen, ob sieh dann funktionieren. Wie langen aber via Yast auf den 16er zurückgegriffen werden kann weiß ich nicht. Er wird sicherlich irgendwann aus der Versionsliste verschwinden. Mir wäre lieb SuSE fixt das Problem. Bin ich jetzt nur noch der einzige oder haben andere auch noch ein Problem mit den Kernelupdate? Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 16. Oktober 2018, 18:04:21 CEST schrieb Herbert Albert:
ist soweit klar, doch mein Problem ist eher, wenn wieder durch eine Update unbeabsichtigt, d.h., durch Unachtsamkeit, mir ein neuer Kernel installiert wird, dieser wieder nicht funktioniert (irgendwann muss ja mal ein funktionierender kommen, oder?) und mir dabei der funktionierende gelöscht wird. Dann kann ich wieder nicht booten und brauche Fremdhilfe (Knoppix).
ich möchte die neuen Kernel schon immer wieder probieren um zu sehen, ob sieh dann funktionieren. Wie langen aber via Yast auf den 16er zurückgegriffen werden kann weiß ich nicht. Er wird sicherlich irgendwann aus der Versionsliste verschwinden.
Mir wäre lieb SuSE fixt das Problem.
Bin ich jetzt nur noch der einzige oder haben andere auch noch ein Problem mit den Kernelupdate?
Gruß
Herbert
zypper al --help Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Tue, 16 Oct 2018 18:04:21 +0200 schrieb Herbert Albert <h.albert@odn.de>:
Bin ich jetzt nur noch der einzige oder haben andere auch noch ein Problem mit den Kernelupdate?
Definitiv nicht! Ich weiß von mindestens 3 Rechnern, bei denen sich diese ... schon seit Tagen durch zieht. Bei einem 4. hat man(n) die Kurve da durch gekriegt, dass seit der Installation und benutzbaren Einrichtung überhaupt keine Updates mehr zulässt. -- MfG Jan-Uwe Kögel
Am 16.10.2018 um 12:29 schrieb Herbert Albert:
Der 22er funktioniert genauso wenig wie der 19er. Nun ist aber im Boot-Menü nur noch der 19er und 22er vorhanden. An den funktionierenden 16er komme ich nicht mehr ran.
Hast Du mal versucht diese Pakete (von der Rettungskonsole oder abgesicherter Boot) zu deinstallieren? * virtualbox-guest-tools * virtualbox-host-kmp-default Siehe auch: meine erste SOLVED Email in diesem Thread Tschö' Sue -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 16. Oktober 2018, 13:40:57 CEST schrieb Sandre Useres:
Am 16.10.2018 um 12:29 schrieb Herbert Albert:
Der 22er funktioniert genauso wenig wie der 19er. Nun ist aber im Boot-Menü nur noch der 19er und 22er vorhanden. An den funktionierenden 16er komme ich nicht mehr ran.
Hast Du mal versucht diese Pakete (von der Rettungskonsole oder abgesicherter Boot) zu deinstallieren?
* virtualbox-guest-tools * virtualbox-host-kmp-default
Siehe auch: meine erste SOLVED Email in diesem Thread
Tschö' Sue Wenn ich das System mal wieder am laufen habe kann ich nachsehen. Soweit ich weiß, habe ich nichts zu virtualbox installiert und standardmäßig wird's wohl nicht installiert.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Moin, Am 16.10.2018 um 14:09 schrieb Herbert Albert:
Am Dienstag, 16. Oktober 2018, 13:40:57 CEST schrieb Sandre Useres:
Hast Du mal versucht diese Pakete (von der Rettungskonsole oder abgesicherter Boot) zu deinstallieren?
* virtualbox-guest-tools * virtualbox-host-kmp-default
Wenn ich das System mal wieder am laufen habe kann ich nachsehen. Soweit ich weiß, habe ich nichts zu virtualbox installiert und standardmäßig wird's wohl nicht installiert.
hier war das auch eine Standard Installation, trotzdem waren die installiert. :-/ Wie die Kollegen schon schrieben... Wenn Du die Maschine zum laufen bekommst, kannst Du mit: zypper se -s kernel-default # Versionen anzeigen zypper in -f kernel-default-4.12.14-lp150.12.16.1 # alten kernel installieren (--force) und ein zypper al kernel-default-4.12.14-lp150.12.16.1 # --add-lock sperrt diesen kernel vor dem löschen Sollte ausreichen um normal weiter Updates zu fahren, dann sollten immer der neueste plus dieser Kernel stehen bleiben. ... Oder zwei neue plus diesen? Hatte das noch nicht... Viel Erfolg! Sue -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Zitat von suse <suse@fkn-systems.de>:
Moin,
Am 16.10.2018 um 14:09 schrieb Herbert Albert:
Am Dienstag, 16. Oktober 2018, 13:40:57 CEST schrieb Sandre Useres:
Hast Du mal versucht diese Pakete (von der Rettungskonsole oder abgesicherter Boot) zu deinstallieren?
* virtualbox-guest-tools * virtualbox-host-kmp-default
Wenn ich das System mal wieder am laufen habe kann ich nachsehen. Soweit ich weiß, habe ich nichts zu virtualbox installiert und standardmäßig wird's wohl nicht installiert.
hier war das auch eine Standard Installation, trotzdem waren die installiert. :-/
Wie die Kollegen schon schrieben... Wenn Du die Maschine zum laufen bekommst, kannst Du mit:
zypper se -s kernel-default # Versionen anzeigen zypper in -f kernel-default-4.12.14-lp150.12.16.1 # alten kernel installieren (--force)
und ein
zypper al kernel-default-4.12.14-lp150.12.16.1 # --add-lock sperrt diesen kernel vor dem löschen
Sollte ausreichen um normal weiter Updates zu fahren, dann sollten immer der neueste plus dieser Kernel stehen bleiben. ... Oder zwei neue plus diesen?
Hatte das noch nicht...
Viel Erfolg! Sue -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.
Hallo, kann man den zypper flag "al" auch in Yast vergeben? In Yast stehen die Versionen ja in dem Fenster unterhalb der Pakete.Hier kann ich für eine Version nur einen Haken anmachen oder wegnehmen. Ich habe jetzt gesetzt: zypper al kernel-default-4.12.14-lp150.12.16.1 zypper al kernel-default-devel-4.12.14-lp150.12.16.1 zypper al kernel-devel-4.12.14-lp150.12.16.1 zypper ll # | Name | Type | Repository --+--------------------------------------------+---------+----------- 1 | kernel-default-4.12.14-lp150.12.16.1 | package | (any) 2 | kernel-default-devel-4.12.14-lp150.12.16.1 | package | (any) 3 | kernel-devel-4.12.14-lp150.12.16.1 | package | (any) Ach ja, ~ # zypper se -si virtualbox Loading repository data... Reading installed packages... No matching items found. Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
h.albert@odn.de <h.albert@odn.de> wrote:
Zitat von suse <suse@fkn-systems.de>: ...
zypper al kernel-default-4.12.14-lp150.12.16.1 # --add-lock sperrt diesen kernel vor dem löschen
Sollte ausreichen um normal weiter Updates zu fahren, dann sollten immer der neueste plus dieser Kernel stehen bleiben. ... Oder zwei neue plus diesen?
Alternativ (wenn du keine echten Platzprobleme in /boot hast) kannst du dem System auch mitteilen, wie viele alte Kernelversionen du behalten möchtest. Schau dir mal die Datei /etc/zypp/zypp.conf an (und dort alles mit "multiversion") Das sollte verhindern das die Kernel "zu früh" aufgeräumt werden. Andreas Rgbx������ץ���r���҉碝��V������ uﮞ˛���m�)z{.��+�I�zr�ק٢�+-��h�;����r���brG�J'��w�j)Z��^�ˬy� ޮ�^�ˬz��
participants (15)
-
Carsten Grebehem -
eilfh -
h.albert＠odn.de -
Herbert Albert
-
Jan-Uwe Koegel -
Kyek, Andreas, Vodafone DE -
Maik Messner -
Manfred Kreisl -
Mathias Homann -
Oskar Schüßler -
Richard Kraut -
Sandre Useres -
Stephan Hemeier -
suse
-
Volker Kohaupt