Omv 4 broken odroid xu4 ?

  • At odroids forum they say that Omv4 is broken for odroid xu4 is it right? "I've run Omv4 some time and have not had any significant problems: /?


    (odroid forum) : "The kernel is broken on Armbian (on XU4), it had a bunch of stack traces on boot up causing a long (88 seconds +) pause that breaks the mounts. OMV images run on top of Armbian. I'm not sure whose fault it is, just that it's broken and you should use something that works for now. " ?

  • What is this post about?


    OMV4 for ODROID XU4/HC1/HC2 has been downloaded over a thousand times. It has been tested as every new release of course. Reports that it is broken here in the forum where such reports belong to: ZERO


    What are you talking about (especially if you do not reference 'someone on the internet claiming random something' with a link)?

  • It's not a campaign Thomas, if you read my last post you will have the information you need to diagnose what I'm seeing.


    If I didn't like Open Media Vault I wouldn't use it, but I do like it. So exactly what is this campaign you speak of?


    I changed my posts to say it's broken for me since Justin tested and it's not broken for him. I also said to use something else that works for now. Not forever.


    I also gave a link where OMV works on DietPi. I have nothing against OMV.


    Whereas you indeed campaign against vendor forums.

    • Offizieller Beitrag

    I changed my posts to say it's broken for me since Justin tested and it's not broken for him. I also said to use something else that works for now. Not forever.


    I also gave a link where OMV works on DietPi. I have nothing against OMV.

    I have been using OMV on the XU4 (and plenty of other odroid boards) before it was released and never had a problem. A problem with the cloudshell is a different issue but it is NOT an OMV issue. Maybe a package or something is not installed but that does not mean there is something wrong with OMV since the cloudshell has nothing to do with OMV. I admit that I don't test most of the time with cloudshell but it should be a simple problem to fix.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

  • When I say it's Armbian do you know what is going to happen?


    Thomas is going to say OMV isn't Armbian, install pure Armbian then I won't have this issue. He has already said this once to me.


    So it's a runaround. If you choose to run Armbian as the OS I don't see how this isn't OMV. It has to be one or the other?


    I wish you would offer OMV without Armbian, I understand that Armbian is great on some if not most devices. On the (XU4) CloudShell 2 which is just a fancy USB to SATA adapter.


    I'm not playing a blame game, it simply does not work in the configuration I'm running. We can leave it at that.


    I won't say anything negative about OMV, I'm no longer using it with Armbian on this device.


    I appreciated your response here and on Hardkernels forum @ryecoaaron and think you do great work.

    2 Mal editiert, zuletzt von rooted () aus folgendem Grund: Adding a bit of praise.

    • Offizieller Beitrag

    However anyone wants to look at it, it is not an omv issue. omv is just a package (it is just writing fstab entries) and the omv arm images aren’t official. Volker did give me sourceforge access to upload them but the aren’t official. That said, tkaiser and myself have put a ton of work into these images (more him than me recently because he builds them correctly).


    I fail to see how the issue would affect an omv
    image and not an armbian image since they use the same kernel.


    I built the omv arm images by hand for years with a stock debian image from various sources. When tkaiser offered armbian images and we worked on them, i thought they were very good and better than mine.


    I thought i was testing the cloudshell properly but i really didnt use most of the features.


    i’m rambling and need to get back to my vacation. I will some testing when i get back.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

    Einmal editiert, zuletzt von ryecoaaron ()

  • Thomas is going to say OMV isn't Armbian, install pure Armbian then I won't have this issue. He has already said this once to me

    Blablabla. Stop talking BS.


    You are the one telling people who suffer from common Cloudshell 2 problems (disks get unmounted due to USB3-A shittyness -- the usual cable/contact problems these things are known for) 'OMV 4 is broken on the XU4' which is obviously not true since otherwise this forum would be full of complaints: https://forum.odroid.com/viewtopic.php?f=97&t=31486


    Been caught lying later you add "(FOR ME)" and try to explain that not 'OMV 4 is broken on the XU4' but it's something with your special Cloudshell 2 thingy to which you flashed a special (AKA broken?) firmware in a combination with NFS obviously no one else around is using (since otherwise someone would have reported it here already and we would've looked into it).


    How many times did you try to reproduce this? If not more than once I assume that's it's some random problem not worth a look. 'UAS stack traces' are often the simple result of underlying connection problems. That's why dealing with the ODROID-XU4 is such a sh*t show (and why HC1 and HC2 have been designed in the first place). The USB3-A receptacles are crap and prone to contact issues. People fiddle around with their board (exchanging SD card), bend the USB cable slightly, then run into strange 'UAS issues' (that are USB connection issues in reality), revert to their previous configuration again fiddling physically around with the board and touching board and cables and then everything works again. Users think they dealt with software but in reality they dealt with cable/contact problems.


    The XU4 with USB3 attached storage is a support nightmare especially in combination with these Cloudshell thingies. It's documented in detail: https://forum.armbian.com/topi…findComment&comment=32340


    I wasted already way too much time on supporting this Cloudshell gimmicks (software support and workarounds to get them working flawlessly and documenting the various problems) but your behaviour now will at least stop me from supporting anything XU4 and especially Cloudshell related.


    Asides from that it still would be great when you run into something you consider a bug that you try to create a bug report worth the name. First step is to provide logs (you never did that to my knowledge or maybe only over there in your fanclub area called Hardkernel forum), next step is to reproduce it yourself multiple times ruling out all other potential problems (which is hard with XU4 due to... USB3-A receptacle crappiness).


    But please don't expect that any developer on this earth buys this Cloudshell 2 thing, flashes an early firmware (why on earth?!) and uses NFS to be able to reproduce something that's most probably not even reproducable since the combination of XU4 and CS2 is prone to connection issues and those 'UAS errors' are most of the times something that happens at the physical layer below.


    The best way to deal with USB3 storage is to avoid if possible. The next best way is to avoid at least the cable/contact issues, the underpowering issues (hello Cloudshell 1!) and issues with crappy USB-to-SATA bridges (often related to their firmware). That's what ODROID HC1 and HC2 and Cloudmedia Transformer try to do.


    Dealing with those other combinations is a waste of time and I will stop this now. No more XU4 and especially Cloudshell support. Life's too short to deal with users having bought unreliable stuff...

  • A problem with the cloudshell is a different issue but it is NOT an OMV issue

    More importantly: Most of the time it's not a software issue AT ALL. At least not one at the host side.


    This Cloudshell 2 gimmick has been shipped in broken state last year breaking (not only) OMV and needs a firmware update (and even that can't fix all the various issues with JMS561). See N° 11 here: forum.armbian.com/topic/3953-p…findComment&comment=32340


    Now someone tells he flashed 'original firmware' to this thing running into troubles with our OMV4 image while having no troubles with our OMV3 image. Both images use exactly the same kernel so it's very unlikely that anything relevant changed on the XU4. So I would assume we're just talking one more time about unreliable hardware if @rooted has not tried to reproduce the problem at least 3 times with 3 different cables between XU4 and the Cloudshell gimmick, see https://forum.armbian.com/topi…findComment&comment=32374


    This is something you should keep in mind when trying to help unfortunate XU4/CS2 users in the future. At least I won't look into any of these issues any more from now since why dealing with horribly unreliable storage combinations? USB3 is best described as 'cheap consumer crap' and the way these Cloudshell thingies are designed as 'unreliable by design' given the USB3-A receptacle problems.


    Thomas is going to say OMV isn't Armbian, install pure Armbian then I won't have this issue. He has already said this once to me.

    Now I got it. You think 'Thomas' and 'Igor' is the same. Impressive way of thinking...

  • That about HC1/HC2 users further support?

    From a software point of view XU4, HC1 and HC2 are identical so no worries.


    The problem is that 'USB attached storage with SuperSpeed -- 5 Gbps -- using those crappy USB3-A receptacles' is the most shitty storage connection method at least I know. It's unreliable as hell especially when USB3-A receptacles are slightly too large as it's the case on my XU4 (and many others, see the links here).


    The possibility to combine somewhat problematic USB3 host implementations (unfortunately true with every ARM SoC today) with crappy USB-to-SATA bridges in disk enclosures or those Cloudshell gimmicks makes things even worse.


    Logical consequence: If USB3 is the only way to attach fast storage then do it like HC1 and HC2 do (or Cloudmedia Transformer or Swiftboard) to eliminate this sh*t show as suggested one year ago.


    I'm just tired of dealing with support issues caused by USB3 connection problems users interpret as 'software/kernel/UAS issues' and I really don't like these Cloudshell gimmicks causing so much troubles. HC1 and HC2 are way better than XU4 combined with one of those things.

  • tkaiser
    It looks some misunderstanding happen.
    I have read about the USB-to-SATA issues. (I was thinking to buy XU4, but changed my mind)
    Of course I know that XU4, HC1 and HC2 are identical and that is why I started to worry, after your decision to quit XU4 support.
    And yes, I'm using HC1 with OMV installed and I'm afraid to lose your support in close future.

  • @tkaiser


    I apologise, it was not you who told me Armbian isn't OMV, I made a mistake there and own up.


    I didn't lie by saying "FOR ME", after reading Justin's post saying it worked for him I edited my post to say it's broken "FOR ME" to change it since it isn't broken in general like I originally thought. Don't call me a liar Thomas. I'm a hard-working father, husband and honest man.


    So because I'm running the firmware the Cloudshell 2 ships with it's somehow a problem? I didn't know the firmware was "broken". I didn't say I flashed the original firmware, I said you would need to flash the original firmware simply because you may not be running it.


    How I reproduced the problem, I flashed OMV/Armbian to the eMMC three times and three times the same thing happened. I flashed Debian Jessie and it's been working for two or three days without issue.


    It is not a cable.


    I don't see how the CloudShell 2 is a gimmick, it's just a USB to SATA adapter. Nothing gimmicky about that.


    You saying you won't support the device any longer because of one person's issue is immature.


    You have a wealth of knowledge Thomas and it's useful, but if you want to take your toys and go home that's up to you. I won't try to stop you.


    The simple answer would have been "you need to upgrade your firmware", but whatever.


    -Tim

  • And yes, I'm using HC1 with OMV installed and I'm afraid to lose your support in close future


    You won't loose support for HC1. It's only about XU4 and these Cloudshell toys. Anyone coming up with a problem with these things and especially the combination doesn't get an answer in the future from me. For the simple reason that supporting this hardware totally sucks. Software-wise it will be supported since HC1 and HC2 are great NAS thingies and providing optimized software for them means supporting the XU4 as well.


    The XU4 problems summarized (once again!):

    • Prone to underpower connected disks especially in combination with Cloudshell 1
    • USB3-A receptacles are crap in general (those laughable tiny SuperSpeed contacts are a joke) and a significant amount of XU4 has been shipped with USB3-A receptacles where average cables fit only loose. I don't know if this has ever been fixed so that cables fit more tightly
    • The 2 USB3 receptacles are behind an internal hub. You really don't want an USB hub between host and disk
    • Hardkernel sold eMMC modules up until last autumn with a castrated bootloader (only capable of Windows filesystems) that caused troubles transferring OMV to eMMC

    The Cloudshell problems summarized (once again!):

    • Cloudshell 1 uses an old and not UAS capable USB-to-SATA bridge responsible for USB resets with modern kernels
    • Cloudshell 1 prone to undervolting connected disks leading again to USB resets (according to Hardkernel only with modern kernels -- I don't buy this)
    • Cloudshell 2 shipped with an inappropriate cable leading to all sorts of connection issues
    • Cloudshell 2 shipped with broken firmware that needed various fixes to behave somewhat properly

    All those problems regularly get denied by the Hardkernel fan club over at ODROID forum but have been documented a long time ago (both a stupid/boring and rather time consuming process). Once again: https://forum.armbian.com/topi…findComment&comment=32340


    Since TL;DR here again the links from the above link where Hardkernel's Justin himself explains the various issues: Cloudshell 1 and both Cloudshells.


    So the hardware is the exact opposite of what you would call a 'reliable NAS' and at least my very own problem is that I hate wasting my time on 'software issues' that aren't software but simple hardware issues. But since the XU4+CS combinations are that unreliable at least novice users can't tell apart real software issues from USB3 connection hassles or undervoltage happening at the physical layer when they're confrontated with connection issues that manifest themselves in the log with messages like 'uas abort handler' (then they google and get told they run in UAS problems or other BS spread in vendor forum)


    This wouldn't be a problem if we could spread the word that these hardware combinations are unreliable and need special caution (or should be avoided in the first place since why would you want a 'NAS' where even minor vibrations can lead to connection issues?!). But we can't due to fan club behaviour happening in the vendor community.


    This thread is the best example for what always happens with those vendor micro communities: A user reports in the vendor forum one of the usual hardware issues with the combination of XU4 and CS2 (connection to disk lost), then a regular and opinion leader there asks whether he uses OpenMediaVault and finally claims OMV would be broken anyway and @'mrperfektone' needs to use anything else (the "(FOR ME)" addition has only been added later when being caught lying).


    This is usual behaviour in those vendor micro communities that always tend to create micro realities. Everything that's new to them is bad (see the insanely stupid 'UAS is evil' campaign running last year in ODROID forum) and they campaign against everything that's not part of their fan club (e.g. Armbian and OMV). This is not specific to this micro community but something that happens in all of them and one of the reasons at least I try to avoid those vendor communities (unfortunately sometimes you must join to get informations or access to forum contents).


    So how does my reality with supporting XU4 and those Cloudshell toys looks like? I wasted huge amounts of time trying to support this hardware (which I would neither buy nor recommend since unreliable) in the best way possible. We added detection of Cloudshell 2 to our OMV installation routine on top of Armbian to install the neccessary support stuff to get display and fan working. I even implemented Cloudshell 1 detection to apply the ugly workaround that makes this thing a bit slower but stable.


    But why on earth should I further waste my time supporting products I can't recommend? Especially when my work gets sabotaged over in the vendor micro community where regulars actively try to mislead affected users not pointing out the various hardware problems but always try to blame everything that's not part of their 'fan club'?


    It's as simple as this: USB3-A connected storage is unrealiable storage unless you take special precautions. HC1 and HC2 have been designed to eliminate the three main problems (connection issues, undervolted disks and crappy USB-to-SATA bridges) since connecting USB3 storage to XU4 is such a sh*t show. That's what people need to learn.


    Final disclaimer: Unfortunately with HC1 you can still run into undervoltage problems users report as 'software issues' and I really hope Hardkernel designs a new HC1 batch that also gets powered by 12V.

  • kaiser
    Everything is clear now.
    Thank's a lot for your irrefragable answer, but it isn't necessary, really.
    I've read topics around XU4 issues before wrote you.
    I wouldn't want to waste your time
    Appreciate your patience and good will.

    You won't loose support for HC1. It's only about XU4 and these Cloudshell toys.

    That's all I wanted to know )


  • Very interesting thread, thanks for the insight.


    I use the XU4 for homeautomatization (ioBroker), pi-hole and the nice plugins of OMV.
    Maybe there are better ways on a plain Linux, but thats the way I know, I tested this in a VM and it works.


    And with the HC1/HC2/XU4-installation, in real life it works like charm.


    Therefore I really appreciate your support, please continue.

Jetzt mitmachen!

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