apt update of debian-zfs on a system running off a zfs root partition

[RJVB]

I have a "real silicon" Linux Mint Debian system running off a zfs root partition (with just /boot on an ext3 partition). I just tried to do an apt-get update && apt-get upgrade which told me about new zfs packages ... and got a configure error suggesting that spl-devel wasn't installed. The basic question is: is it even possible to use the usual upgrading procedures, or would you get a race condition where access to the zfs fs requires the very modules being updated? From what I saw, the "old" kmods were not removed, but I haven't yet tried to reboot ...

R.

FransUrbo commented 13 minutes ago @RJVB What was the exact error? What does the following tell you:

cat find /etc/apt/sources.list* -type f Also, what did the apt-get upgrade command output? Exactly!

[RJVB]

$ cat `find /etc/apt/sources.list* -type f`
deb http://packages.linuxmint.com/ debian main upstream import
deb http://mirror.rts-informatique.fr/linuxmint/debian/latest testing main contrib non-free
deb http://mirror.rts-informatique.fr/linuxmint/debian/latest/security testing/updates main contrib non-free
deb http://mirror.rts-informatique.fr/linuxmint/debian/latest/multimedia testing main non-free

deb http://repository.spotify.com stable non-free
deb-src http://repository.spotify.com stable non-free
deb http://packages.linuxmint.com/ debian main upstream import
deb http://mirror.rts-informatique.fr/linuxmint/debian/latest testing main contrib non-free
deb http://mirror.rts-informatique.fr/linuxmint/debian/latest/security testing/updates main contrib non-free
deb http://mirror.rts-informatique.fr/linuxmint/debian/latest/multimedia testing main non-free

## This file is installed by the zfsonlinux package.

deb http://archive.zfsonlinux.org/debian wheezy main
#deb-src http://archive.zfsonlinux.org/debian wheezy main contrib
## This file is installed by the zfsonlinux package.

deb http://archive.zfsonlinux.org/debian wheezy main
# deb-src http://archive.zfsonlinux.org/debian wheezy main contrib
### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.
deb http://dl.google.com/linux/chrome/deb/ stable main
### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.
deb http://dl.google.com/linux/chrome/deb/ stable main
deb http://packages.linuxmint.com/ debian main upstream import
deb http://mirror.rts-informatique.fr/linuxmint/debian/latest testing main contrib non-free
deb http://mirror.rts-informatique.fr/linuxmint/debian/latest/security testing/updates main contrib non-free
deb http://mirror.rts-informatique.fr/linuxmint/debian/latest/multimedia testing main non-free

$ sudo aptitude upgrade
The following packages will be upgraded: 
  grub-common grub-pc grub-pc-bin grub2-common libnvpair1 libuutil1 libzfs-dev libzfs1 libzpool1 zfs-dkms 
  zfs-initramfs zfsutils 
12 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 6,654 kB of archives. After unpacking 539 kB will be used.
Do you want to continue? [Y/n/?] y
Get: 1 http://archive.zfsonlinux.org/debian/ wheezy/main zfs-dkms all 0.6.2-3 [1,418 kB]
Get: 2 http://archive.zfsonlinux.org/debian/ wheezy/main libuutil1 amd64 0.6.2-3 [51.9 kB]
Get: 3 http://archive.zfsonlinux.org/debian/ wheezy/main libnvpair1 amd64 0.6.2-3 [49.3 kB]
Get: 4 http://archive.zfsonlinux.org/debian/ wheezy/main libzfs-dev amd64 0.6.2-3 [1,056 kB]
Get: 5 http://archive.zfsonlinux.org/debian/ wheezy/main libzpool1 amd64 0.6.2-3 [445 kB]                          
Get: 6 http://archive.zfsonlinux.org/debian/ wheezy/main libzfs1 amd64 0.6.2-3 [147 kB]                            
Get: 7 http://archive.zfsonlinux.org/debian/ wheezy/main grub-pc amd64 2.01-22debian1+zfs3~wheezy [172 kB]         
Get: 8 http://archive.zfsonlinux.org/debian/ wheezy/main grub-pc-bin amd64 2.01-22debian1+zfs3~wheezy [804 kB]     
Get: 9 http://archive.zfsonlinux.org/debian/ wheezy/main grub2-common amd64 2.01-22debian1+zfs3~wheezy [118 kB]    
Get: 10 http://archive.zfsonlinux.org/debian/ wheezy/main grub-common amd64 2.01-22debian1+zfs3~wheezy [2,034 kB]  
Get: 11 http://archive.zfsonlinux.org/debian/ wheezy/main zfsutils amd64 0.6.2-3 [342 kB]                          
Get: 12 http://archive.zfsonlinux.org/debian/ wheezy/main zfs-initramfs amd64 0.6.2-3 [15.9 kB]
Fetched 6,654 kB in 42s (156 kB/s)                                                                                 
Preconfiguring packages ...
(Reading database ... 312523 files and directories currently installed.)
Preparing to replace zfs-dkms 0.6.2-2 (using .../zfs-dkms_0.6.2-3_all.deb) ...

------------------------------
Deleting module version: 0.6.2
completely from the DKMS tree.
------------------------------
Done.
Unpacking replacement zfs-dkms ...
Preparing to replace libuutil1 0.6.2-2 (using .../libuutil1_0.6.2-3_amd64.deb) ...
Unpacking replacement libuutil1 ...
Preparing to replace libnvpair1 0.6.2-2 (using .../libnvpair1_0.6.2-3_amd64.deb) ...
Unpacking replacement libnvpair1 ...
Preparing to replace libzfs-dev 0.6.2-2 (using .../libzfs-dev_0.6.2-3_amd64.deb) ...
Unpacking replacement libzfs-dev ...
Preparing to replace libzpool1 0.6.2-2 (using .../libzpool1_0.6.2-3_amd64.deb) ...
Unpacking replacement libzpool1 ...
Preparing to replace libzfs1 0.6.2-2 (using .../libzfs1_0.6.2-3_amd64.deb) ...
Unpacking replacement libzfs1 ...
Preparing to replace grub-pc 2.00-13ubuntu3+zfs3~raring (using .../grub-pc_2.01-22debian1+zfs3~wheezy_amd64.deb) ...
Unpacking replacement grub-pc ...
Preparing to replace grub-pc-bin 2.00-13ubuntu3+zfs3~raring (using .../grub-pc-bin_2.01-22debian1+zfs3~wheezy_amd64.deb) ...
Unpacking replacement grub-pc-bin ...
Preparing to replace grub2-common 2.00-13ubuntu3+zfs3~raring (using .../grub2-common_2.01-22debian1+zfs3~wheezy_amd64.deb) ...
Unpacking replacement grub2-common ...
Preparing to replace grub-common 2.00-13ubuntu3+zfs3~raring (using .../grub-common_2.01-22debian1+zfs3~wheezy_amd64.deb) ...
Unpacking replacement grub-common ...
Preparing to replace zfsutils 0.6.2-2 (using .../zfsutils_0.6.2-3_amd64.deb) ...
Unpacking replacement zfsutils ...
Preparing to replace zfs-initramfs 0.6.2-2 (using .../zfs-initramfs_0.6.2-3_amd64.deb) ...
Unpacking replacement zfs-initramfs ...
Processing triggers for man-db ...
Processing triggers for install-info ...
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-3.10-2-amd64
cryptsetup: WARNING: could not determine root device from /etc/fstab

Setting up zfs-dkms (0.6.2-3) ...
Loading new zfs-0.6.2 DKMS files...
Building only for 3.10-2-amd64
Building initial module for 3.10-2-amd64
configure: error: 
        *** Please make sure the kmod spl devel <kernel> package for your
        *** distribution is installed then try again.  If that fails you
        *** can specify the location of the spl objects with the
        *** '--with-spl-obj=PATH' option.
