6.18.14: VirtualBox modules don't build anymore; bisected

6.18.14: VirtualBox modules don't build anymore; bisected

[Rainer Fiebig]

In case this hasn't been reported already: with 6.18.14 the
VirtualBox-7.1.16 modules won't build during the boot process, as they
usually do.  Bisecting between 6.18.13/14 led to this:

f056c340b73962ebaffe93997b582bdf16dc6270 is the first bad commit
commit f056c340b73962ebaffe93997b582bdf16dc6270 (HEAD)
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Tue Feb 10 13:45:22 2026 -0800

    kbuild: Add objtool to top-level clean target

    [ Upstream commit 68b4fe32d73789dea23e356f468de67c8367ef8f ]

    Objtool is an integral part of the build, make sure it gets cleaned
    by "make clean" and "make mrproper".
[...]


The script I use for building my kernels includes "make mrproper" before
compiling and "make clean" after the kernel and modules have been
installed.

Perhaps it would be more appropriate to report this to the
VirtualBox-devs but I won't do that because the registration procedure
asks for too many private data.

Thanks.

Rainer

-- 
The truth always turns out to be simpler than you thought.
Richard Feynman

Re: 6.18.14: VirtualBox modules don't build anymore; bisected

[Greg KH]

On Fri, Feb 27, 2026 at 04:33:34PM +0100, Rainer Fiebig wrote:
> In case this hasn't been reported already: with 6.18.14 the
> VirtualBox-7.1.16 modules won't build during the boot process, as they
> usually do.  Bisecting between 6.18.13/14 led to this:
> 
> f056c340b73962ebaffe93997b582bdf16dc6270 is the first bad commit
> commit f056c340b73962ebaffe93997b582bdf16dc6270 (HEAD)
> Author: Josh Poimboeuf <jpoimboe@kernel.org>
> Date:   Tue Feb 10 13:45:22 2026 -0800
> 
>     kbuild: Add objtool to top-level clean target
> 
>     [ Upstream commit 68b4fe32d73789dea23e356f468de67c8367ef8f ]
> 
>     Objtool is an integral part of the build, make sure it gets cleaned
>     by "make clean" and "make mrproper".
> [...]
> 
> 
> The script I use for building my kernels includes "make mrproper" before
> compiling and "make clean" after the kernel and modules have been
> installed.
> 
> Perhaps it would be more appropriate to report this to the
> VirtualBox-devs but I won't do that because the registration procedure
> asks for too many private data.

We obviously can not do anything about external modules, so if you rely
on these, you are going to have to work with them on this, sorry.

thanks,

greg k-h

Re: 6.18.14: VirtualBox modules don't build anymore; bisected

[Rainer Fiebig]

Am 27.02.26 um 21:12 schrieb Greg KH:
> On Fri, Feb 27, 2026 at 04:33:34PM +0100, Rainer Fiebig wrote:
>> In case this hasn't been reported already: with 6.18.14 the
>> VirtualBox-7.1.16 modules won't build during the boot process, as they
>> usually do.  Bisecting between 6.18.13/14 led to this:
>>
>> f056c340b73962ebaffe93997b582bdf16dc6270 is the first bad commit
>> commit f056c340b73962ebaffe93997b582bdf16dc6270 (HEAD)
>> Author: Josh Poimboeuf <jpoimboe@kernel.org>
>> Date:   Tue Feb 10 13:45:22 2026 -0800
>>
>>     kbuild: Add objtool to top-level clean target
>>
>>     [ Upstream commit 68b4fe32d73789dea23e356f468de67c8367ef8f ]
>>
>>     Objtool is an integral part of the build, make sure it gets cleaned
>>     by "make clean" and "make mrproper".
>> [...]
>>
>>
>> The script I use for building my kernels includes "make mrproper" before
>> compiling and "make clean" after the kernel and modules have been
>> installed.
>>
>> Perhaps it would be more appropriate to report this to the
>> VirtualBox-devs but I won't do that because the registration procedure
>> asks for too many private data.
> 
> We obviously can not do anything about external modules, so if you rely
> on these, you are going to have to work with them on this, sorry.

Alright, tough luck.  But that a patch-release of an LTS-kernel breaks
VirtualBox is really a first - at least as far as I can remember.  So, I
think I'll create an experimental branch and revert that commit, as I've
never missed it before.

Rainer

Re: 6.18.14: VirtualBox modules don't build anymore; bisected

[Greg KH]

On Sat, Feb 28, 2026 at 12:30:29AM +0100, Rainer Fiebig wrote:
> Am 27.02.26 um 21:12 schrieb Greg KH:
> > On Fri, Feb 27, 2026 at 04:33:34PM +0100, Rainer Fiebig wrote:
> >> In case this hasn't been reported already: with 6.18.14 the
> >> VirtualBox-7.1.16 modules won't build during the boot process, as they
> >> usually do.  Bisecting between 6.18.13/14 led to this:
> >>
> >> f056c340b73962ebaffe93997b582bdf16dc6270 is the first bad commit
> >> commit f056c340b73962ebaffe93997b582bdf16dc6270 (HEAD)
> >> Author: Josh Poimboeuf <jpoimboe@kernel.org>
> >> Date:   Tue Feb 10 13:45:22 2026 -0800
> >>
> >>     kbuild: Add objtool to top-level clean target
> >>
> >>     [ Upstream commit 68b4fe32d73789dea23e356f468de67c8367ef8f ]
> >>
> >>     Objtool is an integral part of the build, make sure it gets cleaned
> >>     by "make clean" and "make mrproper".
> >> [...]
> >>
> >>
> >> The script I use for building my kernels includes "make mrproper" before
> >> compiling and "make clean" after the kernel and modules have been
> >> installed.
> >>
> >> Perhaps it would be more appropriate to report this to the
> >> VirtualBox-devs but I won't do that because the registration procedure
> >> asks for too many private data.
> > 
> > We obviously can not do anything about external modules, so if you rely
> > on these, you are going to have to work with them on this, sorry.
> 
> Alright, tough luck.  But that a patch-release of an LTS-kernel breaks
> VirtualBox is really a first - at least as far as I can remember.

