Odroid XU4 - can't start OpenMediaVault 4

  • Hi. I previously posted at the Odroid forums: https://forum.odroid.com/viewtopic.php?f=96&t=33656
    However, it might be better to ask here as my problem is related to OMV4.


    Today I got my XU4.
    It works perfectly fine with the "ubuntu-18.04.1-4.14-minimal-odroid-xu4-20181203.img.xz" image. I was able to test sama, aes, etc.


    I would like to use this device as a NAS server for external hard drives. I found out that OMV4 might be a perfect solution.


    Unfortunately, I'm unable to fully boot my XU4 using the "OMV_4_Odroid_XU4_HC1_HC2.img.xz" image. I flashed it (multiple times) using balenaEtcher.
    I connected it with HDMI to my TV. I can see the blinking white "_". After 15-20 minutes a message comes:
    "Give root password for maintenance
    (or type Control-D to continue)"


    I managed to connect my keyboard. When I press ctrl+D a new message appears:
    "cannot read /dev/tty1: Operation not permitted"


    After that the "_" blinks for some minutes, until the same "Give root password" message is shown.
    When I type the root password (openmediavault) I can type commands in terminal.
    Opening "htop" takes quite long time. I can't access the openmediavault web page. My router doesn't see Ethernet connection (perhaps due to inactivity).


    What can I do to solve or detect what is the problem?
    Any help would be very appreciated.

  • Thank you for your reply.


    There are no other devices connected to the USB port (except keyboard now).


    I tested the SD card for the "fake capacity" by copying two big video files (14GB each) and then playing them at the different device (with time jumps).
    I already ordered a new San Disk card and should get it next week (cheaper to buy online).


    I have the PSU called "5V/4A XU4/HC1 DC 5.5x2.1". It didn't have power problems when I did load and performance tests on Ubuntu18.04.


    One thing I noticed - when I open the "OMV_4_Odroid_XU4_HC1_HC2.img" with 7zip, there are two .img files inside (0.img and 1.img). Images for Ubuntu18.04 have "0.fat". Could it be the problem? If so, is there any possibility to change it?


    By the way, my XU4 is: REV 0.1 20180912.
    I can see on Odroid wiki page: https://wiki.odroid.com/odroid-xu4/os_images/linux/start
    "We don't support Kernel 4.9 any more. Please use the latest 4.14 "


    Has "OMV_4_Odroid_XU4_HC1_HC2.img.xz" got the 4.9 kernel? Is it possible that they changed something in hardware to make it even more incompatible?

  • when I open the "OMV_4_Odroid_XU4_HC1_HC2.img" with 7zip

    Well, instructions at the download location recommend to burn the image without decompressing first for a reason. There are two partitions contained and none of them is FAT. The image will be installed +1000 times a month and there's no problem (as the readme at the download location tells, Internet access is needed at first boot and then all the packages -- kernel included -- will be upgraded to latest version).


    If there are real problems it's always either SD card hassles or undervoltage (something impossible to explain since novice SBC users always only focus on amperage ratings and forget about Ohm's law and voltage drops as root cause of so many troubles with 5V powered boards).


    Anyway: the XU4 is not a great device as NAS (due to underpowering problems and everything USB here, especially both USB3 ports behind an internal hub and USB3-A receptacles prone to connection issues). I hope you get the problems sorted...


    BTW: the only reliable ODROID for the NAS use case is the HC2 (HC1 as well but there the undervoltage sh*t show is an issue just like with XU4)

  • I understand. I don't have big requirements for the NAS (using it in Local Network only and SMB speeds were almost 1Gb/s).
    It's just confusing that I didn't notice problems on Ubuntu 18.04 if something is faulty. Anyway, will see more next week :)


    Is it possible to download somewhere an older version of OMV for XU4? I somehow would like to focus on this issue on weekend.


    Thanks again for your replies.

  • Thank you.
    Installation using "Armbian Stretch" went without problems.


    For the last 3 days I was using Ubuntu 18.04 and I manually set up shares and stuff. It was pretty painful (especially disk mounting settings for best performance), but at least learnt something new.
    Setting shares up with openmediavault was much faster, so it will definitely stay installed for this device.


    Also, I really like the performance of this device. Writing/Reading to EXT4 disk gives 110MB/s, to NTFS ~80+MB/s. I even used AES encrypted Vera Crypt volume (NTFS) and was getting over 40MB/s (possibly more). So I'm really happy to use it instead of my old "WD My Cloud" device which all the time wakes up.


    By the way, my new SD card didn't arrive yet, so I'll be trying to flash the "OMV_4_Odroid_XU4_HC1_HC2.img.xz" image later this week. I really hope it's not a PSU problem (shouldn't actually be if I could already do so many things on this device?).

  • By the way, my new SD card didn't arrive yet, so I'll be trying to flash the "ubuntu-18.04.1-4.14-minimal-odroid-xu4-20181203.img.xz" image later this week.


    I do not use ubuntu-18.04.1-4.14-minimal-odroid-xu4-20181203
    And probably not too many people here too. OMV images for arm are based on Armbian(debian). So you're experimenting a little bit on your own with ubuntu + omv.

  • Opps, sorry. I meant the "OMV_4_Odroid_XU4_HC1_HC2.img.xz" image (updated in the previous post now) which doesn't boot on my SD Card.

    Rather, you do not hear anyone complaining about not working image from @tkaiser for xu4.


    If you are not able to force this image from sourceforge to work then just use pure armbian (deb) and add omv. You will have exactly the same thing.


    Although a strange situation ...

  • If you are not able to force this image from sourceforge to work then just use pure armbian (deb) and add omv. You will have exactly the same thing.

    Yes, this is what I did and it works perfectly fine.


    I still want to try this "OMV_4_Odroid_XU4_HC1_HC2.img.xz" image when I get the new card. It's because I'm curious what's wrong. When something fails that hard only for me and nobody else, then there might be a hardware issue, so I maybe should refund this device.

  • Yes, this is what I did and it works perfectly fine.
    I still want to try this "OMV_4_Odroid_XU4_HC1_HC2.img.xz" image when I get the new card. It's because I'm curious what's wrong. When something fails that hard only for me and nobody else, then there might be a hardware issue, so I maybe should refund this device.


    It's good that you're trying.
    On the other hand, I do not really know what the hardware problem may be if Armbian (deb) + OMV4 works. Certainly not PSU. SD ... somehow I have doubts in the sense of this thesis in this case.


    1. Human error
    - File incorrectly downloaded.
    - Incorrectly saved to SD.
    - The installation has not been carried out correctly


    2. Something recently went wrong with the image building for xu4 and compatibility has dropped.... :/


    In general, OMV_4_Odroid_XU4_HC1_HC2 is exactly the same as Debian_stretch_next.7z + omv only that given as a ready dish.


    So I do not really know why one thing works and the other does not. And it's definitely not a physical problem with xu4.
    Either you made some mistake or @tkaiser has some small mistake in the image. Unless it's some interesting problem with sd...


    As the "refund" I do not see any grounds for this and the point in it. If Armbian works then xu4 works here, at most there can be a software problem or a human error.

  • Either you made some mistake or @tkaiser has some small mistake in the image


    Voodoo anyone? The XU4 image has been uploaded at 2018-06-03, has been downloaded and installed +1000 times each month since then so what should be wrong with an image that hasn't change for over 7 months and is known to work?


    What is this whole discussion about?


    The process of providing these images hasn't changed for almost 2 years. I create them, compress then, create an MD5 checksum, then @ryecoaaron uploads them to Sourceforge, I wait and then carefully check the MD5 hashes and if they don't match I get on his nerves again since spotting a problem that could result in broken images (happened twice -- IIRC a Banana Pi image got corrupted while uploading and another time filenames for the new FriendlyELEC RK3399 thingies were wrong).


    Almost all images are tested prior to uploading to SF. We made one exception (Tinkerboard) and as soon as one user reported problems we deleted the image on SF immediately (we have no idea whether the image was the problem or something else but since nobody could reliably test it was an easy decision).


    BTW: Using the OMV4 image or an Armbian Stretch variant '+ OMV' is not always the same. The OMV4 image still uses 4.9 kernel that gets updated to 4.14 on first boot while recent Armbian most probably comes with 4.14 as default. Part of kernel version is the so called 'device-tree' stuff which also defines the so called 'DVFS settings' (dynamic voltage frequency scaling) and different settings can result in different consumption behavior which can result in undervoltage occurring if the PSU sucks which can result in the board freezing.


    And if OMV will be installed using the 'official guide' afterwards instead of using armbian-config performance will suck.

  • Hi.
    Today I received a new microSD card (SanDisk Ultra 32GB microSDHC UHS-I A1) and seems like booting from the "OMV_4_Odroid_XU4_HC1_HC2.img.xz" image worked fine.
    My old card is a Chinese "MIXZA TOHAOLL".


    I did some IOPS benchmark using "fio", and results are a bit confusing. Seems like that old card is better at writing. I attached test results if someone is interested:
    ChineseCard_IOResults_2019-02-07-15-13-07.txt
    SanDiskCard_IOResults_2019-02-07-15-33-17.txt


    One thing I'm not sure about is the "/dev/mmcblk1p3" partition:
    Device Boot Start End Sectors Size Id Type


    /dev/mmcblk1p1 8192 139263 131072 64M 83 Linux


    /dev/mmcblk1p2 139264 15500000 15360737 7.3G 83 Linux


    /dev/mmcblk1p3 15500001 61710591 46210591 22G 83 Linux


    I can't see it in Disks -> File Systems. Can it be somehow used, at least for Plex database?

  • One thing I'm not sure about is the "/dev/mmcblk1p3" partition


    Just check the readme.txt at the download location:


    Code
    - The last partition will be automatically resized to the maximum on
      first boot to be used as a data storage partition. But you need to
      manually format it with your filesystem of choice prior to usage 
      (for example 'mkfs.btrfs /dev/mmcblk0p3')
  • Thanks. I thought it was already an accessible filesystem :[


    For now I flashed the .img backup of the Chinese card to the new one, because I already set up everything on it.


    I'm happy it was the SD card issue, I was worried that I'll need to replace PSU. It's still strange, because that card seem to work fine, however I'm not gonna risk using it for anything else than tests.


    Once again thanks for help.

    • Offizieller Beitrag

    For now I flashed the .img backup of the Chinese card to the new one

    If there are corrupted files due to the "Chinese card", they might be also corrupted in the image/backup.


    You can run armbianmonitor -v from CLI to check if files have been changed, which should not have been changed.

Jetzt mitmachen!

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