Kernel 4.x wanted, running OMV 1.19

    • OMV 1.0
    • Update

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Install your own kernel step by step

      I had the same problem with the new libc
      I solve it and provide now what is to do.

      In a VM with running Openmediavault 2.17
      Install tools to create your own Kernel
      apt-get install build-essential bc kernel-package

      Now I use the debian kernel, it include some patches
      echo "deb http://http.debian.net/debian jessie-backports main" >> /etc/apt/sources.list
      apt-get update
      apt-get install linux-source-4.2

      This step is necessary if you don’t want to upgrade your base system
      nano /etc/apt/sources.list
      uncommit #deb http://http.debian.net/debian jessie-backports main
      apt-get update

      Create Kernel
      cd ~
      mkdir kernel
      cd kernel
      tar xf /usr/src/linux-source-4.*.tar.xz
      cd linux-source-4.2
      cp /boot/config-`uname -r` .config
      yes "" | make oldconfig
      make-kpkg -j 3 --initrd --append-to-version -omvstone-amd64 --revision 1.0.0 buildpackage
      cd ..

      I copy the .dep files with scp to the real storage
      dpkg -i linux-doc-4.2.3-omvstone-amd64_1.0.0_all.deb
      dpkg -i linux-headers-4.2.3-omvstone-amd64_1.0.0_amd64.deb
      dpkg -i linux-image-4.2.3-omvstone-amd64_1.0.0_amd64.deb
      dpkg -i linux-manual-4.2.3-omvstone-amd64_1.0.0_all.deb

      Reboot storage to finish
    • I highly recommend AGAINST using jessie packages on wheezy especially for libc. It is easy enough to compile a 4.2 kernel without using the jessie package.
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.2
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • If you write "It is easy enough to compile a 4.2 kernel without using the Jessie package"
      please provide also a instruction to do this. Otherwise your post ist not very helpful.
      The point is not to compile a 4.2 Kernel, but to get the same patches as the Debian developer using.

      It is possible to download the .deb direct, so that you not have the risk to mix up your system.

      Download http://ftp.de.debian.org/debian/pool/main/l/linux/linux-source-4.2_4.2.3-2~bpo8+1_all.deb
      dpkg -i linux-source-4.2_4.2.3-2~bpo8+1_all.deb

      Hope it will by help
    • Terminator wrote:

      If you write "It is easy enough to compile a 4.2 kernel without using the Jessie package"
      please provide also a instruction to do this. Otherwise your post ist not very helpful.
      The point is not to compile a 4.2 Kernel, but to get the same patches as the Debian developer using.

      I feel my post was helpful (maybe not to you). The point of my post was not to tell you how to compile 4.2. It was to warn people I recommend against using jessie packages especially libc - new libc with lots of old packages can cause problems....

      What is the point of using Debian developer kernel patches when you aren't using all jessie packages?? Those patches are only tested on jessie and mostly with systemd. You might as well use a vanilla kernel if you aren't using the same environment as the Debian devs. And there are plenty of tutorials on the web on how to compile a kernel on debian.
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.2
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • You are right, new libc from Jessie inside wheezy make the system brocken.
      I had many auto reboots with this solution. That the point why I wrote this
      small howto to build the kernel with the libc from wheezy. If you
      look over the steps you see that I don't change the library. To use
      the Debian kernel sources in case of vanilla is that I expect
      Opennmediavoult use the debian kernel also. If you say vanilla kernel
      is ok I will change my how to after testing.
    • I guess when I read your writeup, I was thinking apt-get would pull libc in since the jessie repo was enabled. So, your method would be fairly safe. I do wonder how many of the kernel patches would be helpful on wheezy when they are intended for jessie with systemd. It is possible they wouldn't hurt. While I don't do it much any more, running a vanilla kernel on a debian system has always been stable for me as well. You can always look through the debian patches to see if any would be helpful for a wheezy build.
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.2
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • This script compile a vanilla 4.2.5 kernel inside a Openmediavault installation.
      At the end all necessary deb packets are inside /root/kernel
      Compilation can take more than 1h

      I copy the .dep files with scp to the real storage
      dpkg -i linux-doc-4.2.5-omvstone-amd64_1.0.0_all.deb
      dpkg -i linux-headers-4.2.5-omvstone-amd64_1.0.0_amd64.deb
      dpkg -i linux-image-4.2.5-omvstone-amd64_1.0.0_amd64.deb
      dpkg -i linux-manual-4.2.5-omvstone-amd64_1.0.0_all.deb

      Shell-Script

      1. #!/bin/sh
      2. yes "" | apt-get install build-essential bc kernel-package
      3. cd ~
      4. mkdir kernel
      5. cd kernel
      6. wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.2.5.tar.xz
      7. tar -xf linux-*
      8. cd linux*
      9. cp /boot/config-`uname -r` .config
      10. yes "" | make oldconfig
      11. make-kpkg -j 5 --initrd --append-to-version -omvstone-amd64 --revision 1.0.0 buildpackage
      Display All

      The post was edited 1 time, last by Terminator ().

    • Hi,i get always the message after dpkg -i linux-headers and linux-image, but at linux image the upgrade goes on.....

      Error! The dkms.conf for this module includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch. This indicates that it should not be built.
      Error! Your kernel headers for kernel 4.2.5-omvstone-amd64 cannot be found Please install blabla or use the --kernelsourcedir option to tell DKMS where it's located....

      Any idea?
      Regards
      Nightcrawler

    • OK, I start a retest in my developer system.

      If it possible please use this steps before.
      Fresh installation with Openmediault ISO 2.1
      After installation make apt-get update && apt-get disk-upgrade-> reboot
      Now create as root the script e.g.
      nano /root/kernel.sh
      chmod 700 /root/kernel.sh
      cd /root
      ./kernel.sh
    • Well I just updated to 4.1.12 and removed aufs, sonce only docker used it and can run with overlayfs (better long term alternative) which I directly included.

      The 2.17 auf glibc was indeed needed as a dependency for the btrfs-tools. So it totally depends on your usecase...no btrfs, go vanilla with 2.14 and your fine. Need btrfs, you also need a recent tools version, which implies 2.17 when the .deb is used. Maybe I'll downgrade the lib and try to compile the source directly wirh 2.14...or the vbox guys compile or get a newer version for the 2.17 libc which allows to use the sid btrfs-tools .debs....
    • Create the last master btrfs-tools without changing libc

      Fresh installation with Openmediault ISO 2.1
      After installation make apt-get update && apt-get disk-upgrade-> reboot
      Now create as root the script e.g.
      nano /root/btrfs.sh
      chmod 700 /root/btrfs.sh
      cd /root
      ./btrfs.sh

      Shell-Script

      1. #!/bin/sh
      2. yes "" | apt-get install build-essential debhelper dh-make quilt fakeroot lintian git
      3. yes "" | apt-get install asciidoc xmlto --no-install-recommends
      4. yes "" | apt-get install uuid-dev libattr1-dev zlib1g-dev libacl1-dev e2fslibs-dev libblkid-dev liblzo2-dev automake pkg-config
      5. git clone https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git
      6. cd btrfs*
      7. version=`git show-branch | cut -dv -f2`
      8. ./autogen.sh
      9. cd ..
      10. mv btrfs-progs btrfs-tools-$version
      11. tar -czf btrfs-tools-$version.tar.gz btrfs-tools-$version
      12. cd btrfs-tools-$version
      13. dh_make -f ../btrfs-tools-$version.tar.gz
      14. DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -us -uc
      Display All


      Generate build-system by:

      aclocal: aclocal (GNU automake) 1.11.6
      autoconf: autoconf (GNU Autoconf) 2.69
      autoheader: autoheader (GNU Autoconf) 2.69
      automake: automake (GNU automake) 1.11.6

      Now type './configure' and 'make' to compile.
      Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch?
      [s/i/m/l/k/n] s

      Maintainer name : root
      Email-Address : root@localhost.localdomain
      Date : Sat, 07 Nov 2015 20:23:50 +0100
      Package Name : btrfs-tools
      Version : 4.3
      License : blank
      Type of Package : Multi-Binary
      Hit <enter> to confirm:

      ls -al *.deb
      -rw-r--r-- 1 root root 2870 Nov 7 20:25 btrfs-tools_4.3-1_amd64.deb

      dpkg -i btrfs-tools_4.3-1_amd64.deb

      The post was edited 1 time, last by Terminator ().

    • stone49th wrote:

      I had a look at the omvextrasorg source on github, but I couldn't find much occurence of a "uname" command in there. My current output is:

      Source Code

      1. #name -a
      2. Linux MyHost 4.1.6-omvstone #5 SMP Wed Sep 9 11:03:03 CEST 2015 x86_64 GNU/Linux
      3. #uname -r
      4. 4.1.6-omvstone


      don't know whether an additional "_amd64" or something is missing after the localversion "-omvstone"...any clues on the "correct" name for omvextras?


      subzero79 wrote:



      I just came across this problem after compiling my own kernel too - I didn't add 'amd64' into my localversion string. But why is this being used in the detection routine in omvextrasorg.inc? You could use php_uname('m') for the CPU, but better is dpkg --print-architecture (as is done elsewhere in omvextrasorg.inc in fact), and then you can select on the actual arch installed, rather than just a string in the kernel name.
      Also, I found the code for listing/adding the repos in that file a bit cumbersome. I forked the repo and fixed the arch detection and tidied up the repos array code here: github.com/imgrant/openmediavault-omvextrasorg
      Perhaps I can submit a pull request and merge it back in if there are no objections to my rewrite.
    • stone49th wrote:

      The 2.17 auf glibc was indeed needed as a dependency for the btrfs-tools. So it totally depends on your usecase...no btrfs, go vanilla with 2.14 and your fine. Need btrfs, you also need a recent tools version, which implies 2.17 when the .deb is used. Maybe I'll downgrade the lib and try to compile the source directly wirh 2.14...or the vbox guys compile or get a newer version for the 2.17 libc which allows to use the sid btrfs-tools .debs....


      Also, I rebuilt btrfs-tools 4.3.1 from the testing (stretch) source (without an updated glibc). Note that it requires patching for multi-device btrfs filesystems to work properly with udev and sysvinit on Wheezy rather than systemd; add the following lines back in to the override_dh_auto_install section in debian/rules:

      Source Code

      1. # Adding udev integration
      2. install -D -m 0644 debian/local/btrfs.udev debian/btrfs-tools/lib/udev/rules.d/70-btrfs.rules
      3. install -D -m 0644 debian/local/btrfs-lvm.udev debian/btrfs-tools/lib/udev/rules.d/80-btrfs-lvm.rules

      Also, it puts the binaries in /bin rather than /sbin now.
    • igrnt wrote:


      I just came across this problem after compiling my own kernel too - I didn't add 'amd64' into my localversion string. But why is this being used in the detection routine in omvextrasorg.inc? You could use php_uname('m') for the CPU, but better is dpkg --print-architecture (as is done elsewhere in omvextrasorg.inc in fact), and then you can select on the actual arch installed, rather than just a string in the kernel name.

      Not so fast :) I use it for a reason. I needed to be able to differentiate between the armhf kernels - armv6l (RPi1) and armv7l (RPi2 and other arm boards) because some plugins need true armhf (armv7l only). dpkg --print-architecture on outputs armhf on both of those kernels. And if I remember correctly, php_uname('m") doesn't show enough for the arm processors either. So, I had to remove the 'm'.

      I can only really support the standard Debian kernels. If you are compiling your own, it isn't hard to add what is needed :)
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.2
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      Not so fast :) I use it for a reason. I needed to be able to differentiate between the armhf kernels - armv6l (RPi1) and armv7l (RPi2 and other arm boards) because some plugins need true armhf (armv7l only). dpkg --print-architecture on outputs armhf on both of those kernels. And if I remember correctly, php_uname('m") doesn't show enough for the arm processors either. So, I had to remove the 'm'.

      Haha! Foiled! I knew I was being too smug. uname -m gives armv7l on my RPi2 (admittedly running Arch Linux), don't know what it shows on a RPi1/Raspbian.

      ryecoaaron wrote:


      I can only really support the standard Debian kernels. If you are compiling your own, it isn't hard to add what is needed :)


      True, but seems like x86_64 would still be a better choice for matching amd64?
    • All of the Debian kernels have amd64 in them. I don't why I didn't use x86_64 though. I use it for arch detection in bash (omv-mkconf file). Changes at different times I guess.
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.2
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • Note that it requires patching for multi-device btrfs filesystems to work properly with udev and sysvinit on Wheezy rather than systemd; add the following lines back in to the override_dh_auto_install section in debian/rules:


      I solve this with device=/dev/sdb1,device=/dev/sdc1,device=/dev/sdd1,device=/dev/sde1,device=/dev/sdf1

      Source Code

      1. nano /etc/fstab
      2. UUID=ce25f8ff-716f-45ad-9b56-15948007898f /media/ce25f8ff-716f-45ad-9b56-15948007898f btrfs device=/dev/sdb1,device=/dev/sdc1,device=/dev/sdd1,device=/dev/sde1,device=/dev/sdf1 0 0