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.
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.
According to the labels on the cloudshell.
Hopefully I didn't mix anything up.
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.
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.
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.
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.
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
Alles anzeigen
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
Alles anzeigen
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
Alles anzeigen
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).
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')
@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
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?
can you help with the certificate please?
It is just a warning and fixed by apt-get install openmediavault-keyring
Thank you. Installing OMV now 94MB of dependencies downloading... that was a surprise.
will start new thread if I need any more help... hehe
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
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
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.
# 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
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)
BTW: It might be useful to insert the following drivedb entry nearby JMS567 entry in /var/lib/smartmontools/drivedb/drivedb.h:
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!