Kernel 4.x wanted, running OMV 1.19

  • Cool, thanks :)


    I'll do another compile run today and see if things work out.


    Any further things somebody needs in the kernel? I am very willing to share the packages once omvextras is working correctly again! In case people want to try btrfs raid56 or other new features like the ext4 encryption (already compiled in), etc. Currently, the most vital FSes are compiled into the kernel, the remaining ones are are modules. I also can include more device drivers as modules for convinience.

  • Impressive progress! I'm afraid I lack the experience you guys have. I tried to compile, but failed, among others because of lack of space on my VM (disc size was only 10 GB). I noticed that bc was missing as well.
    I downloaded a Ubuntu/Debian 4.2 kernel from here to try out, and i used the updated btrfs-tools as well. System booted at least and OMV seems to be running.
    But... I noticed the same behavior in regards to the repo-options (missing categories) in the omv-extras tab.


    @stone49th, subzero79
    Would you be willing to make the kernels you compiled available to me (as a .deb packages, the image and header package i think?).

  • Well, not so much progress after all ;) My box has not come to live this morning and is not responding to wol either...so I can't compile the kernel until I get back home to the machine...


    I've actually never compiled a kernel "The Debian Way", but it might be worth a try. Let's see if the wol / rtc-start issue is kernel or config related...I might have messed up with ACPI/Network/Drivers there or it did not configure it properly (maybe a redo in the webgui would help...)


    @subzero79
    You already poked around with the debian source...did you use this one? https://packages.debian.org/je…ackports/linux-source-4.1

  • Yes that one. I modified the control
    file for gcc4.9, but it wasn't enough, plenty of other references. My guess is to use the vanilla one to avoid this annoyances. @davidh2k once mentioned me the steps for building vanilla to be standardized to Debian package, including the headers

  • Ok, my attempt would also be to work with vanilla, and provide those to people willing to use a more recent "non-debian" kernel if they wish to do so. It's much easier to compile and deal with.


    I was building with something like

    Code
    make -j5 deb-pkg LOCALVERSION=-omvstone KDEB_PKGVERSION=5


    soon to be changed to

    Code
    make -j5 deb-pkg LOCALVERSION=-omvstone_amd64 KDEB_PKGVERSION=6


    Hopefully omvextras will accept that. Outcome is the usual .deb collection of headers, images, firmware, libc-dev and debug-image. I incremented the pkgversion after each run (to avoid dpkg yelling at me) because I wasn't sure if I could re-install the .deb in a simple way otherwise without switching kernels, reboot, purge, install, switch, reboot. So far the simple dpkg -i for all packages worked without issues, plus the usual reboot.


    Main problem from my point of view is to know/find all of those patches that are necessary/nice to have for most people in the omv-universe which are not in stable-vanilla. aufs was one of them, which was easy to copy and apply and configure (aufs4.1-standalone). Don't know whether there are other "vital" patches for debian and if they are a major pain in the ass to apply. And a correct config, of course :)


    Edit: Just checked on those patches in the linux-source-4.1.6 by debian. Nothing special there for amd64, and besides aufs4, there is only grsecurity patched in which could be of importance for us. So I guess we're fine with vanilla then?!

  • Ok, forget about the wakeup issue...my fault in wrong auto-shutdown setup to pm-hibernate which my mainboard can't handle for some reasons.


    The kernel is compiling and I will test omvextras with it this evening. After that, I'll upload the debs to github along with my current source directory.


    Edit: omvextras is fine again. I'll upload during the course of the day, along with some basic instructions on how I build / install the kernel. Is there a way to "export the kernel config" to a more pretty format? So that people could easily see if a module/buildin code in question is in there?

  • I have install kernel 4.1.7-omvstone-amd64


    After reboot and install Virtualbox again this error message occur:


  • Thanks for your information’s.
    I have install Openmediavault 2.1 iso and then update to 2.1.16 and after that to 2.1.17.
    In Version 2.1.16 I install omv-extras.org plugin ( Virtualbox, Plex ).
    Now I want use your kernel. I install Git in Openmediavault version 2.1.17 and install your kernel with dpkg -i linux-*.deb.

  • Hm, first up the config seems to be missing in the source. Please go to the kernel source dir (should be in /usr/src/) and run "make oldconfig && make prepare".


    I guess you just have to install a newer version of glibc, I personally installed 2.17 back when I started with the kernel for no apperent reason from this thread here: http://stackoverflow.com/quest…on-2-13-to-2-15-on-debian. Should be working out of the box, but do not forget to remove the sid from the sources list afterwards or your system will break very badly.

  • Quote

    Please go to the kernel source dir (should be in /usr/src/) and run "make oldconfig && make prepare


    Not possible if I install the Kernel from your DEB packets. But your hind to install a newer version of glibc solve the problem.



    Short question why you install a new libc6
    Is it possible to provide a kernel that is compiled with the original version from Debian Wheezy?


    Thanks a lot!

  • Hm, not sure why I needed the libc update in the first place, whether it was a kernel dependency or by other programs. I'm rather busy right now, so I sadly cant do a further investigation in a vm right now. Maybe someone could help out...


    Setup would be:
    -OMV with extras+backports
    -Stock glibc (not sure if backports has a more recent version than stock wheezy)
    -get my github stuff and compile with my config
    -see if it works and report back the outputs, if it is fine, i'll look into providing two sets of packages for the different lib versions if one can specify the lib to be used for the build without rewriting all make files...


    So long,
    Stoney

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!