Building OMV automatically for a bunch of different ARM dev boards

  • @tkaiser - one last question...


    at end of the boot sequence the following is in the logs - relating to ttyS0.device


    systemd[1]: Job dev-ttyS0.device/start timed out.
    systemd[1]: Timed out waiting for device dev-ttyS0.device.
    systemd[1]: Dependency failed for Serial Getty on ttyS0.


    I did a search on google and found the following post
    https://medium.com/@madhav2cod…ttys0-device-827391917c5d


    If you see this “Timed out waiting for device dev-ttyS0.device” during boot up make sure that CONFIG_FHANDLE is enabled in kernel config.


    The web page / post had some code to create a script to check if FHANDLE is enabled. I created/executed the script and it reported that FHANDLE was not enabled in the kernel.


    Is this something that can be ignored or is it worth trying to fix it?

  • systemd[1]: Timed out waiting for device dev-ttyS0.device.

    You're on a RPi 3, right? There UART0 is used for the integrated Bluetooth module (and the whole situation with serial ports is a total mess anyway). Please try


    Code
    mv /etc/systemd/system/getty.target.wants/serial-getty@ttyS0.service /etc/systemd/system/getty.target.wants/serial-getty@ttyS1.service

    then reboot and report back.

  • There are a lot of inofficial OMV images for various ARM devices flying around. Most of them are created in a very questionable way (someone logging into an already existing OS image, then starting to fiddle around here and there, maybe making silly mistakes only bad guys might notice later). And they're all missing the improved settings we developed in this thread and that are active on the official OMV images in the meantime: https://sourceforge.net/projec…s/Other%20armhf%20images/


    How much difference do these settings make? Let's compare with cyryllo's SimpleNAS OMV image for Banana Pi. This is not created from scratch unlike the official images but has been done the 'fiddle around' way (bash history output).


    First let's compare Netatalk performance (since I've no Windows PC around).


    SimpleNAS:

    Official OMV image for Banana Pi:

    Now Samba (not the best idea since to access Samba shares from macOS we would need most recent Samba version and a few tweaks enabled).


    SimpleNAS:

    Now official OMV image:


    Test setup and disk (Samsung EVO 840) was the same as 3 years ago when I started with Allwinner A20 devices and especially this same Banana Pi. Back then I overclocked Banana Pi's SoC and DRAM and LanTest results were a lot better (see also) but will neither do this again nor investigate why performance is so low. It's 2017, USB2 enabled Allwinner SoCs that can make use of USB Attached SCSI outperform those 'native SATA' SoCs on Bananas (see eg. Pine64 numbers or soon various Allwinner H3 and H5 boards once kernel 4.13 is out), we have a few USB3 equipped SBC that outperform this all easily (more to come soon based on RK3328 and even cheaper than those Bananas) and we also have some real 'NAS grade' boards in the meantime where we can use 1 to even 9 'native SATA' ports that do not suck (too much ;) ).



    It's really useless to further investigate NAS performance problems with Bananas but at least by choosing the official OMV images for these boards you get a nice performance boost for free (and a cleaner installation too, eg. flash-memory plugin enabled so your SD card doesn't wear out that fast!)


    @cyryllo: please consider taking your OMV 3 images down and linking to official images. Also your images are currently affected by 'broken after apt upgrade'. Thank you!

  • I am using SMB and NOT AFP on my network at home - basically Mac's & RPi OMV server. All my mac's are running latest macOS - Sierra 10.12.


    SMB on mac seems to be fine. I tested file transfer speed (not scientifically like you!) a year or so ago and didn't notice any significant performance differences between SMB and AFP. Am i missing something or does this issue with SMB only affect older versions of OSX?

  • I am using SMB and NOT AFP on my network at home - basically Mac's & RPi OMV server.

    Any Raspberry Pi is such a bad joke to be used as NAS since way too slow. These things have only Fast Ethernet and are bottlenecked by their single USB2 connection. It's useless to make any performance tests with this stuff since... too slow.


    I really don't know why people don't click on links provided ;)


    If you take the hour to read through my link above and follow the links there you get what's missing. Apple always used an own SMB client implementation (based on the BSD SMB client library) and switched from Samba for SMB server tasks to their smbx implementation almost 5 years ago.


    When OS X 10.8 was released they finalized their work on SMB as a real replacement for AFP (and declared AFP deprecated to us developers at the same time back then). Issues adressed were encoding quirks (some really fancy stuff nobody notices) and metadata representation. Starting with OS X 10.8 it was the first time possible to transfer all Mac specific stuff between two Macs using SMB and not AFP any more ('Mac specific stuff' means representation of Finder metadata, resource forks and encoding specialities). Back then this only worked when both client and server were using OS X 10.8 or above.


    At the same time Apple defined some proprietary SMB extensions (the AAPL stuff) that are necessary to improve handling of many small files (directory enumeration and stuff like that). While you won't see great differences if you're only pushing large files around (with Raspberries you never see anything relevant anyway since still way too slow) handling of small files or directory structures containing loads of files greatly improves once the SMB server in question correctly implements the AAPL extensions.


    For Samba we need Samba 4.6 or above and these settings (check bottom lines for the necessary stacking of Samba modules): https://bugs.freenas.org/issues/5904#note-19


    In other words: We can benefit from this with maybe OMV 5 released in a few years since Debian's 'stable' policy prevents us from using recent software versions :) Until then we simply use Netatalk and are happy :)


    BTW: Funnily Windows (Server) will always be worst choice as SMB server for macOS clients since I doubt Microsoft will ever add Apple's AAPL extensions to their SMB server. And currently it's really absurd when you compare an expensive Windows server with shitty settings accessed by macOS clients compared to a fine-tuned Samba 4.6 setup running on laughable hardware (click 'Reveal hidden contents' here)

  • We can benefit from this with maybe OMV 5 released in a few years since Debian's 'stable' policy prevents us from using recent software versions

    If they move 4.6.5 from Debian 10 Buster to Stretch-Backports (when it is created), OMV 4.x could potentially use it.

    omv 5.6.2 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6
    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!

  • It's me again.
    I played with a 2.5" 5TB HDD which was extracted from the Seagate Backup-plus box because it is not compatible with Linux UAS driver.
    Seagate Baraccuda 5TB HDD is around $200 while the Backup Plus is only $140. So I could save $60 easily. ;)
    Yes, the Backup Plus box has the same Baraccuda 5TB HDD.


    Anyway, I found a small sata-usb adapter board which has JMS578 chip on ebay. It really worked well with the UAS driver in XU4 for a few days.
    I could upload and download over 3TB files without single bit error with stable 100MB/s speed over Samba.
    Last night, I just wanted to clean the disk with a format option in the OMV "file systems" menu.
    It started to wipe and format. But several seconds later, there was a popup of "communication failure".
    I connected to SSH and "dmesg" showed tons of "Ring expansion failed" like followings.

    It seems to be related to the UAS things. So I disabled it and I could successfully format the disk. I can access the Samba again. :)
    The actual read/write speed over Samba has no big difference even I turn the UAS driver off. It is still over 100MB/sec.
    But I just turned the UAS on again for better feeling. It still works stably.


    I just want to share what I met last night and how I could overcome the nightmare.
    Thread based OMV disk formatting routine seems to send a tons of sequential UAS commands and the bad UAS or USB driver in XU4 kernel might make the disk be crazy.
    If anybody knows a real root cause of the "Ring expansion failure" problem, please let me know.

  • If anybody knows a real root cause of the "Ring expansion failure" problem, please let me know.

    I still think it's related to https://github.com/hardkernel/…3a#commitcomment-21996557


    But Hardkernel folks (as well as their community) choose to pray 'UAS is evil' instead of investigating whether the suggested patch fixes the issue. And I'll never again mess with their kernel (eg. patching this at Armbian) since it's a vendor kernel and they're responsible for it.


    In a few weeks first ROCK64 will be shipped. Cheaper, same NAS performance, no UAS problems. Maybe Hardkernel then wakes up or at least starts to investigate the issue instead of providing silly 'UAS disabled' success stories.

  • Might be beneficial to add it as it a patch to the build images?

    Please see at the bottom of https://github.com/armbian/bui…868f4d72ee863146fe9781778


    While I'm still waiting for feedback from users of these broken Seagate enclosures ( eg. @nasnas ) I thought it's worth to add this (it's now part of Armbian's XU4 kernel and will therefore spread into all XU4 OMV installations when updates are installed within the next weeks/months).


    Unfortunately Hardkernel guys behave absolutely irresponsible ignoring this issue since months (and also NOT reporting other UAS/USB findings upstream so it can be fixed for every Linux user out there) and at the same time they still run the unbelievable stupid 'UAS is evil' campaign in their forum (while most users still only suffer from hardware problems due to Cloudshell 1 and host powered disk enclosures prone to under-voltage under load and the Cloudshell 2 gimmick as every other USB3 peripheral suffering from cable/contact crappiness)

  • Thank you for the new kernel package. I've successfully updated the kernel. Kernel version has been changed to 4.9.37 from 4.9.33.
    My CloudShell2(JMS561) has no issue with the new kernel as well as the previous kernel while running "Create File System" (my previous report).


    But "Create File System" crashes another XU4 that works with the JMS578 + 5TB HDD within a few seconds.
    With newer kernel, there was no "Ring expansion failed" but the SSH has no response at all. The blue LED turned off and rebooted in 1~2 minutes automatically.


    I will stop digging the uas things and disable it until my rock64 arrives in few weeks. I'm very curious how the rock64 can manage the various uas chipset issues.
    But I don't know why I've been so interested in the uas things since my HDD Samba performance is not so influenced by the uas feature. :)

  • Please see at the bottom of https://github.com/armbian/bui…868f4d72ee863146fe9781778
    While I'm still waiting for feedback from users of these broken Seagate enclosures ( eg. @nasnas ) I thought it's worth to add this (it's now part of Armbian's XU4 kernel and will therefore spread into all XU4 OMV installations when updates are installed within the next weeks/months).


    Unfortunately Hardkernel guys behave absolutely irresponsible ignoring this issue since months (and also NOT reporting other UAS/USB findings upstream so it can be fixed for every Linux user out there) and at the same time they still run the unbelievable stupid 'UAS is evil' campaign in their forum (while most users still only suffer from hardware problems due to Cloudshell 1 and host powered disk enclosures prone to under-voltage under load and the Cloudshell 2 gimmick as every other USB3 peripheral suffering from cable/contact crappiness)

    Nevermind, it doesn't help. I rebooted yet again and it's still doing it after fresh boot.

  • With newer kernel, there was no "Ring expansion failed" but the SSH has no response at all. The blue LED turned off and rebooted in 1~2 minutes automatically.

    And this should be related to another USB quirk in kernel? Clearly not, right?


    Nevermind, it doesn't help. I rebooted yet again and it's still doing it after fresh boot.

    The above patch was meant to be tested against Seagate enclosures (ASM1153 with 'branded' firmware). Unfortunately zero feedback here.

  • And this should be related to another USB quirk in kernel? Clearly not, right?

    The above patch was meant to be tested against Seagate enclosures (ASM1153 with 'branded' firmware). Unfortunately zero feedback here.

    I have no idea indeed. I used a JMS578 bridge and a 5TB Seagate 2.5inch HDD as I described in previous post.
    I didn't add any USB quirk option in the kernel parameter since many people mentioned the JMS578 is very compatible with Linux.


    By the way, I could reproduce the issue with "mkfs.ext4 -b 4096 -m 0 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sda1" command on Armbian too.
    If I removed " -E lazy_itable_init=0,lazy_journal_init=0", the format process completed without any error.
    The command seems to be identical to the OMV "Create File System" function.


    Did you have any problem while you use "Create File System" menu with your Rock64 + ASM1153 + Hitachi HDD ?

  • I didn't add any USB quirk option in the kernel parameter since many people mentioned the JMS578 is very compatible with Linux.

    Hmm... I'm not that convinced since JMS567 needs some quirks and JMS578 seems to be more or less the same just with TRIM support. I've no JMS578 currently around to test with (only one USB2 NAS Expansion board for Orange Pis). It will take a few weeks until I can look into since I get the ROCK64 SATA cable as sample (EMS shipping) and ordered some JMS578 thingies on Aliexpress just recently.


    The quirks that get applied to a device identifying itself as JMS567 might be needed with JMS561/562/578 too (JMS561 is the JMS567 variant + SATA port multiplier and crappy RAID used in Cloudshell 2).


    So it might be worth a try to test out usb-storage.quirks=0x152d:0x0578:f (see description of quirks, multiple quirks can be added and even multiple devices are supported, see example there at the bottom)


    Since yesterday my Espressobin arrived I will test with ROCK64 only sporadically the next weeks. Also waiting for some more fixes over there where currently community OS images for ROCK64 are generated from scratch: https://jenkins.ayufan.eu/job/linux-build-rock-64/ (glad to see that this isn't an Armbian privilege any more and others also start to realize that 'building automatically from scratch' is the only option to avoid mistakes and ensure best performance)

Participate now!

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