Install OMV on Debian, Qnap TS-109 II

    • Offizieller Beitrag

    Did you install omv-extras? I guess that would help. Didn't think to mention that. OMV-Extras.org Plugin


    That will help with both of those problems.

    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!

  • I finally got the OMV-Extras.org plugin installed, and managed to activate the flashmemory plugin, between error boxes. As SSH access was available and working, I also edited fstab like flashmemory-plugin instructed, saved, rebooted, and did omv-aptclean. This was rather long, about 10 minutes to complete execution.


    But it's not really faster overall, and, accross reboots, ports for SSH and the Web GUI may or may not open, and the serial console would or wouldn't let me log in (stays frozen at the "login: prompt").


    Using htop, I see the CPU stays at 100% with very high load numbers (5 and above), all caused by the webgui itself (multiple instances of php-fpm: pool openmediavault-webgui).


    I don't know if this can be helpful, but the OMV engine itself rarely takes more than 10%.


    Perhaps the issue on this low-power system comes from php-fpm configuration? Starting too manu child processes?

    • Offizieller Beitrag

    An RPi1 isn't much faster and I don't remember having these problems with it but I never tried Jessie on it. Is the IOwait high?

    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!

  • Hmmm, the top command yields


    top - 13:17:25 up 2:16, 1 user, load average: 0,88, 0,31, 0,20
    Tasks: 86 total, 6 running, 80 sleeping, 0 stopped, 0 zombie
    %Cpu(s): 95,3 us, 4,1 sy, 0,0 ni, 0,0 id, 0,0 wa, 0,0 hi, 0,6 si, 0,0 st


    while the interface is displayed.


    wa seems nil


    There's no iostat here.


    iotop yields:
    Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
    Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
    TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
    1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init
    2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
    3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
    5 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]


    Not sure if indeed CPU is too weak (I have OMV 2.0 on a RPi 1 rev B that has issues, but nowhere as bad as this board). What is your hypothesis on this?

    • Offizieller Beitrag

    The 5182 cpu in your device is armel only meaning no hardware floating point (does it in software which is slow). At least the RPi1 has a partial implementation of floating point (vfp2). So, my hypothesis is that it is just slow.

    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!

  • Would there be a way to work around this issue so floating points operations are avoided as much as possible?


    I know it's kind of strange since non-floating point CPUs have almost disappeared.


    Does that means Debian has been compiled for armel, but not php5-fpm?

    • Offizieller Beitrag

    Would there be a way to work around this issue so floating points operations are avoided as much as possible?

    I think the everything uses floating point. There may be some integer only encoders but the Linux/Debian isn't written that way. That is why these CPU emulate the floating point unit. OMV is using bash and php mainly. There really isn't a way to avoid floating point operations.

    Does that means Debian has been compiled for armel, but not php5-fpm?

    Not sure what that means but there is a release of Debian for armel and armhf. php5-fpm would be compiled for each one.


    Sorry to say but I think you need to give up your dream of a smooth running OMV install on this thing. I have a Qnap ts-451 that runs regular 64 bit (amd64) OMV 3.x and it is wonderful.

    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!

  • Sorry to say but I think you need to give up your dream of a smooth running OMV install on this thing. I have a Qnap ts-451 that runs regular 64 bit (amd64) OMV 3.x and it is wonderful.

    I'm jealous. Being cash-strapped at the present time I have to choose between a completely silent setup (i.e. SSD) OR a recent Pi, but not both.


    Would a Banana Pi be powerful enough for OMV 3.0?


    Still wondering if it would be possible to upgrade the internals of a regular Qnap firmware and keep their low-requirements GUI.

Jetzt mitmachen!

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