Error! Bad return status for module build on kernel: 3.10-2-amd64 (x86_64)
Consult /var/lib/dkms/zfs/0.6.2/build/make.log for more information.
Setting up libuutil1 (0.6.2-3) ...
Setting up libnvpair1 (0.6.2-3) ...
Setting up libzpool1 (0.6.2-3) ...
Setting up libzfs1 (0.6.2-3) ...
Setting up libzfs-dev (0.6.2-3) ...
Setting up grub-common (2.01-22debian1+zfs3~wheezy) ...
Installing new version of config file /etc/grub.d/00_header ...
Installing new version of config file /etc/grub.d/20_linux_xen ...
Installing new version of config file /etc/grub.d/05_debian_theme ...
Installing new version of config file /etc/grub.d/30_os-prober ...
Installing new version of config file /etc/grub.d/10_linux ...
Setting up grub2-common (2.01-22debian1+zfs3~wheezy) ...
Setting up grub-pc-bin (2.01-22debian1+zfs3~wheezy) ...
Setting up grub-pc (2.01-22debian1+zfs3~wheezy) ...
Installation finished. No error reported.
Generating grub.cfg ...
Found background image: .background_cache.png
Found linux image: /boot/vmlinuz-3.10-2-amd64
Found initrd image: /boot/initrd.img-3.10-2-amd64
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
Found Windows Recovery Environment (loader) on /dev/sda1
Found Windows 7 (loader) on /dev/sda2
done
Setting up zfsutils (0.6.2-3) ...
Installing new version of config file /etc/bash_completion.d/zfs ...
insserv: can not symlink(../init.d/hwclock.sh, ../rc0.d/K07hwclock.sh): File exists
insserv: can not symlink(../init.d/single, ../rc1.d/S07single): File exists
insserv: can not symlink(../init.d/bootlogs, ../rc1.d/S06bootlogs): File exists
insserv: can not symlink(../init.d/exim4, ../rc2.d/S02exim4): File exists
insserv: can not symlink(../init.d/rsyslog, ../rc2.d/S01rsyslog): File exists
insserv: can not symlink(../init.d/xrdp, ../rc2.d/S01xrdp): File exists
insserv: can not symlink(../init.d/minissdpd, ../rc2.d/S19minissdpd): File exists
insserv: can not symlink(../init.d/cups-browsed, ../rc2.d/S05cups-browsed): File exists
insserv: can not symlink(../init.d/avahi-daemon, ../rc2.d/S03avahi-daemon): File exists
insserv: can not symlink(../init.d/fglrx-atieventsd, ../rc2.d/S02fglrx-atieventsd): File exists
insserv: can not symlink(../init.d/mdm, ../rc2.d/S05mdm): File exists
insserv: can not symlink(../init.d/kdm, ../rc2.d/S05kdm): File exists
insserv: can not symlink(../init.d/acpid, ../rc2.d/S02acpid): File exists
insserv: can not symlink(../init.d/dbus, ../rc2.d/S02dbus): File exists
insserv: can not symlink(../init.d/network-manager, ../rc2.d/S03network-manager): File exists
insserv: can not symlink(../init.d/gdomap, ../rc2.d/S02gdomap): File exists
insserv: can not symlink(../init.d/virtualbox-guest-utils, ../rc2.d/S01virtualbox-guest-utils): File exists
insserv: can not symlink(../init.d/speech-dispatcher, ../rc2.d/S02speech-dispatcher): File exists
insserv: can not symlink(../init.d/privoxy, ../rc2.d/S01privoxy): File exists
insserv: can not symlink(../init.d/dirmngr, ../rc2.d/S01dirmngr): File exists
insserv: can not symlink(../init.d/lirc, ../rc2.d/S02lirc): File exists
insserv: can not symlink(../init.d/openvpn, ../rc2.d/S04openvpn): File exists
insserv: can not symlink(../init.d/zfs-share, ../rc2.d/S18zfs-share): File exists
insserv: can not symlink(../init.d/samba, ../rc2.d/S06samba): File exists
insserv: can not symlink(../init.d/avahi-dnsconfd, ../rc2.d/S05avahi-dnsconfd): File exists
insserv: can not symlink(../init.d/plymouth, ../rc2.d/S19plymouth): File exists
insserv: can not symlink(../init.d/bluetooth, ../rc2.d/S03bluetooth): File exists
insserv: can not symlink(../init.d/winbind, ../rc2.d/S07winbind): File exists
insserv: can not symlink(../init.d/cups, ../rc2.d/S05cups): File exists
insserv: can not symlink(../init.d/atd, ../rc2.d/S02atd): File exists
insserv: can not symlink(../init.d/hddtemp, ../rc2.d/S02hddtemp): File exists
insserv: can not symlink(../init.d/saned, ../rc2.d/S05saned): File exists
insserv: can not symlink(../init.d/smartmontools, ../rc2.d/S02smartmontools): File exists
insserv: can not symlink(../init.d/bootlogs, ../rc2.d/S06bootlogs): File exists
insserv: can not symlink(../init.d/pulseaudio, ../rc2.d/S05pulseaudio): File exists
insserv: can not symlink(../init.d/sudo, ../rc2.d/S01sudo): File exists
insserv: can not symlink(../init.d/rmnologin, ../rc2.d/S19rmnologin): File exists
insserv: can not symlink(../init.d/fancontrol, ../rc2.d/S01fancontrol): File exists
insserv: can not symlink(../init.d/ssh, ../rc2.d/S02ssh): File exists
insserv: can not symlink(../init.d/tpconfig, ../rc2.d/S02tpconfig): File exists
insserv: can not symlink(../init.d/grub-common, ../rc2.d/S19grub-common): File exists
insserv: can not symlink(../init.d/loadcpufreq, ../rc2.d/S02loadcpufreq): File exists
insserv: can not symlink(../init.d/rsync, ../rc2.d/S02rsync): File exists
insserv: can not symlink(../init.d/rc.local, ../rc2.d/S19rc.local): File exists
insserv: can not symlink(../init.d/cpufrequtils, ../rc2.d/S03cpufrequtils): File exists
insserv: can not symlink(../init.d/binfmt-support, ../rc2.d/S01binfmt-support): File exists
insserv: can not symlink(../init.d/cron, ../rc2.d/S02cron): File exists
insserv: can not symlink(../init.d/ntp, ../rc2.d/S02ntp): File exists
insserv: can not symlink(../init.d/exim4, ../rc3.d/S02exim4): File exists
insserv: can not symlink(../init.d/rsyslog, ../rc3.d/S01rsyslog): File exists
insserv: can not symlink(../init.d/xrdp, ../rc3.d/S01xrdp): File exists
insserv: can not symlink(../init.d/minissdpd, ../rc3.d/S19minissdpd): File exists
insserv: can not symlink(../init.d/cups-browsed, ../rc3.d/S05cups-browsed): File exists
insserv: can not symlink(../init.d/avahi-daemon, ../rc3.d/S03avahi-daemon): File exists
insserv: can not symlink(../init.d/fglrx-atieventsd, ../rc3.d/S02fglrx-atieventsd): File exists
insserv: can not symlink(../init.d/mdm, ../rc3.d/S05mdm): File exists
insserv: can not symlink(../init.d/kdm, ../rc3.d/S05kdm): File exists
insserv: can not symlink(../init.d/acpid, ../rc3.d/S02acpid): File exists
insserv: can not symlink(../init.d/dbus, ../rc3.d/S02dbus): File exists
insserv: can not symlink(../init.d/network-manager, ../rc3.d/S03network-manager): File exists
insserv: can not symlink(../init.d/gdomap, ../rc3.d/S02gdomap): File exists
insserv: can not symlink(../init.d/virtualbox-guest-utils, ../rc3.d/S01virtualbox-guest-utils): File exists
insserv: can not symlink(../init.d/speech-dispatcher, ../rc3.d/S02speech-dispatcher): File exists
insserv: can not symlink(../init.d/privoxy, ../rc3.d/S01privoxy): File exists
insserv: can not symlink(../init.d/dirmngr, ../rc3.d/S01dirmngr): File exists
insserv: can not symlink(../init.d/lirc, ../rc3.d/S02lirc): File exists
insserv: can not symlink(../init.d/openvpn, ../rc3.d/S04openvpn): File exists
insserv: can not symlink(../init.d/zfs-share, ../rc3.d/S18zfs-share): File exists
insserv: can not symlink(../init.d/samba, ../rc3.d/S06samba): File exists
insserv: can not symlink(../init.d/avahi-dnsconfd, ../rc3.d/S05avahi-dnsconfd): File exists
insserv: can not symlink(../init.d/plymouth, ../rc3.d/S19plymouth): File exists
insserv: can not symlink(../init.d/bluetooth, ../rc3.d/S03bluetooth): File exists
insserv: can not symlink(../init.d/winbind, ../rc3.d/S07winbind): File exists
insserv: can not symlink(../init.d/cups, ../rc3.d/S05cups): File exists
insserv: can not symlink(../init.d/atd, ../rc3.d/S02atd): File exists
insserv: can not symlink(../init.d/hddtemp, ../rc3.d/S02hddtemp): File exists
insserv: can not symlink(../init.d/saned, ../rc3.d/S05saned): File exists
insserv: can not symlink(../init.d/smartmontools, ../rc3.d/S02smartmontools): File exists
insserv: can not symlink(../init.d/bootlogs, ../rc3.d/S06bootlogs): File exists
insserv: can not symlink(../init.d/pulseaudio, ../rc3.d/S05pulseaudio): File exists
insserv: can not symlink(../init.d/sudo, ../rc3.d/S01sudo): File exists
insserv: can not symlink(../init.d/rmnologin, ../rc3.d/S19rmnologin): File exists
insserv: can not symlink(../init.d/fancontrol, ../rc3.d/S01fancontrol): File exists
insserv: can not symlink(../init.d/ssh, ../rc3.d/S02ssh): File exists
insserv: can not symlink(../init.d/tpconfig, ../rc3.d/S02tpconfig): File exists
insserv: can not symlink(../init.d/grub-common, ../rc3.d/S19grub-common): File exists
insserv: can not symlink(../init.d/loadcpufreq, ../rc3.d/S02loadcpufreq): File exists
insserv: can not symlink(../init.d/rsync, ../rc3.d/S02rsync): File exists
insserv: can not symlink(../init.d/rc.local, ../rc3.d/S19rc.local): File exists
insserv: can not symlink(../init.d/cpufrequtils, ../rc3.d/S03cpufrequtils): File exists
insserv: can not symlink(../init.d/binfmt-support, ../rc3.d/S01binfmt-support): File exists
insserv: can not symlink(../init.d/cron, ../rc3.d/S02cron): File exists
insserv: can not symlink(../init.d/ntp, ../rc3.d/S02ntp): File exists
insserv: can not symlink(../init.d/exim4, ../rc4.d/S02exim4): File exists
insserv: can not symlink(../init.d/rsyslog, ../rc4.d/S01rsyslog): File exists
insserv: can not symlink(../init.d/xrdp, ../rc4.d/S01xrdp): File exists
insserv: can not symlink(../init.d/minissdpd, ../rc4.d/S19minissdpd): File exists
insserv: can not symlink(../init.d/cups-browsed, ../rc4.d/S05cups-browsed): File exists
insserv: can not symlink(../init.d/avahi-daemon, ../rc4.d/S03avahi-daemon): File exists
insserv: can not symlink(../init.d/fglrx-atieventsd, ../rc4.d/S02fglrx-atieventsd): File exists
insserv: can not symlink(../init.d/mdm, ../rc4.d/S05mdm): File exists
insserv: can not symlink(../init.d/kdm, ../rc4.d/S05kdm): File exists
insserv: can not symlink(../init.d/acpid, ../rc4.d/S02acpid): File exists
insserv: can not symlink(../init.d/dbus, ../rc4.d/S02dbus): File exists
insserv: can not symlink(../init.d/network-manager, ../rc4.d/S03network-manager): File exists
insserv: can not symlink(../init.d/gdomap, ../rc4.d/S02gdomap): File exists
insserv: can not symlink(../init.d/virtualbox-guest-utils, ../rc4.d/S01virtualbox-guest-utils): File exists
insserv: can not symlink(../init.d/speech-dispatcher, ../rc4.d/S02speech-dispatcher): File exists
insserv: can not symlink(../init.d/privoxy, ../rc4.d/S01privoxy): File exists
insserv: can not symlink(../init.d/dirmngr, ../rc4.d/S01dirmngr): File exists
insserv: can not symlink(../init.d/lirc, ../rc4.d/S02lirc): File exists
insserv: can not symlink(../init.d/openvpn, ../rc4.d/S04openvpn): File exists
insserv: can not symlink(../init.d/zfs-share, ../rc4.d/S18zfs-share): File exists
insserv: can not symlink(../init.d/samba, ../rc4.d/S06samba): File exists
insserv: can not symlink(../init.d/avahi-dnsconfd, ../rc4.d/S05avahi-dnsconfd): File exists
insserv: can not symlink(../init.d/plymouth, ../rc4.d/S19plymouth): File exists
insserv: can not symlink(../init.d/bluetooth, ../rc4.d/S03bluetooth): File exists
insserv: can not symlink(../init.d/winbind, ../rc4.d/S07winbind): File exists
insserv: can not symlink(../init.d/cups, ../rc4.d/S05cups): File exists
insserv: can not symlink(../init.d/atd, ../rc4.d/S02atd): File exists
insserv: can not symlink(../init.d/hddtemp, ../rc4.d/S02hddtemp): File exists
insserv: can not symlink(../init.d/saned, ../rc4.d/S05saned): File exists
insserv: can not symlink(../init.d/smartmontools, ../rc4.d/S02smartmontools): File exists
insserv: can not symlink(../init.d/bootlogs, ../rc4.d/S06bootlogs): File exists
insserv: can not symlink(../init.d/pulseaudio, ../rc4.d/S05pulseaudio): File exists
insserv: can not symlink(../init.d/sudo, ../rc4.d/S01sudo): File exists
insserv: can not symlink(../init.d/rmnologin, ../rc4.d/S19rmnologin): File exists
insserv: can not symlink(../init.d/fancontrol, ../rc4.d/S01fancontrol): File exists
insserv: can not symlink(../init.d/ssh, ../rc4.d/S02ssh): File exists
insserv: can not symlink(../init.d/tpconfig, ../rc4.d/S02tpconfig): File exists
insserv: can not symlink(../init.d/grub-common, ../rc4.d/S19grub-common): File exists
insserv: can not symlink(../init.d/loadcpufreq, ../rc4.d/S02loadcpufreq): File exists
insserv: can not symlink(../init.d/rsync, ../rc4.d/S02rsync): File exists
insserv: can not symlink(../init.d/rc.local, ../rc4.d/S19rc.local): File exists
insserv: can not symlink(../init.d/cpufrequtils, ../rc4.d/S03cpufrequtils): File exists
insserv: can not symlink(../init.d/binfmt-support, ../rc4.d/S01binfmt-support): File exists
insserv: can not symlink(../init.d/cron, ../rc4.d/S02cron): File exists
insserv: can not symlink(../init.d/ntp, ../rc4.d/S02ntp): File exists
insserv: can not symlink(../init.d/exim4, ../rc5.d/S02exim4): File exists
insserv: can not symlink(../init.d/rsyslog, ../rc5.d/S01rsyslog): File exists
insserv: can not symlink(../init.d/xrdp, ../rc5.d/S01xrdp): File exists
insserv: can not symlink(../init.d/minissdpd, ../rc5.d/S19minissdpd): File exists
insserv: can not symlink(../init.d/cups-browsed, ../rc5.d/S05cups-browsed): File exists
insserv: can not symlink(../init.d/avahi-daemon, ../rc5.d/S03avahi-daemon): File exists
insserv: can not symlink(../init.d/fglrx-atieventsd, ../rc5.d/S02fglrx-atieventsd): File exists
insserv: can not symlink(../init.d/mdm, ../rc5.d/S05mdm): File exists
insserv: can not symlink(../init.d/kdm, ../rc5.d/S05kdm): File exists
insserv: can not symlink(../init.d/acpid, ../rc5.d/S02acpid): File exists
insserv: can not symlink(../init.d/dbus, ../rc5.d/S02dbus): File exists
insserv: can not symlink(../init.d/network-manager, ../rc5.d/S03network-manager): File exists
insserv: can not symlink(../init.d/gdomap, ../rc5.d/S02gdomap): File exists
insserv: can not symlink(../init.d/virtualbox-guest-utils, ../rc5.d/S01virtualbox-guest-utils): File exists
insserv: can not symlink(../init.d/speech-dispatcher, ../rc5.d/S02speech-dispatcher): File exists
insserv: can not symlink(../init.d/privoxy, ../rc5.d/S01privoxy): File exists
insserv: can not symlink(../init.d/dirmngr, ../rc5.d/S01dirmngr): File exists
insserv: can not symlink(../init.d/lirc, ../rc5.d/S02lirc): File exists
insserv: can not symlink(../init.d/openvpn, ../rc5.d/S04openvpn): File exists
insserv: can not symlink(../init.d/zfs-share, ../rc5.d/S18zfs-share): File exists
insserv: can not symlink(../init.d/samba, ../rc5.d/S06samba): File exists
insserv: can not symlink(../init.d/avahi-dnsconfd, ../rc5.d/S05avahi-dnsconfd): File exists
insserv: can not symlink(../init.d/plymouth, ../rc5.d/S19plymouth): File exists
insserv: can not symlink(../init.d/bluetooth, ../rc5.d/S03bluetooth): File exists
insserv: can not symlink(../init.d/winbind, ../rc5.d/S07winbind): File exists
insserv: can not symlink(../init.d/cups, ../rc5.d/S05cups): File exists
insserv: can not symlink(../init.d/atd, ../rc5.d/S02atd): File exists
insserv: can not symlink(../init.d/hddtemp, ../rc5.d/S02hddtemp): File exists
insserv: can not symlink(../init.d/saned, ../rc5.d/S05saned): File exists
insserv: can not symlink(../init.d/smartmontools, ../rc5.d/S02smartmontools): File exists
insserv: can not symlink(../init.d/bootlogs, ../rc5.d/S06bootlogs): File exists
insserv: can not symlink(../init.d/pulseaudio, ../rc5.d/S05pulseaudio): File exists
insserv: can not symlink(../init.d/sudo, ../rc5.d/S01sudo): File exists
insserv: can not symlink(../init.d/rmnologin, ../rc5.d/S19rmnologin): File exists
insserv: can not symlink(../init.d/fancontrol, ../rc5.d/S01fancontrol): File exists
insserv: can not symlink(../init.d/ssh, ../rc5.d/S02ssh): File exists
insserv: can not symlink(../init.d/tpconfig, ../rc5.d/S02tpconfig): File exists
insserv: can not symlink(../init.d/grub-common, ../rc5.d/S19grub-common): File exists
insserv: can not symlink(../init.d/loadcpufreq, ../rc5.d/S02loadcpufreq): File exists
insserv: can not symlink(../init.d/rsync, ../rc5.d/S02rsync): File exists
insserv: can not symlink(../init.d/rc.local, ../rc5.d/S19rc.local): File exists
insserv: can not symlink(../init.d/cpufrequtils, ../rc5.d/S03cpufrequtils): File exists
insserv: can not symlink(../init.d/binfmt-support, ../rc5.d/S01binfmt-support): File exists
insserv: can not symlink(../init.d/cron, ../rc5.d/S02cron): File exists
insserv: can not symlink(../init.d/ntp, ../rc5.d/S02ntp): File exists
insserv: can not symlink(../init.d/hwclock.sh, ../rc6.d/K07hwclock.sh): File exists
insserv: can not symlink(../init.d/console-setup, ../rcS.d/S20console-setup): File exists
insserv: can not symlink(../init.d/mountnfs.sh, ../rcS.d/S17mountnfs.sh): File exists
insserv: can not symlink(../init.d/mountnfs-bootclean.sh, ../rcS.d/S18mountnfs-bootclean.sh): File exists
insserv: can not symlink(../init.d/x11-common, ../rcS.d/S21x11-common): File exists
insserv: can not symlink(../init.d/kbd, ../rcS.d/S19kbd): File exists
insserv: can not symlink(../init.d/alsa-utils, ../rcS.d/S21alsa-utils): File exists
insserv: can not symlink(../init.d/fuse, ../rcS.d/S21fuse): File exists
insserv: can not symlink(../init.d/lm-sensors, ../rcS.d/S21lm-sensors): File exists
insserv: can not symlink(../init.d/dns-clean, ../rcS.d/S21dns-clean): File exists
insserv: can not symlink(../init.d/plymouth-log, ../rcS.d/S21plymouth-log): File exists
insserv: can not symlink(../init.d/virtualbox-guest-x11, ../rcS.d/S21virtualbox-guest-x11): File exists
insserv: can not symlink(../init.d/bootmisc.sh, ../rcS.d/S21bootmisc.sh): File exists
insserv: can not symlink(../init.d/mintsystem, ../rcS.d/S21mintsystem): File exists
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-3.10-2-amd64
cryptsetup: WARNING: could not determine root device from /etc/fstab
Setting up zfs-initramfs (0.6.2-3) ...
Processing triggers for libc-bin ...
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-3.10-2-amd64
cryptsetup: WARNING: could not determine root device from /etc/fstab

