Kernel 4.x wanted, running OMV 1.19

  • 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

    • Offizieller Beitrag

    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 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    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

    • Offizieller Beitrag

    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 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    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.

    • Offizieller Beitrag

    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 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    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


  • 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....

  • 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



    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

  • Do you think i can try this solution to have my dvb driver working ? (normally include in kernel 4.2)

    OMV Erasmus (always the last version) - version:AMD64 - noyau:4.7.0 - CPU:AMD II X2 250 - RAM:8Gb - RAID1 and RAID5

  • 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:

    Code
    #name -a
    Linux MyHost 4.1.6-omvstone #5 SMP Wed Sep 9 11:03:03 CEST 2015 x86_64 GNU/Linux
    #uname -r
    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?



    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: https://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.

  • 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:

    Code
    # Adding udev integration
    	install -D -m 0644 debian/local/btrfs.udev debian/btrfs-tools/lib/udev/rules.d/70-btrfs.rules
    	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.

    • Offizieller Beitrag


    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 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • 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.



    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?

    • Offizieller Beitrag

    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 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Zitat

    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


    Code
    nano /etc/fstab
    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

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!