Problem mit VirtualBox nach Upgrade auf leap 15.6
Hallo Liste, nach dem der Support für leap 15.5 bald endet, habe ich heute mein System per zypper auf leap 15.6 hochgehoben. Das Upgrade ist soweit problemlos durchgelaufen. Doch mit VirtualBox habe ich ein Problem. Ich verwende VirtualBox aus dem SuSE Repo: ~ # zypper se -i virtualbox Loading repository data... Reading installed packages... S | Name | Summary | Type ---+--------------------------------+-------------------------------+-------- i+ | virtualbox | VirtualBox is an Emulator | package i+ | virtualbox-guest-desktop-icons | Icons for guest desktop files | package i+ | virtualbox-guest-tools | VirtualBox guest tools | package i+ | virtualbox-kmp-default | Kernel modules for VirtualBox | package i+ | virtualbox-qt | Qt GUI part for virtualbox | package (warum zeigt zypper mit dem Befehl die Quelle nicht mehr an?) Als ich einen Gast aus der GUI starten wollte, erscheint die Meldung: VM Name: Windows_10_Pro_64 The virtual machine 'Windows_10_Pro_64' has terminated unexpectedly during startup because of signal 11. Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {e36a5081-a82a-40bd-9e4e-42a44d6ce50f} In Yast Diensteverwaltung stand " vboxadd-service Beim Systemstart fehlgeschlagen" und in / var/log/messages vboxadd-service.service: Main process exited, code=exited, status=1/FAILURE vboxadd-service.service: Failed with result 'exit-code' Auch den Dienst in Yast zu starten hat nicht geholfen. Dann habe ich in der VirtualBox GUI gesehen, dass da noch das Extension Pack 7.0.18 installiert war. Ich habe dann von der Oracle Seite das passende 7.1.14 geholt und installiert, das 7.0.18er deinstalliert. Auch das hilft nicht. Hat jemand Rat was zu tun ist? Gruß Herbert
Am Mittwoch, 4. Dezember 2024, 10:50:34 CET schrieb Herbert Albert:
Hallo Liste,
nach dem der Support für leap 15.5 bald endet, habe ich heute mein System per zypper auf leap 15.6 hochgehoben.
Das Upgrade ist soweit problemlos durchgelaufen. Doch mit VirtualBox habe ich ein Problem. Ich verwende VirtualBox aus dem SuSE Repo: ~ # zypper se -i virtualbox Loading repository data... Reading installed packages...
S | Name | Summary | Type ---+--------------------------------+-------------------------------+------- - i+ | virtualbox | VirtualBox is an Emulator | package i+ | virtualbox-guest-desktop-icons | Icons for guest desktop files | package i+ | virtualbox-guest-tools | VirtualBox guest tools | package i+ | virtualbox-kmp-default | Kernel modules for VirtualBox | package i+ | virtualbox-qt | Qt GUI part for virtualbox | package
(warum zeigt zypper mit dem Befehl die Quelle nicht mehr an?)
Als ich einen Gast aus der GUI starten wollte, erscheint die Meldung:
VM Name: Windows_10_Pro_64
The virtual machine 'Windows_10_Pro_64' has terminated unexpectedly during startup because of signal 11. Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {e36a5081-a82a-40bd-9e4e-42a44d6ce50f}
In Yast Diensteverwaltung stand " vboxadd-service Beim Systemstart fehlgeschlagen" und in / var/log/messages vboxadd-service.service: Main process exited, code=exited, status=1/FAILURE vboxadd-service.service: Failed with result 'exit-code'
Auch den Dienst in Yast zu starten hat nicht geholfen. Dann habe ich in der VirtualBox GUI gesehen, dass da noch das Extension Pack 7.0.18 installiert war. Ich habe dann von der Oracle Seite das passende 7.1.14 geholt und installiert, das 7.0.18er deinstalliert. Auch das hilft nicht.
Hat jemand Rat was zu tun ist?
Gruß
Herbert habe gerade gesehen, dass noch alte virtualbox-kmp-default installiert sind. Kann ich die löschen?
*~ #* zypper se -si virtual Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+-----------------------------------+---------+-------------------------------------------+--------+------------------ i+ | libqt5-qtvirtualkeyboard | package | 5.15.12+kde0-150600.1.3 | x86_64 | repo-oss (15.6) i+ | libqt5-qtvirtualkeyboard-hunspell | package | 5.15.12+kde0-150600.1.3 | x86_64 | repo-oss (15.6) i+ | libQt5VirtualKeyboard5 | package | 5.15.12+kde0-150600.1.3 | x86_64 | repo-oss (15.6) i+ | python3-virtualbox | package | 7.1.4-lp156.2.4.1 | x86_64 | update- oss (15.6) i+ | texlive-tex-virtual-academy-pl | package | 2021.189.svn34177-150400.18.1 | noarch | repo-oss (15.6) i+ | virtualbox | package | 7.1.4-lp156.2.4.1 | x86_64 | update-oss (15.6) i+ | virtualbox-guest-desktop-icons | package | 7.1.4-lp156.2.4.1 | noarch | update-oss (15.6) i+ | virtualbox-guest-tools | package | 7.1.4-lp156.2.4.1 | x86_64 | update- oss (15.6) i+ | virtualbox-kmp-default | package | 7.0.18_k5.14.21_150500.55.59-lp155.2.24.1 | x86_64 | (System Packages) i+ | virtualbox-kmp-default | package | 7.0.14_k5.14.21_150500.55.49-lp155.2.16.1 | x86_64 | (System Packages) i+ | virtualbox-kmp-default | package | 7.1.4_k6.4.0_150600.23.25-lp156.2.4.1 | x86_64 | update-oss (15.6) i+ | virtualbox-qt | package | 7.1.4-lp156.2.4.1 | x86_64 | update-oss (15.6)
Zu Virtualbox kann ich noch nichts sagen, ich habe das Upgrade bisher nur einer Virtualbox-VM versucht... Aber du solltest vielleicht generell mal nachsehen, ob 'verwaiste Pakete' installiert sind - da ist dann vielleicht-bestimmt virtualbox-kmp-default auch dabei. Hier waren es einige. Auf shell-Ebene nachsehen: zypper packages --orphaned Oder in Yast2 mit "Anzeigen|Paket-Klassifikation|verwaiste Pakete", da kann man sie dann auch gleich deinstallieren. Am 04.12.24 um 11:44 schrieb Herbert Albert: ....
habe gerade gesehen, dass noch alte virtualbox-kmp-default installiert sind. Kann ich die löschen? ...
-- Viele Grüße Michael
Am Mittwoch, 4. Dezember 2024, 12:00:44 CET schrieb Michael Behrens:
Zu Virtualbox kann ich noch nichts sagen, ich habe das Upgrade bisher nur einer Virtualbox-VM versucht...
Aber du solltest vielleicht generell mal nachsehen, ob 'verwaiste Pakete' installiert sind - da ist dann vielleicht-bestimmt virtualbox-kmp-default auch dabei. Hier waren es einige.
Auf shell-Ebene nachsehen:
zypper packages --orphaned
Oder in Yast2 mit "Anzeigen|Paket-Klassifikation|verwaiste Pakete", da kann man sie dann auch gleich deinstallieren.
Am 04.12.24 um 11:44 schrieb Herbert Albert: ....
habe gerade gesehen, dass noch alte virtualbox-kmp-default installiert sind. Kann ich die löschen? ... Da zeigt mir Yast einen lange Liste, aber virtualbox ist nicht dabei. Die beiden virtualbox-kmp-default 7.0.14 und 7.0.18 habe ich mittlerweile in Yast gelöscht.
Am Mittwoch, 4. Dezember 2024, 12:08:47 CET schrieb Herbert Albert:
Am Mittwoch, 4. Dezember 2024, 12:00:44 CET schrieb Michael Behrens:
Zu Virtualbox kann ich noch nichts sagen, ich habe das Upgrade bisher nur einer Virtualbox-VM versucht...
Aber du solltest vielleicht generell mal nachsehen, ob 'verwaiste Pakete' installiert sind - da ist dann vielleicht-bestimmt virtualbox-kmp-default auch dabei. Hier waren es einige.
Auf shell-Ebene nachsehen: zypper packages --orphaned
Oder in Yast2 mit "Anzeigen|Paket-Klassifikation|verwaiste Pakete", da kann man sie dann auch gleich deinstallieren.
Am 04.12.24 um 11:44 schrieb Herbert Albert: ....
habe gerade gesehen, dass noch alte virtualbox-kmp-default installiert sind. Kann ich die löschen? ...
Da zeigt mir Yast einen lange Liste, aber virtualbox ist nicht dabei. Die beiden virtualbox-kmp-default 7.0.14 und 7.0.18 habe ich mittlerweile in Yast gelöscht. ich bin nun per Yast auf die Version 7.0.18-lp156.1.6 zurück und dann als root
systemctl stop vboxdrv.service /usr/sbin/vboxconfig systemctl start vboxdrv.service und in der VirtualBox GUI das Extension-Pack 7.0.18 installiert. Damit geht es. Aber warum hakt es mit der Version 7.1.14? Hat die jemand hier mit dem aktuellen leap 15.6 und Kernel *#* uname -r 6.4.0-150600.23.25-default VirtualBox 7.1.14 aus dem OS Repo am Laufen?
Am Mittwoch, 4. Dezember 2024, 15:58:54 CET schrieb Herbert Albert:
Hat die jemand hier mit dem aktuellen leap 15.6 und Kernel *#* uname -r 6.4.0-150600.23.25-default
VirtualBox 7.1.14 aus dem OS Repo am Laufen?
Ja. uname -a && zypper se -si virtualbox Linux linux64 6.4.0-150600.23.25-default #1 SMP PREEMPT_DYNAMIC Tue Oct 1 10:54:01 UTC 2024 (ea7c56d) x86_64 x86_64 x86_64 GNU/Linux Repository-Daten werden geladen... Installierte Pakete werden gelesen... S | Name | Type | Version | Arch | Repository ---+------------------------+-------+---------------------------------------+--------+----------- i+ | virtualbox | Paket | 7.1.4-lp156.2.4.1 | x86_64 | Oss-Update i+ | virtualbox-kmp-default | Paket | 7.1.4_k6.4.0_150600.23.25-lp156.2.4.1 | x86_64 | Oss-Update i+ | virtualbox-qt | Paket | 7.1.4-lp156.2.4.1 | x86_64 | Oss-Update Poste mal: uname -a und zypper se -si virtualbox (Dir hat das s vor dem i gefehlt um mehr Informationen zu bekommen).
Am Mittwoch, 4. Dezember 2024, 16:56:50 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 15:58:54 CET schrieb Herbert Albert:
Hat die jemand hier mit dem aktuellen leap 15.6 und Kernel
*#* uname -r
6.4.0-150600.23.25-default
VirtualBox 7.1.14 aus dem OS Repo am Laufen?
Ja.
uname -a && zypper se -si virtualbox Linux linux64 6.4.0-150600.23.25-default #1 SMP PREEMPT_DYNAMIC Tue Oct 1 10:54:01 UTC 2024 (ea7c56d) x86_64 x86_64 x86_64 GNU/Linux Repository-Daten werden geladen... Installierte Pakete werden gelesen...
S | Name | Type | Version | Arch | Repository ---+------------------------+-------+-------------------------------------- -+--------+----------- i+ | virtualbox | Paket | 7.1.4-lp156.2.4.1 | x86_64 | Oss-Update i+ | virtualbox-kmp-default | Paket | 7.1.4_k6.4.0_150600.23.25-lp156.2.4.1 | x86_64 | Oss-Update i+ | virtualbox-qt | Paket | 7.1.4-lp156.2.4.1 | x86_64 | Oss-Update
Poste mal:
uname -a
und
zypper se -si virtualbox
(Dir hat das s vor dem i gefehlt um mehr Informationen zu bekommen).
Alle drei Pakete installiert, alles andere wo virtualbox "draufsteht" gelöscht. Fehler bleibt. uname -a: Linux xxxxxxxxxxxx 6.4.0-150600.23.25-default #1 SMP PREEMPT_DYNAMIC Tue Oct 1 10:54:01 UTC 2024 (ea7c56d) x86_64 x86_64 x86_64 GNU/Linux -- Keinem vernünftigen Menschen wird es einfallen, Tintenflecken mit Tinte, Ölflecken mit Öl wegwaschen zu wollen. Nur Blut soll immer wieder mit Blut abgewaschen werden. (Bertha von Suttner)
Am Mittwoch, 4. Dezember 2024, 17:59:19 CET schrieb Ulrich Walter:
Alle drei Pakete installiert, alles andere wo virtualbox "draufsteht" gelöscht. Fehler bleibt. uname -a:
Linux xxxxxxxxxxxx 6.4.0-150600.23.25-default #1 SMP PREEMPT_DYNAMIC Tue Oct 1 10:54:01 UTC 2024 (ea7c56d) x86_64 x86_64 x86_64 GNU/Linux
Habt ihr secure boot am laufen? mokutil --sb-state
Am Mittwoch, 4. Dezember 2024, 18:24:34 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 17:59:19 CET schrieb Ulrich Walter:
Alle drei Pakete installiert, alles andere wo virtualbox "draufsteht" gelöscht. Fehler bleibt. uname -a:
Linux xxxxxxxxxxxx 6.4.0-150600.23.25-default #1 SMP PREEMPT_DYNAMIC Tue Oct 1 10:54:01 UTC 2024 (ea7c56d) x86_64 x86_64 x86_64 GNU/Linux
Habt ihr secure boot am laufen?
mokutil --sb-state
Ich nicht, nein. Ich habe Virtualbox direkt von Oracle heruntergeladen und installiert. Ergebnis: Version 7.1.4 bringt den gleichen Fehler, 7.0.22 läuft. 7.1.4 will/hat eine QT-Version 6.irgendwas 7.0.22 will/hat eine QT-Version 5.15.12 ob das eine Bedeutung hat, kann ich nicht sagen. Das mal auf die Schnelle Gruß Uli -- Keinem vernünftigen Menschen wird es einfallen, Tintenflecken mit Tinte, Ölflecken mit Öl wegwaschen zu wollen. Nur Blut soll immer wieder mit Blut abgewaschen werden. (Bertha von Suttner)
Am Mittwoch, 4. Dezember 2024, 18:31:01 CET schrieb Ulrich Walter:
Ich nicht, nein. Ich habe Virtualbox direkt von Oracle heruntergeladen und installiert. Ergebnis: Version 7.1.4 bringt den gleichen Fehler, 7.0.22 läuft. 7.1.4 will/hat eine QT-Version 6.irgendwas 7.0.22 will/hat eine QT-Version 5.15.12 ob das eine Bedeutung hat, kann ich nicht sagen.
Wir reden hier von der openSUSE Version, die kommt mit den normalen QT-Paketen aus dem OSS oder SLE-Update Repo klar.
Am Mittwoch, 4. Dezember 2024, 18:24:34 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 17:59:19 CET schrieb Ulrich Walter:
Alle drei Pakete installiert, alles andere wo virtualbox "draufsteht" gelöscht. Fehler bleibt. uname -a:
Linux xxxxxxxxxxxx 6.4.0-150600.23.25-default #1 SMP PREEMPT_DYNAMIC Tue Oct 1 10:54:01 UTC 2024 (ea7c56d) x86_64 x86_64 x86_64 GNU/Linux
Habt ihr secure boot am laufen?
mokutil --sb-state bei mir *#* mokutil --sb-state SecureBoot disabled
Am Mittwoch, 4. Dezember 2024, 16:56:50 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 15:58:54 CET schrieb Herbert Albert:
Hat die jemand hier mit dem aktuellen leap 15.6 und Kernel
*#* uname -r
6.4.0-150600.23.25-default
VirtualBox 7.1.14 aus dem OS Repo am Laufen?
Ja.
uname -a && zypper se -si virtualbox Linux linux64 6.4.0-150600.23.25-default #1 SMP PREEMPT_DYNAMIC Tue Oct 1 10:54:01 UTC 2024 (ea7c56d) x86_64 x86_64 x86_64 GNU/Linux Repository-Daten werden geladen... Installierte Pakete werden gelesen...
S | Name | Type | Version | Arch | Repository ---+------------------------+-------+-------------------------------------- -+--------+----------- i+ | virtualbox | Paket | 7.1.4-lp156.2.4.1 | x86_64 | Oss-Update i+ | virtualbox-kmp-default | Paket | 7.1.4_k6.4.0_150600.23.25-lp156.2.4.1 | x86_64 | Oss-Update i+ | virtualbox-qt | Paket | 7.1.4-lp156.2.4.1 | x86_64 | Oss-Update
Poste mal:
uname -a
und
zypper se -si virtualbox
(Dir hat das s vor dem i gefehlt um mehr Informationen zu bekommen).
Hallo Stephan, *#* uname -a Linux wodan2 6.4.0-150600.23.25-default #1 SMP PREEMPT_DYNAMIC Tue Oct 1 10:54:01 UTC 2024 (ea7c56d) x86_64 x86_64 x86_64 GNU/Linux *#* zypper se -si virtualbox Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+--------------------------------+---------+-----------------------------------+--------+---------------- i+ | python3-virtualbox | package | 7.0.18-lp156.1.6 | x86_64 | repo-oss (15.6) i+ | virtualbox | package | 7.0.18-lp156.1.6 | x86_64 | repo-oss (15.6) i+ | virtualbox-guest-desktop-icons | package | 7.0.18-lp156.1.6 | noarch | repo-oss (15.6) i+ | virtualbox-guest-tools | package | 7.0.18-lp156.1.6 | x86_64 | repo-oss (15.6) i+ | virtualbox-host-source | package | 7.0.18-lp156.1.6 | noarch | repo-oss (15.6) i+ | virtualbox-kmp-default | package | 7.0.18_k6.4.0_150600.21-lp156.1.4 | x86_64 | repo- oss (15.6) i+ | virtualbox-qt | package | 7.0.18-lp156.1.6 | x86_64 | repo-oss (15.6) Gruß Herbert
Am Mittwoch, 4. Dezember 2024, 18:25:58 CET schrieb Herbert Albert:
Hallo Stephan,
*#* uname -a Linux wodan2 6.4.0-150600.23.25-default #1 SMP PREEMPT_DYNAMIC Tue Oct 1 10:54:01 UTC 2024 (ea7c56d) x86_64 x86_64 x86_64 GNU/Linux *#* zypper se -si virtualbox Loading repository data... Reading installed packages...
Poste mal: ls -al /lib/modules/
Am Mittwoch, 4. Dezember 2024, 18:42:05 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 18:25:58 CET schrieb Herbert Albert:
Hallo Stephan,
*#* uname -a Linux wodan2 6.4.0-150600.23.25-default #1 SMP PREEMPT_DYNAMIC Tue Oct 1 10:54:01 UTC 2024 (ea7c56d) x86_64 x86_64 x86_64 GNU/Linux *#* zypper se -si virtualbox Loading repository data... Reading installed packages...
Poste mal:
ls -al /lib/modules/
*#* ls -al /lib/modules/ total 132 drwxr-xr-x 33 root root 4096 Dec 4 11:46 *.* drwxr-xr-x 11 root root 4096 Dec 4 11:18 *..* drwxr-xr-x 3 root root 4096 Jun 11 2019 *4.12.14-lp150.12.48-default* drwxr-xr-x 3 root root 4096 Jun 30 2019 *4.12.14-lp150.12.58-default* drwxr-xr-x 3 root root 4096 Jul 31 2019 *4.12.14-lp150.12.61-default* drwxr-xr-x 3 root root 4096 Aug 17 2019 *4.12.14-lp150.12.64-default* drwxr-xr-x 3 root root 4096 Dec 16 2019 *4.12.14-lp150.12.67-default* drwxr-xr-x 3 root root 4096 Dec 16 2019 *4.12.14-lp150.12.70-default* drwxr-xr-x 3 root root 4096 Oct 28 2019 *4.12.14-lp150.12.73-default* drwxr-xr-x 3 root root 4096 Nov 15 2019 *4.12.14-lp150.12.76-default* drwxr-xr-x 3 root root 4096 Dec 16 2019 *4.12.14-lp150.12.79-default* drwxr-xr-x 3 root root 4096 Mar 14 2020 *4.12.14-lp150.12.82-default* drwxr-xr-x 3 root root 4096 Mar 27 2020 *4.12.14-lp151.28.36-default* drwxr-xr-x 3 root root 4096 Apr 23 2020 *4.12.14-lp151.28.40-default* drwxr-xr-x 3 root root 4096 Jul 4 2020 *4.12.14-lp151.28.44-default* drwxr-xr-x 3 root root 4096 Aug 7 2020 *4.12.14-lp151.28.48-default* drwxr-xr-x 3 root root 4096 Sep 25 2020 *4.12.14-lp151.28.52-default* drwxr-xr-x 3 root root 4096 Sep 9 2020 *4.12.14-lp151.28.59-default* drwxr-xr-x 3 root root 4096 Sep 28 2020 *4.12.14-lp151.28.63-default* drwxr-xr-x 3 root root 4096 Oct 3 2020 *4.12.14-lp151.28.67-default* drwxr-xr-x 2 root root 4096 Dec 27 2023 *5.14.21-150400.22-default* drwxr-xr-x 3 root root 4096 Dec 4 10:09 *5.14.21-150500.53-default* drwxr-xr-x 4 root root 4096 Dec 4 15:40 *5.14.21-150500.55.83-default* drwxr-xr-x 2 root root 4096 Jan 2 2023 *5.3.18-150300.59.101-preempt* drwxr-xr-x 2 root root 4096 Jan 2 2023 *5.3.18-150300.59.106-preempt* drwxr-xr-x 2 root root 4096 Dec 23 2022 *5.3.18-57-default* drwxr-xr-x 2 root root 4096 Feb 17 2023 *5.3.18-57-preempt* drwxr-xr-x 2 root root 4096 Sep 11 2021 *5.3.18-lp152.19-default* drwxr-xr-x 3 root root 4096 Dec 15 2020 *5.3.18-lp152.41-default* drwxr-xr-x 2 root root 4096 Sep 11 2021 *5.3.18-lp152.84-default* drwxr-xr-x 2 root root 4096 Sep 11 2021 *5.3.18-lp152.87-default* drwxr-xr-x 4 root root 4096 Dec 4 15:40 *6.4.0-150600.21-default* drwxr-xr-x 5 root root 4096 Dec 4 15:50 *6.4.0-150600.23.25-default*
Da hängen aber einige drin........ Poste mal: zypper se -si kernel Am Mittwoch, 4. Dezember 2024, 18:55:39 CET schrieb Herbert Albert:
drwxr-xr-x 33 root root 4096 Dec 4 11:46 *.* drwxr-xr-x 11 root root 4096 Dec 4 11:18 *..* drwxr-xr-x 3 root root 4096 Jun 11 2019 *4.12.14-lp150.12.48-default* drwxr-xr-x 3 root root 4096 Jun 30 2019 *4.12.14-lp150.12.58-default* drwxr-xr-x 3 root root 4096 Jul 31 2019 *4.12.14-lp150.12.61-default* drwxr-xr-x 3 root root 4096 Aug 17 2019 *4.12.14-lp150.12.64-default* drwxr-xr-x 3 root root 4096 Dec 16 2019 *4.12.14-lp150.12.67-default* drwxr-xr-x 3 root root 4096 Dec 16 2019 *4.12.14-lp150.12.70-default* drwxr-xr-x 3 root root 4096 Oct 28 2019 *4.12.14-lp150.12.73-default* drwxr-xr-x 3 root root 4096 Nov 15 2019 *4.12.14-lp150.12.76-default* drwxr-xr-x 3 root root 4096 Dec 16 2019 *4.12.14-lp150.12.79-default* drwxr-xr-x 3 root root 4096 Mar 14 2020 *4.12.14-lp150.12.82-default* drwxr-xr-x 3 root root 4096 Mar 27 2020 *4.12.14-lp151.28.36-default* drwxr-xr-x 3 root root 4096 Apr 23 2020 *4.12.14-lp151.28.40-default* drwxr-xr-x 3 root root 4096 Jul 4 2020 *4.12.14-lp151.28.44-default* drwxr-xr-x 3 root root 4096 Aug 7 2020 *4.12.14-lp151.28.48-default* drwxr-xr-x 3 root root 4096 Sep 25 2020 *4.12.14-lp151.28.52-default* drwxr-xr-x 3 root root 4096 Sep 9 2020 *4.12.14-lp151.28.59-default* drwxr-xr-x 3 root root 4096 Sep 28 2020 *4.12.14-lp151.28.63-default* drwxr-xr-x 3 root root 4096 Oct 3 2020 *4.12.14-lp151.28.67-default* drwxr-xr-x 2 root root 4096 Dec 27 2023 *5.14.21-150400.22-default* drwxr-xr-x 3 root root 4096 Dec 4 10:09 *5.14.21-150500.53-default* drwxr-xr-x 4 root root 4096 Dec 4 15:40 *5.14.21-150500.55.83-default* drwxr-xr-x 2 root root 4096 Jan 2 2023 *5.3.18-150300.59.101-preempt* drwxr-xr-x 2 root root 4096 Jan 2 2023 *5.3.18-150300.59.106-preempt* drwxr-xr-x 2 root root 4096 Dec 23 2022 *5.3.18-57-default* drwxr-xr-x 2 root root 4096 Feb 17 2023 *5.3.18-57-preempt* drwxr-xr-x 2 root root 4096 Sep 11 2021 *5.3.18-lp152.19-default* drwxr-xr-x 3 root root 4096 Dec 15 2020 *5.3.18-lp152.41-default* drwxr-xr-x 2 root root 4096 Sep 11 2021 *5.3.18-lp152.84-default* drwxr-xr-x 2 root root 4096 Sep 11 2021 *5.3.18-lp152.87-default* drwxr-xr-x 4 root root 4096 Dec 4 15:40 *6.4.0-150600.21-default* drwxr-xr-x 5 root root 4096 Dec 4 15:50 *6.4.0-150600.23.25-default*
Am Mittwoch, 4. Dezember 2024, 19:13:02 CET schrieb Stephan Hemeier:
Da hängen aber einige drin........
Poste mal: zypper se -si kernel
Am Mittwoch, 4. Dezember 2024, 18:55:39 CET schrieb Herbert Albert:
drwxr-xr-x 33 root root 4096 Dec 4 11:46 *.* drwxr-xr-x 11 root root 4096 Dec 4 11:18 *..* drwxr-xr-x 3 root root 4096 Jun 11 2019 *4.12.14-lp150.12.48-default* drwxr-xr-x 3 root root 4096 Jun 30 2019 *4.12.14-lp150.12.58-default* drwxr-xr-x 3 root root 4096 Jul 31 2019 *4.12.14-lp150.12.61-default* drwxr-xr-x 3 root root 4096 Aug 17 2019 *4.12.14-lp150.12.64-default* drwxr-xr-x 3 root root 4096 Dec 16 2019 *4.12.14-lp150.12.67-default* drwxr-xr-x 3 root root 4096 Dec 16 2019 *4.12.14-lp150.12.70-default* drwxr-xr-x 3 root root 4096 Oct 28 2019 *4.12.14-lp150.12.73-default* drwxr-xr-x 3 root root 4096 Nov 15 2019 *4.12.14-lp150.12.76-default* drwxr-xr-x 3 root root 4096 Dec 16 2019 *4.12.14-lp150.12.79-default* drwxr-xr-x 3 root root 4096 Mar 14 2020 *4.12.14-lp150.12.82-default* drwxr-xr-x 3 root root 4096 Mar 27 2020 *4.12.14-lp151.28.36-default* drwxr-xr-x 3 root root 4096 Apr 23 2020 *4.12.14-lp151.28.40-default* drwxr-xr-x 3 root root 4096 Jul 4 2020 *4.12.14-lp151.28.44-default* drwxr-xr-x 3 root root 4096 Aug 7 2020 *4.12.14-lp151.28.48-default* drwxr-xr-x 3 root root 4096 Sep 25 2020 *4.12.14-lp151.28.52-default* drwxr-xr-x 3 root root 4096 Sep 9 2020 *4.12.14-lp151.28.59-default* drwxr-xr-x 3 root root 4096 Sep 28 2020 *4.12.14-lp151.28.63-default* drwxr-xr-x 3 root root 4096 Oct 3 2020 *4.12.14-lp151.28.67-default* drwxr-xr-x 2 root root 4096 Dec 27 2023 *5.14.21-150400.22-default* drwxr-xr-x 3 root root 4096 Dec 4 10:09 *5.14.21-150500.53-default* drwxr-xr-x 4 root root 4096 Dec 4 15:40 *5.14.21-150500.55.83-default* drwxr-xr-x 2 root root 4096 Jan 2 2023 *5.3.18-150300.59.101-preempt* drwxr-xr-x 2 root root 4096 Jan 2 2023 *5.3.18-150300.59.106-preempt* drwxr-xr-x 2 root root 4096 Dec 23 2022 *5.3.18-57-default* drwxr-xr-x 2 root root 4096 Feb 17 2023 *5.3.18-57-preempt* drwxr-xr-x 2 root root 4096 Sep 11 2021 *5.3.18-lp152.19-default* drwxr-xr-x 3 root root 4096 Dec 15 2020 *5.3.18-lp152.41-default* drwxr-xr-x 2 root root 4096 Sep 11 2021 *5.3.18-lp152.84-default* drwxr-xr-x 2 root root 4096 Sep 11 2021 *5.3.18-lp152.87-default* drwxr-xr-x 4 root root 4096 Dec 4 15:40 *6.4.0-150600.21-default* drwxr-xr-x 5 root root 4096 Dec 4 15:50 *6.4.0-150600.23.25-default*
wie kann man Altlasten wieder loswerden? Habe mein System seit Jahren per zypper dup hochgehoben. *#* zypper se -si kernel Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+-----------------------------+---------+-------------------------------+-------- +------------------------------------------------------------- i+ | jupyter-ipykernel | package | 5.2.1-bp156.3.1 | noarch | repo-oss (15.6) i+ | kernel-default | package | 5.14.21-150500.55.83.1 | x86_64 | (System Packages) i+ | kernel-default | package | 6.4.0-150600.23.25.1 | x86_64 | update-sle (15.6) i+ | kernel-default | package | 6.4.0-150600.23.25.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-default-devel | package | 6.4.0-150600.23.25.1 | x86_64 | update-sle (15.6) i+ | kernel-default-devel | package | 6.4.0-150600.23.25.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-default-devel | package | 6.4.0-150600.21.3 | x86_64 | repo-oss (15.6) i+ | kernel-default-extra | package | 5.14.21-150500.55.83.1 | x86_64 | (System Packages) i+ | kernel-default-extra | package | 6.4.0-150600.23.25.1 | x86_64 | update-sle (15.6) i+ | kernel-default-extra | package | 6.4.0-150600.23.25.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-default-optional | package | 5.14.21-150500.55.83.1 | x86_64 | (System Packages) i+ | kernel-default-optional | package | 6.4.0-150600.23.25.1 | x86_64 | update-sle (15.6) i+ | kernel-default-optional | package | 6.4.0-150600.23.25.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-devel | package | 5.3.18-150300.59.106.1 | noarch | (System Packages) i+ | kernel-devel | package | 5.3.18-150300.59.101.1 | noarch | (System Packages) i+ | kernel-devel | package | 6.4.0-150600.23.25.1 | noarch | update-sle (15.6) i+ | kernel-devel | package | 6.4.0-150600.23.25.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-devel | package | 6.4.0-150600.21.2 | noarch | repo-oss (15.6) i+ | kernel-firmware-all | package | 20240728-150600.3.6.1 | noarch | update-sle (15.6) i+ | kernel-firmware-all | package | 20240728-150600.3.6.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-firmware-amdgpu | package | 20240728-150600.3.6.1 | noarch | update-sle (15.6) i+ | kernel-firmware-amdgpu | package | 20240728-150600.3.6.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-firmware-ath10k | package | 20240728-150600.3.6.1 | noarch | update-sle (15.6) i+ | kernel-firmware-ath10k | package | 20240728-150600.3.6.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-firmware-ath11k | package | 20240728-150600.3.6.1 | noarch | update-sle (15.6) i+ | kernel-firmware-ath11k | package | 20240728-150600.3.6.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15 i | kernel-firmware-ath12k | package | 20240728-150600.3.6.1 | noarch | update-sle (15.6) i | kernel-firmware-ath12k | package | 20240728-150600.3.6.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-firmware-atheros | package | 20240728-150600.3.6.1 | noarch | update-sle (15.6) i+ | kernel-firmware-atheros | package | 20240728-150600.3.6.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-firmware-bluetooth | package | 20240728-150600.3.6.1 | noarch | update-sle (15.6) i+ | kernel-firmware-bluetooth | package | 20240728-150600.3.6.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-firmware-bnx2 | package | 20240728-150600.3.6.1 | noarch | update-sle (15.6) i+ | kernel-firmware-bnx2 | package | 20240728-150600.3.6.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-firmware-brcm | package | 20240728-150600.3.6.1 | noarch | update-sle (15.6)
Am Mittwoch, 4. Dezember 2024, 19:16:16 CET schrieb Herbert Albert:
wie kann man Altlasten wieder loswerden? Habe mein System seit Jahren per zypper dup hochgehoben.
Alles, was angezeigt wird als System Packages kann gelöscht werden. Hinterher sollten nur die kernel 6.4 Pakete übrig bleiben. Sowie alle kernel-firmware. Aber poste vorher auch mal: zypper se -si zypper se -si kmp
Am Mittwoch, 4. Dezember 2024, 19:21:44 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 19:16:16 CET schrieb Herbert Albert:
wie kann man Altlasten wieder loswerden? Habe mein System seit Jahren per zypper dup hochgehoben.
Alles, was angezeigt wird als System Packages kann gelöscht werden.
Hinterher sollten nur die kernel 6.4 Pakete übrig bleiben. Sowie alle kernel-firmware.
Aber poste vorher auch mal:
zypper se -si zypper se -si kmp verstehe ich noch nicht. Heißt das:
kernel-default 5.14.21-150500.55.83.1 kernel-default-extra 5.14.21-150500.55.83.1 kernel-default-optional 5.14.21-150500.55.83.1 kernel-devel 5.3.18-150300.59.* kernel-preempt-devel 5.3.18-150300.59.* löschen? und was ist mit den anderen, die nicht 6.4.0-* sind und den ganzen kernel-firmware- *? Und was hat es damit auf sich, dass vermeintlich alles doppelt aus Update repository with updates from SUSE Linux Enterprise 15 und update-sle (15.6) kommt.
Am Mittwoch, 4. Dezember 2024, 19:35:59 CET schrieb Herbert Albert:
kernel-default 5.14.21-150500.55.83.1 kernel-default-extra 5.14.21-150500.55.83.1 kernel-default-optional 5.14.21-150500.55.83.1 kernel-devel 5.3.18-150300.59.* kernel-preempt-devel 5.3.18-150300.59.*
Die kannst du löschen, sind alles alte Pakete. Zum Thema SLE-Update Repo: Du hast das 2 x eingebunden, 1x reicht. schau dir die URL an. PS: das hier fehlt: zypper se -si kmp war nur doppelt geschrieben......
Am Mittwoch, 4. Dezember 2024, 19:43:03 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 19:35:59 CET schrieb Herbert Albert:
kernel-default 5.14.21-150500.55.83.1 kernel-default-extra 5.14.21-150500.55.83.1 kernel-default-optional 5.14.21-150500.55.83.1 kernel-devel 5.3.18-150300.59.* kernel-preempt-devel 5.3.18-150300.59.*
Die kannst du löschen, sind alles alte Pakete.
Zum Thema SLE-Update Repo: Du hast das 2 x eingebunden, 1x reicht.
schau dir die URL an.
PS: das hier fehlt:
zypper se -si kmp
war nur doppelt geschrieben...... ich dachte das habe ich schon mal bereinigt, das die Repos auf Grund eines Update oder Upgrades doppelt sind: -rw-r--r-- 1 root root 209 Dec 4 14:38 openSUSE:repo-non-oss-debug.repo -rw-r--r-- 1 root root 203 Dec 4 14:38 openSUSE:repo-non-oss.repo -rw-r--r-- 1 root root 186 Dec 4 14:38 openSUSE:repo-openh264.repo -rw-r--r-- 1 root root 197 Dec 4 14:38 openSUSE:repo-oss-debug.repo -rw-r--r-- 1 root root 200 Dec 4 14:38 openSUSE:repo-oss-source.repo -rw-r--r-- 1 root root 191 Dec 4 14:38 openSUSE:repo-oss.repo -rw-r--r-- 1 root root 208 Dec 4 14:38 openSUSE:update-backports-debug.repo -rw-r--r-- 1 root root 202 Dec 4 14:38 openSUSE:update-backports.repo -rw-r--r-- 1 root root 202 Dec 4 14:38 openSUSE:update-non-oss-debug.repo -rw-r--r-- 1 root root 196 Dec 4 14:38 openSUSE:update-non-oss.repo -rw-r--r-- 1 root root 190 Dec 4 14:38 openSUSE:update-oss-debug.repo -rw-r--r-- 1 root root 184 Dec 4 14:38 openSUSE:update-oss.repo -rw-r--r-- 1 root root 190 Dec 4 14:38 openSUSE:update-sle-debug.repo -rw-r--r-- 1 root root 184 Dec 4 14:38 openSUSE:update-sle.repo -rw-r--r-- 1 root root 197 Dec 4 14:38 opensuse-guide.org-openSUSE_Leap_$releasever.repo -rw-r--r-- 1 root root 156 Dec 4 14:38 packman.repo -rw-r--r-- 1 root root 244 Dec 4 14:38 repo-backports-debug-update.repo -rw-r--r-- 1 root root 256 Aug 29 10:49 repo-backports-debug-update.repo.rpmsave -rw-r--r-- 1 root root 199 Dec 4 14:38 repo-backports-update.repo -rw-r--r-- 1 root root 199 Aug 29 10:49 repo-backports-update.repo.rpmsave -rw-r--r-- 1 root root 197 Aug 29 10:49 repo-non-oss.repo.rpmsave -rw-r--r-- 1 root root 185 Aug 29 10:49 repo-oss.repo.rpmsave -rw-r--r-- 1 root root 222 Dec 4 14:38 repo-sle-debug-update.repo -rw-r--r-- 1 root root 222 Aug 29 10:49 repo-sle-debug-update.repo.rpmsave -rw-r--r-- 1 root root 208 Dec 4 14:38 repo-sle-update.repo -rw-r--r-- 1 root root 307 Aug 29 10:49 repo-sle-update.repo.rpmsave -rw-r--r-- 1 root root 200 Aug 29 10:49 repo-update-non-oss.repo.rpmsave -rw-r--r-- 1 root root 180 Aug 29 10:49 repo-update.repo.rpmsave Da hatten wir, so glaube ich mich zu erinnern, einen threat.
Am Mittwoch, 4. Dezember 2024, 19:52:07 CET schrieb Herbert Albert:
Am Mittwoch, 4. Dezember 2024, 19:43:03 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 19:35:59 CET schrieb Herbert Albert:
kernel-default 5.14.21-150500.55.83.1 kernel-default-extra 5.14.21-150500.55.83.1 kernel-default-optional 5.14.21-150500.55.83.1 kernel-devel 5.3.18-150300.59.* kernel-preempt-devel 5.3.18-150300.59.*
Die kannst du löschen, sind alles alte Pakete.
Zum Thema SLE-Update Repo: Du hast das 2 x eingebunden, 1x reicht.
schau dir die URL an.
PS: das hier fehlt:
zypper se -si kmp
war nur doppelt geschrieben......
ich dachte das habe ich schon mal bereinigt, das die Repos auf Grund eines Update oder Upgrades doppelt sind: -rw-r--r-- 1 root root 209 Dec 4 14:38 openSUSE:repo-non-oss-debug.repo -rw-r--r-- 1 root root 203 Dec 4 14:38 openSUSE:repo-non-oss.repo -rw-r--r-- 1 root root 186 Dec 4 14:38 openSUSE:repo-openh264.repo -rw-r--r-- 1 root root 197 Dec 4 14:38 openSUSE:repo-oss-debug.repo -rw-r--r-- 1 root root 200 Dec 4 14:38 openSUSE:repo-oss-source.repo -rw-r--r-- 1 root root 191 Dec 4 14:38 openSUSE:repo-oss.repo -rw-r--r-- 1 root root 208 Dec 4 14:38 openSUSE:update-backports-debug.repo -rw-r--r-- 1 root root 202 Dec 4 14:38 openSUSE:update-backports.repo -rw-r--r-- 1 root root 202 Dec 4 14:38 openSUSE:update-non-oss-debug.repo -rw-r--r-- 1 root root 196 Dec 4 14:38 openSUSE:update-non-oss.repo -rw-r--r-- 1 root root 190 Dec 4 14:38 openSUSE:update-oss-debug.repo -rw-r--r-- 1 root root 184 Dec 4 14:38 openSUSE:update-oss.repo -rw-r--r-- 1 root root 190 Dec 4 14:38 openSUSE:update-sle-debug.repo -rw-r--r-- 1 root root 184 Dec 4 14:38 openSUSE:update-sle.repo -rw-r--r-- 1 root root 197 Dec 4 14:38 opensuse-guide.org-openSUSE_Leap_$releasever.repo -rw-r--r-- 1 root root 156 Dec 4 14:38 packman.repo -rw-r--r-- 1 root root 244 Dec 4 14:38 repo-backports-debug-update.repo -rw-r--r-- 1 root root 256 Aug 29 10:49 repo-backports-debug-update.repo.rpmsave -rw-r--r-- 1 root root 199 Dec 4 14:38 repo-backports-update.repo -rw-r--r-- 1 root root 199 Aug 29 10:49 repo-backports-update.repo.rpmsave -rw-r--r-- 1 root root 197 Aug 29 10:49 repo-non-oss.repo.rpmsave -rw-r--r-- 1 root root 185 Aug 29 10:49 repo-oss.repo.rpmsave -rw-r--r-- 1 root root 222 Dec 4 14:38 repo-sle-debug-update.repo -rw-r--r-- 1 root root 222 Aug 29 10:49 repo-sle-debug-update.repo.rpmsave -rw-r--r-- 1 root root 208 Dec 4 14:38 repo-sle-update.repo -rw-r--r-- 1 root root 307 Aug 29 10:49 repo-sle-update.repo.rpmsave -rw-r--r-- 1 root root 200 Aug 29 10:49 repo-update-non-oss.repo.rpmsave -rw-r--r-- 1 root root 180 Aug 29 10:49 repo-update.repo.rpmsave Da hatten wir, so glaube ich mich zu erinnern, einen threat. das waren doch die http://cdn.opensuse.org[1] Repos, die jetzt wieder da sind.
-------- [1] http://cdn.opensuse.org
Am Mittwoch, 4. Dezember 2024, 19:56:54 CET schrieb Herbert Albert:
Am Mittwoch, 4. Dezember 2024, 19:52:07 CET schrieb Herbert Albert:
Am Mittwoch, 4. Dezember 2024, 19:43:03 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 19:35:59 CET schrieb Herbert Albert:
kernel-default 5.14.21-150500.55.83.1 kernel-default-extra 5.14.21-150500.55.83.1 kernel-default-optional 5.14.21-150500.55.83.1 kernel-devel 5.3.18-150300.59.* kernel-preempt-devel 5.3.18-150300.59.*
Die kannst du löschen, sind alles alte Pakete.
Zum Thema SLE-Update Repo: Du hast das 2 x eingebunden, 1x reicht.
schau dir die URL an.
PS: das hier fehlt:
zypper se -si kmp
war nur doppelt geschrieben......
ich dachte das habe ich schon mal bereinigt, das die Repos auf Grund eines Update oder Upgrades doppelt sind: -rw-r--r-- 1 root root 209 Dec 4 14:38 openSUSE:repo-non-oss-debug.repo -rw-r--r-- 1 root root 203 Dec 4 14:38 openSUSE:repo-non-oss.repo -rw-r--r-- 1 root root 186 Dec 4 14:38 openSUSE:repo-openh264.repo -rw-r--r-- 1 root root 197 Dec 4 14:38 openSUSE:repo-oss-debug.repo -rw-r--r-- 1 root root 200 Dec 4 14:38 openSUSE:repo-oss-source.repo -rw-r--r-- 1 root root 191 Dec 4 14:38 openSUSE:repo-oss.repo -rw-r--r-- 1 root root 208 Dec 4 14:38 openSUSE:update-backports-debug.repo -rw-r--r-- 1 root root 202 Dec 4 14:38 openSUSE:update-backports.repo -rw-r--r-- 1 root root 202 Dec 4 14:38 openSUSE:update-non-oss-debug.repo -rw-r--r-- 1 root root 196 Dec 4 14:38 openSUSE:update-non-oss.repo -rw-r--r-- 1 root root 190 Dec 4 14:38 openSUSE:update-oss-debug.repo -rw-r--r-- 1 root root 184 Dec 4 14:38 openSUSE:update-oss.repo -rw-r--r-- 1 root root 190 Dec 4 14:38 openSUSE:update-sle-debug.repo -rw-r--r-- 1 root root 184 Dec 4 14:38 openSUSE:update-sle.repo -rw-r--r-- 1 root root 197 Dec 4 14:38 opensuse-guide.org-openSUSE_Leap_$releasever.repo -rw-r--r-- 1 root root 156 Dec 4 14:38 packman.repo -rw-r--r-- 1 root root 244 Dec 4 14:38 repo-backports-debug-update.repo -rw-r--r-- 1 root root 256 Aug 29 10:49 repo-backports-debug-update.repo.rpmsave -rw-r--r-- 1 root root 199 Dec 4 14:38 repo-backports-update.repo -rw-r--r-- 1 root root 199 Aug 29 10:49 repo-backports-update.repo.rpmsave -rw-r--r-- 1 root root 197 Aug 29 10:49 repo-non-oss.repo.rpmsave -rw-r--r-- 1 root root 185 Aug 29 10:49 repo-oss.repo.rpmsave -rw-r--r-- 1 root root 222 Dec 4 14:38 repo-sle-debug-update.repo -rw-r--r-- 1 root root 222 Aug 29 10:49 repo-sle-debug-update.repo.rpmsave -rw-r--r-- 1 root root 208 Dec 4 14:38 repo-sle-update.repo -rw-r--r-- 1 root root 307 Aug 29 10:49 repo-sle-update.repo.rpmsave -rw-r--r-- 1 root root 200 Aug 29 10:49 repo-update-non-oss.repo.rpmsave -rw-r--r-- 1 root root 180 Aug 29 10:49 repo-update.repo.rpmsave Da hatten wir, so glaube ich mich zu erinnern, einen threat.
das waren doch die http://cdn.opensuse.org[1] Repos, die jetzt wieder da sind.
-------- [1] http://cdn.opensuse.org sollte ich da wieder die Pakete openSUSE-repos-Leap openSUSE-repos-Leap-NVIDIA löschen?
Am Mittwoch, 4. Dezember 2024, 20:59:06 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 20:28:02 CET schrieb Herbert Albert:
sollte ich da wieder die Pakete openSUSE-repos-Leap openSUSE-repos-Leap-NVIDIA löschen?
Besser ist erstmal die komplette Liste posten, denn am Schluss geht es noch weiter..... wie soll die aussehen und wie generiere ich die? Die zwei habe ich in Yast mit "suchen repos" gefunden.
Am Mittwoch, 4. Dezember 2024, 21:06:50 CET schrieb Herbert Albert:
Am Mittwoch, 4. Dezember 2024, 20:59:06 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 20:28:02 CET schrieb Herbert Albert:
sollte ich da wieder die Pakete openSUSE-repos-Leap openSUSE-repos-Leap-NVIDIA löschen?
Besser ist erstmal die komplette Liste posten, denn am Schluss geht es noch weiter.....
wie soll die aussehen und wie generiere ich die? Die zwei habe ich in Yast mit "suchen repos" gefunden. mit zypper gefiltert ergibt *#* zypper lr -d | grep "| Yes" | grep cdn 14 | openSUSE:repo-non-oss | repo-non-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/distribution/leap/15.6/repo/non-oss | openSUSE 17 | openSUSE:repo-oss | repo-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/distribution/leap/15.6/repo/oss | openSUSE 20 | openSUSE:update-backports | update-backports (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/update/leap/15.6/backports | openSUSE 22 | openSUSE:update-non-oss | update-non-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/update/leap/15.6/non-oss | openSUSE 24 | openSUSE:update-oss | update-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/update/leap/15.6/oss | openSUSE 26 | openSUSE:update-sle | update-sle (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/update/leap/15.6/sle | openSUSE Aber wenn ich das von damals noch in Erinnerung habe, reicht es nicht die Repos zu löschen, sondern irgendwelche Pakete.
Am Mittwoch, 4. Dezember 2024, 21:12:34 CET schrieb Herbert Albert:
mit zypper gefiltert ergibt *#* zypper lr -d | grep "| Yes" | grep cdn 14 | openSUSE:repo-non-oss | repo-non-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/distribution/leap/15.6/repo/non-oss | openSUSE 17 | openSUSE:repo-oss | repo-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/distribution/leap/15.6/repo/oss | openSUSE 20 | openSUSE:update-backports | update-backports (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/update/leap/15.6/backports | openSUSE 22 | openSUSE:update-non-oss | update-non-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/update/leap/15.6/non-oss | openSUSE 24 | openSUSE:update-oss | update-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/update/leap/15.6/oss | openSUSE 26 | openSUSE:update-sle | update-sle (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/update/leap/15.6/sle | openSUSE Aber wenn ich das von damals noch in Erinnerung habe, reicht es nicht die Repos zu löschen, sondern irgendwelche Pakete.
Die erste Liste war nicht vollständig, schau dir mal deine Mail von 20:04 an......... Die Repoliste ist eh etwas "gewöhnungsbedürftig", viel zu viele Repo mit factory Paketen.
Am Mittwoch, 4. Dezember 2024, 23:10:53 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 21:12:34 CET schrieb Herbert Albert:
mit zypper gefiltert ergibt *#* zypper lr -d | grep "| Yes" | grep cdn 14 | openSUSE:repo-non-oss | repo-non-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/distribution/leap/15.6/repo/non-oss | openSUSE 17 | openSUSE:repo-oss | repo-oss (15.6)
| Yes | (r ) Yes | Yes | 99 |
rpm-md | http://*cdn*.opensuse.org/distribution/leap/15.6/repo/oss | openSUSE 20 | openSUSE:update-backports | update-backports (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/update/leap/15.6/backports | openSUSE 22 | openSUSE:update-non-oss | update-non-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/update/leap/15.6/non-oss | openSUSE 24 | openSUSE:update-oss | update-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/update/leap/15.6/oss | openSUSE 26 | openSUSE:update-sle | update-sle (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://*cdn*.opensuse.org/update/leap/15.6/sle | openSUSE Aber wenn ich das von damals noch in Erinnerung habe, reicht es nicht die Repos zu löschen, sondern irgendwelche Pakete.
Die erste Liste war nicht vollständig, schau dir mal deine Mail von 20:04 an.........
ich habe die Liste ja auch nach Repos mit "cdn" gefiltert.
Die Repoliste ist eh etwas "gewöhnungsbedürftig", viel zu viele Repo mit factory Paketen.
Ist halt gewachsen, da ich von manchen Repos nur ein spezielles Paket gebraucht habe, welches früher nicht in den Standard-Repos war. Aber wieso Factory? Ich habe, wenn immer Repos passend zu der jeweiligen Distribution eingebunden. Welche, außer dem openSUSE:repo-openh264 (warum ich das rein genommen habe, weiß jetzt nicht mehr) sind den Deiner Meinung nach factory Repos? Wenn es die Pakete dann auch in den System Repos gibt und ich auf diese umsteigen will, wie mache ich das am geschicktesten? Primär möchte ich die "cdn" wieder los werden, damit nicht Doppeltes vorhanden ist. Aber das geht ja wohl nicht, indem man nur die Repos entfernt.
Am Donnerstag, 5. Dezember 2024, 08:42:18 CET schrieb Herbert Albert:
Primär möchte ich die "cdn" wieder los werden, damit nicht Doppeltes vorhanden ist. Aber das geht ja wohl nicht, indem man nur die Repos entfernt.
Das machen wir hinterher. Poste noch einmal: zypper se -si kernel-default kmp Stephan
Am Donnerstag, 5. Dezember 2024, 09:29:50 CET schrieb Stephan Hemeier:
Am Donnerstag, 5. Dezember 2024, 08:42:18 CET schrieb Herbert Albert:
Primär möchte ich die "cdn" wieder los werden, damit nicht Doppeltes vorhanden ist. Aber das geht ja wohl nicht, indem man nur die Repos entfernt. Das machen wir hinterher. Poste noch einmal: zypper se -si kernel-default kmp
Stephan ~ # zypper se -si kernel-default kmp Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository ---+---------------------------+--------- +----------------------------------------+-------- +------------------------------------------------------------- i+ | kernel-default | package | 5.14.21-150500.55.83.1 | x86_64 | (System Packages) i+ | kernel-default | package | 6.4.0-150600.23.25.1 | x86_64 | update-sle (15.6) i+ | kernel-default | package | 6.4.0-150600.23.25.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-default-devel | package | 6.4.0-150600.23.25.1 | x86_64 | update-sle (15.6) i+ | kernel-default-devel | package | 6.4.0-150600.23.25.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-default-devel | package | 6.4.0-150600.21.3 | x86_64 | repo-oss (15.6) i+ | kernel-default-extra | package | 5.14.21-150500.55.83.1 | x86_64 | (System Packages) i+ | kernel-default-extra | package | 6.4.0-150600.23.25.1 | x86_64 | update-sle (15.6) i+ | kernel-default-extra | package | 6.4.0-150600.23.25.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-default-optional | package | 5.14.21-150500.55.83.1 | x86_64 | (System Packages) i+ | kernel-default-optional | package | 6.4.0-150600.23.25.1 | x86_64 | update-sle (15.6) i+ | kernel-default-optional | package | 6.4.0-150600.23.25.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 i+ | nvidia-gfxG05-kmp-default | package | 470.256.02_k6.4.0_150600.21- lp156.64.2 | x86_64 | repo-non-free (15.6) il | virtualbox-kmp-default | package | 7.0.18_k6.4.0_150600.21-lp156.1.4 | x86_64 | repo-oss (15.6)
Am Mittwoch, 4. Dezember 2024, 19:52:07 CET schrieb Herbert Albert:
Zum Thema SLE-Update Repo:
Du hast das 2 x eingebunden, 1x reicht.
schau dir die URL an.
PS: das hier fehlt:
zypper se -si kmp
war nur doppelt geschrieben......
Nur mal als Info: Das fehlt noch: zypper se -si kmp Zum Thema Repos: wie die Repos heißen oder welchen Namen die Datein haben ist egal. Poste: zypper lr -d Denn dann wird das wichtigste angezeigt, die URL.
Am Mittwoch, 4. Dezember 2024, 20:01:44 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 19:52:07 CET schrieb Herbert Albert:
Zum Thema SLE-Update Repo:
Du hast das 2 x eingebunden, 1x reicht.
schau dir die URL an.
PS: das hier fehlt:
zypper se -si kmp
war nur doppelt geschrieben......
Nur mal als Info:
Das fehlt noch: zypper se -si kmp
Zum Thema Repos: wie die Repos heißen oder welchen Namen die Datein haben ist egal. Poste: zypper lr -d
Denn dann wird das wichtigste angezeigt, die URL. *#* zypper se -si kmp Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository ---+---------------------------+---------+----------------------------------------+--------+--------------------- i+ | nvidia-gfxG05-kmp-default | package | 470.256.02_k6.4.0_150600.21-lp156.64.2 | x86_64 | repo-non-free (15.6) il | virtualbox-kmp-default | package | 7.0.18_k6.4.0_150600.21-lp156.1.4 | x86_64 | repo- oss (15.6)
Am Mittwoch, 4. Dezember 2024, 20:01:44 CET schrieb Stephan Hemeier:
Am Mittwoch, 4. Dezember 2024, 19:52:07 CET schrieb Herbert Albert:
Zum Thema SLE-Update Repo:
Du hast das 2 x eingebunden, 1x reicht.
schau dir die URL an.
PS: das hier fehlt:
zypper se -si kmp
war nur doppelt geschrieben......
Nur mal als Info:
Das fehlt noch: zypper se -si kmp
Zum Thema Repos: wie die Repos heißen oder welchen Namen die Datein haben ist egal. Poste: zypper lr -d
Denn dann wird das wichtigste angezeigt, die URL. *#* zypper lr -d # | Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI | Service ---+---------------------------------------------- +---------------------------------------------------------------------------------------------+---------+----------- +---------+----------+- -------+----------------------------------------------------------------------------------+--------- 1 | Application_Geo | Applications related to the earth (GIS, Mapping, geodesy, GPS, astronomy) (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/Application:/Geo/15.6/ | 2 | Education | Applications for education users (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/Education/15.6/ | 3 | KDE_KDE3 | KDE 3.5.10 and associated software (15.6) | Yes | (r ) Yes | Yes | 97 | rpm-md | http://download.opensuse.org/repositories/KDE:/KDE3/15.6/ | 4 | LibreOffice_24.8 | LibreOffice 24.8 (openSUSE_Leap_15.6) | No | ---- | ---- | 98 | rpm-md | https://download.opensuse.org/repositories/LibreOffice:/24.8/openSUSE_Leap_1... | 5 | NVIDIA:repo-non-free | repo-non-free (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | https://download.nvidia.com/opensuse/leap/15.6 | NVIDIA 6 | Publishing | Publishing | Yes | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/Publishing/openSUSE_Leap_15.6/ | 7 | SoftMaker | SoftMaker | Yes | (r ) Yes | Yes | 99 | rpm-md | https://shop.softmaker.com/repo/rpm | 8 | devel_languages_perl | perl modules (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/devel:/languages:/perl/15.6/ | 9 | graphics | Graphics Project (15.6) | Yes | (r ) Yes | Yes | 101 | rpm-md | http://download.opensuse.org/repositories/graphics/15.6/ | 10 | home_ecsos_Publishing | home:ecsos:Publishing (openSUSE_Leap_15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/home:/ecsos:/Publishing/15.6/ | 11 | mozilla | Mozilla based projects (openSUSE_Leap_15.6) | Yes | (r ) Yes | Yes | 98 | rpm-md | http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.6/ | 12 | multimedia_apps | multimedia:apps | Yes | (r ) Yes | Yes | 102 | rpm-md | http://download.opensuse.org/repositories/multimedia:/apps/15.6/ | 13 | multimedia_libs | Multimedia Libraries, Codecs and Command Line Tools (15.6) | Yes | (r ) Yes | Yes | 102 | rpm-md | https://download.opensuse.org/repositories/multimedia:/libs/15.6/ | 14 | openSUSE:repo-non-oss | repo-non-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://cdn.opensuse.org/distribution/leap/15.6/repo/non-oss | openSUSE 15 | openSUSE:repo-non-oss-debug | repo-non-oss-debug (15.6) | No | ---- | ---- | 99 | N/A | http://cdn.opensuse.org/debug/distribution/leap/15.6/repo/non-oss | openSUSE 16 | openSUSE:repo-openh264 | repo-openh264 (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://codecs.opensuse.org/openh264/openSUSE_Leap | openSUSE 17 | openSUSE:repo-oss | repo-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://cdn.opensuse.org/distribution/leap/15.6/repo/oss | openSUSE 18 | openSUSE:repo-oss-debug | repo-oss-debug (15.6) | No | ---- | ---- | 99 | N/A | http://cdn.opensuse.org/debug/distribution/leap/15.6/repo/oss | openSUSE 19 | openSUSE:repo-oss-source | repo-oss-source (15.6) | No | ---- | ---- | 99 | N/A | http://cdn.opensuse.org/source/distribution/leap/15.6/repo/oss | openSUSE 20 | openSUSE:update-backports | update-backports (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://cdn.opensuse.org/update/leap/15.6/backports | openSUSE 21 | openSUSE:update-backports-debug | update-backports-debug (15.6) | No | ---- | ---- | 99 | N/A | http://cdn.opensuse.org/update/leap/15.6/backports_debug | openSUSE 22 | openSUSE:update-non-oss | update-non-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://cdn.opensuse.org/update/leap/15.6/non-oss | openSUSE 23 | openSUSE:update-non-oss-debug | update-non-oss-debug (15.6) | No | ---- | ---- | 99 | N/A | http://cdn.opensuse.org/debug/update/leap/15.6/non-oss | openSUSE 24 | openSUSE:update-oss | update-oss (15.6) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://cdn.opensuse.org/update/leap/15.6/oss | openSUSE 25 | openSUSE:update-oss-debug | update-oss-debug (15.6) | No | ---- | ---- | 99 | N/A | http://cdn.opensuse.org/debug/update/leap/15.6/oss | openSUSE 26 | openSUSE:update-sle | update-sle (15.6) | Yes | (r ) Yes | Yes | 99 |
Am Mittwoch, dem 04.12.2024 um 18:25 +0100 schrieb Herbert Albert:
i+ | virtualbox-guest-desktop-icons | package | 7.0.18- lp156.1.6 | noarch | repo-oss (15.6) i+ | virtualbox-guest-tools | package | 7.0.18- lp156.1.6 | x86_64 | repo-oss (15.6)
Also die Gastpakete brauchst Du nur, sofern Deine openSUSE-Installation nicht der Host, sondern der Gast ist. -- MfG Richi
Am Samstag, 7. Dezember 2024, 21:02:01 CET schrieb Richard Kraut:
Am Mittwoch, dem 04.12.2024 um 18:25 +0100 schrieb Herbert Albert:
i+ | virtualbox-guest-desktop-icons | package | 7.0.18- lp156.1.6 | noarch | repo-oss (15.6) i+ | virtualbox-guest-tools | package | 7.0.18- lp156.1.6 | x86_64 | repo-oss (15.6)
Also die Gastpakete brauchst Du nur, sofern Deine openSUSE-Installation nicht der Host, sondern der Gast ist. ah ja, wieder was gelernt.
Am Samstag, 7. Dezember 2024, 21:02:01 CET schrieb Richard Kraut:
Am Mittwoch, dem 04.12.2024 um 18:25 +0100 schrieb Herbert Albert:
i+ | virtualbox-guest-desktop-icons | package | 7.0.18- lp156.1.6 | noarch | repo-oss (15.6) i+ | virtualbox-guest-tools | package | 7.0.18- lp156.1.6 | x86_64 | repo-oss (15.6)
Also die Gastpakete brauchst Du nur, sofern Deine openSUSE-Installation nicht der Host, sondern der Gast ist. was man aber schon braucht ist das Extension Pack von Oracle, das wird mit den OS Paketen nicht mit geliefert. Ich hole mir immer das passende und hänge es ein, ebenso die Gasterweiterungen.
Hallo Albert, Am 8. Dezember 2024 09:14:22 MEZ schrieb Herbert Albert <herbert.albert@nefkom.net>:
Am Samstag, 7. Dezember 2024, 21:02:01 CET schrieb Richard Kraut:
Am Mittwoch, dem 04.12.2024 um 18:25 +0100 schrieb Herbert Albert:
i+ | virtualbox-guest-desktop-icons | package | 7.0.18- lp156.1.6 | noarch | repo-oss (15.6) i+ | virtualbox-guest-tools | package | 7.0.18- lp156.1.6 | x86_64 | repo-oss (15.6)
Also die Gastpakete brauchst Du nur, sofern Deine openSUSE-Installation nicht der Host, sondern der Gast ist. was man aber schon braucht ist das Extension Pack von Oracle, das wird mit den OS Paketen nicht mit geliefert. Ich hole mir immer das passende und hänge es ein, ebenso die Gasterweiterungen.
Ich möchte dich darauf hinweisen, dass das Virtualbox Extension Pack von Oracle Lizenzkosten verursacht, wenn man nicht aufpasst. Das übersieht man schnell. Wofür brauchst Du das Extension Pack wirklich? Wenn du die Frage nicht klar beantworten kannst, brauchst du es normalerweise nicht. Wenn es um eine Darstellung der GUI des Gastes geht kannst du auch das Paket virtualbox-vnc aus dem opensuse Repo verwenden. Dann kannst du Dir via vnc Client die GUI ansehen und bedienen. Mark
Hallo Mark, Am Sonntag, 8. Dezember 2024, 10:38:09 CET schrieb mark.wenzel@gmx.net:
Hallo Albert,
Am 8. Dezember 2024 09:14:22 MEZ schrieb Herbert Albert <herbert.albert@nefkom.net>:
Am Samstag, 7. Dezember 2024, 21:02:01 CET schrieb Richard Kraut:
Am Mittwoch, dem 04.12.2024 um 18:25 +0100 schrieb Herbert Albert:
i+ | virtualbox-guest-desktop-icons | package | 7.0.18- lp156.1.6 | noarch | repo-oss (15.6) i+ | virtualbox-guest-tools | package | 7.0.18- lp156.1.6 | x86_64 | repo-oss (15.6)
Also die Gastpakete brauchst Du nur, sofern Deine openSUSE-Installation nicht der Host, sondern der Gast ist.
was man aber schon braucht ist das Extension Pack von Oracle, das wird mit den OS Paketen nicht mit geliefert. Ich hole mir immer das passende und hänge es ein, ebenso die Gasterweiterungen.
Ich möchte dich darauf hinweisen, dass das Virtualbox Extension Pack von Oracle Lizenzkosten verursacht, wenn man nicht aufpasst. Das übersieht man schnell.
https://www.virtualbox.org/wiki/Licensing_FAQ The VirtualBox Extension Pack is freely available under the VirtualBox Extension Pack Personal Use and Educational License (PUEL) for personal and educational use. For a fee, the VirtualBox Extension Pack is also available for most commercial, non-distribution uses restricted by the PUEL. Da ich es nicht für den kommerziellen Gebrauch benutze müsste es frei sein.
Wofür brauchst Du das Extension Pack wirklich? Wenn du die Frage nicht klar beantworten kannst, brauchst du es normalerweise nicht.
Das kann ich Dir so nicht mehr genau sagen, da ich das routinemäßig seit vielen Jahren mache. Früher war es wohl nötig, zumindest für die verbesserte USB-Geräteunterstützung.
Wenn es um eine Darstellung der GUI des Gastes geht kannst du auch das Paket virtualbox-vnc aus dem opensuse Repo verwenden. Dann kannst du Dir via vnc Client die GUI ansehen und bedienen.
damit habe ich keine Problem, das läuft alle prima, nur eben z. Z. nicht mit der 7.1.4.
Mark
Gruß Herbert
Hallo Herbert, Am 8. Dezember 2024 11:14:35 MEZ schrieb Herbert Albert <herbert.albert@nefkom.net>:
Hallo Mark,
Am Sonntag, 8. Dezember 2024, 10:38:09 CET schrieb mark.wenzel@gmx.net:
Hallo Albert,
Am 8. Dezember 2024 09:14:22 MEZ schrieb Herbert Albert <herbert.albert@nefkom.net>:
Am Samstag, 7. Dezember 2024, 21:02:01 CET schrieb Richard Kraut:
Am Mittwoch, dem 04.12.2024 um 18:25 +0100 schrieb Herbert Albert:
i+ | virtualbox-guest-desktop-icons | package | 7.0.18- lp156.1.6 | noarch | repo-oss (15.6) i+ | virtualbox-guest-tools | package | 7.0.18- lp156.1.6 | x86_64 | repo-oss (15.6)
Also die Gastpakete brauchst Du nur, sofern Deine openSUSE-Installation nicht der Host, sondern der Gast ist.
was man aber schon braucht ist das Extension Pack von Oracle, das wird mit den OS Paketen nicht mit geliefert. Ich hole mir immer das passende und hänge es ein, ebenso die Gasterweiterungen.
Ich möchte dich darauf hinweisen, dass das Virtualbox Extension Pack von Oracle Lizenzkosten verursacht, wenn man nicht aufpasst. Das übersieht man schnell.
https://www.virtualbox.org/wiki/Licensing_FAQ The VirtualBox Extension Pack is freely available under the VirtualBox Extension Pack Personal Use and Educational License (PUEL) for personal and educational use. For a fee, the VirtualBox Extension Pack is also available for most commercial, non-distribution uses restricted by the PUEL.
Da ich es nicht für den kommerziellen Gebrauch benutze müsste es frei sein. Solange du es nur auf einem Computer installiert hast. Ab zwei Installationen wird kommerzielle Nutzung daraus und du müsstest Lizenzen kaufen. Kleinste Menge sind glaube ich 100(!) Lizenzen.
Wofür brauchst Du das Extension Pack wirklich? Wenn du die Frage nicht klar beantworten kannst, brauchst du es normalerweise nicht.
Das kann ich Dir so nicht mehr genau sagen, da ich das routinemäßig seit vielen Jahren mache. Früher war es wohl nötig, zumindest für die verbesserte USB-Geräteunterstützung.
Wenn es um eine Darstellung der GUI des Gastes geht kannst du auch das Paket virtualbox-vnc aus dem opensuse Repo verwenden. Dann kannst du Dir via vnc Client die GUI ansehen und bedienen.
damit habe ich keine Problem, das läuft alle prima, nur eben z. Z. nicht mit der 7.1.4.
Mark
Gruß
Herbert Viele Grüße Mark
Am Sonntag, 8. Dezember 2024, 11:14:35 CET schrieb Herbert Albert:
damit habe ich keine Problem, das läuft alle prima, nur eben z. Z. nicht mit der 7.1.4. Kannst du die 3 Pakete der Virtualbox 7.1.4 installieren:
S | Name | Type | Version | Arch | Repository ---+------------------------+-------+---------------------------------------+--------+----------- i+ | virtualbox | Paket | 7.1.4-lp156.2.4.1 | x86_64 | Oss-Update i+ | virtualbox-kmp-default | Paket | 7.1.4_k6.4.0_150600.23.25-lp156.2.4.1 | x86_64 | Oss-Update i+ | virtualbox-qt | Paket | 7.1.4-lp156.2.4.1 | x86_64 | Oss-Update Danach neu starten und als User in der Konsole eingeben: VirtualBox Falls Fehlermeldungen auftreten, bitte hier posten und auf keinen Fall vboxcofig ausführen. Wenn Fehler auftreten bitte als root einmal: lsmod | grep -i vbox Und hier posten. Falls keine Ausgabe ergibt, bitte als root: modprobe -i vboxdrv Falls Fehlermeldung, hier posten, ansonsten noch einmal als User ausführen: VirtualBox Startet es dann? Lass mal bis morgen die Virtualbox 7.1.4 installiert, wir schauen einmal heute weiter. Stephan
Hallo Stephan, Am Sonntag, 8. Dezember 2024, 15:38:33 CET schrieb Stephan Hemeier:
Am Sonntag, 8. Dezember 2024, 11:14:35 CET schrieb Herbert Albert:
damit habe ich keine Problem, das läuft alle prima, nur eben z. Z. nicht mit der 7.1.4.
Kannst du die 3 Pakete der Virtualbox 7.1.4 installieren:
S | Name | Type | Version | Arch | Repository ---+------------------------+-------+-------------------------------------- -+--------+----------- i+ | virtualbox | Paket | 7.1.4-lp156.2.4.1 | x86_64 | Oss-Update i+ | virtualbox-kmp-default | Paket | 7.1.4_k6.4.0_150600.23.25-lp156.2.4.1 | x86_64 | Oss-Update i+ | virtualbox-qt | Paket | 7.1.4-lp156.2.4.1 | x86_64 | Oss-Update
Danach neu starten und als User in der Konsole eingeben: VirtualBox
Falls Fehlermeldungen auftreten, bitte hier posten und auf keinen Fall vboxcofig ausführen. nun ~ # zypper se -si virtualbox Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository ---+------------------------+---------+--------------------------------------- +--------+---------------- i+ | virtualbox | package | 7.1.4-lp156.2.4.1 | x86_64 | repo-update-oss i+ | virtualbox-kmp-default | package | 7.1.4_k6.4.0_150600.23.25-lp156.2.4.1 | x86_64 | repo-update-oss i+ | virtualbox-qt | package | 7.1.4-lp156.2.4.1 | x86_64 | repo-update-oss ohne vorherigen reboot in der konsole ~> VirtualBox GUI startet ohne Fehlermeldung. Sobald ich einen Gast starten will kommt die altbekannte Fehlermeldung: VM Name: Windows_10_Pro_64 The virtual machine 'Windows_10_Pro_64' has terminated unexpectedly during startup because of signal 11. Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {e36a5081-a82a-40bd-9e4e-42a44d6ce50f}
Wenn Fehler auftreten bitte als root einmal: lsmod | grep -i vbox
Und hier posten.
~ # lsmod | grep -i vbox vboxnetadp 32768 0 vboxnetflt 40960 0 vboxdrv 684032 2 vboxnetadp,vboxnetflt
Falls keine Ausgabe ergibt, bitte als root: modprobe -i vboxdrv
~ # modprobe -i vboxdrv ohne Fehlermeldung
Falls Fehlermeldung, hier posten, ansonsten noch einmal als User ausführen: VirtualBox
keine Fehlermeldung
Startet es dann?
Gast startet nicht
Lass mal bis morgen die Virtualbox 7.1.4 installiert, wir schauen einmal heute weiter.
Stephan
Gruß Herbert
Am Sonntag, dem 08.12.2024 um 16:14 +0100 schrieb Herbert Albert: <...snip...>
keine Fehlermeldung
Startet es dann?
Gast startet nicht
Hast Du auch das Erweiterungspakt passend zu Deiner VirtualBox-Version installiert? Wenn ich selbiges bei mir entferne, möchten auch die VMs in der VB nicht mehr starten. -- MfG Richi
Am Sonntag, dem 08.12.2024 um 16:28 +0100 schrieb Richard Kraut:
Hast Du auch das Erweiterungspakt passend zu Deiner VirtualBox-Version installiert?
Wenn ich selbiges bei mir entferne, möchten auch die VMs in der VB nicht mehr starten.
Noch zwei, drei Möglichkeiten woran es evtl. liegen könnte: - falsch gesetzte Rechte irgendow in der VB-Instalaltion - eine fehlerhafte VB-Installation oder aber - VirtualBox stört sich am geladenen KVM-Kernel-Modul Letzteres ist mir gerade passiert. Wollte eine VB-VM starten um darin kurz was nachzusehen. Und dann ist genau das passiert: VM Name: Disinfec't VirtualBox can't enable the AMD-V extension. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_SVM_IN_USE). Result Code: NS_ERROR_FAILURE (0x80004005) Component: ConsoleWrap Interface: IConsole {6ac83d89-6ee7-4e33-8ae6-b257b2e81be8} Wenn ich mit 'modprobe -r kvm_amd' das Modul entlade (kvm wird automatisch mit entladen) starten die VMs wieder. -- MfG Richi
Am Sonntag, 8. Dezember 2024, 16:53:12 CET schrieb Richard Kraut:
Am Sonntag, dem 08.12.2024 um 16:28 +0100 schrieb Richard Kraut:
Hast Du auch das Erweiterungspakt passend zu Deiner VirtualBox-Version installiert?
Wenn ich selbiges bei mir entferne, möchten auch die VMs in der VB nicht mehr starten.
Noch zwei, drei Möglichkeiten woran es evtl. liegen könnte:
- falsch gesetzte Rechte irgendow in der VB-Instalaltion - eine fehlerhafte VB-Installation oder aber - VirtualBox stört sich am geladenen KVM-Kernel-Modul
Letzteres ist mir gerade passiert. Wollte eine VB-VM starten um darin kurz was nachzusehen. Und dann ist genau das passiert:
VM Name: Disinfec't
VirtualBox can't enable the AMD-V extension. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_SVM_IN_USE). Result Code: NS_ERROR_FAILURE (0x80004005) Component: ConsoleWrap Interface: IConsole {6ac83d89-6ee7-4e33-8ae6-b257b2e81be8}
Wenn ich mit 'modprobe -r kvm_amd' das Modul entlade (kvm wird automatisch mit entladen) starten die VMs wieder. Hallo Richard,
KVM habe ich nicht, es ist allerdings ein Paket namens "system-group-kvm" installiert. lsmod | grep -i kvm zeigt auch nichts an. Meine Fehlermeldung ist etwas anders: The virtual machine 'Windows_10_Pro_64' has terminated unexpectedly during startup because of signal 11.
Am Sonntag, 8. Dezember 2024, 16:28:41 CET schrieb Richard Kraut:
Am Sonntag, dem 08.12.2024 um 16:14 +0100 schrieb Herbert Albert:
<...snip...>
keine Fehlermeldung
Startet es dann?
Gast startet nicht
Hast Du auch das Erweiterungspakt passend zu Deiner VirtualBox-Version installiert?
Wenn ich selbiges bei mir entferne, möchten auch die VMs in der VB nicht mehr starten. Ja, war installiert. Ich habe im Moment beide drin. Wird aber automatisch das richtige aktiviert, zumindest zeigt die GUI das so an.
Hallo, ich hänge mich mal mit rein. am Sonntag, 8. Dezember 2024, 16:14:41 CET schrieb Herbert Albert: snip
ohne vorherigen reboot in der konsole
kann man machen, der Reboot wäre sicherer gewesen.
~> VirtualBox GUI startet ohne Fehlermeldung. Sobald ich einen Gast starten will kommt die altbekannte Fehlermeldung:
VM Name: Windows_10_Pro_64
The virtual machine 'Windows_10_Pro_64' has terminated unexpectedly during startup because of signal 11. Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {e36a5081-a82a-40bd-9e4e-42a44d6ce50f}
Dein Problem ist nicht VirtualBox, sondern das Gastsystem, also dein Win10- System. Prüfe mal die Konfiguration der virtuellen Win10-Maschine. Findet VBox alle notwendigen Dateien? Hast du schon mal bei der Suchmaschine deines Vertrauens nach der Fehlermeldung NS_ERROR_FAILURE gesucht? Kannst du mit dem laufenden VBox 7.1.4 eine neue virtuelle Maschine mit z.B. einem Ubuntu oder sonst irgendeinem Linux einrichten? Läuft dann der Gast? Kannst du eventl. nochmal eine Win10-Maschine einrichten und läuft diese dann? -- Mit freundlichen Grüßen Matthias Müller Diese Mail ist mit OpenPGP signiert! Zum überprüfen der Signatur, der Integrität und Authentizität meiner Mails kann man OpenPGP (https://www.openpgp.org/) installieren. Bitte senden Sie als Antwort auf meine E-Mails reine Text-Nachrichten!
Am Sonntag, 8. Dezember 2024, 17:44:08 CET schrieb Matthias Müller:
Hallo,
ich hänge mich mal mit rein.
am Sonntag, 8. Dezember 2024, 16:14:41 CET schrieb Herbert Albert: snip
ohne vorherigen reboot in der konsole
kann man machen, der Reboot wäre sicherer gewesen.
~> VirtualBox GUI startet ohne Fehlermeldung. Sobald ich einen Gast starten will kommt die altbekannte Fehlermeldung:
VM Name: Windows_10_Pro_64
The virtual machine 'Windows_10_Pro_64' has terminated unexpectedly during startup because of signal 11. Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {e36a5081-a82a-40bd-9e4e-42a44d6ce50f}
Dein Problem ist nicht VirtualBox, sondern das Gastsystem, also dein Win10- System.
das war nur ein Beispiel, die Meldung kommt bei allen meiner Gastsysteme.
Prüfe mal die Konfiguration der virtuellen Win10-Maschine. Findet VBox alle notwendigen Dateien?
Hast du schon mal bei der Suchmaschine deines Vertrauens nach der Fehlermeldung NS_ERROR_FAILURE gesucht?
habe ich, doch keine Lösung gefunden.
Kannst du mit dem laufenden VBox 7.1.4 eine neue virtuelle Maschine mit z.B. einem Ubuntu oder sonst irgendeinem Linux einrichten? Läuft dann der Gast?
Kannst du eventl. nochmal eine Win10-Maschine einrichten und läuft diese dann?
Ich glaube das ist die falsche Richtung, da ja mit der Vorgängerversion alles prima läuft.
Am Sonntag, 8. Dezember 2024, 17:58:35 CET schrieb Herbert Albert:
Am Sonntag, 8. Dezember 2024, 17:44:08 CET schrieb Matthias Müller:
Hallo,
ich hänge mich mal mit rein.
am Sonntag, 8. Dezember 2024, 16:14:41 CET schrieb Herbert Albert: snip
ohne vorherigen reboot in der konsole
kann man machen, der Reboot wäre sicherer gewesen.
~> VirtualBox GUI startet ohne Fehlermeldung. Sobald ich einen Gast starten will kommt die altbekannte Fehlermeldung:
VM Name: Windows_10_Pro_64
The virtual machine 'Windows_10_Pro_64' has terminated unexpectedly during startup because of signal 11. Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {e36a5081-a82a-40bd-9e4e-42a44d6ce50f}
Dein Problem ist nicht VirtualBox, sondern das Gastsystem, also dein Win10- System.
das war nur ein Beispiel, die Meldung kommt bei allen meiner Gastsysteme.
Prüfe mal die Konfiguration der virtuellen Win10-Maschine. Findet VBox alle notwendigen Dateien?
Hast du schon mal bei der Suchmaschine deines Vertrauens nach der Fehlermeldung NS_ERROR_FAILURE gesucht?
habe ich, doch keine Lösung gefunden.
Kannst du mit dem laufenden VBox 7.1.4 eine neue virtuelle Maschine mit z.B. einem Ubuntu oder sonst irgendeinem Linux einrichten? Läuft dann der Gast?
Kannst du eventl. nochmal eine Win10-Maschine einrichten und läuft diese dann?
Ich glaube das ist die falsche Richtung, da ja mit der Vorgängerversion alles prima läuft.
Ich hoffe du hast noch nicht wieder die alte Version installiert....... Poste Mal: VBoxManage list extpacks Stephan
Nein, Du hast ja gesagt ich soll warten. Am 8. Dezember 2024 18:20:47 MEZ schrieb Stephan Hemeier <Sauerlandlinux@gmx.de>:
Am Sonntag, 8. Dezember 2024, 17:58:35 CET schrieb Herbert Albert:
Am Sonntag, 8. Dezember 2024, 17:44:08 CET schrieb Matthias Müller:
Hallo,
ich hänge mich mal mit rein.
am Sonntag, 8. Dezember 2024, 16:14:41 CET schrieb Herbert Albert: snip
ohne vorherigen reboot in der konsole
kann man machen, der Reboot wäre sicherer gewesen.
~> VirtualBox GUI startet ohne Fehlermeldung. Sobald ich einen Gast starten will kommt die altbekannte Fehlermeldung:
VM Name: Windows_10_Pro_64
The virtual machine 'Windows_10_Pro_64' has terminated unexpectedly during startup because of signal 11. Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {e36a5081-a82a-40bd-9e4e-42a44d6ce50f}
Dein Problem ist nicht VirtualBox, sondern das Gastsystem, also dein Win10- System.
das war nur ein Beispiel, die Meldung kommt bei allen meiner Gastsysteme.
Prüfe mal die Konfiguration der virtuellen Win10-Maschine. Findet VBox alle notwendigen Dateien?
Hast du schon mal bei der Suchmaschine deines Vertrauens nach der Fehlermeldung NS_ERROR_FAILURE gesucht?
habe ich, doch keine Lösung gefunden.
Kannst du mit dem laufenden VBox 7.1.4 eine neue virtuelle Maschine mit z.B. einem Ubuntu oder sonst irgendeinem Linux einrichten? Läuft dann der Gast?
Kannst du eventl. nochmal eine Win10-Maschine einrichten und läuft diese dann?
Ich glaube das ist die falsche Richtung, da ja mit der Vorgängerversion alles prima läuft.
Ich hoffe du hast noch nicht wieder die alte Version installiert.......
Poste Mal:
VBoxManage list extpacks
Stephan
Hallo, am Sonntag, 8. Dezember 2024, 18:36:57 CET schrieb Herbert Albert:
Nein, Du hast ja gesagt ich soll warten. snip
Am 8. Dezember 2024 18:20:47 MEZ schrieb Stephan Hemeier
snip
Poste Mal:
VBoxManage list extpacks
Stephan Nach allem was ich so gelesen habe läuft es auf ein Problem mit den Extensionpack raus.
Mach mal den Post, den Stephan angefragt hat. -- Mit freundlichen Grüßen Matthias Müller Diese Mail ist mit OpenPGP signiert! Zum überprüfen der Signatur, der Integrität und Authentizität meiner Mails kann man OpenPGP (https://www.openpgp.org/) installieren. Bitte senden Sie als Antwort auf meine E-Mails reine Text-Nachrichten!
Am Sonntag, 8. Dezember 2024, 19:02:17 CET schrieb Matthias Müller:
Hallo,
am Sonntag, 8. Dezember 2024, 18:36:57 CET schrieb Herbert Albert:
Nein, Du hast ja gesagt ich soll warten.
snip
Am 8. Dezember 2024 18:20:47 MEZ schrieb Stephan Hemeier
snip
Poste Mal:
VBoxManage list extpacks
Stephan
Nach allem was ich so gelesen habe läuft es auf ein Problem mit den Extensionpack raus.
Mach mal den Post, den Stephan angefragt hat. habe ich glatt überlesen.
:~> VBoxManage list extpacks Extension Packs: 1 Pack no. 0: Oracle VirtualBox Extension Pack Version: 7.1.4 Revision: 165100 Edition: Description: Oracle Cloud Infrastructure integration, Host Webcam, VirtualBox RDP, PXE ROM, Disk Encryption, NVMe, full VM encryption. VRDE Module: VBoxVRDP Crypto Module: VBoxPuelCrypto Usable: true Why unusable: :~> VBoxManage --version 7.1.4_SUSEr165100
Am Sonntag, 8. Dezember 2024, 19:16:55 CET schrieb Herbert Albert:
habe ich glatt überlesen.
:~> VBoxManage list extpacks Extension Packs: 1 Pack no. 0: Oracle VirtualBox Extension Pack Version: 7.1.4 Revision: 165100 Edition: Description: Oracle Cloud Infrastructure integration, Host Webcam, VirtualBox RDP, PXE ROM, Disk Encryption, NVMe, full VM encryption. VRDE Module: VBoxVRDP Crypto Module: VBoxPuelCrypto Usable: true Why unusable:
:~> VBoxManage --version 7.1.4_SUSEr165100 Hast du ein log in deinem /home?
Poste mal den Link der entsteht: cat ~/.config/VirtualBox/VBoxSVC.log | susepaste -e 130000
Am Sonntag, 8. Dezember 2024, 20:33:39 CET schrieb Stephan Hemeier:
Am Sonntag, 8. Dezember 2024, 19:16:55 CET schrieb Herbert Albert:
habe ich glatt überlesen.
:~> VBoxManage list extpacks
Extension Packs: 1 Pack no. 0: Oracle VirtualBox Extension Pack Version: 7.1.4 Revision: 165100 Edition: Description: Oracle Cloud Infrastructure integration, Host Webcam, VirtualBox RDP, PXE ROM, Disk Encryption, NVMe, full VM encryption. VRDE Module: VBoxVRDP Crypto Module: VBoxPuelCrypto Usable: true
Why unusable: :~> VBoxManage --version
7.1.4_SUSEr165100
Hast du ein log in deinem /home?
Poste mal den Link der entsteht: cat ~/.config/VirtualBox/VBoxSVC.log | susepaste -e 130000 die log Datei liegt bei mir wo anderes.
:~> cat ~/.VirtualBox/VBoxSVC.log | susepaste -e 130000 Pasted as: https://susepaste.org/86d35e44187d https://paste.opensuse.org/86d35e44187d Link is also in your clipboard.
Am Sonntag, 8. Dezember 2024, 20:47:00 CET schrieb Herbert Albert:
Am Sonntag, 8. Dezember 2024, 20:33:39 CET schrieb Stephan Hemeier:
Am Sonntag, 8. Dezember 2024, 19:16:55 CET schrieb Herbert Albert:
habe ich glatt überlesen.
:~> VBoxManage list extpacks
Extension Packs: 1 Pack no. 0: Oracle VirtualBox Extension Pack Version: 7.1.4 Revision: 165100 Edition: Description: Oracle Cloud Infrastructure integration, Host Webcam, VirtualBox RDP, PXE ROM, Disk Encryption, NVMe, full VM encryption. VRDE Module: VBoxVRDP Crypto Module: VBoxPuelCrypto Usable: true
Why unusable: :~> VBoxManage --version
7.1.4_SUSEr165100
Hast du ein log in deinem /home?
Poste mal den Link der entsteht: cat ~/.config/VirtualBox/VBoxSVC.log | susepaste -e 130000 die log Datei liegt bei mir wo anderes.
:~> cat ~/.VirtualBox/VBoxSVC.log | susepaste -e 130000 Pasted as: https://susepaste.org/86d35e44187d https://paste.opensuse.org/86d35e44187d Link is also in your clipboard.
Hast du da einen Sicherungspunkt (Schnappschuss )von dieser Windows Maschine gemacht?
Am Sonntag, 8. Dezember 2024, 21:24:29 CET schrieb Stephan Hemeier:
Am Sonntag, 8. Dezember 2024, 20:47:00 CET schrieb Herbert Albert:
Am Sonntag, 8. Dezember 2024, 20:33:39 CET schrieb Stephan Hemeier:
Am Sonntag, 8. Dezember 2024, 19:16:55 CET schrieb Herbert Albert:
habe ich glatt überlesen.
:~> VBoxManage list extpacks
Extension Packs: 1 Pack no. 0: Oracle VirtualBox Extension Pack Version: 7.1.4 Revision: 165100 Edition: Description: Oracle Cloud Infrastructure integration, Host Webcam, VirtualBox RDP, PXE ROM, Disk Encryption, NVMe, full VM encryption. VRDE Module: VBoxVRDP Crypto Module: VBoxPuelCrypto Usable: true
Why unusable: :~> VBoxManage --version
7.1.4_SUSEr165100
Hast du ein log in deinem /home?
Poste mal den Link der entsteht: cat ~/.config/VirtualBox/VBoxSVC.log | susepaste -e 130000
die log Datei liegt bei mir wo anderes.
:~> cat ~/.VirtualBox/VBoxSVC.log | susepaste -e 130000
Pasted as: https://susepaste.org/86d35e44187d https://paste.opensuse.org/86d35e44187d
Link is also in your clipboard.
Hast du da einen Sicherungspunkt (Schnappschuss )von dieser Windows Maschine gemacht? nein, ich sichere immer die ova weg (Appliance exportieren). Wie gesagt, der Fehler kommt bei allen Gast VM u.a. auch ein Linux.
Am Sonntag, 8. Dezember 2024, 22:11:25 CET schrieb Stephan Hemeier:
Am Sonntag, 8. Dezember 2024, 21:43:20 CET schrieb Herbert Albert:
nein, ich sichere immer die ova weg (Appliance exportieren). Wie gesagt, der Fehler kommt bei allen Gast VM u.a. auch ein Linux.
Kannst du eine neue VM erstellen?
Bis morgen denn. Hallo Stephan,
habe gerade versucht eine VM mit OS leap 15.6 zu erstellen. Geht nicht, sobald ich in der GUI auf Starten drücke - hier sollte der eigentliche Einrichtungsprozess vom eingehängten ISO-Image beginnen - erscheint: VM Name: Test Linux The virtual machine 'Test Linux' has terminated unexpectedly during startup because of signal 11. Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {e36a5081-a82a-40bd-9e4e-42a44d6ce50f} Schau auch mal hier: :~> cat ~/.VirtualBox/selectorwindow.log | susepaste -e 130000 Pasted as: https://susepaste.org/e3422257cb97 https://paste.opensuse.org/e3422257cb97 Link is also in your clipboard. Gruß Herbert
Am Montag, 9. Dezember 2024, 11:24:06 CET schrieb Herbert Albert:
Am Sonntag, 8. Dezember 2024, 22:11:25 CET schrieb Stephan Hemeier:
Am Sonntag, 8. Dezember 2024, 21:43:20 CET schrieb Herbert Albert:
nein, ich sichere immer die ova weg (Appliance exportieren). Wie gesagt, der Fehler kommt bei allen Gast VM u.a. auch ein Linux.
Kannst du eine neue VM erstellen?
Bis morgen denn.
Hallo Stephan,
habe gerade versucht eine VM mit OS leap 15.6 zu erstellen. Geht nicht, sobald ich in der GUI auf Starten drücke - hier sollte der eigentliche Einrichtungsprozess vom eingehängten ISO-Image beginnen - erscheint: VM Name: Test Linux
The virtual machine 'Test Linux' has terminated unexpectedly during startup because of signal 11. Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {e36a5081-a82a-40bd-9e4e-42a44d6ce50f}
Schau auch mal hier: :~> cat ~/.VirtualBox/selectorwindow.log | susepaste -e 130000
Pasted as: https://susepaste.org/e3422257cb97 https://paste.opensuse.org/e3422257cb97 Link is also in your clipboard.
Gruß
Herbert vielleicht noch die Info. Nach dem Neustart sagt mir wodan2:~ # systemctl status vboxdrv.service ● vboxdrv.service - VirtualBox Linux kernel module Loaded: loaded (/usr/lib/virtualbox/vboxdrv.sh; disabled; preset: disabled) Active: active (exited) since Mon 2024-12-09 11:30:07 CET; 1min 10s ago Process: 1090 ExecStart=/usr/lib/virtualbox/vboxdrv.sh start (code=exited, status=0/SUCCESS) CPU: 262ms
Dec 09 11:30:07 wodan2 systemd[1]: Starting VirtualBox Linux kernel module... Dec 09 11:30:07 wodan2 vboxdrv.sh[1090]: vboxdrv.sh: Starting VirtualBox services. Dec 09 11:30:07 wodan2 vboxdrv.sh[1204]: Starting VirtualBox services. Dec 09 11:30:07 wodan2 vboxdrv.sh[1323]: VirtualBox services started. Dec 09 11:30:07 wodan2 systemd[1]: Started VirtualBox Linux kernel module. D. h. /usr/lib/virtualbox/vboxdrv.sh wird nicht oder kann nicht geladen werden, oder interpretiere ich das falsch? Und vboxdrv.sh ist aus dem Paket virtualbox-7.1.4-lp156.2.4.1.x86_64 Gruß Herbert
Am Montag, 9. Dezember 2024, 12:45:31 CET schrieb Herbert Albert:
vielleicht noch die Info. Nach dem Neustart sagt mir wodan2:~ # systemctl status vboxdrv.service ● vboxdrv.service - VirtualBox Linux kernel module Loaded: loaded (/usr/lib/virtualbox/vboxdrv.sh; disabled; preset: disabled) Active: active (exited) since Mon 2024-12-09 11:30:07 CET; 1min 10s ago Process: 1090 ExecStart=/usr/lib/virtualbox/vboxdrv.sh start (code=exited, status=0/SUCCESS) CPU: 262ms
Dec 09 11:30:07 wodan2 systemd[1]: Starting VirtualBox Linux kernel module... Dec 09 11:30:07 wodan2 vboxdrv.sh[1090]: vboxdrv.sh: Starting VirtualBox services. Dec 09 11:30:07 wodan2 vboxdrv.sh[1204]: Starting VirtualBox services. Dec 09 11:30:07 wodan2 vboxdrv.sh[1323]: VirtualBox services started. Dec 09 11:30:07 wodan2 systemd[1]: Started VirtualBox Linux kernel module.
D. h. /usr/lib/virtualbox/vboxdrv.sh wird nicht oder kann nicht geladen werden, oder interpretiere ich das falsch? Und vboxdrv.sh ist aus dem Paket virtualbox-7.1.4-lp156.2.4.1.x86_64
Gruß
Herbert
Alles gut. Kannst du mal Diese Befehle ausführen: sudo ln -s /lib64/libpthread.so.0 /usr/lib/virtualbox/libpthread.so sudo ln -s /lib64/libdl.so.2 /usr/lib/virtualbox/libdl.so Neu starten und ausprobieren. Stephan
Am Montag, 9. Dezember 2024, 13:44:08 CET schrieb Stephan Hemeier:
Am Montag, 9. Dezember 2024, 12:45:31 CET schrieb Herbert Albert:
vielleicht noch die Info. Nach dem Neustart sagt mir wodan2:~ # systemctl status vboxdrv.service ● vboxdrv.service - VirtualBox Linux kernel module
Loaded: loaded (/usr/lib/virtualbox/vboxdrv.sh; disabled; preset: disabled)
Active: active (exited) since Mon 2024-12-09 11:30:07 CET; 1min 10s ago
Process: 1090 ExecStart=/usr/lib/virtualbox/vboxdrv.sh start (code=exited,
status=0/SUCCESS)
CPU: 262ms
Dec 09 11:30:07 wodan2 systemd[1]: Starting VirtualBox Linux kernel module... Dec 09 11:30:07 wodan2 vboxdrv.sh[1090]: vboxdrv.sh: Starting VirtualBox services. Dec 09 11:30:07 wodan2 vboxdrv.sh[1204]: Starting VirtualBox services. Dec 09 11:30:07 wodan2 vboxdrv.sh[1323]: VirtualBox services started. Dec 09 11:30:07 wodan2 systemd[1]: Started VirtualBox Linux kernel module.
D. h. /usr/lib/virtualbox/vboxdrv.sh wird nicht oder kann nicht geladen werden, oder interpretiere ich das falsch? Und vboxdrv.sh ist aus dem Paket virtualbox-7.1.4-lp156.2.4.1.x86_64
Gruß
Herbert
Alles gut.
Kannst du mal Diese Befehle ausführen:
sudo ln -s /lib64/libpthread.so.0 /usr/lib/virtualbox/libpthread.so sudo ln -s /lib64/libdl.so.2 /usr/lib/virtualbox/libdl.so
Neu starten und ausprobieren.
Stephan Hallo Stephan,
damit läuft die VM. Warum findet bei mir VBox die libs nicht und bei euch schon? Gruß Herbert
Am Montag, 9. Dezember 2024, 14:06:30 CET schrieb Herbert Albert:
Am Montag, 9. Dezember 2024, 13:44:08 CET schrieb Stephan Hemeier:
Am Montag, 9. Dezember 2024, 12:45:31 CET schrieb Herbert Albert:
vielleicht noch die Info. Nach dem Neustart sagt mir wodan2:~ # systemctl status vboxdrv.service ● vboxdrv.service - VirtualBox Linux kernel module
Loaded: loaded (/usr/lib/virtualbox/vboxdrv.sh; disabled; preset: disabled)
Active: active (exited) since Mon 2024-12-09 11:30:07 CET; 1min 10s ago
Process: 1090 ExecStart=/usr/lib/virtualbox/vboxdrv.sh start (code=exited,
status=0/SUCCESS)
CPU: 262ms
Dec 09 11:30:07 wodan2 systemd[1]: Starting VirtualBox Linux kernel module... Dec 09 11:30:07 wodan2 vboxdrv.sh[1090]: vboxdrv.sh: Starting VirtualBox services. Dec 09 11:30:07 wodan2 vboxdrv.sh[1204]: Starting VirtualBox services. Dec 09 11:30:07 wodan2 vboxdrv.sh[1323]: VirtualBox services started. Dec 09 11:30:07 wodan2 systemd[1]: Started VirtualBox Linux kernel module.
D. h. /usr/lib/virtualbox/vboxdrv.sh wird nicht oder kann nicht geladen werden, oder interpretiere ich das falsch? Und vboxdrv.sh ist aus dem Paket virtualbox-7.1.4-lp156.2.4.1.x86_64
Gruß
Herbert
Alles gut.
Kannst du mal Diese Befehle ausführen:
sudo ln -s /lib64/libpthread.so.0 /usr/lib/virtualbox/libpthread.so sudo ln -s /lib64/libdl.so.2 /usr/lib/virtualbox/libdl.so
Neu starten und ausprobieren.
Stephan
Hallo Stephan,
damit läuft die VM. Warum findet bei mir VBox die libs nicht und bei euch schon?
Gruß
Herbert ok, diesen fix habe ich nun auch hier gefunden: https://forums.virtualbox.org/viewtopic.php?t=112370
Nur was ist, wenn das nächste Update von glibc oder virtualbox kommt?
Am Montag, 9. Dezember 2024, 15:23:22 CET schrieb Herbert Albert:
ok, diesen fix habe ich nun auch hier gefunden: https://forums.virtualbox.org/viewtopic.php?t=112370
Nur was ist, wenn das nächste Update von glibc oder virtualbox kommt?
Ich schätze mal nichts..... Da ja nur symbolische Verknüpfungen. Stephan
Herbert Albert schrieb:
Hast du ein log in deinem /home?
Poste mal den Link der entsteht: cat ~/.config/VirtualBox/VBoxSVC.log | susepaste -e 130000 die log Datei liegt bei mir wo anderes.
:~> cat ~/.VirtualBox/VBoxSVC.log | susepaste -e 130000 Pasted as: https://susepaste.org/86d35e44187d https://paste.opensuse.org/86d35e44187d Link is also in your clipboard.
Das scheint mir die entscheidende Meldung zu sein: 00:00:00.021959 DCon01 rtldrNativeLoad: dlopen('/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/VBoxPuelMain.so', RTLD_NOW | RTLD_LOCAL) failed: /usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/VBoxPuelMain.so: undefined symbol: _ZNK9RTCString10startsWithERKS_NS_15CaseSensitivityE Ein unauflösbares Symbol bei dlopen() darf eigentlich nicht passieren. Woher auch immer dieser Fehler kommt, dazu kenne ich VirtualBox zu wenig. Aber der Fehler wird hier beschrieben, mit (seltsamen) Workarounds (System-Libraries auf das Virtualbox-Directory versoftlinken, da bringt wohl Virtualbox zuviele Libraries mit und die dann noch in falschen Versionen): https://forums.virtualbox.org/viewtopic.php?t=112370 Vielleicht hilft das ja. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am Mittwoch, 4. Dezember 2024, 15:58:54 CET schrieb Herbert Albert:
Am Mittwoch, 4. Dezember 2024, 12:08:47 CET schrieb Herbert Albert:
Am Mittwoch, 4. Dezember 2024, 12:00:44 CET schrieb Michael Behrens:
Zu Virtualbox kann ich noch nichts sagen, ich habe das Upgrade bisher nur einer Virtualbox-VM versucht...
Aber du solltest vielleicht generell mal nachsehen, ob 'verwaiste Pakete' installiert sind - da ist dann vielleicht-bestimmt virtualbox-kmp-default auch dabei. Hier waren es einige.
Auf shell-Ebene nachsehen: zypper packages --orphaned
Oder in Yast2 mit "Anzeigen|Paket-Klassifikation|verwaiste Pakete", da kann man sie dann auch gleich deinstallieren.
Am 04.12.24 um 11:44 schrieb Herbert Albert: ....
habe gerade gesehen, dass noch alte virtualbox-kmp-default installiert sind. Kann ich die löschen? ...
Da zeigt mir Yast einen lange Liste, aber virtualbox ist nicht dabei. Die beiden virtualbox-kmp-default 7.0.14 und 7.0.18 habe ich mittlerweile in Yast gelöscht.
ich bin nun per Yast auf die Version 7.0.18-lp156.1.6 zurück und dann als root
systemctl stop vboxdrv.service /usr/sbin/vboxconfig systemctl start vboxdrv.service
und in der VirtualBox GUI das Extension-Pack 7.0.18 installiert.
Damit geht es. Aber warum hakt es mit der Version 7.1.14?
Hat die jemand hier mit dem aktuellen leap 15.6 und Kernel *#* uname -r 6.4.0-150600.23.25-default
VirtualBox 7.1.14 aus dem OS Repo am Laufen?
Ich habe das gleiche Problem und es ebenso wie du "gelöst". -- Keinem vernünftigen Menschen wird es einfallen, Tintenflecken mit Tinte, Ölflecken mit Öl wegwaschen zu wollen. Nur Blut soll immer wieder mit Blut abgewaschen werden. (Bertha von Suttner)
participants (8)
-
Herbert Albert -
Manfred Haertel, DB3HM -
mark.wenzel＠gmx.net -
Matthias Müller -
Michael Behrens -
Richard Kraut -
Stephan Hemeier -
Ulrich Walter