Building OMV automatically for a bunch of different ARM dev boards

  • Anyone here with access to Cloudshell 2 with 2 disks inside able to do a quick check of all 3 JMS561 modes (RAID-0, RAID-1 and JBOD) providing the output of the following script?

    I can later tonight.

    omv 5.5.1 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • According to the labels on the cloudshell.

    • PM - http://sprunge.us/WIIP
    • Raid 1 - http://sprunge.us/eTiA
    • Raid 0 - http://sprunge.us/McZV
    • Span - http://sprunge.us/fhgU

    Hopefully I didn't mix anything up.

    omv 5.5.1 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

    Edited once, last by ryecoaaron ().

  • Thank you @ryecoaaron! But unfortunately I forgot to add '-d sat' to the smartctl call. If time permits can you please provide output of


    Code
    smartctl -d sat -q noserial -x -i -r ioctl,2 /dev/sda
    smartctl -d sat -q noserial -x -i -r ioctl,2 /dev/sdb

    when Cloudshell is in PM mode again (and maybe even also for Span)? At least http://sprunge.us/WIIP answered already my main question: The two disks appear as one USB device so it's not another USB hub involved in this mode but real port multiplier functionality (thinking about how to get those capacilities, FIS based vs. CBS makes a huge difference performance wise)

  • I am coming back with the question. Should apt-get upgrade also upgrade the kernel? Because I was on 4.9.23 image (when I was testing this release) and after upgrade, the kernel was not updated. I also ran apt-get dist-upgrade.

    Riddle me this, riddle me that
    Who is afraid of the big, black bat?
    I write on a blog (Romanian mostly)
    Testing (latest) OMV 4.x on an oDroid H2 (currently with kernel 4.19.x)

  • Should apt-get upgrade also upgrade the kernel? Because I was on 4.9.23 image (when I was testing this release) and after upgrade, the kernel was not updated. I also ran apt-get dist-upgrade.

    Expected behaviour already answered above: Building OMV automatically for a bunch of different ARM dev boards


    We provide regular kernel updates only every few weeks since it requires an insane amount of testing (Armbian supports more than 50 different SBC in the meantime). So you either need to wait a bit, use Armbian's build system to generate own kernel package or much much better start over with latest OMV 3.0.76 image based on kernel 4.9.28 (for various reasons -- just check the link in my signature!)

  • I was under the (wrong) impression that, since there is a 4.9.28 image already generated, that there will be an upgrade on the kernel as well. I will use the latest available image, thank you for replying.

    Riddle me this, riddle me that
    Who is afraid of the big, black bat?
    I write on a blog (Romanian mostly)
    Testing (latest) OMV 4.x on an oDroid H2 (currently with kernel 4.19.x)

  • PM mode - http://sprunge.us/cKRP and http://sprunge.us/PXMg


    Span mode - http://sprunge.us/CcFI and http://sprunge.us/EeXY


    First link is smartctl output and second link is armbianmonitor output.

    omv 5.5.1 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Thank you for the output. Now it gets even more weird. With JMS561 in PM mode we get this for /dev/sda:

    And this for /dev/sdb:

    Please note the difference for 'ATA Version' and total lack of 'SATA Version' for /dev/sda. For sdb we also get more details (see 'SATA Phy Event Counters' for example). In Span mode sda info will be used and capacity of 2nd disk simply added. Hmm... no thanks, no Cloudshell 2 for me.


    Edit: Just to elaborate what's wrong with Cloudshell 2 behaviour: @ryecoaaron has one disk with a real problem (sdb in PM mode):


    Code
    197 Current_Pending_Sector -O--C- 100 100 000 - 104
    198 Offline_Uncorrectable ----C- 100 100 000 - 104

    In Span mode (will be the same with the 2 RAID modes) all this information seems to be missing -- see http://sprunge.us/CcFI:



    I brought this problem to Hardkernel's attention several weeks ago but wonder now how they deal with this? It's simply impossible to use OMV's SMART capabilities with 3 of 4 possible Cloudshell 2 operation modes. This needs a warning in big red letters. Also I wonder what this cloudshell-lcd script displays now with other modes than PM/JBOD? Just faked information for the unavailable disk or nothing at all?


    BTW: Anyone wanting to rely on this hardware and wanting to improve support for it... Please open a ticket upstream to get native smartmontool support (should be sufficient if it looks like this then).

  • @ryecoaaron has one disk with a real problem (sdb in PM mode):

    I thought I heard some funny clicks when I was powering the system up. Didn't have a chance to look at the output. I just put a couple of old drives in it for testing. I have more :)

    omv 5.5.1 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • I thought I heard some funny clicks when I was powering the system up

    Ah, great. Acoustic montitoring ;)


    We all know that relying on SMART data is useless to predict drive longevity. But there are some situations where something went already wrong and SMART data/checks become vitally important: that's at least those two attributes above 197 (Current_Pending_Sector) and 198 (Offline_Uncorrectable) as well as 193 (Load Cycle Count) and 199 (CRC errors indicating data corruption on the wire and therefore cabling/contact problems between SATA controller and drive). If these are not available but the user trusts in 'switching on SMART monitoring' then that's just an inexcusable fail that needs to be addressed by documention/warnings (or avoiding the product)


    BTW: The journey continues! Now that we have a bunch of mainline kernel patches here is OMV_3_0_76_Odroidxu4_4.9.28.7z -- be warned since the most important stuff doesn't work out of the box: https://github.com/armbian/bui…0f#commitcomment-22265098 (but since both issues are maybe just wrong/insufficient DT nodes that can be fixed using dtc tool from device-tree-compiler package and Igor decided to set support level to next instead of dev I thought I provide something to play for the more adventurous testers already)

  • @tkaiser - hope all is well with you. Not sure if you remember but we chatted on this thread a couple of weeks ago. You explained that i made a bad choice buying a Banana Pi M2 Ultra...


    Anyway, it arrived from china yesterday and i put the latest Bpi debian/jessie image on it. It seems to be working fine so far (4hrs and counting). What I want to do is get it running OMV (headless) and disable the Raspian GUI etc. Hope you can help a little bit. This is what I want to do:


    1. disable stuff that I don't need to start automatically. The raspian GUI for a start. Note that raspi-config does not work on banana pi
    2. install OMV using apt-get
    3. transfer boot / startup to eMMC from the SD card


    any tips or advice appreciated.

  • Banana Pi M2 Ultra

    Good luck, especially when using the crappy vendor OS images (full of security vulnerabilities due to an unpatched kernel and unauthenticated root backdoor -- adb listening on USB OTG port -- and according to banana pi forums also plagued with stability issues). Using Raspbian on any other SBC than 1st and 2nd generation Raspberries (those with the single core ARMv6 CPU cores) is IMO a great way to destroy performance since userland is compiled with an outdated GCC version for ARMv6 architecture.


    If you want to run OMV on this BPi M2 Ultra (or an even weirder design called 'Banana Pi M2 Berry' available soon) think about solving the general stability issues first (no idea how and whether that's possible at all), then think about improving IRQ affinity (see prepare_board function in Armbian's armhwinfo startup script for the idea) then add OMV and OMV Extras repository and finally apply the tweaks here: http://www.cnx-software.com/20…c-battery/#comment-542387


    BTW: community members patched M2 Ultra vendor kernel (3.10.65) up to latest 3.10 LTS version (3.10.105 currently) but of course this vendor doesn't give a sh*t and still provides only unpatched 3.10.65 on his OS images.


    I can't comment on problems maybe occuring when you add OMV (ARMv7/armhf) to a Raspbian (ARMv6) userland since this is nothing I would even think about and you should keep in mind that there exist different kinds of eMMC modules. The eMMC the Banana folks use on every board (except overpriced M3) is dog slow and ultra cheap EOLed eMMC that will be outperformed by every decent Samsung EVO/EVO+ (don't make a mistake and consider eMMC always superiour, faster and more reliable -- it depends!).


    And please let's stop discussing totally unsupported hardware here, simply ask for help in the vendor forum (to get the idea how lost you are with every Banana that is not based on A20 since while those first ones also receive no/poor vendor support they are backed by a great community and are able to run with latest and greatest mainline kernel)

  • ha ha. thanks! I'm only playing with this thing for fun - not using it for anything serious. I have a RPi OMV setup working fine.


    Most of the stuff you mention above is so far beyond my skill level but I will have a go over the next couple of weeks


    So far I have:


    1. disabled the GUI from launching at startup (thanks google)
    2. added the main OMV repo - echo "deb http://packages.openmediavault.org/public/ erasmus main" > /etc/apt/sources.list.d/openmediavault.list


    tried a apt-get update but it comes back with an error saying ... signature can't be verified because the public key is not available: NO_PUBKEY 7E7A6C592EF35D13


    so I think I need to add a key but not sure how. @ryecoaaron - can you help with the certificate please?

  • Anyone here with access to Cloudshell 2 able to test through 2 different scenarios with UAS disabled?


    You need to edit /boot/boot.cmd and append ' usb-storage.quirks=0x152d:0x0561:u' (trailing space!) to the line that starts with 'setenv bootargs', then do an

    Code
    sudo mkimage -c none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

    and reboot. Test with Cloudshell 2 in either PM/JBOD mode and in any of the other modes: chdir to a disk device that is handled by Cloudshell, then do


    Code
    stress -i 1 -t 10 & sleep 1 && smartctl -a /dev/sda

    And then please provide output from 'armbianmonitor -u' (containing relevant system info and also most recent dmesg output). Of course /dev/sda above should match the actual disk device where 'stress' is putting some IO load on.

  • Code
    # stress -i 1 -t 10 && sleep 1 && smartctl -a /dev/sdb
    stress: info: [3481] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd
    stress: info: [3481] successful run completed in 10s
    smartctl 6.4 2014-10-07 r4002 [armv7l-linux-4.9.28-odroidxu4] (local build)
    Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
    /dev/sdb: Unknown USB bridge [0x152d:0x0561 (0x8037)]
    Please specify device type with the -d option.

    armbianmonitor output: http://sprunge.us/UUVN

    omv 5.5.1 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Please specify device type with the -d option.

    Silly me! Sorry, I again forgot that '-d sat' is needed. The idea behind is to check whether SMART queries in certain modes (JBOD vs. Span/RAID) interrupt data connections.


    So it has to read instead (please note the single '&' in front of the sleep statement too, with '&&' it won't work)

    Code
    stress -i 1 -t 10 & sleep 1 && smartctl -d sat -a /dev/sdb

    BTW: It might be useful to insert the following drivedb entry nearby JMS567 entry in /var/lib/smartmontools/drivedb/drivedb.h:


    Code
    { "USB: ; JMicron JMS561", USB->SATA
    "0x152d:0x0561",
    "", 0x0100
    "",
    "-d sat"
    },

Participate now!

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