Beiträge von stone49th

Having the same issue here since I updated to OMV 3 just yesterday. Besides this, everything seems fine so far.

A few minutes ago, I removed the current config and generated a new one with omv-mkconfig samba. So far no error with clients connected, but I have to retest without clients this evening...

Edit: Nope, false alarm...error also persists with clients connected and config regenerated...

Any way to "safely" but completely purge samba with all associated stuff and regenerate the omv-configs?

Edit2: Ok, maybe I fixed it somehow, now I got 3-4 reboots and shutdowns without the panic...Steps included reinstalling samba and fixing an issue with my nut-client for remote UPS on the way...I also regenerated the smb.conf once again....I will report back if the panic keeps popping up the next days...

Zitat von T.Underhill

I can confirm that the build dependencies install a run-time dependency of btrfs-tools, because on the VM I used for compiling, there was no dependency issue when installing the btrfs tools.

I plan to do a new VM install (I messed up "tweaking" monit config files) so I'll be able to tell you later (today, i hope) what package was missing.

EDIT:
The missing package is liblzo2-2

Nice, thanks for the debugging

I've updated the build script for the 4.4-series. Removed the stupid hard-coded version number - you can now simply specify the last digit of the version when asked for by the script. 4.4.2 is out, and 4.4 is more or less in the lts state...script shouldn't need much change/attention in the future.

Looking forward to OMV3.X and repeating the work once again for the next 4.X / 5.X LTS-Kernels to come

yes, the symlink removal is safe...this leads only to non-existing sources for the debs, but thats not an issue. The headers are important to compile dkms modules and other stuff on demand, but as long as they install correctly you should be good to go.

the btrfs-tools might need some dependencies, but as long as a standard install command resolved the issue, it should be fine. Do you remember which package was missing?? Might be that the build dependencies I install automatically when the scripts run install a run-time dependency of btrfs-tools.

Good to hear that the scripts are helpful to somebody

I've updated the build scripts and the config to 4.4.1 and updated the kernel on my machine. So far no issues or stuff in the dmesg, other than a Device Tree Error for CPU0 which is perfectly normal...since I enabled device tree support for embedded systems (though some drivers might be missing, but thats why I enabled the menuconfig during the kernel build, so you guys can select/upgrade the config with your special SoC driver suites).

Also updated the github-repo with a new build script and a new config (.config_4.4.1). Make sure to install btrfs-tools_4.4 after you installed the new kernel (compile against 4.4 kernel headers, not before kernel is running) if you're using btrfs. I'll try to stay up date with 4.4 series for now, kernel 4.1.X support is therefore deprecated

The problem with his script is that he modifies the sources.list. This is never a good idea, and might lead to very bad things...But hey, they work good, so we now have 2 working ways to easily get a working recent kernel to the old but great wheezy and OMV 2.X.

Anyone interessted in bcache-tools? I can provide a script for those too if someone needs it (might experiment with it, hence the idea...)

And btw, just updated the repo and added a btrfs-tools script for version 4.4. Config for kernel 4.4 is on the way, and I'll try to optimize it as much as I can while not throwing out too much drivers and stuff to be compatible with most (and old) hardware and also embedded stuff.

Did you do *anything* to any libs in your system? I mean, like really stupid things...there were this stone49th guy who updated his libc, which was not a good idea

This is rather strange...could someone not on the latest 3.beta try out the scripts?? I'll to setup a vm if nobody can help out, but this will have to wait till next week...

Edit: I just ran the scripts in a fresh vm, OMV 2.x series, no fiddels other than omv-extras and the backports kernel. Building and installing the kernel and the btrfs-tools went fine, without any failures. I guess I therefore call the scripts final and for general public use.

You're on jessi...thats the standard backport kernel right now. Compiling should work nonetheless, with the stock kernel in place. So for the beta-users I guess and until I moved to 4.4, there is no need to do this. Please report back if something goes wrong or the compilation went fine (might take up to 45min...my i3 rig is faster on the SSD, but still needs a coffee and a cigarette ).