Current status: 0 updates [-12].
468.172 user_cpu 79.280 kernel_cpu 25:40.99 total_time 35.5%CPU {0W 0X 0D 0K 110376M 3066F 7538584R 659336I 191720O 0r 0s 0k 131156w 85085c}

$ cat /var/lib/dkms/zfs/0.6.2/build/make.log
DKMS make.log for zfs-0.6.2 for kernel 3.10-2-amd64 (x86_64)
Wed  1 Jan 14:38:27 CET 2014
make: *** No targets specified and no makefile found.  Stop.

[FransUrbo]

Yes, the whole point with the ZoL repository is to be able to do upgrades from one version to the next without problem.

So from you output, it seems you're trying to do exactly the same thing I did a few hours ago to tripple check that my new package works - upgrade from 0.6.2-2 to 0.6.2-3....

Please give me the output of the command dpkg -l *spl* *zfs* | grep ^i.

You should get something like this:

root@debianzfsroot:~# dpkg -l \*spl\* \*zfs\* | grep ^i
ii  debian-zfs                         7~wheezy                   amd64        Native ZFS filesystem metapackage for Debian.
ii  libzfs1                            0.6.2-3                    amd64        Native ZFS filesystem library for Linux
ii  spl                                0.6.2-2                    amd64        Solaris Porting Layer user-space utilities for Linux
ii  spl-dkms                           0.6.2-2                    all          Solaris Porting Layer kernel modules for Linux
ii  zfs-dkms                           0.6.2-3                    all          Native ZFS filesystem kernel modules for Linux
ii  zfs-initramfs                      0.6.2-3                    amd64        Native ZFS root filesystem capabilities for Linux
ii  zfsonlinux                         2~wheezy                   all          archive.zfsonlinux.org trust package
ii  zfsutils                           0.6.2-3                    amd64        command-line tools to manage ZFS filesystems

