Package: linux-kbuild-3.16
Version: 3.16-3
Severity: important
Tags: lfs
Dear Maintainer,
* What led up to the situation?
I am running Debian Jessie, Linux debian 3.16.0-4-amd64 #1 SMP Debian
3.16.7-ckt2-1 (2014-12-08) x86_64 GNU/Linux. I attempted to install fglrx and
discovered that ALL dkms kernel module builds were failing for me with: "Value
too large for defined data type"
I have a ~4TB XFS filesystem... According to XFS documentation, by
default for any FS over 2GB, the filesystem is created to support 64 bit
inodes. There have been many years of migration efforts to address LFS issues
with tools compiled in 32bit mode. In retrospect, this issue has been present
for some months now. Here is the mount-line showing that XFS is mounted with
inode64:
# mount
/dev/mapper/root on / type xfs (rw,relatime,attr2,inode64,noquota)
* What exactly did you do (or not do) that was effective (or ineffective)?
When attempting to run a dkms build, the build would fail.
For example, here is the case for acpi-call.
ALL other kernel modules fail for me due to the inode64 issue.
root@debian:/usr/src# aptitude install acpi-call-dkms
The following NEW packages will be installed:
acpi-call-dkms
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 12.9 kB of archives. After unpacking 73.7 kB will be used.
Get: 1 http://debian.lcs.mit.edu/debian/ testing/main acpi-call-dkms all
1.1.0-2 [12.9 kB]
Fetched 12.9 kB in 0s (82.9 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package acpi-call-dkms.
(Reading database ... 716228 files and directories currently installed.)
Preparing to unpack .../acpi-call-dkms_1.1.0-2_all.deb ...
Unpacking acpi-call-dkms (1.1.0-2) ...
Setting up acpi-call-dkms (1.1.0-2) ...
Loading new acpi-call-1.1.0 DKMS files...
First Installation: checking all kernels...
Building only for 3.16.0-4-amd64
Building initial module for 3.16.0-4-amd64
Error! Bad return status for module build on kernel: 3.16.0-4-amd64 (x86_64)
Consult /var/lib/dkms/acpi-call/1.1.0/build/make.log for more information.
* What was the outcome of this action?
A failed build for rather mysterious reasons:
root@debian:/usr/src# cat /var/lib/dkms/acpi-call/1.1.0/build/make.log
DKMS make.log for acpi-call-1.1.0 for kernel 3.16.0-4-amd64 (x86_64)
Sat Feb 14 16:09:33 EST 2015
make: Entering directory '/usr/src/linux-headers-3.16.0-4-amd64'
make[1]: Entering directory `/usr/src/linux-headers-3.16.0-4-amd64'
LD /var/lib/dkms/acpi-call/1.1.0/build/built-in.o
CC [M] /var/lib/dkms/acpi-call/1.1.0/build/acpi_call.o
/var/lib/dkms/acpi-call/1.1.0/build/acpi_call.o: Value too large for defined
data type
/usr/src/linux-headers-3.16.0-4-common/scripts/Makefile.build:268: recipe for
target '/var/lib/dkms/acpi-call/1.1.0/build/acpi_call.o' failed
make[3]: *** [/var/lib/dkms/acpi-call/1.1.0/build/acpi_call.o] Error 1
/usr/src/linux-headers-3.16.0-4-common/Makefile:1350: recipe for target
'_module_/var/lib/dkms/acpi-call/1.1.0/build' failed
make[2]: *** [_module_/var/lib/dkms/acpi-call/1.1.0/build] Error 2
Makefile:181: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
Makefile:8: recipe for target 'all' failed
make: *** [all] Error 2
make: Leaving directory '/usr/src/linux-headers-3.16.0-4-amd64'
Some days later I narrowed the build action down to make, and ran strace on the
make process:
# cd /usr/src/acpi-call-1.1.0
# strace -v -ttt -T -e trace=file -y -ff -o acpi_call-strace-make make --debug
1424548709.184383 execve("./scripts/recordmcount", ["./scripts/recordmcount",
"/usr/src/acpi-call-1.1.0/acpi_ca"...], ["SUDO_GID=1000", "ARCH=x86", "MAIL=/va
r/mail/root", "USER=root", "LANGUAGE=", "OBJCOPY=objcopy",
"mod_strip_cmd=true", "MODVERDIR=/usr/src/acpi-call-1.1"..., "HOSTCC=gcc",
"SHLVL=1", "HOME=/root"
, "OLDPWD=/usr/src", "REALMODE_CFLAGS= -m32 -include /"...,
"GENKSYMS=scripts/genksyms/genksy"..., "INSTALLKERNEL=installkernel",
"CONFIG_X86_X32_ABI=y", "VP
ATH=/usr/src/linux-headers-3.1"..., "LDFLAGS=-m elf_x86_64",
"KBUILD_VERBOSE=0", "KBUILD_BUILTIN=", "MAKEFLAGS=rR -I/usr/src/linux-he"...,
"HOSTCXXFLAGS=-O2"
, "LDFLAGS_MODULE=", "Q=@", "CPP= gcc-4.8 -E", "KBUILD_MODULES=1",
"SRCARCH=x86", "SUDO_UID=1000", "STRIP=strip", "VERSION=3", "LOGNAME=root",
"CROSS_COMPILE
=", "KERNELVERSION=3.16.7-ckt4", "_=/usr/bin/strace", "O=/usr/src/linux-
headers-3.16.0-"..., "AR=ar", "KERNELRELEASE=3.16.0-4-amd64", "NOSTDINC_FLAGS=
-nostd
inc -isyst"..., "USERNAME=root", "AS=as", "OBJCOPYFLAGS=", "CHECK=sparse",
"RCS_FIND_IGNORE=\\( -name SCCS -o"..., "TERM=xterm", "AWK=awk",
"KBUILD_EXTMOD=/u
sr/src/acpi-call"..., "KBUILD_CHECKSRC=0", "quiet=quiet_", "CFLAGS_KERNEL=",
"LC_COLLATE=C", "KBUILD_SUBDIR_CCFLAGS= ", "KBUILD_SRC=/usr/src/linux-
header"...
, "PATH=/usr/local/sbin:/usr/local/"..., "KBUILD_AFLAGS_KERNEL=", "M=/usr/src
/acpi-call-1.1.0", "MAKELEVEL=5", "KBUILD_AFLAGS=-D__ASSEMBLY__ -m6"...,
"DISPLA
Y=:0", "KCONFIG_CONFIG=.config", "KBUILD_CFLAGS_KERNEL=", "obj=/usr/src/acpi-
call-1.1.0", "UTS_MACHINE=x86_64", "BUILD_C_RECORDMCOUNT=y",
"LANG=en_US.UTF-8",
"AFLAGS_KERNEL=", "CFLAGS_MODULE=", "LS_COLORS=rs=0:di=01;34:ln=01;36"...,
"MAKEOVERRIDES=${-*-command-varia"..., "KBUILD_CFLAGS=-Wall -Wundef -Wst"...,
"SU
DO_COMMAND=/bin/bash", "KBUILD_IMAGE=arch/x86/boot/bzIma"..., "srctree=/usr/src
/linux-headers-3"..., "LINUXINCLUDE=-I/usr/src/linux-he"..., "KBUILD_AFLAGS_MO
DULE=-DMODULE", "SHELL=/bin/bash", "KBUILD_LDFLAGS_MODULE=-T /usr/sr"...,
"objtree=.", "SUBLEVEL=7", "KBUILD_ARFLAGS=D", "PERL=perl",
"KBUILD_CFLAGS_MODULE=-
DMODULE", "SUDO_USER=user", "KBUILD_CPPFLAGS=-D__KERNEL__ ", "CFLAGS_GCOV
=-fprofile-arcs -ftes"..., "HOSTCFLAGS=-Wall -Wmissing-proto"...,
"AFLAGS_MODULE=",
"mod_sign_cmd=true", "CONFIG_SHELL=/bin/bash", "CHECKFLAGS=-D__linux__ -Dlinux
-"..., "INSTALL_PATH=/boot", "PWD=/usr/src/linux-headers-3.16."..., "MODLIB=/l
ib/modules/3.16.0-4-amd"..., "LD=ld", "KBUILD_SUBDIR_ASFLAGS= ",
"PATCHLEVEL=16", "LC_NUMERIC=C", "HOSTCXX=g++", "MAKE=make", "CC= gcc-4.8",
"MFLAGS=-rR -I/u
sr/src/linux-head"..., "BITS=64", "NM=nm", "RCS_TAR_IGNORE=--exclude SCCS
--"..., "OBJDUMP=objdump", "INSTALL_DTBS_PATH=/boot/dtbs/3.1"...]) = 0
<0.000115>
1424548709.184666 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file
or directory) <0.000007>
1424548709.184701 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file
or directory) <0.000006>
1424548709.184721 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) =
3</etc/ld.so.cache> <0.000007>
1424548709.184784 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file
or directory) <0.000006>
1424548709.184809 open("/lib/i386-linux-gnu/i686/cmov/libc.so.6",
O_RDONLY|O_CLOEXEC) = 3</lib/i386-linux-gnu/i686/cmov/libc-2.19.so> <0.000009>
1424548709.185063 open("/usr/src/acpi-call-1.1.0/acpi_call.o", O_RDWR) =
3</usr/src/acpi-call-1.1.0/acpi_call.o> <0.000008>
1424548709.185339 +++ exited with 1 +++
Which reveals that the offending program in the build is
root@debian:/usr/src/linux-headers-3.16.0-4-common# ./scripts/recordmcount
/usr/src/acpi-call-1.1.0/acpi_call.o
/usr/src/acpi-call-1.1.0/acpi_call.o: Value too large for defined data type
Indeed, recordmcount is a 32-bit ELF binary:
root@debian:/usr/src/linux-headers-3.16.0-4-common/scripts# file *
bin2c: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=abbc968b29bb04da26ec25f9c9193b12aff55462, stripped
conmakehash: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=45e48692a5764c9df4c96b31e5ef6f57fbc5d868, stripped
kallsyms: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=b20dbba866d06b4aa861f6947b09ffa73ba6594c, stripped
pnmtologo: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=72e766341658e629ca67ba592c6f906d041f132b, stripped
recordmcount: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=dd7c4b98b4d3474c696dc37533cc4a198bf02d90, stripped
Next I copied /usr/src to a smaller 250GB XFS filesystem, one also mounted with
inode64:
/dev/sdh2 on /mnt/lacie_ruggedfw2 type xfs (rw,relatime,attr2,inode64,noquota)
root@debian:/mnt/248G_xfs/src/acpi-call-1.1.0# /usr/src/linux-
headers-3.16.0-4-common/scripts/recordmcount acpi_call.o
warning: __mcount_loc already exists: acpi_call.o
Which is not a success, though encouraging.
However to repeat the test even further, I tried it with EXT4 on a filesystem
smaller than 2GB.
root@debian:/mnt/2G_ext4/src/acpi-call-1.1.0# /usr/src/linux-
headers-3.16.0-4-common/scripts/recordmcount acpi_call.o
Which succeeded:
-rw-r--r-- 1 root root 163K Feb 21 17:20 acpi_call.o
I tried it also on an small < 2G XFS filesystem, also created and mounted with
inode64:
root@debian:/mnt/2G_xfs/acpi-call-1.1.0# /usr/src/linux-
headers-3.16.0-4-common/scripts/recordmcount acpi_call.o
Which also succeeded:
-rw-r--r-- 1 root root 11980 Sep 21 06:07 acpi_call.c
And to round out the tests, on a large EXT4 filesystem:
root@debian:/mnt/248G_ext4/acpi-call-1.1.0# /usr/src/linux-
headers-3.16.0-4-common/scripts/recordmcount acpi_call.o
Which again, succeeded, even though it ought to fail. EXT4 must be doing
something special here, or XFS has a bug above and beyond the errant 32-bit
binaries in linux-kbuild.
* WORKAROUND
This led me to mount the 248G ext4 partition on /usr/src (a duplicate of
/usr/src and symbolic links) for testing kernel module installs.
Surprisingly, it too worked:
root@debian:/usr/src# aptitude reinstall acpi-call-dkms
The following packages will be REINSTALLED:
acpi-call-dkms
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not
upgraded.
Need to get 12.9 kB of archives. After unpacking 0 B will be used.
Get: 1 http://debian.lcs.mit.edu/debian/ testing/main acpi-call-dkms all
1.1.0-2 [12.9 kB]
Fetched 12.9 kB in 0s (71.9 kB/s)
(Reading database ... 712938 files and directories currently installed.)
Preparing to unpack .../acpi-call-dkms_1.1.0-2_all.deb ...
------------------------------
Deleting module version: 1.1.0
completely from the DKMS tree.
------------------------------
Done.
Unpacking acpi-call-dkms (1.1.0-2) over (1.1.0-2) ...
Setting up acpi-call-dkms (1.1.0-2) ...
Loading new acpi-call-1.1.0 DKMS files...
Building only for 3.16.0-4-amd64
Building initial module for 3.16.0-4-amd64
Done.
acpi_call:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.16.0-4-amd64/updates/dkms/
depmod............
DKMS: install completed.
So the dkms script worked, as did the resulting binaries.
* What outcome did you expect instead?
I expect dkms builds to succeed automatically! :)
* Recommendation to fix:
Here are some sites I found helpful when researching this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44116
http://www.tcm.phy.cam.ac.uk/sw/inodes64.html
http://blog.fmeh.org/2013/05/11/does-the-world-need-32-bit-inodes/
https://raw.githubusercontent.com/gnb/junkcode/master/summarise_stat.pl
This looks like a regression of the linux-kbuild tools for kernel 3.16. While
it might work OK on EXT4 it most certainly does not work on XFS partitions
larger than 2G. Of the large number of linux-headers-common and linux-kbuild
trees on my system there are only a few files using 32-bit stat() family
interface only, and only in linux-kbuild-3.16:
user@debian:src$ summarise_stat.pl linux-kbuild-3.16/
Summary by status
-----------------
29 69.0% are scripts (shell, perl, whatever)
6 14.3% don't use any stat() family calls at all
7 16.7% use 32-bit stat() family interfaces only [BROKEN]
7 16.7% BROKEN
List of broken files
--------------------
These use 32-bit stat() family interfaces only
linux-kbuild-3.16//scripts/basic/fixdep
linux-kbuild-3.16//scripts/kconfig/conf
linux-kbuild-3.16//scripts/mod/modpost.real-msb-32
linux-kbuild-3.16//scripts/mod/modpost.real-msb-64
linux-kbuild-3.16//scripts/mod/modpost.real-lsb-64
linux-kbuild-3.16//scripts/mod/modpost.real-lsb-32
linux-kbuild-3.16//scripts/recordmcount
user@debian:src$ summarise_stat.pl linux-kbuild-*
Summary by status
-----------------
222 69.2% are scripts (shell, perl, whatever)
86 26.8% are 64-bit executables
6 1.9% don't use any stat() family calls at all
7 2.2% use 32-bit stat() family interfaces only [BROKEN]
7 2.2% BROKEN
List of broken files
--------------------
These use 32-bit stat() family interfaces only
linux-kbuild-3.16/scripts/basic/fixdep
linux-kbuild-3.16/scripts/kconfig/conf
linux-kbuild-3.16/scripts/mod/modpost.real-msb-32
linux-kbuild-3.16/scripts/mod/modpost.real-msb-64
linux-kbuild-3.16/scripts/mod/modpost.real-lsb-64
linux-kbuild-3.16/scripts/mod/modpost.real-lsb-32
linux-kbuild-3.16/scripts/recordmcount
Please supply amd64 binaries for the linux-kbuild package.
Thanks.
have a nice debian day.yad
jdpf
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages linux-kbuild-3.16 depends on:
ii libc6 2.19-13
linux-kbuild-3.16 recommends no packages.
linux-kbuild-3.16 suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