Ok, please go back to stock kernel, reboot and then try to buid the 4.1.15. This is most likely the broken libc in my old packages. Sorry Mate

Hm, this is strange, the source shouldn't be altered at all if you dont run ./autogen.sh manually. Did you try to do this as root? If not, could you try it as root, and as root in /root/ to see if this a permission issue?

If not, and if you used my previous kernel packages, please build a new kernel first with the new scripts....the old ones were not that great...because of this whole libc idiot move I did...

Edit:
Jup, just checked, this is libc relates...the log states it already...please drop my old kernel and build a new 4.1.15 with the script (btrfs will be fine without the tools until you build and add them)

Ok. Sorry, I overlooked your error in the btrfs-tools build. Can you try to start clean, deleting the source folder and the downloaded files and start over again?

oh, I see systemd, are you on OMV3.beta with the dmesg output?

The ACPI error is actually a feature, not a bug. Strange enough but see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349740

Must be on your skylake rig or the J2900 one because of the hda_intel error...seems like this is normal for a headless machine, since the HDA audio driver can not access the intel integrated gpu driver and hence the error, see (sorry, GERMAN): http://www.phoronix.com/forums…q-nvidia-geforce-gtx-970m
You could disable the on-baoard audio, if you don't use it to get rid of the message, or simple don't give anything about it. Same goes for the systemd error I guess, because no display is connected, aka. headless?

The tsc error is more complicated. Try to google for that one yourself for a while, I see different solutions/sources of this. http://askubuntu.com/questions…st-tsc-calibration-failed seems to solve an issue with a patch that came into the kernel some time ago (after 3.16). Or even better, see https://eduard-dopler.de/de/64…bration-failed-loswerden/
(sorry, german again). He states running:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

and entering the returned clock source in the grub option also works great. Effectively changes the default clock source the kernel starts to try out...the message was promoted from "FYI" to error due to the patch...

The dvb-usb might not be of any importance at all, if the device works.

Edit: I provided an expeimental 4.4 config in the repo...but use this own risk, its experimental and not tested at all. In theory, it should work, but I did not compile the kernel, just made the config based on the 4.1.15 one (with oldconfig).A whole lot of new options there...as always
Edit2: For the btrfs-users out there, it might be a good idea to delay the 4.4 update until btrfs_tools has its new version out as well, right now they released the 4.4rc1 version 13h ago...They had some issues with previous new versions (some even resulted in fs damage). I'm really not willing to go there too fast and risking data and spending hours to fix a broken storage, even with external backups...

Just a quick sidenote: Depending on how new your hardware is or how often non-free updates are published and required by the kernel, it *might* be necessairy, to look out for dmesg entries for microcode.
Example: My MB has a Intel 7260 WiFi onboard. The microcode revision required by the kernel was missing (not that I was using the device, but anyway, I dont like errors in dmesg...). Just run these with the new kernel, to check if something is missing or not in place. Firmware can be downloaded on a per file basis from the kernel homepage directly. Just google for it according to the dmesg entry.

dmesg | grep error
dmesg | grep fail
dmesg | grep critical

Zitat von hammondb4

Hi @stone49th
I was triying to compile using your scripts and I found in my case that it's necessary to include in build_btrfs_tools.sh to 'apt-get install' the 'devscripts' package because it includes the 'dget' downloader and without it the script crashes.
Thank you for your scripts. Would be nice to move to latest version of kernel.
Greeetings.

Thanks! I added devscripts to the inital apt-get. Did someone try out the kernel build scripts? Did I get the dependencies right there too? I'll try to provide a working config for 4.4 as soon as it reaches 4.4.1 (no longer ml but in its lts state).