The important line here is the spl-dkms.

[RJVB]

But I did answer your questions! I simply didn't extract the error message from the upgrade output, which I copied in full!

$ dpkg -l \*spl\* \*zfs\* | grep ^i
ii  debian-zfs             7~wheezy         amd64            Native ZFS filesystem metapackage for Debian.
ii  hfsplus                1.0.4-12         amd64            Tools to access HFS+ formatted volumes
ii  konqueror-nsplugins    4:4.8.4-2        amd64            Netscape plugin support for Konqueror
ii  libzfs-dev             0.6.2-3          amd64            Native ZFS filesystem development files for Linux
ii  libzfs1                0.6.2-3          amd64            Native ZFS filesystem library for Linux
ii  printer-driver-splix   2.0.0+svn306-2   amd64            Driver for Samsung and Xerox SPL2 and SPLc laser p
ii  spl                    0.6.2-2          amd64            Solaris Porting Layer user-space utilities for Lin
ii  spl-core               1.0~pre6-4       amd64            SPL Programming Language
ii  spl-dkms               0.6.2-2          all              Solaris Porting Layer kernel modules for Linux
ii  spl-mysql              1.0~pre6-4       amd64            SPL Programming Language -- MySQL adapter
ii  spl-postgres           1.0~pre6-4       amd64            SPL Programming Language -- postgres adapter
ii  spl-sdl                1.0~pre6-4       amd64            SPL Programming Language -- SDL adapter
ii  spl-sqlite             1.0~pre6-4       amd64            SPL Programming Language -- sqlite adapter
ii  spl-webspl             1.0~pre6-4       amd64            SPL based web application framework
ii  spl-xml                1.0~pre6-4       amd64            SPL Programming Language -- XML adapter
ii  zfs-dkms               0.6.2-3          all              Native ZFS filesystem kernel modules for Linux
ii  zfs-initramfs          0.6.2-3          amd64            Native ZFS root filesystem capabilities for Linux
ii  zfsonlinux             2~wheezy         all              archive.zfsonlinux.org trust package
ii  zfsutils               0.6.2-3          amd64            command-line tools to manage ZFS filesystems

[RJVB]

I realised the issue seemed to be with spl-dkms, so I did:

$ sudo aptitude reinstall spl-dkms
The following packages will be REINSTALLED:
  spl-dkms 
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 551 kB of archives. After unpacking 0 B will be used.
Get: 1 http://archive.zfsonlinux.org/debian/ wheezy/main spl-dkms all 0.6.2-2 [551 kB]
Fetched 551 kB in 3s (168 kB/s)   
(Reading database ... 312529 files and directories currently installed.)
Preparing to replace spl-dkms 0.6.2-2 (using .../spl-dkms_0.6.2-2_all.deb) ...

------------------------------
Deleting module version: 0.6.2
completely from the DKMS tree.
------------------------------
Done.
Unpacking replacement spl-dkms ...
Setting up spl-dkms (0.6.2-2) ...
Loading new spl-0.6.2 DKMS files...
Building only for 3.10-2-amd64
Building initial module for 3.10-2-amd64
Error! Bad return status for module build on kernel: 3.10-2-amd64 (x86_64)
Consult /var/lib/dkms/spl/0.6.2/build/make.log for more information.

