F21: building kernels from srpms is broken

Josh Boyer jwboyer at fedoraproject.org
Tue Aug 26 17:54:25 UTC 2014


On Tue, Aug 26, 2014 at 1:47 PM, Steve Dickson <SteveD at redhat.com> wrote:
>
>
> On 08/26/2014 01:30 PM, Josh Boyer wrote:
>> On Tue, Aug 26, 2014 at 1:18 PM, Steve Dickson <SteveD at redhat.com> wrote:
>>> Hello,
>>>
>>> When build kernel from the source rpm I
>>> get the following depmod failure:
>>>
>>> + depmod -b . -aeF ./System.map 3.16.1-301.fc20.x86_64
>>> + '[' -s depmod.out ']'
>>> + echo 'Depmod failure'
>>> Depmod failure
>>> + cat depmod.out
>>> depmod: WARNING: /home/steved/rpmbuild/BUILDROOT/kernel-3.16.1-301.fc20.x86_64/./lib/modules/3.16.1-301.fc20.x86_64/kernel/fs/gfs2/gfs2.ko needs unknown symbol dlm_new_lockspace
>>> depmod: WARNING: /home/steved/rpmbuild/BUILDROOT/kernel-3.16.1-301.fc20.x86_64/./lib/modules/3.16.1-301.fc20.x86_64/kernel/fs/gfs2/gfs2.ko needs unknown symbol dlm_unlock
>>> depmod: WARNING: /home/steved/rpmbuild/BUILDROOT/kernel-3.16.1-301.fc20.x86_64/./lib/modules/3.16.1-301.fc20.x86_64/kernel/fs/gfs2/gfs2.ko needs unknown symbol dlm_release_lockspace
>>> depmod: WARNING: /home/steved/rpmbuild/BUILDROOT/kernel-3.16.1-301.fc20.x86_64/./lib/modules/3.16.1-301.fc20.x86_64/kernel/fs/gfs2/gfs2.ko needs unknown symbol dlm_posix_unlock
>>> depmod: WARNING: /home/steved/rpmbuild/BUILDROOT/kernel-3.16.1-301.fc20.x86_64/./lib/modules/3.16.1-301.fc20.x86_64/kernel/fs/gfs2/gfs2.ko needs unknown symbol dlm_posix_get
>>> depmod: WARNING: /home/steved/rpmbuild/BUILDROOT/kernel-3.16.1-301.fc20.x86_64/./lib/modules/3.16.1-301.fc20.x86_64/kernel/fs/gfs2/gfs2.ko needs unknown symbol dlm_lock
>>> depmod: WARNING: /home/steved/rpmbuild/BUILDROOT/kernel-3.16.1-301.fc20.x86_64/./lib/modules/3.16.1-301.fc20.x86_64/kernel/fs/gfs2/gfs2.ko needs unknown symbol dlm_posix_lock
>>> + exit 1
>>>
>>> What needs to happen to get this fixed? Should I open up a bz or
>>> open up a ticket somewhere? Please tell me where to go... nicely! ;-)
>>
>> Didn't we discuss all of this in #fedora-kernel yesterday?  Did the
>> advice we gave there not work, or?
> Yes.. Your advice was to use 'fedpkg local' which does indeed work but
> it also builds a bunch of rpms I don't need or use, like debug kernels.

Which you failed to tell us yesterday.  Come on Steve.

> When I rpmbuild from a srpm I use the following flags
>    --without extra --without tools --without debug --without perf --without headers

I'm guessing it's the --without extra that's breaking things.  gfs2.ko
is typically shoved in the modules-extra package.  You aren't actually
saving any build time by passing that, since everything in there is
still getting built.  It's just winding up in some other package.  We
should probably just remove that config switch because it really
doesn't make sense.

The --without headers isn't going to save you much time either.

> which greatly decrease the compiling time... from 70mins to 30mins
> depending on the machine...
>
> Now if I can set those flags in the fedpkg local build... Then
> I'm good to go...
>
>>
>> I guess we can start over.  Can you tell us exactly what you
>> downloaded from where, and how you're invoking the build?  This
>> obviously builds in koji, and it's built multiple times locally as
>> well.  It's rather confusing that you're having troubles, so we need
>> as much info on what you're doing as possible so we can try and
>> recreate.
> All I'm trying to do is build from a source rpm so I can set those flags.
> Here is what I'm doing... If there is a better way please let me know...
>
> fedpkg clone kernel
> cd kernel
> fedpkg srpm
> rpm -ihv kernel*.rpm
> cd /home/src/SPEC
> rpmbuild -bb --without extra --without tools --without debug --without perf --without headers --target x86_64 kernel.spec
>
> I've been build kernels this way for quite a while... but again,
> if there is a better way I'm more than willing to try...

Those steps are fine, with the caveat about --without extras from
above.  if you had told us all of this yesterday, you would have had
an answer yesterday too.

josh


More information about the kernel mailing list