Repo is updated with config and build scripts for btrfs-tools and kernel 4.1.15. The readme is out of date, I will update the page some time soon, but the scripts seem to work. Please report any erros / problems in using them, github issues preffered
Edit: Readme updated.

See:
https://github.com/Stoney49th/openmediavault-linux-kernel

Just script files:
https://github.com/Stoney49th/…ster/build_btrfs_tools.sh
https://github.com/Stoney49th/…ter/build_linux_4.1.15.sh

If you build for a different architecture then amd64, you have to change the --append-to-version to whatever holds for your CPU. The compile arch itself is most likely auto-detected based on the current kernel. If you like to change the script and work with a more recent kernel, feel free, but make sure to run menuconfig after downloading and before clean...you obviously know what you're doing if you go this route

after some time, I finally found the time and the guts to revert my inital idiot move of upgrading libc6...so, this is what I went through and how I got things to work (and compile) perfectly now:

Libc6 downgrade:
oh boy, what a mess. Finally got the idea why everybody who knows something about distros will tell you that this is a very, very bad idea. But got it back to wheezy-backports state, with the 3.16 kernel booting.

Update btrfs-tools to 4.3.1:
Before the kernel upgrade, I decided to recompile btrfs-tools myself. The steps listet in this thread (sh-script) were very very helpful. But I realized that the standard source is missing some important udev patches, which make volumes not mountable during boot or even manual intervention. What worked our perfect for me was:

• Install prerequisites as per shell script in this thread
• run:
  
  Code

  dget -u http://http.debian.net/debian/pool/main/b/btrfs-tools/btrfs-tools_4.3-1.dsc

  this will pull the necessairy stuff from the debian archives, extract it into a new directory in current dir

• cd into extracted btrfs dir
• run:
  
  Code

  dpkg-buildpackage -us -uc

  this will create a working package. DO NOT RUN ./autogen.sh. buildpackage will complain, because this alters the already patched and configured sources.

• cd ..
• dpkg -i with the created package

After that, i got a working btrfs-tools, with proper udev rules and all the goodness, including all pre- and post-install scripts in the package.

Kernel building:
Totally different approach now. Since I already got the .config, things were easy. I still went with 4.1 series, since it is lts, and 4.4 is still a bit new. But I will upgrade when it hits 4.4.1 or maybe 4.4.2.

• Code

  apt-get install git fakeroot build-essential ncurses-dev xz-utils

  
  

• very important to get make-kpkg:
  
  Code

  apt-get --no-install-recommends install kernel-package

• Code

  wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.1.15.tar.xz

• Code

  tar xvf linux-4.1.15.tar.xz

  
  

• Code

  cd linux-4.1.15

• copy .config and run make menuconfig, just to be sure. You can get my config from github (see this thread)
• run the magic:
  
  Code

  fakeroot make-kpkg -j5 --initrd --append-to-version=-amd64 --revision=1.0.YOURCUSTOMNAME  kernel_image kernel_headers

• cd ..
• dpkg -i the header and image

Building with make-kpkg is so much easier, and from what I've read, preffered over deb-pkg (make-kpkg actually runs deb-pkg and A LOT of other stuff). With these, everything seems to be in place properly. I got rid of a lot of concerning dmesg entries from my previous compiles. I will work on the github repo some time soon to update the instructions and provide the packages there, since I'm back on stock libc6 now, which shouldn't break with all the other packages anymore.

Sorry for some redundant information for some of you, hope this helps, just wanted to give you guys an update. I'm going to upgrade my hardware in the future (C226 based MB with IPMI, ECC RAM, more drives), hence the need for some additional work here. Stay tuned for the updated packages on the repo...I will remove the source completely and only provide .configs and prebuild packages in the future...but this will have to wait until the next day or the upcoming weekend.

Ok cool, i'll try to do the downgrade some time soon and see if i get things working...on the other hand, my system is stable and running atm, so I'm not so sure if I really want to change the lib back

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

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

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.