$ cat /var/lib/dkms/spl/0.6.2/build/make.log
DKMS make.log for spl-0.6.2 for kernel 3.10-2-amd64 (x86_64)
Wed  1 Jan 15:35:40 CET 2014
make  all-recursive
make[1]: Entering directory `/var/lib/dkms/spl/0.6.2/build'
Making all in module
make[2]: Entering directory `/var/lib/dkms/spl/0.6.2/build/module'
make -C /lib/modules/3.10-2-amd64/build SUBDIRS=`pwd`  CONFIG_SPL=m modules
make[3]: Entering directory `/usr/src/linux-headers-3.10-2-amd64'
  CC [M]  /var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-debug.o
  CC [M]  /var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-proc.o
  CC [M]  /var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-kmem.o
  CC [M]  /var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-thread.o
  CC [M]  /var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-taskq.o
  CC [M]  /var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-rwlock.o
  CC [M]  /var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-vnode.o
/var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-vnode.c: In function ‘vn_remove’:
/var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-vnode.c:461:2: error: implicit declaration of function ‘path_lookup’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[7]: *** [/var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-vnode.o] Error 1
make[6]: *** [/var/lib/dkms/spl/0.6.2/build/module/spl] Error 2
make[5]: *** [_module_/var/lib/dkms/spl/0.6.2/build/module] Error 2
make[4]: *** [sub-make] Error 2
make[3]: *** [all] Error 2
make[3]: Leaving directory `/usr/src/linux-headers-3.10-2-amd64'
make[2]: *** [modules] Error 2
make[2]: Leaving directory `/var/lib/dkms/spl/0.6.2/build/module'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/lib/dkms/spl/0.6.2/build'
make: *** [all] Error 2

Is it possible not to pass -Werror=implicit-function-declaration

[FransUrbo]

Ok, so you have spl-dkms and the right version...

/var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-vnode.c: In function ‘vn_remove’:
/var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-vnode.c:461:2: error: implicit declaration of function ‘path_lookup’ [-Werror=implicit-function-declaration]

It seems that there's a problem building for your kernel version (3.10). Where did you get it from? Built it yourself? I'm not sure that the released version of spl/zfs works for something that new.... How did you get the old version built?! You DID run spl/zfs from a deb package on this kernel before the upgrade, right?

[FransUrbo]

On my bog standard Debian GNU/Linux Wheezy virtual machine, using a ZFS and a /boot on ext3 and the standard kernel linux-image-3.2.0-4-amd64 and digging deeper into this I see:

The path_lookup() function has been renamed to kern_path_parent()

It checks include/linux/namei.h in the kernel directory. So on my test machine, this looks like:

root@debianzfsroot:/usr/src# ll linux-headers-3.2.0-4-*/include/linux/namei.h
-rw-r--r-- 1 root root 3083 Sep 20 03:13 linux-headers-3.2.0-4-common/include/linux/namei.h
root@debianzfsroot:/usr/src# grep kern_path_parent linux-headers-3.2.0-4-*/include/linux/namei.h
extern int kern_path_parent(const char *, struct nameidata *);

However, I downloaded 3.10.1 and 3.10.25 from kernel.org just to double check, and kern_path_parent doesn't exist there. So I'm currently stumped.

Could you, just to tripple check and make absolutly sure, boot into the default 3.2.0-4-amd64 kernel?

[RJVB]

Yes, I built on this very system, that is, I installed debian-zfs and let that do its thing. The kernel is from the Linux Mint Debian install, a semi-rolling distribution based on Debian Testing.

I saw the same things re: path_lookup and kern_path_parent, yet I'm sure I managed to build the previous spl-dkms package ...

Erm, can I boot into my old 3.2 kernel given I've never installed debian-zfs on there?

[RJVB]

On Wednesday January 01 2014 16:09:08 Turbo Fredriksson wrote:

Could you, just to tripple check and make absolutly sure, boot into the default 3.2.0-4-amd64 kernel?

As I thought, the 3.2 kernel is just listed because it was already there before I moved to zfs - and it never occurred to me to install zfs on that kernel too.

In fact, I had a hard time booting back into my default, 3.10, kernel - had to mount the pool by hand at least twice from within the busybox env. :-/

[FransUrbo]

Yes, I built on this very system

Weird, very, very weird!

I can't explain it! It should not have been possible to build the module(s) on that (this) kernel...

I'm sure I managed to build the previous spl-dkms package ...

Stupid (and possibly rude) question: How sure? Erm, can I boot into my old 3.2 kernel given I've never installed debian-zfs on there?

Right, no. Not since you're using a ZFS root...

Check the manpage for 'dkms'. It should have an option to build a module for a specific kernel... Use that to build a module for the 3.2 version and if that succeeds, try booting that again. Don't forget to update the initrd for that kernel to...

Something like this:

1. dkms <option to build spl for 3.2.0-4-amd64>
2. dkms <option to build zfs for 3.2.0-4-amd64>
3. update-initramfs -u -k 3.2.0-4-amd64

If all these commands (and only if!) succeed in succession, then you can try booting the 3.2 kernel...

[RJVB]

On Wednesday January 01 2014 16:41:04 Turbo Fredriksson wrote:

I'm sure I managed to build the previous spl-dkms package ...

Stupid (and possibly rude) question: How sure?

Heh. If it just my memory, you're right to have your doubts. But I had just reinstalled the machine to Mint Debian, I've certainly not tried to install zfs before that!

Check the manpage for 'dkms'. It should have an option to build a module for a specific kernel... Use that to build a module for the 3.2 version and if that succeeds, try booting that again. Don't forget to update the initrd for that kernel to...

Something like this:

1. dkms <option to build spl for 3.2.0-4-amd64>
2. dkms <option to build zfs for 3.2.0-4-amd64>
3. update-initramfs -u -k 3.2.0-4-amd64

If all these commands (and only if!) succeed in succession, then you can try booting the 3.2 kernel...

Will look into that. I'm first trying to get the module to build by hand for 3.10

When I do a very brute

extern int path_lookup();

at the top of spl-vnode.c the module builds without further issues. But how to check if I'm not referencing an inexistant symbol other than the hard way?

[RJVB]

https://github.com/zfsonlinux/spl/issues/308 unrelated?

[RJVB]

http://sourceware.org/bugzilla/show_bug.cgi?id=13055 ?

https://github.com/zfsonlinux/spl/pull/179 seems very relevant, though, https://github.com/zfsonlinux/spl/pull/177 even more!

[FransUrbo]

At first glance, zfsonlinux/spl#308 doesn't look related. Not considering you're both having problem building on 3.10..

And your extern line won't work anyway, since the sycall just isn't available in your kernel... So it might compile, but probably not link... Or crash horribly once you try to load it...

Simples solution, if you insist on using the 3.10 kernel, is to find the relevant commits in the GIT repo's, manually apply them and then build. Or simply go with the GIT repo all together (both for spl and zfs in that case). That way you're on the bleeding edge. Usually not a good idea and I would understand that you're skeptical, but when it comes to spl/zfs, at this moment it is a good idea - there's heavy development of ZoL and soooo many bugs have been fixed.

But my recommendation is to ignore 3.10 (for now - ZoL v0.6.3 is due 'very soon').

[RJVB]

On Wednesday January 01 2014 17:46:27 Turbo Fredriksson wrote:

Simples solution, if you insist on using the 3.10 kernel, is to find the relevant commits in the GIT repo's, manually apply them and then build. Or simply go with the GIT repo all together (both for spl and zfs in that case). That way you're on the bleeding edge. Usually not a good idea and I would understand that you're skeptical, but when it comes to spl/zfs, at this moment it is a good idea - there's heavy development of ZoL and soooo many bugs have been fixed.

I know, I also use MacZFS :) Indeed, I was also planning to apply the spl patches from one of the issues I cited, and see if that'd get me somewhere. Curiously, when I did

dkms spl/0.6.2 -k 3.2.0-4/amd64

it failed because of path_lookup, whereas it ought to have found kern_path_parent ...

But my recommendation is to ignore 3.10 (for now - ZoL v0.6.3 is due 'very soon').

That'd be, ignore 0.6.2 . I find the 3.10 kernel to be much better for the netbook I'm running on! Also, as you've seen, kern_path_parent hasn't been exported since kernel 3.6, so maybe it's time the solution using kern_path_locked is generalised for the more recent kernels? ;)

[FransUrbo]

Right. Why not just remove the ZoL packages and build your own for 3.10 from GIT and install those packages instead?

[RJVB]

Say, when did 0.6.2 come out? I was just looking at my other zfs system (a VM, not touched since about a week) and saw it has the spl and zfs 0.6.2 sources in /usr/src ...

[FransUrbo]

Aug 22, 2013 - commit 0c28fb480836ab7bb1bbf8de6e572d2443273396.

[RJVB]

On Wednesday January 01 2014 18:58:04 Turbo Fredriksson wrote:

Aug 22, 2013 - commit 0c28fb480836ab7bb1bbf8de6e572d2443273396.

Then why did apt-get upgrade try to update them?

The mystery remains why they ever built for me... I just saw that the modifications from spl issue 177 are still there, so in theory the build procedure should detect the presence of kern_path_locked ...

[RJVB]

I may be onto something. I cloned the VM I mentioned into a zvol, chrooted into it and then did a dkms build spl/0.6.2, which went fine. The same in the real root still gave problems, but now I could compare the config.log's .

If anything, my "true" Linux Mint Debian system is detected as an ubuntu system, and configure wants to use /lib/modules/3.10-2-rt-amd64/build for kernel sources AND build.

in the configure script, one has

        { $as_echo "$as_me:${as_lineno-$LINENO}: checking linux distribution" >&5
$as_echo_n "checking linux distribution... " >&6; }
        if test -f /etc/toss-release ; then
                VENDOR=toss ;
        elif test -f /etc/fedora-release ; then
                VENDOR=fedora ;
        elif test -f /etc/redhat-release ; then
                VENDOR=redhat ;
        elif test -f /etc/gentoo-release ; then
                VENDOR=gentoo ;
        elif test -f /etc/arch-release ; then
                VENDOR=arch ;
        elif test -f /etc/SuSE-release ; then
                VENDOR=sles ;
        elif test -f /etc/slackware-version ; then
                VENDOR=slackware ;
        elif test -f /etc/lunar.release ; then
                VENDOR=lunar ;
        elif test -f /etc/lsb-release ; then
                VENDOR=ubuntu ;
        elif test -f /etc/debian_version ; then
                VENDOR=debian ;
        else
                VENDOR= ;
        fi

and my real system (Patux) has

$ cat /etc/lsb-release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=1
DISTRIB_CODENAME=debian
DISTRIB_DESCRIPTION="LMDE Cinnamon Edition"

The file is even very new, probably updated when I did the apt-get upgrade earlier, but it's apparently not a member of one of my packages. Note how it is clearly stated that this is a Debian distribution ... and /etc/debian_version is there but of course ignored by the above code. The VM does have /etc/debian_version even though it's a LMDE system too ... but one that was created from a Debian/Testing by simply modifying apt/sources.list .

[RJVB]

And moving /etc/lsb_release out of the way was enough to get the spl module to build.

Accommodating for Linux Mint Debian shouldn't be hard in configure (test for debian_version before testing for lsb_release, OR parse lsb_release), but a bit less so in dkms.conf (where lsb_release -is is invoked). Any ideas?

[FransUrbo]

Aug 22, 2013 - commit 0c28fb480836ab7bb1bbf8de6e572d2443273396.

Then why did apt-get upgrade try to update them?

Because I did some changes to the zfs-initramfs package. Basically, you where (and still is) running 0.6.2 and there is no change to the actual code. The only change was a packaging fix I applied.

And I only updated zfs. The spl package have been untouched since Oct 15 so that wasn't updated in your update.

The mystery remains why they ever built for me...

Indeed!

If anything, my "true" Linux Mint Debian system is detected as an ubuntu system

Not necessarily wrong... configure wants to use /lib/modules/3.10-2-rt-amd64/build for kernel sources AND build.

And this is wrong?

/etc/debian_version is there but of course ignored by the above code

@behlendorf Simplest fix (so I/we don't have to parse the lsb_release file) might just be to move the check for debian_version before checking lsb_release.

@RJVB So you're saying that the only thing you did was remove the lsb-release file and everything worked as it was supposed?

[RJVB]

Turns out it's a little more .. intricate. On Linux Mint, /etc/lsb_release is (re)generated on each boot through the mintsystem package, based on /etc/linuxmint/info, itself member of the mint-info-debian-cinnamon package (probably, of a mint-info-debian-* package as LinuxMint is available with several different default GUIs).

Just to be exhaustive: I've not modified the code in configure, so apparently the option passed via dkms.conf primes. That's not to say it might be cleaner to invert the checking order anyway, debian_version before lsb-release ...

I'll raise an issue with LinuxMint, but presuming they have good reasons to code /etc/lsb_release as they do, the cleanest option might be to modify dkms.conf :

PRE_BUILD="configure
  --prefix=/usr
  --with-config=kernel
  --with-linux=$(case `lsb_release -is` in
                   (Debian)
                     if [ -e ${kernel_source_dir/%build/source} ]
                     then
                       echo ${kernel_source_dir/%build/source}
                     else
                       # This is a kpkg exception for Proxmox 2.0
                       echo ${kernel_source_dir}
                     fi
                     ;;
                   (LinuxMint)
                     if [ "`lsb_release -cs`" = "debian" ]
                     then
                       # This is Linux Mint Debian
                       echo ${kernel_source_dir/%build/source}
                     else
                       # This must be a Linux Mint variant based on Ubuntu
                       echo ${kernel_source_dir}
                     fi
                     ;;
                   (*)
                     echo ${kernel_source_dir}
                     ;;
                 esac)
  --with-linux-obj=${kernel_source_dir}
"

(same (LinuxMint) case in the zfs dkms.conf, of course)

[FransUrbo]

               (LinuxMint)
                 if [ "`lsb_release -cs`" = "debian" ]
                 then
                   # This is Linux Mint Debian
                   echo ${kernel_source_dir/%build/source}
                 else
                   # This must be a Linux Mint variant based on Ubuntu
                   echo ${kernel_source_dir}
                 fi

I don't like this. Not that it won't work, but because it's to ... 'hardcoded'. There's a lot of Debian GNU/Linux derivates out there, and we can't add them all! Well, we could I guess, but it's not a very effective way to do it...

There is no way to be sure that some other dist doesn't also say 'debian' in this case...

And by the way:

$ cat /etc/lsb-release DISTRIB_ID=LinuxMint DISTRIB_RELEASE=1 DISTRIB_CODENAME=debian DISTRIB_DESCRIPTION="LMDE Cinnamon Edition"

lsb_release -cs SHOULD in their version really say cinnamon, not debian. Since you're already talking to them, maybe you could file a bug about this in their own tracker?

configure wants to use /lib/modules/3.10-2-rt-amd64/build for kernel sources AND build.

Can you try to find out why it tries to find the 'build' directory there? That is for a RT (RealTime) kernel, and that doesn't seem to be the one you're using!

What does uname -r tell you? If I remember correctly, it should say 3.10-2-amd64, right? Without the 'rt' bit.

Personally, I think the problem is that it finds the wrong modules directory so we need to figure that out...

[FransUrbo]

dkms spl/0.6.2 -k 3.2.0-4/amd64

Looking at this again, and checking with the manpage of dkms, this is wrong. It should have been:

dkms spl/0.6.2 -k 3.2.0-4-amd64/amd64

because this was in the update log earlier:

Found linux image: /boot/vmlinuz-3.2.0-4-amd64

This can be an indication to why it tries to look in the /lib/modules/3.10-2-rt-amd64 directory instead of /lib/modules/3.10-2-amd64.

Your update log states:

Setting up zfs-dkms (0.6.2-3) ...
Loading new zfs-0.6.2 DKMS files...
Building only for 3.10-2-amd64
Building initial module for 3.10-2-amd64
configure: error:
        *** Please make sure the kmod spl devel <kernel> package for your
        *** distribution is installed then try again.  If that fails you
        *** can specify the location of the spl objects with the
        *** '--with-spl-obj=PATH' option.
Error! Bad return status for module build on kernel: 3.10-2-amd64 (x86_64)
Consult /var/lib/dkms/zfs/0.6.2/build/make.log for more information.

and your build log:

make -C /lib/modules/3.10-2-amd64/build SUBDIRS=`pwd`  CONFIG_SPL=m modules
make[3]: Entering directory `/usr/src/linux-headers-3.10-2-amd64'

