Syscall_32.tbl Missing From Kernel Source

Rick Stevens ricks at alldigital.com
Thu Mar 17 22:50:26 UTC 2016


On 03/17/2016 02:42 PM, Rick Stevens wrote:
> On 03/17/2016 02:16 PM, Stephen Morris wrote:
>> On 17/03/16 09:53, Rick Stevens wrote:
>>> On 03/16/2016 12:44 PM, Stephen Morris wrote:
>>>> On 16/03/16 19:25, Stephen Morris wrote:
>>>>> Hi,
>>>>>
>>>>>     I am trying to compile the kernel from the source for kernel
>>>>> 4.4.3-300 but the compile is failing even though I have downloaded
>>>>> kcbench to get the module source code. I have looked in
>>>>> arch/x86/entry/syscalls in the kernel source and syscall_32.tbl is not
>>>>> there, all that is in that directory is Makefile. Have I downloaded
>>>>> the wrong source package, or should I just try and find where it has
>>>>> been placed in the kcbench-data directory and copy it over?
>>>>>
>>>>>
>>>>> regards,
>>>>>
>>>>> Steve
>>>>>
>>>> I copied the syscall_32.tbl module across to the kernel from where the
>>>> kcbench_data package installed it to, but the compile then fails on the
>>>> next module from the kcbench_data package. Why are these not in the
>>>> kernel, or is there another place that I need to update to reflect that
>>>> the necessary source has been installed and where it is, that the
>>>> package install is not updating?
>>>
>>> I'm not having any issues (well, so far).
>>>
>>> 1. I downloaded the kernel source RPM from a Fedora mirror to my /tmp
>>> directory. If you want the exact commands I used:
>>>
>>>     $ cd /tmp
>>>     $ wget
>>> http://mirrors.kernel.org/fedora/updates/23/SRPMS/k/kernel-4.4.4-301.fc23.src.rpm
>>>
>>>
>>>
>>> 2. As myself (not a privileged user), I just did:
>>>
>>>     $ cd /tmp
>>>     $ rpm -ivp kernel-4.4.4-301.fc23.src.rpm
>>>
>>> to install it in my rpmbuild directory tree. It whined about some items
>>> I needed to build it, so I downloaded and installed them:
>>>
>>>     $ sudo dnf install audit-libs-devel binutils-devel bison
>>> elfutils-devel flex hmaccalc newt-devel numactl-devel pciutils-devel
>>> pesign
>>>
>>> 3. Next, I did:
>>>
>>>     $ cd ~/rpmbuild/SPECS
>>>     $ rpmbuild -bp kernel.spec
>>>
>>> This builds the initial stuff required to configure the kernel itself,
>>> applies the patches, etc. and puts the results in
>>>
>>>     ~/rpmbuild/BUILD/kernel-4.4.fc23
>>>
>>> You'll see two directories inside the one I mention above. The one
>>> named "linux-4.4.4-301.fc23.x86_64" is the Fedora-specific one (with
>>> Fedora-specific patches). The one named "vanilla-4.4" is the one
>>> straight from kernel.org (without Fedora-specific patches and the
>>> like). Use the Fedora-specific one.
>>>
>>> 4. Next, I did:
>>>
>>>     $ cd ~/rpmbuild/BUILD/kernel-4.4.fc23/linux-4.4.4-301.fc23.x86_64
>>>     $ make xconfig
>>>
>>> Made my changes and saved the resulting ".config" file.
>>>
>>> 4. Next, I did:
>>>
>>>     make
>>>
>>> At this point, it starts building the kernel. It's still building right
>>> now (I'm using my poor little 4-core i5 laptop with only 8G of RAM),
>>> but so far I've not seen any issues like you're having.
>>>
>>> It's been a while since I built a kernel, but this is more-or-less what
>>> I've done in the past. I hope it helps.
>> Thanks Rick, I'll try this 3rd method.
>>
>> What led to this thread was, I have had the kernel-devel package
>> installed from fc18 onwards, so having this package installed I used
>> dolphin to copy /usr/src/kernels/4.4.4-301.fc23.x86_64 to
>> /usr/local/downloads/kernels/4.4.4-301.fc23.x86_64, so that I could work
>> on it without being root.
>>
>> I did:
>>      $ cd /usr/local/downloads/kernels/4.4.4-301.fc23.x86_64
>>      $ make xconfig
>>           loaded /boot/config-4.4.4-301.fc23.x86_64
>>          set the config_ath9k_channel_context_support option (I'm trying
>> this to see if it activates dual channel support on my 802.11ac usb
>> wireless adapter)
>>          saved the config to .config
>>
>> Then I did:
>>      make bzImage (just make does the same thing)
>>
>> This was where I got the message that led to this track, as the kernel
>> subdirectory of   arch/x86/entry/syscalls  which was where make was
>> expecting to find syscall_32.tbl only contained a makefile and nothing
>> else.
>>
>> After raising this thread I did some net searches for the error and got
>> some hits that led me to the following command:
>>          dnf provides */syscall_32.tbl
>> which led me to the kcbench-data package as being the container.
>>
>> I installed the package and its dependencies, and re-ran the kernel make
>> but it still produced the same error.
>>
>> I then copied syscall_32.tbl from the sub-directory of /usr/share, which
>> is where the install of the kcbench-data installed all its source to,
>> and re-ran the make. This rectified the syscall_32.tbl issue but failed
>> the next source code that was part of the kcbench-data package. Hence,
>> from my perspective, either the source packages in the Fedora
>> repositories are packaged wrong, or once the source packages are
>> installed there is some other configuration process that needs to be
>> done to tie them all together so that the make process knows where to
>> find everything.
>>
>> I also tried a   make prepare  but that had exactly the same issues as
>> the compile process.
>>
>>
>> I also tried following the instructions at
>> https://fedoraproject.org/wiki/Building_a_custom_kernel in the section
>> 'Building a Kernel from the source RPM', but I couldn't work out what
>> the required syntax was for the command   su -c 'dnf builddep
>> kernel-<version>.src.rpm'  , but you instructions above have given me an
>> idea of what the required syntax may be.
>
> "dnf builddep kernel-<version>.src.rpm" is a special dnf command (not
> documented in the man page, GRRRR!). From what I can gather, it looks
> at the RPM's requirements and possibly the "BuildRequires:" stuff in the
> source RPM's "*.spec" file and installs missing items.
>
> It does more or less what I did manually when my first "rpm -ivh" of
> the kernel source whined about missing packages and I manually installed
> them.
>
> The format of the command for the kernel I built would have been:
>
>      su -c 'dnf builddep kernel-4.4.4-301.fc23.src.rpm'
>
> Note that you must have downloaded the kernel source RPM to some
> scratch directory first, then "cd" to that scratch directory, THEN
> issue the "su -c 'dnf builddep..." command from there. The command
> needs to see the RPM (and possibly extract the .spec file to find the
> "BuildRequires:" data).

I wanted to add one more thing about that syscall_32.tbl file.

Note that I ONLY did specifically what I mentioned in my initial
response. I decided to trawl through the resultant stuff and this is
what I see:

	[rick at golem4 ~]$ ls -l 
/home/rick/rpmbuild/BUILD/kernel-4.4.fc23/linux-4.4.4-301.fc23.x86_64/arch/x86/entry/syscalls
	total 44
	-rw-r--r-- 2 rick rick  2137 Jan 10 15:01 Makefile
	-rw-r--r-- 2 rick rick 15362 Jan 10 15:01 syscall_32.tbl
	-rw-r--r-- 2 rick rick 12862 Jan 10 15:01 syscall_64.tbl
	-rw-r--r-- 2 rick rick   644 Jan 10 15:01 syscallhdr.sh
	-rw-r--r-- 2 rick rick   327 Jan 10 15:01 syscalltbl.sh

Note that the dates on those files (Jan 10) have NOTHING to do with
the date of my build (Mar 16), so they came from the source RPM--more
specifically from the "linux-4.4.tar.xz" source tarball included in
the source RPM that gets unpacked during the "rpmbuild -bp" command:

	[rick at golem4 ~]$ tar tJf ~/rpmbuild/SOURCES/linux-4.4.tar.xz | grep 
arch/x86/entry/syscalls
	linux-4.4/arch/x86/entry/syscalls/
	linux-4.4/arch/x86/entry/syscalls/Makefile
	linux-4.4/arch/x86/entry/syscalls/syscall_32.tbl
	linux-4.4/arch/x86/entry/syscalls/syscall_64.tbl
	linux-4.4/arch/x86/entry/syscalls/syscallhdr.sh
	linux-4.4/arch/x86/entry/syscalls/syscalltbl.sh

----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    ricks at alldigital.com -
- AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
-                                                                    -
- Grabel's Law: 2 is not equal to 3--not even for large values of 2. -
----------------------------------------------------------------------


More information about the users mailing list