Then they have gotten really lucky :)

good luck!

greg k-h

Re: 6.18.14: VirtualBox modules don't build anymore; bisected

[Nathan Chancellor]

On Fri, Feb 27, 2026 at 08:29:05PM -0500, Greg KH wrote:
> On Sat, Feb 28, 2026 at 12:30:29AM +0100, Rainer Fiebig wrote:
> > Am 27.02.26 um 21:12 schrieb Greg KH:
> > > On Fri, Feb 27, 2026 at 04:33:34PM +0100, Rainer Fiebig wrote:
> > >> In case this hasn't been reported already: with 6.18.14 the
> > >> VirtualBox-7.1.16 modules won't build during the boot process, as they
> > >> usually do.  Bisecting between 6.18.13/14 led to this:
> > >>
> > >> f056c340b73962ebaffe93997b582bdf16dc6270 is the first bad commit
> > >> commit f056c340b73962ebaffe93997b582bdf16dc6270 (HEAD)
> > >> Author: Josh Poimboeuf <jpoimboe@kernel.org>
> > >> Date:   Tue Feb 10 13:45:22 2026 -0800
> > >>
> > >>     kbuild: Add objtool to top-level clean target
> > >>
> > >>     [ Upstream commit 68b4fe32d73789dea23e356f468de67c8367ef8f ]
> > >>
> > >>     Objtool is an integral part of the build, make sure it gets cleaned
> > >>     by "make clean" and "make mrproper".
> > >> [...]
> > >>
> > >>
> > >> The script I use for building my kernels includes "make mrproper" before
> > >> compiling and "make clean" after the kernel and modules have been
> > >> installed.
> > >>
> > >> Perhaps it would be more appropriate to report this to the
> > >> VirtualBox-devs but I won't do that because the registration procedure
> > >> asks for too many private data.
> > > 
> > > We obviously can not do anything about external modules, so if you rely
> > > on these, you are going to have to work with them on this, sorry.
> > 
> > Alright, tough luck.  But that a patch-release of an LTS-kernel breaks
> > VirtualBox is really a first - at least as far as I can remember.
> 
> Then they have gotten really lucky :)

I think this is firmly a Kbuild bug, as we broke the contract of
'make clean' leaving around enough to build external modules:

  https://lore.kernel.org/20260227-avoid-objtool-binary-removal-clean-v1-1-122f3e55eae9@kernel.org/

Kbuild is what runs objtool, not the external module itself. I don't
care much for external modules but this does not appear to be something
they have done or relied on.

Cheers,
Nathan

Re: 6.18.14: VirtualBox modules don't build anymore; bisected

[Rainer Fiebig]

Am 28.02.26 um 06:48 schrieb Nathan Chancellor:
> On Fri, Feb 27, 2026 at 08:29:05PM -0500, Greg KH wrote:
>> On Sat, Feb 28, 2026 at 12:30:29AM +0100, Rainer Fiebig wrote:
>>> Am 27.02.26 um 21:12 schrieb Greg KH:
>>>> On Fri, Feb 27, 2026 at 04:33:34PM +0100, Rainer Fiebig wrote:
>>>>> In case this hasn't been reported already: with 6.18.14 the
>>>>> VirtualBox-7.1.16 modules won't build during the boot process, as they
>>>>> usually do.  Bisecting between 6.18.13/14 led to this:
>>>>>
>>>>> f056c340b73962ebaffe93997b582bdf16dc6270 is the first bad commit
>>>>> commit f056c340b73962ebaffe93997b582bdf16dc6270 (HEAD)
>>>>> Author: Josh Poimboeuf <jpoimboe@kernel.org>
>>>>> Date:   Tue Feb 10 13:45:22 2026 -0800
>>>>>
>>>>>     kbuild: Add objtool to top-level clean target
>>>>>
>>>>>     [ Upstream commit 68b4fe32d73789dea23e356f468de67c8367ef8f ]
>>>>>
>>>>>     Objtool is an integral part of the build, make sure it gets cleaned
>>>>>     by "make clean" and "make mrproper".
>>>>> [...]
>>>>>
>>>>>
>>>>> The script I use for building my kernels includes "make mrproper" before
>>>>> compiling and "make clean" after the kernel and modules have been
>>>>> installed.
>>>>>
>>>>> Perhaps it would be more appropriate to report this to the
>>>>> VirtualBox-devs but I won't do that because the registration procedure
>>>>> asks for too many private data.
>>>>
>>>> We obviously can not do anything about external modules, so if you rely
>>>> on these, you are going to have to work with them on this, sorry.
>>>
>>> Alright, tough luck.  But that a patch-release of an LTS-kernel breaks
>>> VirtualBox is really a first - at least as far as I can remember.
>>
>> Then they have gotten really lucky :)
> 
> I think this is firmly a Kbuild bug, as we broke the contract of
> 'make clean' leaving around enough to build external modules:
> 
>   https://lore.kernel.org/20260227-avoid-objtool-binary-removal-clean-v1-1-122f3e55eae9@kernel.org/
> 
> Kbuild is what runs objtool, not the external module itself. I don't
> care much for external modules but this does not appear to be something
> they have done or relied on.

Thanks for the info!  I have the "make clean" step in my script because
the repo gets backed up but I don't want the remnants of an old
kernel-build in it then.  Good to know that a fix is under way.

Rainer