So it DOES clearly find the correct kernel here automatically, with the correct build directory!

Now, the question is: why did it find a 'rt' libdir?

I need to ask you again: Did moving lsb_release out of the way allow you to build spl and zfs for the 3.10 kernel? Was that the only thing you did? Did that/those module work? Are you running on them right now?

Because:

make[2]: Entering directory `/var/lib/dkms/spl/0.6.2/build/module'
make -C /lib/modules/3.10-2-amd64/build SUBDIRS=`pwd`  CONFIG_SPL=m modules
make[3]: Entering directory `/usr/src/linux-headers-3.10-2-amd64'
[...]
/var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-vnode.c: In function ‘vn_remove’:
/var/lib/dkms/spl/0.6.2/build/module/spl/../../module/spl/spl-vnode.c:461:2: error: implicit declaration of function ‘path_lookup’ [-Werror=implicit-function-declaration]

I find it odd to say the least, that just because you moved the lsb_release file out of the way, it suddenly started to be able to compile spl-vnode.c! It clearly states here that it DO find the correct source directory for the kernel, not the 'rt' one...

You really need to explain this, I'm having a really hard time understanding your problem and what you're doing to try to replicate this:

I may be onto something. I cloned the VM I mentioned into a zvol, chrooted into it and then did a dkms build spl/0.6.2, which went fine. The same in the real root still gave problems, but now I could compare the config.log's .

What VM is that? A Mint system or a Debian GNU/Linux one? What version? If anything, my "true" Linux Mint Debian system is detected as an ubuntu system, and configure wants to use /lib/modules/3.10-2-rt-amd64/build for kernel sources AND build.

Why the 'rt' directory?

[RJVB]

On Thursday January 02 2014 15:41:10 Turbo Fredriksson wrote:

Looking at this again, and checking with the manpage of dkms, this is wrong. It should have been:

dkms spl/0.6.2 -k 3.2.0-4-amd64/amd64

Yes, indeed. Apparently you have a better manpage than I, but this is what I also figured out in the end.

Your update log states:

Setting up zfs-dkms (0.6.2-3) ... Loading new zfs-0.6.2 DKMS files... Building only for 3.10-2-amd64 Building initial module for 3.10-2-amd64 configure: error: * Please make sure the kmod spl devel package for your * distribution is installed then try again. If that fails you * can specify the location of the spl objects with the * '--with-spl-obj=PATH' option. Error! Bad return status for module build on kernel: 3.10-2-amd64 (x86_64) Consult /var/lib/dkms/zfs/0.6.2/build/make.log for more information.

So it DOES clearly find the correct kernel here automatically, with the correct build directory!

Now, the question is: why did it find a 'rt' libdir?

include dir!

Well, I think that in the end there are 2 issues. The zfs build failure you cited above turns out to have nothing to do with what linux header files are being used. It simply means just what it says (except that it could be more explicit): there's something not kosher with the spl installation. I discovered that earlier today when I rebuilt spl with slightly different optimisation flags (to try and get maximum performance out of this netbook...). The spl rebuild went fine with the dkms.conf mod I posted, but I didn't install it - yet. Then the dkms build of zfs failed the same way as above. Apparently the build procedure detected that I had rebuilt spl, but not yet installed it. Installing it with dkms install made the zfs build go through OK.

So chances are that during that upgrade step, the spl build failed but the working dir remained in place in /var/lib/dkms/spl where it was detected by the zfs build. Then again, I don't know (yet) if zfs can be build without the spl build directory (dkms build zfs/0.62 spent a LONG time "checking spl build directory" only to tell me it didn't exist with an identical error message as above).

