Building OMV automatically for a bunch of different ARM dev boards

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

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)

Forgot: Additional 'armbianmonitor -u' output when running in PM mode would also be great.

Zitat von tmihai20

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!)

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

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.14 (AF)
Device Model:     ST1000DM003-1CH162
Firmware Version: CC49
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA/ATAPI-7 (minor revision not indicated)
Local Time is:    Wed May 24 11:44:04 2017 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM level is:     254 (maximum performance)
Rd look-ahead is: Disabled
Write cache is:   Enabled
ATA Security is:  Disabled, frozen [SEC2]
Wt Cache Reorder: Unavailable

And this for /dev/sdb:

Model Family:     Seagate Barracuda 7200.14 (AF)
Device Model:     ST1000DM003-1CH162
Firmware Version: CC49
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed May 24 11:44:04 2017 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM level is:     254 (maximum performance)
Rd look-ahead is: Enabled
Write cache is:   Enabled
ATA Security is:  Disabled, NOT FROZEN [SEC1]
Wt Cache Reorder: Unavailable

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):

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:

REPORT-IOCTL: Device=/dev/sda Command=SMART STATUS CHECK returned -1 errno=38 [Incomplete response, ATA output registers missing]
SMART Status not supported: Incomplete response, ATA output registers missing
...
SMART capabilities:            (0x0000)	Automatic saving of SMART data					is not implemented.
Error logging capability:        (0x00)	Error logging NOT supported.
...
REPORT-IOCTL: Device=/dev/sda Command=SMART READ LOG returned 0 errno=38 [Incomplete response, ATA output registers missing]
...
sat_device::ata_pass_through: scsi error: aborted command
ATA_READ_LOG_EXT (addr=0x00:0x00, page=0, n=1) failed: scsi error aborted command
Read GP Log Directory failed


SMART Log Directory Version 0
Address    Access  R/W   Size  Description
0x00           SL  R/O      1  Log Directory


SMART Extended Comprehensive Error Log (GP Log 0x03) not supported


SMART Error Log not supported


SMART Extended Self-test Log (GP Log 0x07) not supported


SMART Self-test Log not supported


Selective Self-tests/Logging not supported


SCT Commands not supported


Device Statistics (GP/SMART Log 0x04) not supported


SATA Phy Event Counters (GP Log 0x11) not supported

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

Zitat von tmihai20

I will use the latest available image

That's the best idea anway. I touched XU4 OMV relevant stuff today one last time and here is an archive with latest kernel 4.9.29 for XU4: http://kaiser-edv.de/tmp/NumpU6/ ('dpkg -i')

Zitat von ryecoaaron

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)

Zitat von jata1

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)

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

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

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.

Zitat von ryecoaaron

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)

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:

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