[opensuse-kernel] wrong version for update virtualbox-host-kmp-deskltop
Four days ago there was a kernel update for 13.2. In the update the packages virtualbox-{guest,host}-kmp-<flavor> were missing. Today virtualbox was updated as well, but the version is wrong. The last kernel version is 3.16.7-24.1. The version for the virtualbox-{guest,host}-kmp-<flavor> update should be 4.3.30_k3.16.7_24-17.1 but instead it is 4.3.30_k3.16.7_21-17.1 (incompatible with kernel 3.16.7-24.1). Giacomo -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 08/18/2015, 03:39 PM, Giacomo Comes wrote:
Four days ago there was a kernel update for 13.2. In the update the packages virtualbox-{guest,host}-kmp-<flavor> were missing. Today virtualbox was updated as well, but the version is wrong. The last kernel version is 3.16.7-24.1. The version for the virtualbox-{guest,host}-kmp-<flavor> update should be 4.3.30_k3.16.7_24-17.1 but instead it is 4.3.30_k3.16.7_21-17.1 (incompatible with kernel 3.16.7-24.1).
What do you mean by incompatible? The kernel has a frozen kABI, so no rebuilds of KMPs should be needed. -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
This was already discussed. See this thread: http://lists.opensuse.org/opensuse-kernel/2014-12/msg00064.html A simple check is to install the last kernel 3.16.7-24.1, install virtualbox-host-kmp-desktop and run: rpm -e --test kernel-desktop-3.16.7-21.1 there will be a dependency failure. Giacomo On Tue, Aug 18, 2015 at 04:10:35PM +0200, Jiri Slaby wrote:
On 08/18/2015, 03:39 PM, Giacomo Comes wrote:
Four days ago there was a kernel update for 13.2. In the update the packages virtualbox-{guest,host}-kmp-<flavor> were missing. Today virtualbox was updated as well, but the version is wrong. The last kernel version is 3.16.7-24.1. The version for the virtualbox-{guest,host}-kmp-<flavor> update should be 4.3.30_k3.16.7_24-17.1 but instead it is 4.3.30_k3.16.7_21-17.1 (incompatible with kernel 3.16.7-24.1).
What do you mean by incompatible? The kernel has a frozen kABI, so no rebuilds of KMPs should be needed.
-- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 08/18/2015, 04:36 PM, Giacomo Comes wrote:
This was already discussed. See this thread: http://lists.opensuse.org/opensuse-kernel/2014-12/msg00064.html
A simple check is to install the last kernel 3.16.7-24.1, install virtualbox-host-kmp-desktop and run: rpm -e --test kernel-desktop-3.16.7-21.1
there will be a dependency failure.
Ok, what failure? -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi everyone, jumping in here because I feel affected ..... Am 18.08.2015 um 16:56 schrieb Jiri Slaby:
On 08/18/2015, 04:36 PM, Giacomo Comes wrote:
This was already discussed. See this thread: http://lists.opensuse.org/opensuse-kernel/2014-12/msg00064.html
A simple check is to install the last kernel 3.16.7-24.1, install virtualbox-host-kmp-desktop and run: rpm -e --test kernel-desktop-3.16.7-21.1
there will be a dependency failure.
Ok, what failure?
A quick look at the dependencies of *any* -kmp package reveals: Depends: kernel-uname-r = 3.16.7-21-desktop So whenever the kernel package is updated, the -kmp ones need to be rebuilt. Apparently the virtualbox -kmp packages were built before 3.16.7-24 was published to the repos ...... br Josua Mayer -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tue, 18 Aug 2015 17:05:48 +0200, Josua Mayer wrote:
Hi everyone,
jumping in here because I feel affected .....
Am 18.08.2015 um 16:56 schrieb Jiri Slaby:
On 08/18/2015, 04:36 PM, Giacomo Comes wrote:
This was already discussed. See this thread: http://lists.opensuse.org/opensuse-kernel/2014-12/msg00064.html
A simple check is to install the last kernel 3.16.7-24.1, install virtualbox-host-kmp-desktop and run: rpm -e --test kernel-desktop-3.16.7-21.1
there will be a dependency failure.
Ok, what failure?
A quick look at the dependencies of *any* -kmp package reveals: Depends: kernel-uname-r = 3.16.7-21-desktop
So whenever the kernel package is updated, the -kmp ones need to be rebuilt. Apparently the virtualbox -kmp packages were built before 3.16.7-24 was published to the repos ......
Oh yeah, we had the very same problem at the previous kernel update, too. IIRC, we need to do submitreq for the affected KMPs to just to rebuild. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Отправлено с iPhone
18 авг. 2015 г., в 18:54, Takashi Iwai <tiwai@suse.de> написал(а):
On Tue, 18 Aug 2015 17:05:48 +0200, Josua Mayer wrote:
Hi everyone,
jumping in here because I feel affected .....
Am 18.08.2015 um 16:56 schrieb Jiri Slaby:
On 08/18/2015, 04:36 PM, Giacomo Comes wrote: This was already discussed. See this thread: http://lists.opensuse.org/opensuse-kernel/2014-12/msg00064.html
A simple check is to install the last kernel 3.16.7-24.1, install virtualbox-host-kmp-desktop and run: rpm -e --test kernel-desktop-3.16.7-21.1
there will be a dependency failure.
Ok, what failure? A quick look at the dependencies of *any* -kmp package reveals: Depends: kernel-uname-r = 3.16.7-21-desktop
So whenever the kernel package is updated, the -kmp ones need to be rebuilt. Apparently the virtualbox -kmp packages were built before 3.16.7-24 was published to the repos ......
Oh yeah, we had the very same problem at the previous kernel update, too. IIRC, we need to do submitreq for the affected KMPs to just to rebuialso
If we guarantee kABI stability, why cannot kmp require kernel version >= build version?-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tue, 18 Aug 2015 18:05:04 +0200, Andrei Borzenkov wrote:
Отправлено с iPhone
18 авг. 2015 г., в 18:54, Takashi Iwai <tiwai@suse.de> написал(а):
On Tue, 18 Aug 2015 17:05:48 +0200, Josua Mayer wrote:
Hi everyone,
jumping in here because I feel affected .....
Am 18.08.2015 um 16:56 schrieb Jiri Slaby:
On 08/18/2015, 04:36 PM, Giacomo Comes wrote: This was already discussed. See this thread: http://lists.opensuse.org/opensuse-kernel/2014-12/msg00064.html
A simple check is to install the last kernel 3.16.7-24.1, install virtualbox-host-kmp-desktop and run: rpm -e --test kernel-desktop-3.16.7-21.1
there will be a dependency failure.
Ok, what failure? A quick look at the dependencies of *any* -kmp package reveals: Depends: kernel-uname-r = 3.16.7-21-desktop
So whenever the kernel package is updated, the -kmp ones need to be rebuilt. Apparently the virtualbox -kmp packages were built before 3.16.7-24 was published to the repos ......
Oh yeah, we had the very same problem at the previous kernel update, too. IIRC, we need to do submitreq for the affected KMPs to just to rebuialso
If we guarantee kABI stability, why cannot kmp require kernel version >= build version?
I can we get rid of it now, but the old KMP has already the dependency, so it's no help at this time :) Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 08/18/2015, 06:09 PM, Takashi Iwai wrote:
If we guarantee kABI stability, why cannot kmp require kernel version >= build version?
I can we get rid of it now, but the old KMP has already the dependency, so it's no help at this time :)
And what about Provides? -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 08/18/2015 02:34 PM, Jiri Slaby wrote:
On 08/18/2015, 06:09 PM, Takashi Iwai wrote:
If we guarantee kABI stability, why cannot kmp require kernel version >= build version?
I can we get rid of it now, but the old KMP has already the dependency, so it's no help at this time :)
And what about Provides?
As maintainer of VirtualBox on openSUSE, I would like to know how to prevent this in the future. My understanding of the build process is rather rudimentary. Thanks, Larry -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2015-08-19 02:46, Larry Finger wrote:
On 08/18/2015 02:34 PM, Jiri Slaby wrote:
On 08/18/2015, 06:09 PM, Takashi Iwai wrote:
If we guarantee kABI stability, why cannot kmp require kernel version >= build version?
I can we get rid of it now, but the old KMP has already the dependency, so it's no help at this time :)
And what about Provides?
As maintainer of VirtualBox on openSUSE, I would like to know how to prevent this in the future. My understanding of the build process is rather rudimentary.
The "proper" fix would be to reintroduce the ksym() dependencies, i.e. make the KMPs depend on the kernel ABI checksums rather than the kernel release string. But this has been explicitly disabled by the maintainer of rpm, because results in too big package metadata. The second best thing is some check to ensure that each kernel update is accompanied by all openSUSE KMPs. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 08/19/2015, 12:29 PM, Michal Marek wrote:
As maintainer of VirtualBox on openSUSE, I would like to know how to prevent this in the future. My understanding of the build process is rather rudimentary.
The "proper" fix would be to reintroduce the ksym() dependencies, i.e. make the KMPs depend on the kernel ABI checksums rather than the kernel release string.
Which leads to another question: why do we still fight with kabi in opensuse when we don't leverage from that? Sidenote: if we don't use kabi, we can drop it and can update to higher major kernel versions easier, if needed (e.g. once, to the next longterm stable). thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2015-08-19 12:42, Jiri Slaby wrote:
On 08/19/2015, 12:29 PM, Michal Marek wrote:
As maintainer of VirtualBox on openSUSE, I would like to know how to prevent this in the future. My understanding of the build process is rather rudimentary.
The "proper" fix would be to reintroduce the ksym() dependencies, i.e. make the KMPs depend on the kernel ABI checksums rather than the kernel release string.
Which leads to another question: why do we still fight with kabi in opensuse when we don't leverage from that?
That's a good question. I personally do not think that it makes sense to keep the kabi in openSUSE. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 19 Aug 2015 12:47:16 +0200, Michal Marek wrote:
On 2015-08-19 12:42, Jiri Slaby wrote:
On 08/19/2015, 12:29 PM, Michal Marek wrote:
As maintainer of VirtualBox on openSUSE, I would like to know how to prevent this in the future. My understanding of the build process is rather rudimentary.
The "proper" fix would be to reintroduce the ksym() dependencies, i.e. make the KMPs depend on the kernel ABI checksums rather than the kernel release string.
Which leads to another question: why do we still fight with kabi in opensuse when we don't leverage from that?
That's a good question. I personally do not think that it makes sense to keep the kabi in openSUSE.
It makes our lives easier in one side, but also makes hard in another side. It means that we need to publish the kernel update and the updates of the all KMPs in a shot. Otherwise it'll break the system. And rpm / zypper doesn't detect it... (the update of kernel won't be blocked by the lack of KMP). Or was it already improved? Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2015-08-19 12:54, Takashi Iwai wrote:
On Wed, 19 Aug 2015 12:47:16 +0200, Michal Marek wrote:
On 2015-08-19 12:42, Jiri Slaby wrote:
On 08/19/2015, 12:29 PM, Michal Marek wrote:
As maintainer of VirtualBox on openSUSE, I would like to know how to prevent this in the future. My understanding of the build process is rather rudimentary.
The "proper" fix would be to reintroduce the ksym() dependencies, i.e. make the KMPs depend on the kernel ABI checksums rather than the kernel release string.
Which leads to another question: why do we still fight with kabi in opensuse when we don't leverage from that?
That's a good question. I personally do not think that it makes sense to keep the kabi in openSUSE.
It makes our lives easier in one side, but also makes hard in another side. It means that we need to publish the kernel update and the updates of the all KMPs in a shot. Otherwise it'll break the system.
To make it clear: Given the decision to drop ksym() dependencies, I do not think it makes sense to keep the kabi. I would of course prefer having the ksym() dependencies and maintaining the kabi.
And rpm / zypper doesn't detect it... (the update of kernel won't be blocked by the lack of KMP). Or was it already improved?
It does not detect it, because we enable multiversion for the kernel packages by default. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, Aug 19, 2015 at 12:42:31PM +0200, Jiri Slaby wrote:
On 08/19/2015, 12:29 PM, Michal Marek wrote:
As maintainer of VirtualBox on openSUSE, I would like to know how to prevent this in the future. My understanding of the build process is rather rudimentary.
The "proper" fix would be to reintroduce the ksym() dependencies, i.e. make the KMPs depend on the kernel ABI checksums rather than the kernel release string.
Which leads to another question: why do we still fight with kabi in opensuse when we don't leverage from that?
Sidenote: if we don't use kabi, we can drop it and can update to higher major kernel versions easier, if needed (e.g. once, to the next longterm stable).
FWIW, I update all KMPs with all 13.2 updates. This is a bit tedious. I did not include virtualbox, as we had a parallel upgrade of it in the queue. I however now started a virtualbox update which should be built against the current kernel. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/19/15 6:42 AM, Jiri Slaby wrote:
On 08/19/2015, 12:29 PM, Michal Marek wrote:
As maintainer of VirtualBox on openSUSE, I would like to know how to prevent this in the future. My understanding of the build process is rather rudimentary.
The "proper" fix would be to reintroduce the ksym() dependencies, i.e. make the KMPs depend on the kernel ABI checksums rather than the kernel release string.
Which leads to another question: why do we still fight with kabi in opensuse when we don't leverage from that?
Sidenote: if we don't use kabi, we can drop it and can update to higher major kernel versions easier, if needed (e.g. once, to the next longterm stable).
Isn't the major issue that widely-used third party modules like nvidia and fglrx would also need to be rebuilt? That's the biggest reason I always wanted to keep the kABI stable. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQIcBAEBAgAGBQJV1d26AAoJEB57S2MheeWyxlAQAKMfG5tq+pDnkRKsPowLYqtV OOCNJbm8miwDpBad8dsMytJ1BpSI1xXs6xQ4XvfiTB/MAv5frpftRWyAgRAB2bkB pULz0y0cz5eIvbNuEMnhM7xFvUp2aoqSu0iVr94pMS1Glv2pruBylJNQk1Ec3PX8 vrW0A3lHP7MkAUJTb7cLQniDpvrmAgbdEitIqmZPDTRXURbcu10nvGv3jYBQnqMy ffg6UOVGZAJO2om4hba9caYlIgCM3jkMw36tsRWumI09PzLtb/MlA1FneQexMvBX sGjPRbnnLDX5BMLEAW0cuDjCseOiiTTp033H4HPPS23FHljlkbfJ6T7G8SCEEiEq CeB+WaRtDBwQrapOMoLspSvcAW4/dhFy7RNcx5/Zt7SKdi/e2wDhgBLWwYWaYwwI LeFhrDN+QDRpLd3ShT9Ixc+My3YHMAiwrT3LLAG5cA5MuZnVi5+rBaAsM1nGcEm/ /QFCp/p2tFnvNnynJlUaI4Q/Ct2eMC5W5e66lK9sey3/KRCpNMjINfmYeQEnzWua 3S9CUrxObwoelR3mBOyGhGIAZrW5jhxKPUqDYKymVvk6ObXdXqsBrww8n77aE8la dNoh034vIgWdpLVt1dYJxDYp1ZsZ74HzKkwMdEYqxcupPr31h7t7lwuRTiZABSR8 B8x41lNBGUNeY1vgC3h3 =cr2s -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, 20 Aug 2015 16:01:30 +0200, Jeff Mahoney wrote:
On 8/19/15 6:42 AM, Jiri Slaby wrote:
On 08/19/2015, 12:29 PM, Michal Marek wrote:
As maintainer of VirtualBox on openSUSE, I would like to know how to prevent this in the future. My understanding of the build process is rather rudimentary.
The "proper" fix would be to reintroduce the ksym() dependencies, i.e. make the KMPs depend on the kernel ABI checksums rather than the kernel release string.
Which leads to another question: why do we still fight with kabi in opensuse when we don't leverage from that?
Sidenote: if we don't use kabi, we can drop it and can update to higher major kernel versions easier, if needed (e.g. once, to the next longterm stable).
Isn't the major issue that widely-used third party modules like nvidia and fglrx would also need to be rebuilt? That's the biggest reason I always wanted to keep the kABI stable.
Yes, they need rebuilds, but I don't think there would be any kABI checks. IIRC, they (both Nvidia and AMD) switched to a packaging way to compile the module at the package installation time instead of KMPs. But I myself haven't used them, so others can explain better. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/20/15 10:37 AM, Takashi Iwai wrote:
On Thu, 20 Aug 2015 16:01:30 +0200, Jeff Mahoney wrote:
On 8/19/15 6:42 AM, Jiri Slaby wrote:
On 08/19/2015, 12:29 PM, Michal Marek wrote:
As maintainer of VirtualBox on openSUSE, I would like to know how to prevent this in the future. My understanding of the build process is rather rudimentary.
The "proper" fix would be to reintroduce the ksym() dependencies, i.e. make the KMPs depend on the kernel ABI checksums rather than the kernel release string.
Which leads to another question: why do we still fight with kabi in opensuse when we don't leverage from that?
Sidenote: if we don't use kabi, we can drop it and can update to higher major kernel versions easier, if needed (e.g. once, to the next longterm stable).
Isn't the major issue that widely-used third party modules like nvidia and fglrx would also need to be rebuilt? That's the biggest reason I always wanted to keep the kABI stable.
Yes, they need rebuilds, but I don't think there would be any kABI checks. IIRC, they (both Nvidia and AMD) switched to a packaging way to compile the module at the package installation time instead of KMPs. But I myself haven't used them, so others can explain better.
Yeah, I'd appreciate an update on what the current state of those are. I don't use either of those modules either, but wanted to make sure we could present a path of least pain to users who do. If that's not working, I'd consider that a bug. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQIcBAEBAgAGBQJV1eaCAAoJEB57S2MheeWyTqkP/A7Y9/WTG4errJ1klvt7MwJ6 34EpbuKVjVkCxwkPoSSOBbxChc3ofZUZ8fDjnYbR5VLmd7VC7QS4HXPDb4h1Lcwe bD2OixcpHabQeQmwSnX+DhiGqBxXFyWPBueQwaYUTNdNrEANtz6Ne/iO1IvJ/zGY VongPdo3uEqFW9QGUoezcWRMEcT674igLO0BQxGMpHh/x4S4LS9WqBpJLszqKbwz ZUVJhlC8NGYzaPTaQFIfrCU34AlzTcHGPLaIEwx9IxXfCK8ufBxnZfKhJup4gmcT b7K1mH2tsrAUfhhM2srOJzxlQdffkwrjs4IZmfgoPtvaHqLCY0MKvSQOl5omQ3pB GQWSH23/MAnIsJf/bKWGLIStjPKNyd3cbNWeGrI7cLI0tfTPcxT5Mp8kTZd8vmGv YyiyOijTHgIz90EBgHRYQdICJgZaj2VXx7+w8mgH2pzGjNTnSRQNDPnCpd/bwrhf sZPpBn1d7qpFpCpVNCS//zhiW2vcj+6raabb03sNtv+Ja2vDZC7B7X2d53mP9HKI 01FNssWQNTM6fvlPIYH1H/fxJcJulLJTy0F5YQkRrdBPaxkFAJS7ERO38les8+r9 y/o0xg9Ifz5s98gE9PMR+WcNGCPVNQX48zE1Nyyuab3PTGHa5sntKYeW/grNyOur lrwUxKZ0LHufP0CD3M+H =EY/D -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, 20 Aug 2015 16:38:58 +0200, Jeff Mahoney wrote:
On 8/20/15 10:37 AM, Takashi Iwai wrote:
On Thu, 20 Aug 2015 16:01:30 +0200, Jeff Mahoney wrote:
On 8/19/15 6:42 AM, Jiri Slaby wrote:
On 08/19/2015, 12:29 PM, Michal Marek wrote:
As maintainer of VirtualBox on openSUSE, I would like to know how to prevent this in the future. My understanding of the build process is rather rudimentary.
The "proper" fix would be to reintroduce the ksym() dependencies, i.e. make the KMPs depend on the kernel ABI checksums rather than the kernel release string.
Which leads to another question: why do we still fight with kabi in opensuse when we don't leverage from that?
Sidenote: if we don't use kabi, we can drop it and can update to higher major kernel versions easier, if needed (e.g. once, to the next longterm stable).
Isn't the major issue that widely-used third party modules like nvidia and fglrx would also need to be rebuilt? That's the biggest reason I always wanted to keep the kABI stable.
Yes, they need rebuilds, but I don't think there would be any kABI checks. IIRC, they (both Nvidia and AMD) switched to a packaging way to compile the module at the package installation time instead of KMPs. But I myself haven't used them, so others can explain better.
Yeah, I'd appreciate an update on what the current state of those are. I don't use either of those modules either, but wanted to make sure we could present a path of least pain to users who do. If that's not working, I'd consider that a bug.
I asked Stefan (now Cc'ed) about this, and he explained that - - AMD should work as is, since it does check-and-rebuild modules at each reboot (by some init script-like voodoo) - Nvidia has a kind of fake KMP, and it may keep working as long as kABI is kept. The actual modules are built at KMP installation time, so it means kABI at the package installation time. The latter was the problem at the previous kernel update; we broke kABI, then user reinstalled Nvidia package to "fix". Soon after that, we re-release the kernel with kABI fix, then Nvidia for the users who updated got broke again... Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2015-08-20 16:52, Takashi Iwai wrote:
- Nvidia has a kind of fake KMP, and it may keep working as long as kABI is kept. The actual modules are built at KMP installation time, so it means kABI at the package installation time.
The latter was the problem at the previous kernel update; we broke kABI, then user reinstalled Nvidia package to "fix". Soon after that, we re-release the kernel with kABI fix, then Nvidia for the users who updated got broke again...
This sounds like a reason to keep the kabi even if we have this kernel-uname-r depedency. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/20/15 10:59 AM, Michal Marek wrote:
On 2015-08-20 16:52, Takashi Iwai wrote:
- Nvidia has a kind of fake KMP, and it may keep working as long as kABI is kept. The actual modules are built at KMP installation time, so it means kABI at the package installation time.
The latter was the problem at the previous kernel update; we broke kABI, then user reinstalled Nvidia package to "fix". Soon after that, we re-release the kernel with kABI fix, then Nvidia for the users who updated got broke again...
This sounds like a reason to keep the kabi even if we have this kernel-uname-r depedency.
Agreed. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQIcBAEBAgAGBQJV1e19AAoJEB57S2MheeWyuWQQAMNOIMCSf/oLd3AkO+3ovTai TVwFOh86aCaWJK5HcuFcQndWbU2ZMu9sEH6e0wouFL5E4zznvvT8HPvKatCULcJ7 K7ew0tyvTlKCwHYHXP09Q3WjaPh5hJ3KSjUXmasX4/yE0OxgQy4TRxdy19jTE5lN 3r4YmrVmcxpC5PumwdeRd29hklTNVVea37FFH2t/awzTeBU5nr8GrdkFuvbTWCFB JWFIQcubVIXMX+q8TQNraYuq6Dh93EDO1UohgoAUTQhSrAmgXDuwU/7IR38ERZVS fI3OMaaptDfpXWFyuUreswLm/58lz0Q4kb5UBADDD5ybVHxjCkvlDjs+0aGuqLuu pfSFoz6F6FBiwU4wfli+x8oWWfQhzxqs6CPHlefS8Ocjd9IC7fZrE9ig5GywRF2S GsajCEDoVyACnxGXzh05AmEd6dR4vd0g3Ou64Ai6bOmBtaXSzIeUCa95/pWi8c8A tovyi1iAjQbqtcouDZuwNZ201G6Nd4RNLZ/VfR2AYeZkcvp/OXBGmJjrSSaQjCCL OGMpuHWVQ6AMS6fTgT4Od95J68qjyx9KywZVuEolctcRn0gxQt6RHZphMqk/yEvd 1Z5+NG+/kLP9nb5H9YAm6IwAWNIImj8hTMbycq7bz8yCMF2LTrtgVcHKs8Gqr+SP QWFm5byqT4jRlcCoaavS =+yBQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, 20 Aug 2015 17:08:46 +0200, Jeff Mahoney wrote:
On 8/20/15 10:59 AM, Michal Marek wrote:
On 2015-08-20 16:52, Takashi Iwai wrote:
- Nvidia has a kind of fake KMP, and it may keep working as long as kABI is kept. The actual modules are built at KMP installation time, so it means kABI at the package installation time.
The latter was the problem at the previous kernel update; we broke kABI, then user reinstalled Nvidia package to "fix". Soon after that, we re-release the kernel with kABI fix, then Nvidia for the users who updated got broke again...
This sounds like a reason to keep the kabi even if we have this kernel-uname-r depedency.
Agreed.
I checked the update on KVM and at least the weak-updates survived for Nvidia modules. So it looks better at this time, so far. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
The updated virtualbox package is now available in the update repo. I will try to keep this problem from happening again. Larry -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tue, 18 Aug 2015 21:34:24 +0200, Jiri Slaby wrote:
On 08/18/2015, 06:09 PM, Takashi Iwai wrote:
If we guarantee kABI stability, why cannot kmp require kernel version >= build version?
I can we get rid of it now, but the old KMP has already the dependency, so it's no help at this time :)
And what about Provides?
Do you mean the line like this Provides: virtualbox-ose-host-kmp-%1 = %version I guess this is harmless. The problem is only the hard requirement in preambles in virtualbox-*-kmp: Requires: kernel-%1 And this should be removed for stable ABI; in other words, it should be enabled only for Tumbleweed. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 08/19/2015, 07:09 AM, Takashi Iwai wrote:
On Tue, 18 Aug 2015 21:34:24 +0200, Jiri Slaby wrote:
On 08/18/2015, 06:09 PM, Takashi Iwai wrote:
If we guarantee kABI stability, why cannot kmp require kernel version >= build version?
I can we get rid of it now, but the old KMP has already the dependency, so it's no help at this time :)
And what about Provides?
Do you mean the line like this
Provides: virtualbox-ose-host-kmp-%1 = %version
No, I mean some magic in the kernel spec like: Provides: kernel-<something> to satisfy:
I guess this is harmless. The problem is only the hard requirement in preambles in virtualbox-*-kmp:
Requires: kernel-%1
this ^^^^^^. But I am not sure it is worth it.
And this should be removed for stable ABI; in other words, it should be enabled only for Tumbleweed.
Yes, I agree. So when the KMPs are about to be rebuilt, they should be fixed appropriately first to avoid the breakage in the future :). thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tue, Aug 18, 2015 at 04:56:43PM +0200, Jiri Slaby wrote:
On 08/18/2015, 04:36 PM, Giacomo Comes wrote:
This was already discussed. See this thread: http://lists.opensuse.org/opensuse-kernel/2014-12/msg00064.html
A simple check is to install the last kernel 3.16.7-24.1, install virtualbox-host-kmp-desktop and run: rpm -e --test kernel-desktop-3.16.7-21.1
there will be a dependency failure.
Ok, what failure?
# rpm -e --test kernel-desktop-3.16.7-21.1 error: Failed dependencies: kernel-uname-r = 3.16.7-21-desktop is needed by (installed) virtualbox-host-kmp-desktop-4.3.30_k3.16.7_21-17.1.x86_64 kernel-uname-r = 3.16.7-21-desktop is needed by (installed) virtualbox-guest-kmp-desktop-4.3.30_k3.16.7_21-17.1.x86_64 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (9)
-
Andrei Borzenkov -
Giacomo Comes -
Jeff Mahoney -
Jiri Slaby -
Josua Mayer -
Larry Finger -
Marcus Meissner -
Michal Marek -
Takashi Iwai