How would you have me check why the rt directory was chosen? I have the headers on here because at some point I installed a complete header package, but not the kernel (though it's on my list of things to play with :) ). Is there reason to suspect that the rt kernel would lack headers that spl and/or zfs need? Rather, is there any reason to suspect that spl and/or zfs depend on kernel features that are susceptible to be different in the rt version of a given kernel? AFAIK an RT kernel has a set of additional extensions (like the self-built Xenomai kernel I once ran with).

I need to ask you again: Did moving lsb_release out of the way allow you to build spl and zfs for the 3.10 kernel? Was that the only thing you did? Did that/those module work? Are you running on them right now?

Yes, the sole act of moving lsb-release out of the way allowed me to build (and install) spl yesterday. As I mentioned, dkms stopped functioning afterwards for a reason I haven't been able to understand, even after a reboot (i.e. running the new spl). Putting back the file and modifying it so lsb_release -is says Debian instead of LinuxMint allowed me to build and install zfs. I then built and installed spl & zfs for the 3.2.0-4 kernel, and verified that I could boot both that and the 3.10 kernel. So yes, at least spl built WITHOUT lsb-release worked. I am now running the optimised spl & zfs modules that I built earlier, with the dkms.conf mod I posted.

I find it odd to say the least, that just because you moved the lsb_release file out of the way, it suddenly started to be able to compile spl-vnode.c! It clearly states here that it DO find the correct source directory for the kernel, not the 'rt' one...

Whatever the reason, it didn't detect the presence of neither kern_path_locked nor kern_path_parent.

I may be onto something. I cloned the VM I mentioned into a zvol, chrooted into it and then did a dkms build spl/0.6.2, which went fine. The same in the real root still gave problems, but now I could compare the config.log's .

What VM is that? A Mint system or a Debian GNU/Linux one? What version?

Heh, it's a VM that once ran Debian/Stable (last year, when it was Squeeze if memory serves me well), that I then "evolved" into a Debian/Testing system only to decide I preferred something a little less bleeding-edge, so I took the /etc/apt/sources.list from the Linux Mint Debian system and let apt-get {dist-,}upgrade have its way. Arguably it's a bit of a Frankenmonster esp. since I also kicked the whole Cinnamon environment off (including most of gnome), but it runs fine. Apparently it never received the mintsystem package, though.

If anything, my "true" Linux Mint Debian system is detected as an ubuntu system, and configure wants to use /lib/modules/3.10-2-rt-amd64/build for kernel sources AND build.

My point was that it wanted to use /build for the source directory, instead of /source, NOT that it looked in the rt directory (TBH I didn't notice that).

Why the 'rt' directory?

No idea, but maybe if you tell me where kernel_source_dir and %build are defined that are used in dkms.conf I can begin to try and understand?

[RJVB]

I understand you don't like the tailored mod to dkms.conf ...

[FransUrbo]

I have the headers on here because at some point I installed a complete header package, but not the kernel (though it's on my list of things to play with :)

Ahh..... Maybe that's the problem then!

If nothing have changed without me noticing it, spl/zfs won't work with a RealTime kernel!

Is there reason to suspect that the rt kernel would lack headers that spl and/or zfs need?

A rt kernel is, from what I have understood (which might be wrong - haven't bothered to investigate further) is a 'stripped down and more economical' kernel compiled with preemption (which is, what I understand) is why spl/zfs fails for some reason.

So yes, at least spl built WITHOUT lsb-release worked.

Ok, thanx.

Could you just try without your modifications, and remove any headers and stuff that you don't use (the 'rt' packages)?

My point was that it wanted to use /build for the source directory, instead of /source, NOT that it looked in the rt directory (TBH I didn't notice that).

What's the target of those two links?

[RJVB]

On Thursday January 02 2014 15:41:10 Turbo Fredriksson wrote:

If anything, my "true" Linux Mint Debian system is detected as an ubuntu system, and configure wants to use /lib/modules/3.10-2-rt-amd64/build for kernel sources AND build.

Why the 'rt' directory?

Looking further into this, the rt headers are slightly more voluminous, but whatever caused them to be picked earlier, it is no longer the case even when building spl with the stock /etc/lsb-release and the stock dkms.conf .

However, /lib/modules/3.10-2-rt-amd64/build points to /usr/src/linux-headers-3.10-2-rt-amd64 instead of to /usr/src/linux-headers-3.10-2-rt-common , and that makes a huge difference (to the point I'm surprised the build doesn't fail on a missing header, actually). Looking at how configure is invoked (recorded in config.log), we see

/var/lib/dkms/spl/0.6.2/build/configure --prefix=/usr --with-config=kernel --with-linux=/lib/modules/3.10-2-amd64/build --with-linux-obj=/lib/modules/3.10-2-amd64/build

and that's (apparently) simply because the stock dkms.conf fails to recognise the system for a Debian system...

[FransUrbo]

/lib/modules/3.10-2-rt-amd64/build points to /usr/src/linux-headers-3.10-2-rt-amd64

No, this is correct.

instead of to /usr/src/linux-headers-3.10-2-rt-common

... because that's the source directory..

/var/lib/dkms/spl/0.6.2/build/configure --prefix=/usr --with-config=kernel --with-linux=/lib/modules/3.10-2-amd64/build --with-linux-obj=/lib/modules/3.10-2-amd64/build

Is this WITH your modifications? What does it say WITOUT them?

Actually, I think it should have said:

--with-config=kernel --with-linux=/lib/modules/3.10-2-amd64/source --with-linux-obj=/lib/modules/3.10-2-amd64/build

I have to double check that. I just installed the rt headers (installed linux-headers-3.2.0-4-common-rt and linux-headers-3.2.0-4-rt-amd64 and my build also failed:

configure: error:
        *** Please make sure the kmod spl devel <kernel> package for your
        *** distribution is installed then try again.  If that fails you
        *** can specify the location of the spl objects with the
        *** '--with-spl-obj=PATH' option.

However, my make.log say:

DKMS make.log for zfs-0.6.2 for kernel 3.2.0-4-rt-amd64 (x86_64)
Thu Jan  2 17:09:00 UTC 2014
make: *** No targets specified and no makefile found.  Stop.

while yours say:

DKMS make.log for zfs-0.6.2 for kernel 3.10-2-amd64 (x86_64)
Wed  1 Jan 14:38:27 CET 2014
make: *** No targets specified and no makefile found.  Stop.

Notice the 'rt' part in mine..

But I'm fairly certain the rt headers have something to do with it anyway! Please deinstall them and try again (without any modifications!).

[FransUrbo]

Removing the rt headers and setting verbose=1 in the dkms config file mentioned above and running

dkms build spl/0.6.2 -k `uname -r`/amd64 2>&1 | tee /tmp/x

I see:

checking kernel source directory... /lib/modules/3.2.0-4-amd64/source
checking kernel build directory... /lib/modules/3.2.0-4-amd64/build
checking kernel source version... 3.2.0-4-amd64

and:

root@debianzfsroot:~# ll /lib/modules/3.2.0-4-amd64/{build,source}
lrwxrwxrwx 1 root root 36 Sep 20 03:46 /lib/modules/3.2.0-4-amd64/build -> /usr/src/linux-headers-3.2.0-4-amd64
lrwxrwxrwx 1 root root 37 Sep 20 03:46 /lib/modules/3.2.0-4-amd64/source -> /usr/src/linux-headers-3.2.0-4-common

Which is correct for me.

[FransUrbo]

Something is indeed really weird here!

Installing the 'rt' headers again, doing a force purge of zfs-dkms and then installing it again gives me all the correct values:

Loading new zfs-0.6.2 DKMS files...
Building initial module for 3.2.0-4-amd64

and in another shell:

root@debianzfsroot:~# ps faxwww | grep /configure
24956 pts/3    S+     0:00  |                                   \_ /bin/bash /var/lib/dkms/zfs/0.6.2/build/configure --prefix=/usr --with-config=kernel --with-linux=/lib/modules/3.2.0-4-amd64/source --with-linux-obj=/lib/modules/3.2.0-4-amd64/build --with-spl=/usr/src/spl-0.6.2 --with-spl-obj=/var/lib/dkms/spl/0.6.2/3.2.0-4-amd64/x86_64 --with-spl-timeout=600
26282 pts/2    S+     0:00          \_ grep /configure
17923 ?        S      0:00          \_ /bin/bash /var/lib/dkms/zfs/0.6.2/build/configure --prefix=/usr --with-config=kernel --with-linux=/lib/modules/3.2.0-4-rt-amd64/source --with-linux-obj=/lib/modules/3.2.0-4-rt-amd64/build --with-spl=/usr/src/spl-0.6.2 --with-spl-obj=/var/lib/dkms/spl/0.6.2/3.2.0-4-rt-amd64/x86_64 --with-spl-timeout=600
root@debianzfsroot:~# grep '/lib/modules' /var/lib/dkms/zfs/0.6.2/build/config.log
  $ /var/lib/dkms/zfs/0.6.2/build/configure --prefix=/usr --with-config=kernel --with-linux=/lib/modules/3.2.0-4-amd64/source --with-linux-obj=/lib/modules/3.2.0-4-amd64/build --with-spl=/usr/src/spl-0.6.2 --with-spl-obj=/var/lib/dkms/spl/0.6.2/3.2.0-4-amd64/x86_64 --with-spl-timeout=600
configure:12133: result: /lib/modules/3.2.0-4-amd64/source
configure:12171: result: /lib/modules/3.2.0-4-amd64/build

And yet, it's now hung on the checking spl build directory. I expect it to fail 'shortly'.

Ok, I was wrong. It apparently IS looking for the SPL objects in /var/lib/dkms...

And removing the rt headers, {spl,zfs}-dkms packages and then install the dkms packages again, they build just fine.

Yes, I accidentally used zfs-dkms instead of spl-dkms here, but still - it works without the rt headers, but not with. Even though it finds the correct directories and values etc...

[FransUrbo]

I need to get newer glasses (no, really - these ones suck!):

--with-linux=/lib/modules/3.2.0-4-rt-amd64/source --with-linux-obj=/lib/modules/3.2.0-4-rt-amd64/build 

I need to go back to the beginning. I'll be back...

[RJVB]

Again, with my mod the whole procedure works flawlessly on my system. I'll leave things a little time to boil down, and then I'll raise an issue with LinuxMint to modify their lsb-release file.

[FransUrbo]

And I'm trying to tell you that your fix is wrong. If you consider this issue closed and done, then please close it so I don't have to spend time unnecessarily.

[RJVB]

No, I don't consider it closed, that's not what I was saying. However, I don't see you saying my fix is wrong either. It's not very elegant, I agree, but if things build with but not without, I don't see how it could not be a solution ...

Again, I think the whole issue is that dkms calls configure with --with-linux pointing to a build rather than a source directory, and that is because my LMDE system is not recognised as a Debian variant.

And let me just state that this LMDE system (NOT the VM!) has been reinstalled from scratch the last month, so we're not dealing with side-effects of a hacked-together system.

[FransUrbo]

Making sure I start with a 'clean' environment:

dpkg --purge --force-depends linux-headers-3.2.0-4-common-rt linux-headers-3.2.0-4-rt-amd64 zfs-dkms spl-dkms

Then, just install the rt headers:

dpkg -i /var/cache/apt/archives/linux-headers-3.2.0-4-*

Ok, so now we can begin. Let's start with ONLY installing spl-dkms:

dpkg -i /var/cache/apt/archives/spl-dkms_0.6.2-2_all.deb

gives me:

Setting up spl-dkms (0.6.2-2) ...
Loading new spl-0.6.2 DKMS files...
First Installation: checking all kernels...
dpkg: warning: version '*-*' has bad syntax: version number does not start with digit
It is likely that 3.2.0-4-amd64 belongs to a chroot's host
Building initial module for 3.2.0-4-amd64

Ok, so that eventually worked.

Let's try again. Remove the rt headers and spl-dkms and then install them in the reverse order.

dpkg --purge --force-depends linux-headers-3.2.0-4-common-rt linux-headers-3.2.0-4-rt-amd64 zfs-dkms spl-dkms
dpkg -i /var/cache/apt/archives/spl-dkms_0.6.2-2_all.deb

Which works. Now try to install the rt headers:

# dpkg -i /var/cache/apt/archives/linux-headers-3.2.0-4-*
[...]
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 3.2.0-4-rt-amd64
Error! Bad return status for module build on kernel: 3.2.0-4-rt-amd64 (x86_64)
Consult /var/lib/dkms/spl/0.6.2/build/make.log for more information.

which bombs because of --with-linux=/lib/modules/3.2.0-4-rt-amd64/source --with-linux-obj=/lib/modules/3.2.0-4-rt-amd64/build.

So how does this corresponds to @RJVB problem?

1. Installed {spl,zfs}-dkms modules
2. Installed rt headers
3. Upgraded {spl,zfs}-dkms modules to a new (package) version

So I consider this a problem with dkms, not ZoL - dkms is trying to build modules (see the run-parts part above), just because headers are installed. In my opinion it should only do that if a KERNEL is installed!

@RJVB please close this bug. It is not with ZoL but dkms. Feel free to take this up with them.

PS. This might have worked if it wasn't a RT header...

[FransUrbo]

No, I don't consider it closed, that's not what I was saying. However, I don't see you saying my fix is wrong either. It's not very elegant, I agree, but if things build with but not without, I don't see how it could not be a solution ...

Because it's hardcoded for your system. It's BOUND to break 'very soon' (as soon as someone tries to install on another Debian GNU/Linux system that have the same problematic lab_release file. Again, I think the whole issue is that dkms calls configure with --with-linux pointing to a build rather than a source directory

And I told you (several times) that that exactly what it's supposed to! There's a difference between the --with-linux (which is the source directory) and the --with-linux-obj (which is the directory with the binary/object files). For a make-kpkg built kernel, these are two different directories. For a home made kernel, it should be the same directory (or one could skip the with-linux-obj because it will figure this out itself).

So it IS correct.

and that is because my LMDE system is not recognised as a Debian variant.

Completely irrelevant. The problem is the rt headers. Which I have been able to prove.

[RJVB]

ERm, no. You're having a fixation on the rt headers, but if it wasn't clear enough yet,

I REMOVED THE RT HEADERS

and despite that, the stock spl package will not build because Linux Mint Debian is detected as something that is not Debian.

Also, I ended up having the rt headers installed BECAUSE SPL DIDN"T BUILD back when I did that ill-fated apt-get upgrade . I thought maybe it didn't find that undeclared path_lookup function because I had something wrong with my kernel headers, so took a short-cut and installed a package containing ALL 3.10 headers.

I'm willing to accept that this could be a dkms issue, but only if

1 your spl's dkms.conf is stock apart from the obvious things that need to be tailored for a given package 2 dkms claims that the code used to determine the way configure is invoked, notably the values passed through --with-linux and --with-linux-obj are guaranteed to work on any linux distribution, regardless of package requirements.

(evidently a package depending only on headers also present in the linux build/include directory will not care which path is passed in via --with-linux (source or build) but spl and probably zfs are more intricate.)

[FransUrbo]

I REMOVED THE RT HEADERS

YOU HAVE FAILED TO SAY THAT!!

If you only give me part of a description leaving out the parts that matter, how do you expect me to help you?

[RJVB]

OOps, my bad. I see that the reply via email in which that's said is still sitting in my outbox ... getting it to send now.

[RJVB]

On Thursday January 02 2014 18:12:41 Turbo Fredriksson wrote:

/lib/modules/3.10-2-rt-amd64/build points to /usr/src/linux-headers-3.10-2-rt-amd64

No, this is correct.

instead of to /usr/src/linux-headers-3.10-2-rt-common

... because that's the source directory..

Sorry, yes. (Still not fully recovered from my gutbug it seems :-/). The 'instead' was out of place.

/var/lib/dkms/spl/0.6.2/build/configure --prefix=/usr --with-config=kernel --with-linux=/lib/modules/3.10-2-amd64/build --with-linux-obj=/lib/modules/3.10-2-amd64/build

Is this WITH your modifications? What does it say WITOUT them?

That's WITHOUT my modifications!

Actually, I think it should have said:

--with-config=kernel --with-linux=/lib/modules/3.10-2-amd64/source --with-linux-obj=/lib/modules/3.10-2-amd64/build

Indeed, and it does with my mod.

But I'm fairly certain the rt headers have something to do with it anyway! Please deinstall them and try again (without any modifications!).

I just did, and to be sure reinstalled the "normal" headers (aptitude reinstall). Of course that triggered a rebuild of my extensions, and because I'd remove my mod the spl build failed, again because it tried to use path_lookup. Reapplying my mod and doing another aptitude reinstall caused the whole thing to go through without error.

All of this takes forever on a netbook ...

[FransUrbo]

1 your spl's dkms.conf is stock apart from the obvious things that need to be tailored for a given package

There is NO change what so ever to ANY config file (exept setting verbose=1 to the dkms global config). 2 dkms claims that the code used to determine the way configure is invoked

What? notably the values passed through --with-linux and --with-linux-obj are guaranteed to work on any linux distribution, regardless of package requirements.

Yes. It needs BOTH the kernel common AND the object parts. I.e.:

root@debianzfsroot:/usr/src# ll 
total 55
drwxr-xr-x 4 root root  9 Dec 28 20:06 linux-headers-3.2.0-4-amd64
drwxr-xr-x 4 root root  6 Dec 28 20:05 linux-headers-3.2.0-4-common
lrwxrwxrwx 1 root root 23 Jun 24  2012 linux-kbuild-3.2 -> ../lib/linux-kbuild-3.2
drwxr-xr-x 5 root root 18 Jan  2 18:25 spl-0.6.2
drwxr-xr-x 5 root root 21 Jan  2 18:27 zfs-0.6.2

The first dir is the object directory and the second is the source dir:

root@debianzfsroot:/usr/src# ls -l /lib/modules/3.2.0-4-amd64/{build,source}
lrwxrwxrwx 1 root root 36 Sep 20 03:46 /lib/modules/3.2.0-4-amd64/build -> /usr/src/linux-headers-3.2.0-4-amd64
lrwxrwxrwx 1 root root 37 Sep 20 03:46 /lib/modules/3.2.0-4-amd64/source -> /usr/src/linux-headers-3.2.0-4-common

(evidently a package depending only on headers also present in the linux build/include directory will not care which path is passed in via --with-linux (source or build) but spl and probably zfs are more intricate.)

ANY package that uses dkms will need those two packages. Period. That's why installing the object package will automatically install the source package as well.

root@debianzfsroot:/usr/src# apt-get install linux-headers-3.2.0-4-rt-amd64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  linux-headers-3.2.0-4-common-rt
The following NEW packages will be installed:
  linux-headers-3.2.0-4-common-rt linux-headers-3.2.0-4-rt-amd64

[RJVB]

How just one more thing: I have never tried to build for the 3.2 kernel in presence of the 3.2 RT headers, but from what I saw yesterday and this morning, the 3.10 headers apparently do not cause any trouble by just being present; dkms just found the correct path (the standard headers). Provided my, erm, kludge(?) is applied ...

[FransUrbo]

Actually, I think it should have said:

--with-config=kernel --with-linux=/lib/modules/3.10-2-amd64/source --with-linux-obj=/lib/modules/3.10-2-amd64/build

Indeed, and it does with my mod.

And without? Especially now, when you have removed the rt headers?

I just did, and to be sure reinstalled the "normal" headers (aptitude reinstall).

What does ls -l /lib/modules/ /usr/src/ say?

[FransUrbo]

What does ls -l /lib/modules/ /usr/src/ say?

Oh, and

ls -l /lib/modules/`uname -r`/{build,source}

[RJVB]

sigh.

/usr/src/spl-0.6.2/dkms.conf has several lines that are clearly specific to spl (logically so, I presume that it's not the dkms project who wrote it ...).

However, it also has

PRE_BUILD="configure
  --prefix=/usr
  --with-config=kernel
  --with-linux=$(case `lsb_release -is` in
                   (Debian)
                     if [ -e ${kernel_source_dir/%build/source} ]
                     then
                       echo ${kernel_source_dir/%build/source}
                     else
                       # This is a kpkg exception for Proxmox 2.0
                       echo ${kernel_source_dir}
                     fi
                     ;;
                   (*)
                     echo ${kernel_source_dir}
                     ;;
                 esac)
  --with-linux-obj=${kernel_source_dir}
"

Of course this is required for any kernel extension. That is evidently not the question I am raising. My question is, is this code from the dkms project, and if so, do the assure that it is guaranteed to allow any and all kernel extensions to build on all possible distributions?

Without my mod, configure is invoked with

--with-config=kernel --with-linux=/lib/modules/3.10-2-amd64/build --with-linux-obj=/lib/modules/3.10-2-amd64/build

and as I wrote earlier, the headers in build/include appear to be a small subset of the ones in source/include . To me this explains perfectly why kern_path_locked isn't found, nor kern_path_parent and path_lookup (because we're on a post 3.6 kernel).

$ ls -l /lib/modules/ /usr/src/
/lib/modules/:
total 43
drwxr-xr-x 2 root root  3 Jun 30  2011 2.6.32-5-amd64
drwxr-xr-x 2 root root  3 Apr  3  2012 2.6.39-2-amd64
drwxr-xr-x 5 root root 18 Jan  2 18:57 3.10-2-amd64
drwxr-xr-x 3 root root  3 Jan 16  2013 3.2.0-2-amd64
drwxr-xr-x 4 root root 17 Jan  1 22:58 3.2.0-4-amd64

/usr/src/:
total 78
drwxr-xr-x 2 root root 36 Dec 17 00:35 fglrx-13.4
drwxr-xr-x 4 root root  9 Jan  2 18:41 linux-headers-3.10-2-amd64
drwxr-xr-x 4 root root  6 Jan  2 18:42 linux-headers-3.10-2-common
drwxr-xr-x 4 root root  9 Dec 10  2012 linux-headers-3.2.0-4-amd64
drwxr-xr-x 4 root root  6 Dec 10  2012 linux-headers-3.2.0-4-common
lrwxrwxrwx 1 root root 24 Aug  8 23:34 linux-kbuild-3.10 -> ../lib/linux-kbuild-3.10
lrwxrwxrwx 1 root root 23 Dec 15 11:18 linux-kbuild-3.2 -> ../lib/linux-kbuild-3.2
drwxr-xr-x 2 root root 39 Dec 15 13:53 ndiswrapper-1.58
drwxr-xr-x 5 root root 18 Jan  2 18:32 spl-0.6.2
drwxr-xr-x 7 root root  9 Dec 15 13:44 virtualbox-guest-4.2.16
drwxr-xr-x 5 root root 21 Jan  2 11:39 zfs-0.6.2

$ ls -l /lib/modules/`uname -r`/{build,source}
lrwxrwxrwx 1 root root 35 Aug  8 13:41 /lib/modules/3.10-2-amd64/build -> /usr/src/linux-headers-3.10-2-amd64
lrwxrwxrwx 1 root root 36 Aug  8 13:41 /lib/modules/3.10-2-amd64/source -> /usr/src/linux-headers-3.10-2-common

[RJVB]

BTW:

$ cat /usr/src/fglrx-13.4/dkms.conf /usr/src/ndiswrapper-1.58/dkms.conf 
PACKAGE_NAME="fglrx"
PACKAGE_VERSION="13.4"
BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
DEST_MODULE_LOCATION[0]="/updates"
AUTOINSTALL=yes
CLEAN="rm -f *.*o"
PACKAGE_NAME="ndiswrapper"
PACKAGE_VERSION="1.58"
DEST_MODULE_LOCATION[0]="/updates"
BUILT_MODULE_NAME[0]="ndiswrapper"
AUTOINSTALL="yes"

i.e. those dkms.conf files miss the whole PRE_BUILD statement, is that because they lack a configure step?

Anyway, it gave me the idea to try a mod consisting of removing the whole --with-linux and --with-linux-obj step. It's processing now, but the initial impression is that it's using the correct kernel source and build directories.

[FransUrbo]

i.e. those dkms.conf files miss the whole PRE_BUILD statement, is that because they lack a configure step?

Probably.

[RJVB]

OK, so with

PRE_BUILD="configure
  --prefix=/usr
  --with-config=kernel
"

the build works fine for the current kernel, but not when building for a different kernel (-k) :(

[FransUrbo]

the build works fine for the current kernel, but not when building for a different kernel (-k) :(

Which is quite obvious, because it doesn't take into account the way dkms was called...