Beiträge von k-meleon

    Hi all!


    As I have already reported in https://forum.openmediavault.o…u/?postID=79653#post79653 I have created an EyeFi plugin for OMV2.x which worked without any problem. I tried to update it to OMV3.x, but after installing it, omv reports that "The data model 'xxx' is already registered.


    How can I analyze that issue? Could someone please support me?



    Thank you and best regards,
    k-meleon

    Yes, I even used the backports 3.2 kernel on Squeeze before I recompiled my own kernel.


    Well, it seems to be a BIOS setting which wasn't respected in Squeeze and in Wheezy now is (exactly the same kernel was used on both systems, it wasn't even replaced): I disabled all PowerManagement features in BIOS now and the speed seems to be as fast as on Squeeze. The system comsumes 1,5W more power. I'll try to install Openmediavault now and let's see, if I can reach the throughput via Samba as on Squeeze.

    Hi guys!


    I created a backup of my OMV 0.5.x Debian Squeeze image and tried to update to Debian Wheezy (due to some missing bluetooth feature). The update was done without nearly any problem. What I noticed is, that the system seems to be slower than before (i.e. in apt-get and omv login). But I thought, that this is a result of updating (larger databases, more files, obsolete files etc.). As I compiled my own kernel I even suspected some kernel changes which have to be done for Wheezy (currently running latest stable 3.16.1) or CPU governor problems. So I rebooted with the latest backport kernel for Debian Squeeze which was 3.2.0.x . With this kernel the machine was even 5 times slower, than with my self-build kernel. The transfer rate which was 35MB/s via Samba shares (and S-ATA) before dropped to 12MB/s after the update. Writing to NTFS via USB2.0 even dropped to 1MB/s. What the hell is going on there?!


    Well, I thought, that the update might be the problem, so I just reinstalled Debian Wheezy via the netinst image. But I get the same SLOW speed. The Linux systems seems to be as slow as on a I386 !
    Does anybody know why the system is so slow?


    The hardware I'm using is a Kontron PITX-SP based on an Intel Atom Z530 with 1.6 GHz and 2GB RAM.


    Thank you and best regards,
    k-meleon

    No, I didn't change anything beside turning on the SSH and Samba service. I haven't got a HDD installed right now, only the micro USB stick.


    What I've tested now:


    libparted and parted is definitely not the problem: I just installed the two packages, rebooted and tried with omv 0.4.6 . I was not able to crash the system. Everything is fine and stable. My last step (some minutes ago) was to install the last package offered by the Update Manager: omv 0.4.16 . After the update I clicked on "Physical Disks" and I instantly reproduced the crash. The first message is


    usb 1-4: device descriptor read/64, error -110


    and when I try to run the "poweroff" command a lot of the following error messages are displayed:


    EXT4-fs error (device sda1): ext4_find_entry: reading directory


    It seems, that the USB stick is disconnected for some reason. I even attached a 'stronger' power supply...with no luck. Before installing the update I installed a lot of packages and had a fine and stable system.


    It seems, that - for some reason - omv is bringing a hidden error to light. Even the current backport kernel 3.2 doesn't solve the problem :(


    Volker, do you have an idea :-)?

    Thank you for your time! That normally should reproduce the error. It's really strange! I installed it over and over again to try to fix it, without success! As soon, as I installed the update, I get this error.


    I'm using a similar USB stick: Kingston DT Micro with 8GB. And I even tried a completely different NoName USB stick with USB2.0 and 2GB just to see if it's the stick which is causing the problem. Same result with this stick! Strange!


    The system is a fitPC2 (Intel Atom Z530 @ 1.6 Ghz, Intel SCH US15W Systemchip, Realtek RTL8111D).

    Hallo!


    I just installed the OMV iso (0.4.6) on a new micro USB stick. Everything is working without problems! I can selectively update packages which are reported by the Update Manager. But as soon as I update OMV to 0.4.15 or 0.4.16 (which indirectly selects parted and libparted due to dependencies) I can crash the whole linux system really fast by clicking the "Storage" sub entries (Physical Disks, RAID management, Filesystems, S.M.A.R.T.) one after the other randomly. The WebGUI just says that it's "Loading" and never changes this state again. After some seconds tty1 (via TFT-display) reports lots of


    usb 1-4: device descriptor read/64, error -110


    messages. After that, you get lots of ext4 error messages and the system is inoperable now. If you are logged in via SSH, the system doesn't find any command (i.e.poweroff etc.) anymore. After a poweroff everything works fine until you use the WebGUI again! An update to the current linux kernel (3.x) doesn't resolve the problem. A reinstall of OMV on this USB stick is possible and the problem is gone until you update to 0.4.15 .



    The micro USB stick runs fine in every PC I own and is brand new. I even verified, if data that is copied to it, is consistent. Everything seems to be fine!


    Is the parted stuff perhaps responsible for that? As soon as I install any of the three left packages (libparted, OMV or parted), the system crashes with some clicks. Is that a known problem? Can I exclude the parted stuff from updating to find the package causing the problem?


    Of course I know, that it's not advised to install OMV on USB flash devices, but why was it working on version 0.4.6 without a problem?


    Thank you for your support!


    Best regards,
    Sven

    It's pretty early now, but I got it working without any hard problems:


    - downloaded Debian Squeeze kernel
    - copied the kernel config from OMV (/boot/)
    - compiled the 2.6.32 kernel+modules on my Ubuntu VMware
    - installed modules
    - adapted the Realtek scripts to work with a kernel, which is not the running kernel
    - compiled the driver
    - rmmod r8169 and insmod r8168
    - update modprobe stuff
    - update init-ramfs
    - reboot


    The driver is accepted by the OMV machine kernel and the ethernet link seems to be not crashing anymore. Perhaps it's a little bit slower, but better slower than crashing. Link speed is set to correct 1000Mbit.


    Yeeeha!

    Sorry, you are right of course, I meant Ubuntu.


    Your solution is possible, but I don't prefer it. Imagine I use four or five different boxes running linux (i.e. Dreambox, OMV, Popcorn etc.) and for every box I have to install and maintain a different linux version running in a virtual box. I prefer to only have one linux box which I have to configure and maintain. From this machine I want to be able to compile for all different linux boxes. Please don't get me wrong, I'm just asking if this is easily possible!


    If the effort for this is higher than the effort to maintain five different virtual boxes, this makes no sense of course...

    Hallo!


    First of all I have to thank Volker for OMV and his great work. I'm really happy with it!


    Unfortunately the current kernel used for OMV uses an ethernet driver for the RTL8111, which very often looses it's link under high load on 1000MBit and makes OMV unreliable/inoperable for me. So I have to use the ethernet driver from Realtek, which I have to compile first. Despite this I want to compile some other sourcecode for OMV.


    As I don't want to install gcc and compile the stuff on my OMV-PC (it's very slow) I have to "cross compile" everything on my laptop. As I'm using Debian 12.04.1 on it, I fear that many things will be incompatible and the compiled files will not work (different libc, gcc and kernel). So my question is, if anyone has more experience in that and explain the easiest way to get a working compiled file.


    In the embedded world, one can download a cross compile toolchain and it's done. How is it done in this case?


    I guess there are three possible solutions


    1. I downgrade my laptop to the exact version OMV is using (which I don't prefer)
    2. I use my current debian version and download the packages OMV is using and cross compile
    3. There is no problem and I only have some strange thoughts


    Any other solutions? Can somebody help me?


    Thanks for your help!


    Best regards,
    Sven