New approach for Raspberry Pi OMV images

    Zitat von dogg!~

    How will the rpi specific kernel updates get handled from here on out? do they come straight through apt or do they roll in automatically like what happens at first boot?

    They come through apt just like what happened at first boot ;)


    Seriously: We use the repos from archive.raspberrypi.org for kernel + 'firmware' so once they release a new stable kernel as .deb package you're just one 'apt update' away. In case they mark their kernel updates a security update then unattended-upgrades package should install it automagically but of course it then needs a reboot for the new kernel to be active.


    BTW: Thank you for the tip and cheers! :)

    Great news. The constant under-voltage sh*t show those Raspberries are plagued with got somewhat addressed by RPi folks: With latest kernel and 'firmware' under-voltage occurences will be directly logged to syslog/dmesg:


    Code
    Mar 26 20:57:50 rbpi2 kernel: Under-voltage detected! (0x00050005)
Mar 26 20:58:25 rbpi2 kernel: Voltage normalised (0x00000000)

    Little update on lousy RPi 3 B+ (the 'great' Gigabit Ethernet capable new incarnaton).


    It should be obvious in the meantime that RPi folks simply did not test anything at all prior to replacing the old LAN9514 with LAN7515 on their new board. Those LAN* chips are a combination of internal USB hub and an USB Ethernet chip (on the LAN7515 it's even two cascaded USB hubs -- so if you manage to attach an USB disk to the wrong two ports it's even more bottlenecked than before).


    https://www.raspberrypi.org/fo…208512&start=100#p1297910


    Just read through the whole thread to get an idea of what's going on. Manufacturer not giving a sh*t about networking at all in the beginning. Then surprised that they have an EEE issue, then surprised that performance sucks, then surprised that other USB2 attached Gigabit Ethernet solutions do not suck that much. And in the meantime constantly blaming others and censoring their forum ensuring their users remaining clueless.


    What a mess... :(

    • Offizieller Beitrag
    Zitat von dogg!~

    I just need to buy the Rock64 and be done with this mess.

    Yes :)

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    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!

    you guys think 1g of memory is sufficient for running OMV on the Rock64 or should I upgrade? what plugins would require more RAM? I'm assuming that the ARM processor will still be more of a bottleneck for plugins like Plex than RAM. Don't want to spend more than I need to but if it will make a difference I'll buy up. Thoughts?

    • Offizieller Beitrag
    Zitat von dogg!~

    you guys think 1g of memory is sufficient for running OMV on the Rock64 or should I upgrade? what plugins would require more RAM? I'm assuming that the ARM processor will still be more of a bottleneck for plugins like Plex than RAM. Don't want to spend more than I need to but if it will make a difference I'll buy up. Thoughts?

    Are you really debating spending an $10? :) If plex isn't transcoding (pretty sure it doesn't on arm cpus), then the rock64's cpu is not a bottleneck. Plenty of plugins would be happy with more ram but it really depends on how many plugins you install and how you use it. I'm sure 1GB is fine for simple tasks but I personally would get at least 2GB.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    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!

    Zitat von dogg!~

    you guys think 1g of memory is sufficient for running OMV on the Rock64 or should I upgrade? what plugins would require more RAM? I'm assuming that the ARM processor will still be more of a bottleneck for plugins like Plex than RAM. Don't want to spend more than I need to but if it will make a difference I'll buy up. Thoughts?

    Dont get a ROCK64 for running as a NAS. USB3.0 support is terrible. I bought a ROCK64 for this purpose but the harddrive isnt recognized on boot, only on USB2.0 and/or powering on and off the harddrive on the USB3.0 port.


    Official support is terrible, they blame it on a "HDD vendor issue that not implemented UAS correctly". It works without issues on an Odroid-XU4. Community support is insufficient. There isnt an official linux image for the ROCK64 from Pine.


    I found multiple people having USB3.0 issues as well... Dont expect it to work unless you get perhaps their USB3.0 SATA connector.


    https://forum.pine64.org/showthread.php?tid=5875
    https://github.com/ayufan-rock64/linux-build/issues/140


    I would definately go for an Odroid-XU4 IMO. At a friends place I have OMV XU4 NAS running with 3+ months uptime now without any problems. Their HC-2 looks pretty nice if you want to run a NAS:


    Transcoding in Plex seems to work on the XU4 as well for some content...

    • Offizieller Beitrag
    Zitat von k8Ga

    Official support is terrible, they blame it on a "HDD vendor issue that not implemented UAS correctly".

    What makes you think they are wrong? They don't write the usb device drivers. Maybe the image/kernel you were using didn't have the right module or version compiled?


    I know a few people who have these boards and they are quite good with ayufan's image.


    Zitat von k8Ga

    I would definately go for an Odroid-XU4 IMO. At a friends place I have OMV XU4 NAS running with 3+ months uptime now without any problems. Their HC-2 looks pretty nice if you want to run a NAS:

    The xu4 is a good board but uses quite a bit more energy than the rock64. The HC-1/2 are pretty much the same board as the xu4 - they use the same OMV/armbian image.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    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!

    Zitat von k8Ga

    Dont get a ROCK64 for running as a NAS. USB3.0 support is terrible.

    Nope! Please stop giving such bad advise.


    There were some XHCI/USB3 issues last year but AFAIK they're all resolved. I didn't look through your whole thread on pine64 forum and the github issue since it's copy&paste from here to there (which is an insane waste of developer's time!) but if you have random issues with 2 different USB3 disk enclosures I would check/clean the SuperSpeed contacts in Rock64's USB3 receptacle as first measure (I know, very unpopular recommendation since people love to blame software even if it's just a simple hardware issue like underpowering or USB3-A crappiness -- this connector is IMO broken by design).


    BTW: you find some anecdotical stuff around ASM1153 (that's maybe the device you're using -- unfortunately ASMedia has a somewhat stupid USB product ID naming scheme) and USB3-A receptacle crappiness here: Building OMV automatically for a bunch of different ARM dev boards (look also through the pages prior and after that)


    And your try to UAS blacklist your enclosure does not work unless you also run update-initramfs. But it's not an UAS issue you're running into.


    TL;DR: Get a Rock64 with sufficient amount of memory. Don't forget to order the PSU and also their SATA cable (worth the 10 bucks!).


    The ODROID boards really do waste a lot more energy for nothing (talking about the 'NAS use case'). But they're fine too (and HC1/HC2 avoid the common USB3 receptacle problems by integrating the USB-to-SATA bridge on the PCB).


    And wrt software support: The Exynos 5244 used on those ODROIDs is pretty old and that's why overall software support is a bit more mature compared to RK3328 (Rock64). That's the whole secret behind 'good software support': running on old hardware (The RPi SoC appeared on SBC in 2011, Exynos 5244 in 2014, RK3328 in 2017). The relationship between old hardware and mature software support should be obvious...

    Zitat von k8Ga

    USB3.0 support is terrible

    USB3 'problems' are often hardware related at least when the USB3-A receptacle has to be used. The contacts for the Hi-Speed data lines (people call 'USB 2.0') are huge and it's almost impossible to get contact problems.


    While the contacts for the SuperSpeed data lines (designed for a link rate of 5 Gbps!) are

    • laughable tiny,
    • require the user to push the cable with full force into the receptacle to get any contact area at all and
    • are located at the outer position so slightly bending the cable will easily result in contact issues



    So if you run into strange 'USB3 problems' and have to use this crappy connector always check for contact issues first and be aware that you might have to improvise and fixate the USB3 cable to prevent connection errors (once USB-C will be widely adopted we'll see a huge drop in 'USB3 problems' since then this USB3-A crappiness can be avoided)


    See also: https://forum.armbian.com/topi…ab=comments#comment-35333

    Ehm, my post is deleted. There was a duplicate, but now everything is gone...


    EDIT:



    What makes you think they are wrong? They don't write the usb device drivers. Maybe the image/kernel you were using didn't have the right module or version compiled?
    I know a few people who have these boards and they are quite good with ayufan's image.


    With official support I mean proper linux images provided by the hardware vendor taking into account all the specific hardware peculiarities. I cannot see why Pine would not release an official linux image for there hardware like most hardware vendors do too.


    Community support, by Ayufan, is great. But IMO is not for substitute for the responsibility of hardware vendors providing proper linux images, tweaks. Including as a bare minumum mainline support, which is the case now I think for the SOC.



    There were some XHCI/USB3 issues last year but AFAIK they're all resolved.


    Other people also have the same problem:
    https://github.com/ayufan-rock…40#issuecomment-375164120
    https://github.com/ayufan-rock64/linux-build/issues/123
    https://forum.pine64.org/showt…d=5875&pid=36617#pid36617



    but if you have random issues with 2 different USB3 disk enclosures I would check/clean the SuperSpeed contacts in Rock64's USB3 receptacle as first measure (I know, very unpopular recommendation since people love to blame software even if it's just a simple hardware issue like underpowering or USB3-A crappiness -- this connector is IMO broken by design).
    BTW: you find some anecdotical stuff around ASM1153 (that's maybe the device you're using -- unfortunately ASMedia has a somewhat stupid USB product ID naming scheme) and USB3-A receptacle crappiness here: Building OMV automatically for a bunch of different ARM dev boards (look also through the pages prior and after that)


    All I can say I have tried with 2 different harddrives and they both dont work on the ROCK64, they both do work on the XU4 and they both work after powering on and off the harddrives a few times. So IMO there it isnt a:
    - power issue (external powered)
    - connector issue (powering on and off doesnt affect the connector)
    - "HDD vendor issue that not implemented UAS correctly" which cannot be fixed, with XU4 no problems



    BTW: you find some anecdotical stuff around ASM1153 (that's maybe the device you're using -- unfortunately ASMedia has a somewhat stupid USB product ID naming scheme) and USB3-A receptacle crappiness here: Building OMV automatically for a bunch of different ARM dev boards (look also through the pages prior and after that)
    And your try to UAS blacklist your enclosure does not work unless you also run update-initramfs. But it's not an UAS issue you're running into.

    I look into this a bit more. Thanks.



    And wrt software support: The Exynos 5244 used on those ODROIDs is pretty old and that's why overall software support is a bit more mature compared to RK3328 (Rock64). That's the whole secret behind 'good software support': running on old hardware (The RPi SoC appeared on SBC in 2011, Exynos 5244 in 2014, RK3328 in 2017). The relationship between old hardware and mature software support should be obvious...



    Totally agree. But I expected at least some sort of support from Pine64 getting the SBC to play nice. Their product is almost useless for me now, and they dont seem to care. I cannot see why they dont release an offical linux image, as if they dont want to put in the effort and take responsibility.



    I didnt want to open a topic here, issues not related to OMV. My goal was to run OMV. These are the errors Im getting (in a sequence powering off and on the harddrives a few times), then it works.

    Zitat von k8Ga

    So IMO there it isnt a:
    - power issue (external powered)
    - connector issue (powering on and off doesnt affect the connector)
    - "HDD vendor issue that not implemented UAS correctly" which cannot be fixed, with XU4 no problems

    'IMO'? Seriously? You do not follow a simple advice to look at the potential problematic USB3-A connector since you prefer to rely on your own 'opinion'?


    Well, it's time to not only stop supporting the lousy RPi but SBC in general. Way too frustrating since users all the time blame software for simple hardware issues.


    BTW: ayufan left almost all the USB stuff on Rock64 for me last year. If you would've visited the links I provided you would know that we were directly in touch with Rockchip engineers who even used protocol analyzers to fix the known issues. And you would also know in which problems I and other users ran. Yours is not amongst this. End of 'discussion' (you did not create a 'topic' but this was just some Rock64 badmouthing)

    Zitat von tkaiser

    Well, it's time to not only stop supporting the lousy RPi but SBC in general. Way too frustrating since users all the time blame software for simple hardware issues.


    I started using OMV recently on a RPi 3B+. For my case, it works well and I like it. Wireless NAS (!!!), rarely used by two users, and absolutely nothing about speed. 15MB/s transfer speed over WiFi is more than three times of that what needs most speed in my use case (MiniDLNA for some tv shows). I could replace that very well with a simple "apt install samba minidlna" and a small config file for each of the two, but I like how i can configure the shares and the DLNA server in the clicky clicky WebGUI. A welcome alternation to all my other more used servers/services which I have to maintain on the command line. A simple short THANKS for your work!


    I can understand your desire to drop RPi support. The Raspberry Pis draw a lot of attention and pull a lot of n00Bs into the business. Most n00Bs stay with the RPi, the freaks and more interested go with other platforms. If the other platforms would do more marketing, they would pull in also more people of the kind, that attach a rocked down 15-20 year old 100MBit cable (the blue Netgear cable, we all have at least one of them somewhere) and complain about speed. But I like the Pis because of the price point and the availability. I'm especially interested in the ROCK64 (and also looking at the Asus tinker board probably just for some marketing reasons), but it's double the price in europe, or you need to order it from china and wait weeks for it. I can get a new Pi in 15 minutes from home.


    To cut the long story short now: How is your actual view about the Pi things? Do you think you gonna support it in the future, or would you better drop the "apt install samba minidlna" line on a fresh raspbian lite in my case?

    Hello,
    I have a quiestion.
    when i run the raspimon command i recieve an warning and also the /var/log/raspihealth.log file is empty
    Why i recive that warning?

    Zitat von sergiu46
    Code
    /usr/sbin/raspimon: line 23: printf: warning: 10000000000000000000: Numerical result out of range

    So for whatever reasons the RPi Trading guys changed the output of the vcgencmd get_throttled command with latest ThreadX update rendering output parsing meaningless. Well done, these guys are really great hiding the crappiness of their platform.


    Ah, found it: the change is by intention and implemented in their latest firmware update from 21 Sep: https://github.com/raspberrypi…33f70659eafdcefa3b68cd7ae


    I don't know how to fix this since as usual everything relevant for the RPi is not documented appropriately by the manufacturer and the change happened in their closed source primary OS (ThreadX, also known as 'firmware').

    One of the RPi Trading guys answered and explains the additional bits: https://github.com/raspberrypi…ae#commitcomment-31620514


    So the new behavior is documented at least there. To fix things occurrences of printf "%019d" should be replaced with printf "%021d" in both /usr/sbin/raspimon and /etc/init.d/armhwinfo is existing (this is for /var/log/raspihealth.log).


    With this fix applied at least on RPi 3 B+ the output can then be decoded like this:

    Code
    111100000000000001010
||||             ||||_ under-voltage
||||             |||_ currently throttled
||||             ||_ arm frequency capped
||||             |_ soft temperature reached
||||_ under-voltage has occurred since last reboot
|||_ throttling has occurred since last reboot
||_ arm frequency capped has occurred since last reboot
|_ soft temperature reached since last reboot

    I don't plan on 'fixing' this since obviously almost nobody is using this functionality anyway and I've no idea whether the new/enhanced output is only generated on the RPi 3 B+ where this 'soft temperature' stuff has been invented or on the other/older RPi as well.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden