• Like 0

    after today's update, zfs module not building


    dkms status
    spl, 0.6.5.7, 4.5.4-1-ARCH, x86_64: installed
    zfs, 0.6.5.7.r2178_4.5.4_1: added

    sudo dkms autoinstall

    checking spl source directory… /usr/src/spl-0.6.5.7.r2178_4.5.4_1
    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 source with the ‘–with-spl=PATH’ option.
    *** The spl version must match the version of ZFS you are building,
    *** 0.6.5. Failed to find spl.release.in in the following:
    300,

    Building module:
    cleaning build area…(bad exit status: 2)
    make KERNELRELEASE=4.5.4-1-ARCH…(bad exit status: 2)
    Error! Bad return status for module build on kernel: 4.5.4-1-ARCH (x86_64)
    Consult /var/lib/dkms/zfs/0.6.5.7.r2178_4.5.4_1/build/make.log for more information.

    cat /var/lib/dkms/zfs/0.6.5.7.r2178_4.5.4_1/build/make.log
    DKMS make.log for zfs-0.6.5.7.r2178_4.5.4_1 for kernel 4.5.4-1-ARCH (x86_64)
    Mon May 30 08:12:11 EDT 2016
    make: *** No targets specified and no makefile found. Stop.

    linux-headers is installed, spl, and zfs packages are also installed.

    systemctl status dkms.service
    ● dkms.service
    Loaded: not-found (Reason: No such file or directory)
    Active: inactive (dead)

    systemctl start dkms.service
    Failed to start dkms.service: Unit dkms.service not found.

  • Like 0

    It appears that there is no /usr/src/spl-0.6.5.7.r2178_4.5.4_1 directory?
    Just /usr/src/spl-0.6.5.7.

    Lucky I’m not trying to boot from my ZFS pool…

  • Like 0

    For some strange reason, linux-headers were not installed!
    I wrongly thought they’d been sucked in automatically with dkms.

    Anyway, pacman -S linux-headers fixed dkms and spl, zfs modules then build without errors.

  • Like 0

    Nevermind… It looked like dkms succeeded, but I didn’t read carefully.
    I’m now totally confused:

    Your kernel headers for kernel 4.5.4.0-1-ARCH cannot be found at
    /usr/lib/modules/4.5.4.0-1-ARCH/build or /usr/lib/modules/4.5.4.0-1-ARCH/source.

    I installed linux-headers again, but they seem to be for a different kernel?!

    ls -l /lib/modules
    total 8
    drwxr-xr-x 5 root root 4096 May 30 09:14 4.5.4-1-ARCH
    drwxr-xr-x 2 root root 4096 May 29 15:20 extramodules-4.5-ARCH

  • Like 0

    ok, I uninstalled the spl, spl-utils zfs, zfs-utils packages from the antergos repository and just installed spl-dkms and zfs-dkms (0.6.5.7-1) from AUR using yaourt.

    Now dkms and zfs works (even automounting pools at boot) , but I am getting an update nag from pamac-tray, because (I guess) it thinks these AUR packages came from the antergos repo.

    pacman -Ss Solaris
    extra/nss_ldap 265-6
    The nss_ldap module provides the means for Linux and Solaris workstations to
    resolve the entities defined in RFC 2307 from LDAP directories.
    antergos/spl 0.6.5.7.r980_4.5.4_1-1
    Solaris Porting Layer kernel modules.
    antergos/spl-utils 0.6.5.7.r980_4.5.4_1-1 (system zfs) [installed: 0.6.5.7-1]
    Kernel module support files for the Solaris Porting Layer.

    pacman -Ss zfs
    antergos/grub-zfs 1:2.02.beta2-6
    GNU GRand Unified Bootloader (2). Patched for ZFS.
    antergos/spl-utils 0.6.5.7.r980_4.5.4_1-1 (system zfs) [installed: 0.6.5.7-1]
    Kernel module support files for the Solaris Porting Layer.
    antergos/zfs 0.6.5.7.r2178_4.5.4_1-2
    Kernel modules for the Zettabyte File System.
    antergos/zfs-utils 0.6.5.7.r2178_4.5.4_1-1 (system) [installed: 0.6.5.7-1]
    Kernel module support files for the Zettabyte File System.

    Is there a way I can keep the antergos repo and fix this confusing package situation?

  • Like 2

    Hi! I experienced the very same thing today.

    You are correct, the same happens with linux-headers installed as well.

    It seems the dkms.conf in the supplied zfs-0.6.5.7 package contains: (take note of PACKAGE_VERSION)

    $> head -n 2 dkms.conf 
    PACKAGE_NAME="zfs"
    PACKAGE_VERSION="0.6.5.7.r2178_4.5.4_1"
    

    whereas the previous version:

    PACKAGE_VERSION="0.6.5.6"
    

    without the revision and kernel version info.

    Temporary workaround:
    Manually modify
    /usr/src/zfs-0.6.5.7.r2178_4.5.4_1/dkms.conf
    and remove the revision and kernel version. Should look like this:
    PACKAGE_VERSION="0.6.5.7"
    Symlink to use the correct name:

    # pwd
    /usr/src
    # ln -s zfs-0.6.5.7.r2178_4.5.4_1/ zfs-0.6.5.7
    

    Check with dkms status if you have any zfs module, remove if broken etc.

    Then clean and reinstall with DKMS:

    $> sudo dkms add -m zfs -v 0.6.5.7
    
    Creating symlink /var/lib/dkms/zfs/0.6.5.7/source ->
                     /usr/src/zfs-0.6.5.7
    
    DKMS: add completed.
    
    
    
    $> sudo dkms install -m zfs -v 0.6.5.7
    *BUILD LOG STUFF*
    
    $> sudo mkinitcpio -p linux
    *SHOULD SUCCEED NOW!*
    

    I have added an issue to the relevant git repo

  • Like 1

    Thanks, henrik.tjader. That is easier than messing with yaourt. I imagine a lot of newbs were scared off when their ZFS root systems mysteriously stopped booting due to this typo in one little file.

    Sad that lawyer bullshit is making it impossible for ZFS to get into the kernel…like something out of Atlas Shrugged. I suppose there will be mature BTRFS someday. Oh well. Don’t mean nuthin.

  • Like 0

    @romanaOne I’m sure that one day it all be sorted and we can work with the best of the available tools, btrfs, zfs and more…

    I’m just amazed by the responsiveness of this community, the issue over at github have already been closed and the source of the problem we had today is fixed. Just awesome :o

  • Like 0

    Is this what is stopping the live cd installer from creating a zfs install too? I swear it worked in the past.

  • Like 0

    Sorry to take all year to respond. I was on vacation and that means no gadgets. :)

    I think it is just a bad idea to have the root filesystem depend on an external module like ZFS/SPL. At least until grub supports it better…

    I have 3 drives in my laptop and boot from ext4, with the other two drives set up as a zfsmirror for data. It really is much simpler to just symlink ~/Docs, ~/Downloads, Music, etc. to datasets in the zfsmirror than jump through all the zfs-root hoops for very little gain and a good chance of future breakage.

    Even BSD-based FreeNAS systems don’t boot from ZFS, but from a SD flash card. The only easy way to do ZFS root is PC-BSD and–unless you have ALL BSD-supported hardware–you’ll be having lots of problems with Xorg, Wifi, and sound. I think PC-BSD is great, but *BSD is just not widely enough used to have good hardware support.

    ZFS is always going to be a PITA on Linux because it is not in the kernel but has to be built separately; it really rankles how the “last word in filesystems” is being held up because of license nonsense and that people are expending HUGE, duplicated effort to reinvent this wheel in the form of BTRFS. Who is John Galt?

    As the kernel changes, we just have to hope the people maintaining ZFS on Linux module and the Solaris module (SPL) will keep it working.

    I wouldn’t use ZFS for root on Linux until grub supports it better or some method of booting (like EFI(STUB) becomes standard. (My laptop has wacky broken EFI so I just “legacy boot” Clover in the MBR )

    I am currently booting Antergos by chainloading rEFInd from Clover (The Hackintosh Bootloader).
    Since my system is Hackintoshed, I do not let anything touch the MBR except Clover, which then does some kind of fake EFI boot using my patched DSDTs and SSDTs; Linux and OS X think they have booted EFI, thanks to Clover.

    >dmesg | grep EFI
    [    0.000000] efi: EFI v2.60 by CLOVER
    [    0.299915] fb0: EFI VGA frame buffer device
    [    2.278981] fb: switching to inteldrmfb from EFI VGAcode here
    

    I don’t understand fully how Clover works because up until recently, I’ve never had much trouble with Clover: it picks up EFISTUB Ubuntu kernels and (the initrd) automatically every single time I upgrade. Not sure what is different about Antergos/Arch: rEFInd finds the Arch kernel+initrd, but not Clover. Of course, just like grub rEFInd/Clover know nothing about ZFS so you have to keep the kernel/initrd on a little FAT/ext partition.

  • Like 0

    Cool! Thanks for the info. I’m new to Arch so I’m learning & I didn’t know some of that.

    I was really liking what I had read about backing up the ZFS drives & sounded really good for the boot drive. Oh well. I gave up trying to use it on the boot drive on my system but still use ZFS as a 20TB 8 drive pool. It’s pretty quick & I haven’t seen anything easier and/or better yet.

  • Like 0

    i notices after Systemd update 230 my dkms.service is lost…

    i had it before, i use it for my virtualbox nothing more :p

    systemctl status dkms : should see dkms ?

    just curius,

  • Like 0

    Do you have virtualbox-host-dkms installed?

    And no, you won’t get status from the dkms service, because dkms is no real service. Since the introduction of Pacman hooks, the rebuilt of the modules is handled automatically when a kernel is upgraded.

    Cheers!

  • Like 0

    ahh karasu, thanks for info :)

  • Like 0

    @romanaOne said in after today's update, zfs module not building:

    Even BSD-based FreeNAS systems don’t boot from ZFS, but from a SD flash card. The only easy way to do ZFS root is PC-BSD and–unless you have ALL BSD-supported hardware–you’ll be having lots of problems with Xorg, Wifi, and sound. I think PC-BSD is great, but *BSD is just not widely enough used to have good hardware support.

    This is true for versions prior to version 9.3 of FreeNAS, however now the USB memory stick/SD-card or whichever (typically flash based) storage you use is formatted as a ZFS volume by default.

    I have two USB-sticks in a mirror:

      pool: freenas-boot
     state: ONLINE
      scan: scrub repaired 0 in 0h1m with 0 errors on Sat May 14 03:46:12 2016
    config:
    
    	NAME        STATE     READ WRITE CKSUM
    	freenas-boot  ONLINE       0     0     0
    	  mirror-0  ONLINE       0     0     0
    	    da1p2   ONLINE       0     0     0
    	    da0p2   ONLINE       0     0     0
    
    errors: No known data errors
    

    Otherwise I agree, it would be so much nicer if the number of “moving parts” would be kept lower, i.e. kernel and ZFS integration.

  • Like 0

    Interesting! I will have to take another look at FreeNAS before I end up converting my PC-BSD system into it…

todays1 zfs20 building1 module2 Posts 16Views 2084
Log in to reply