read this one until the end - same issue, i guess --> https://github.com/Stoney49th/…ult-linux-kernel/issues/1
I'll update to a more recent 4.1 in the next days, just FYI (which probably wont resolve your issue...)
Since we now had this problem two times already, it seems like something is wrong with some installations...did you also update from old versions like the fellow member in the github issue?
Updated to linux-4.1.7. Update went fine - updated the github repo.
VirtBox installs and compiled just fine, he might have a general problem - see the issue on github. I tested this yesterday. Creating and running vms worked wirh my machine.
the plugin also for some reasons needs the full kernel source, and the .config slipped by my initial commit because of the kernels own gitignore. It's now included in the repo.
Its up: https://github.com/Stoney49th/openmediavault-linux-kernel
You're welcome 
Report issues directly via github, it's easier to track them there. Since I only can devote very little time to this, I'm not sure if I can provide proper support...
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?
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
make -j5 deb-pkg LOCALVERSION=-omvstone KDEB_PKGVERSION=5
soon to be changed to
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?!
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
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.
Ok, now docker is fine again (yet another option from the cgroups missing in grub linux config (cgroup_enable=memory swapaccount=1, from here: https://docs.docker.com/instal…emory-and-swap-accounting) which wasnt an error but a warning i fixed up along the way).
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:
#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-omvstonedon't know whether an additional "_amd64" or something is missing after the localversion "-omvstone"...any clues on the "correct" name for omvextras?
If I remember, It guesses the arch based on uname. So if the kernel wasn't named properly some repos might be unavailable. You can check the source in github
could well be the case, I'll check on that.
Enough of compiling for today...aufs is now fine, but I messed up with the iptables options (damn, thought the oldconfig would deal with that...), and docker/iptables was complaining yet again...seems like this might take some time to get all the options right. I'll check on them later after some sleep and work.
ah ok, but I guess that requires deleting images/containers and starting over...right now I'm just too lazy for a re-setup
I'm building with vanilla, so the gcc dependency is no problem... just a strange thing though, with the last build without aufs, I noticed that the repo-options (different categories like multimedia/filesystems/etc.) in the omv-extras tab were gone, but the addon-packages itself were still selectable. Does the omv-extras somehow check/work with the kernel version installed?
ok, thought I got everything...seems like aufs is missing in my current configuration (dockers needs it, 
). But I can't find it in the menuconfig...or this is some debian patchy thing to include those modules...back to building 
Edit: patching done, yet another compile run
Hi, I did the update to 4.1 some days ago. Running stable since then, no issues so far (I also didnt expect any).
Went with standard kernel.org source (stable:4.1.6, not the 4.2 - just to keep on the stable side of things), and used the old 3.16 packports config. I really didn't change anything, but I ran menuconfig and resaved just to be sure.
Make sure to also update the btrfs-tools as well if you're using btrfs as your main storage FS (like I do). I used this one: http://ftp.se.debian.org/debia…s-tools_4.1.2-1_amd64.deb. It's the "after-bugfix version" without the broken mkfs in 4.1.1.
So no fiddeling around with apt and sources, and it just works I had to replace two variables in the rules file prior to building since dpkg-parsechangelog failed on me (might be too old on wheezy, but who cares). Just filled in the release date and distro manually from the output of "dpkg-parsechangelog" and things went smoothly from there on. bs was also missing on my system
Oh, btw, I generated packages like this guy here to re-install later/keep them:
The plugin is great!
To spoil the fun a bit:
Currently my emby with the omv-emby plugin from the repo (1.0, thanks guys!) is only listening in on IPv4 adresses...
mono-sgen 9367 emby 40u IPv4 26374 0t0 TCP *:8096 (LISTEN)
mono-sgen 9367 emby 42u IPv4 26375 0t0 TCP *:8921 (LISTEN)
... more localhost connections for the DB and stuffany way to get emby to listen in on IPv4 and IPv6?
Dont know weather its a hard task or not, but I bet there is also some effort involved with mounting the volume correctly (had to change the mount options in the config.xml by hand, etc.).
Also, don't forget about all that functionality for error reporting, restore, configuration, balancing, srubbing, etc. Proper error reporting and stupid-user checks also need to be implemented... guess a very experienced plugin dev would be required here. Anyhow, if one ready the mailing list on btrfs, it's really not that production ready, since raid56 and some other features have just been released in the latest kernels. Another problem is, that the interface to the btrfs tools changes quiet often from release to release, so the effort maintaining and testing a filesystem plugin that does not kill your data or fs would be too high for just another side project of a side project. You have to monitor the mailinglist, keep tracks of the bugs and avoid them. I don't know... I personally wouldn't touch it just now. Btrfs is on a good way, but its still evolving too fast for a rock-solid integration in my opinion.
Could be the case that I'm completely wrong on this matter, just my thoughts 
I guess your right...would be a great thing if we get to jessie during this years course of development...Maybe I'll just get the hdds and convert to a raid10 instead, which seems stable right now. I'm pretty impressed by btrfs at this point...did Volker already talk about making btrfs the default data fs, once the parity features aka raid56 become stable?
Could you then post some instructions on how to compile the kernel for omv/debian?? I'd love to update to 3.19.0 / 3.19.5 for better (or even some) raid5 support...I successfully migrated from a old xpenology disk setup with md and lvm to a btrfs raid1 (due lacking srub, etc. support in the 3.16 packport kernel) which is working fine, but I'm going to replace the oldest hdds pretty soon on my setup...time to migrate to a raid5 again, if I get the right kernel and maybe an updated version of the tools too :). Or are there any guides on the forum for the kernel stuff?? I'm not a real expert for the kernel config during build...
Out of curiosity, I just checked my fstab (OS resides on small Intel SSD) and the "discard" parameter is missing How can one edit this file to survive mkconfigs? Currently, only errors=remount-ro is setup there....the filesystem is ext4. Can anyone recommend some parameters?
hey,
jup, this also worked at my machine with the fritzbox network. Thanks for the help