Random reboots on omv4

    • OMV 4.x
    • Resolved

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Random reboots on omv4

      Hello again everybody, my omv installation is on top of an Orange Pi PC2, omv4 and up to last night it was working with some random slowdowns every few hours maybe 2-5 minutes of massive slowdown then it started to move again, i didnt update the system for about 10 days, last night i updated and now the system works a LOT faster but i get random reboots every few hours (every 2-4 hours mostly), im not very tech savvy, at most an advanced user, so i dont know where to look or what to check to see whats wrong, i did a "/var/log/messages" and i see a lot of

      Source Code

      1. Jan 31 11:17:29 omv kernel: [ 1260.105731] BTRFS warning (device mmcblk0p2): csum failed root 306 ino 4407 off 2137825280 csum 0xdc2523f0 expected csum 0x1b9ce9


      Is it really just a warning or should i be worried about the SD card health?
      This is a the part where i think something happens that start the restart but i see nothing different compared as example with 15 min or half hour before, the network devices messages seem like some docker thing happening in the background but also, repeating so i guess not critical, and the btrfs warning seem also non critical since it repeat in several places, i might be wrong:


      Source Code

      1. Jan 31 12:57:58 omv kernel: [ 7288.856485] BTRFS warning (device mmcblk0p2): csum failed root 5 ino 115405 off 1183248384 csum 0x808731d1 expected csum 0x0cd4b68d mirror 1
      2. Jan 31 13:12:18 omv kernel: [ 8149.572326] BTRFS warning (device mmcblk0p2): csum failed root 5 ino 115405 off 1187336192 csum 0x743f6925 expected csum 0xb7d18330 mirror 1
      3. Jan 31 13:12:19 omv kernel: [ 8149.978024] BTRFS warning (device mmcblk0p2): csum failed root 5 ino 115405 off 1187336192 csum 0x6b8cf65c expected csum 0xb7d18330 mirror 1
      4. Jan 31 13:12:26 omv kernel: [ 8156.928693] BTRFS warning (device mmcblk0p2): csum failed root 5 ino 115405 off 1187336192 csum 0x22b16c23 expected csum 0xb7d18330 mirror 1
      5. Jan 31 13:12:40 omv NetworkManager[720]: <info> [1517415160.7624] manager: (veth7e73be6): new Macvlan device (/org/freedesktop/NetworkManager/Devices/15)
      6. Jan 31 13:12:41 omv NetworkManager[720]: <info> [1517415161.1061] manager: (vethd832b1e): new Macvlan device (/org/freedesktop/NetworkManager/Devices/16)
      7. Jan 31 13:12:41 omv NetworkManager[720]: <info> [1517415161.1563] devices added (path: /sys/devices/virtual/net/veth7e73be6, iface: veth7e73be6)
      8. Jan 31 13:12:41 omv NetworkManager[720]: <info> [1517415161.1564] device added (path: /sys/devices/virtual/net/veth7e73be6, iface: veth7e73be6): no ifupdown configuration found.
      9. Jan 31 13:12:41 omv NetworkManager[720]: <info> [1517415161.1572] devices added (path: /sys/devices/virtual/net/vethd832b1e, iface: vethd832b1e)
      10. Jan 31 13:12:41 omv NetworkManager[720]: <info> [1517415161.1573] device added (path: /sys/devices/virtual/net/vethd832b1e, iface: vethd832b1e): no ifupdown configuration found.
      11. Jan 31 13:12:42 omv kernel: [ 8173.355689] eth0: renamed from veth7e73be6
      12. Jan 31 13:12:42 omv NetworkManager[720]: <info> [1517415162.6172] devices removed (path: /sys/devices/virtual/net/veth7e73be6, iface: veth7e73be6)
      13. Jan 31 13:12:43 omv NetworkManager[720]: <info> [1517415163.9185] devices removed (path: /sys/devices/virtual/net/vethd832b1e, iface: vethd832b1e)
      14. Jan 31 13:12:43 omv kernel: [ 8174.660255] eth0: renamed from vethd832b1e
      15. Jan 31 13:15:36 omv kernel: [ 8346.913768] device eth0 left promiscuous mode
      16. Jan 31 13:28:43 omv kernel: [ 0.000000] Boot CPU: AArch64 Processor [410fd034]
      17. Jan 31 13:28:43 omv kernel: [ 0.000000] Machine model: Xunlong Orange Pi PC 2
      18. Jan 31 13:28:43 omv kernel: [ 0.000000] cma: Reserved 128 MiB at 0x0000000078000000
      Display All

      Any ideas? thanks in advance for any help.

      IMPORTANT NOTE: im not complaining at all, dont get me wrong, if at all i want to discover what causes this to help the developers (if its a bug) or somebody else in the future with the same problem (if it is a setup/hardware problem)

      The post was edited 1 time, last by Trash_Can_Man ().

    • Also i have this earlier but no reboots for another half hour there, so im not sure if critical:

      Source Code

      1. Jan 31 11:06:10 omv kernel: [ 581.278560] BTRFS warning (device mmcblk0p2): csum failed root 306 ino 4407 off 2137825280 csum 0x02574ca4 expected csum 0xa2231655 mirror 1
      2. Jan 31 11:06:11 omv kernel: [ 582.282259] BTRFS warning (device mmcblk0p2): csum failed root 306 ino 4407 off 2137825280 csum 0x33108ad6 expected csum 0x1b9ce995 mirror 1
      3. Jan 31 11:06:12 omv kernel: [ 582.629475] Modules linked in: xt_nat macvlan ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype iptable_filter xt_conntrack nf_nat nf_conntrack br_netfilter bridge zram snd_soc_hdmi_codec rc_cec dw_hdmi_i2s_audio dw_hdmi_cec sun8i_dw_hdmi dw_hdmi ir_lirc_codec lirc_dev sun8i_codec_analog sunxi_cir cec sun4i_codec rc_core sun4i_gpadc_iio sun4i_i2s snd_soc_simple_card snd_soc_simple_card_utils snd_soc_core snd_pcm_dmaengine iio_hwmon snd_pcm sun8i_mixer snd_timer sun4i_drm sun4i_tcon industrialio r8152 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c raid1 raid0 multipath linear md_mod uas sy8106a_regulator sunxi musb_hdrc
      4. Jan 31 11:06:12 omv kernel: [ 582.696933] CPU: 1 PID: 4274 Comm: qbittorrent-nox Not tainted 4.14.15-sunxi64 #21
      5. Jan 31 11:06:12 omv kernel: [ 582.704501] Hardware name: Xunlong Orange Pi PC 2 (DT)
      6. Jan 31 11:06:12 omv kernel: [ 582.709638] task: ffff8000219f8d80 task.stack: ffff00000d018000
      7. Jan 31 11:06:12 omv kernel: [ 582.715567] PC is at skb_release_data+0x7c/0x158
      8. Jan 31 11:06:12 omv kernel: [ 582.720190] LR is at __consume_stateless_skb+0x14/0x28
      9. Jan 31 11:06:12 omv kernel: [ 582.725326] pc : [<ffff0000087ef364>] lr : [<ffff0000087f25c4>] pstate: 60000145
      10. Jan 31 11:06:12 omv kernel: [ 582.732717] sp : ffff00000d01bb00
      11. Jan 31 11:06:12 omv kernel: [ 582.736032] x29: ffff00000d01bb00 x28: 000000000000058f
      12. Jan 31 11:06:12 omv kernel: [ 582.741345] x27: ffff80002554a300 x26: 0000000000000011
      13. Jan 31 11:06:12 omv kernel: [ 582.746655] x25: 0000000000000040 x24: 0000000000000000
      14. Jan 31 11:06:12 omv kernel: [ 582.751969] x23: 000000000000058f x22: ffff00000d01be60
      15. Jan 31 11:06:12 omv kernel: [ 582.757281] x21: ffff80002554a300 x20: ffff80003472e500
      16. Jan 31 11:06:12 omv kernel: [ 582.762594] x19: 0000000000000000 x18: 00000000ee5a079f
      17. Jan 31 11:06:12 omv kernel: [ 582.767906] x17: 0000ffffb3276708 x16: ffff0000087e52f0
      18. Jan 31 11:06:12 omv kernel: [ 582.773217] x15: 000021a75fdb3392 x14: 2a0bd9a30a66d87b
      19. Jan 31 11:06:12 omv kernel: [ 582.778529] x13: 6c15b7b2269c9493 x12: 0c98c9401353dd58
      20. Jan 31 11:06:12 omv kernel: [ 582.783842] x11: c78d4d81ccb60a24 x10: d21814ed3cfdab07
      21. Jan 31 11:06:12 omv kernel: [ 582.789154] x9 : c0b5d28dc6d7134c x8 : 22ebcb075ca8489f
      22. Jan 31 11:06:12 omv kernel: [ 582.794466] x7 : 8b10e1014aa8f185 x6 : 0000aaab1a0c582f
      23. Jan 31 11:06:12 omv kernel: [ 582.799768] x5 : 0000aaab1a0c582f x4 : 0000000000000004
      24. Jan 31 11:06:12 omv kernel: [ 582.805078] x3 : ffff00000d01bd88 x2 : 0000000000000700
      25. Jan 31 11:06:12 omv kernel: [ 582.810390] x1 : ffff80003472e500 x0 : 42dc5c3a36349ee9
      26. Jan 31 11:06:12 omv kernel: [ 582.823183] Call trace:
      27. Jan 31 11:06:12 omv kernel: [ 582.825634] Exception stack(0xffff00000d01b9c0 to 0xffff00000d01bb00)
      28. Jan 31 11:06:12 omv kernel: [ 582.832076] b9c0: 42dc5c3a36349ee9 ffff80003472e500 0000000000000700 ffff00000d01bd88
      29. Jan 31 11:06:12 omv kernel: [ 582.839905] b9e0: 0000000000000004 0000aaab1a0c582f 0000aaab1a0c582f 8b10e1014aa8f185
      30. Jan 31 11:06:12 omv kernel: [ 582.847734] ba00: 22ebcb075ca8489f c0b5d28dc6d7134c d21814ed3cfdab07 c78d4d81ccb60a24
      31. Jan 31 11:06:12 omv kernel: [ 582.855564] ba20: 0c98c9401353dd58 6c15b7b2269c9493 2a0bd9a30a66d87b 000021a75fdb3392
      32. Jan 31 11:06:12 omv kernel: [ 582.863395] ba40: ffff0000087e52f0 0000ffffb3276708 00000000ee5a079f 0000000000000000
      33. Jan 31 11:06:12 omv kernel: [ 582.871224] ba60: ffff80003472e500 ffff80002554a300 ffff00000d01be60 000000000000058f
      34. Jan 31 11:06:12 omv kernel: [ 582.879053] ba80: 0000000000000000 0000000000000040 0000000000000011 ffff80002554a300
      35. Jan 31 11:06:12 omv kernel: [ 582.886884] baa0: 000000000000058f ffff00000d01bb00 ffff0000087f25c4 ffff00000d01bb00
      36. Jan 31 11:06:12 omv kernel: [ 582.894714] bac0: ffff0000087ef364 0000000060000145 ffff00000d01bae0 ffff000008880a8c
      37. Jan 31 11:06:12 omv kernel: [ 582.902545] bae0: 0001000000000000 ffff000008880b60 ffff00000d01bb00 ffff0000087ef364
      38. Jan 31 11:06:12 omv kernel: [ 582.910379] [<ffff0000087ef364>] skb_release_data+0x7c/0x158
      39. Jan 31 11:06:12 omv kernel: [ 582.916045] [<ffff0000087f25c4>] __consume_stateless_skb+0x14/0x28
      40. Jan 31 11:06:12 omv kernel: [ 582.922232] [<ffff000008880424>] skb_consume_udp+0x3c/0xd0
      41. Jan 31 11:06:12 omv kernel: [ 582.927720] [<ffff000008880c98>] udp_recvmsg+0x1d8/0x490
      42. Jan 31 11:06:12 omv kernel: [ 582.933037] [<ffff00000888c7c4>] inet_recvmsg+0x4c/0xe8
      43. Jan 31 11:06:12 omv kernel: [ 582.938270] [<ffff0000087e2978>] sock_recvmsg+0x48/0x58
      44. Jan 31 11:06:12 omv kernel: [ 582.943500] [<ffff0000087e3d78>] ___sys_recvmsg+0xc8/0x1e0
      45. Jan 31 11:06:12 omv kernel: [ 582.948991] [<ffff0000087e5290>] __sys_recvmsg+0x58/0xb8
      46. Jan 31 11:06:12 omv kernel: [ 582.954306] [<ffff0000087e5300>] SyS_recvmsg+0x10/0x20
      47. Jan 31 11:06:12 omv kernel: [ 582.959445] Exception stack(0xffff00000d01bec0 to 0xffff00000d01c000)
      48. Jan 31 11:06:12 omv kernel: [ 582.965887] bec0: 0000000000000011 0000ffffb03d5c88 0000000000000000 0000000000000000
      49. Jan 31 11:06:12 omv kernel: [ 582.973717] bee0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      50. Jan 31 11:06:12 omv kernel: [ 582.981548] bf00: 00000000000000d4 0000ffffb03d6198 0000aaab1bce8890 0000000006c854ae
      51. Jan 31 11:06:12 omv kernel: [ 582.989379] bf20: 0000000000000018 000000005a71cd54 0000aaab1b310770 000021a75fdb3392
      52. Jan 31 11:06:12 omv kernel: [ 582.997209] bf40: 0000ffffb3205a60 0000ffffb3276708 00000000ee5a079f 00000000000000d4
      53. Jan 31 11:06:12 omv kernel: [ 583.005038] bf60: 0000ffffb03d5f98 0000000000000000 0000ffffb03d5d60 0000000000000001
      54. Jan 31 11:06:12 omv kernel: [ 583.012865] bf80: 0000ffffb03d5d98 0000000000000001 0000000000000001 0000ffffb03d5d48
      55. Jan 31 11:06:12 omv kernel: [ 583.020694] bfa0: 0000000000000000 0000ffffb03d5c30 0000ffffb328f434 0000ffffb03d5c30
      56. Jan 31 11:06:12 omv kernel: [ 583.028521] bfc0: 0000ffffb328e9a0 0000000060000000 0000000000000011 00000000000000d4
      57. Jan 31 11:06:12 omv kernel: [ 583.036349] bfe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      58. Jan 31 11:06:12 omv kernel: [ 583.044182] [<ffff000008083008>] __sys_trace_return+0x0/0x4
      59. Jan 31 11:06:12 omv kernel: [ 583.055865] ---[ end trace 0bf8d5fd08a36bed ]---
      60. Jan 31 11:06:12 omv kernel: [ 583.284761] BTRFS warning (device mmcblk0p2): csum failed root 306 ino 4407 off 2137825280 csum 0x64f7bdc3 expected csum 0x1b9ce995 mirror 1
      61. Jan 31 11:06:13 omv kernel: [ 584.299045] BTRFS warning (device mmcblk0p2): csum failed root 306 ino 4407 off 2137825280 csum 0x9b062c5a expected csum 0xa2231655 mirror 1
      62. Jan 31 11:06:14 omv kernel: [ 585.290136] BTRFS warning (device mmcblk0p2): csum failed root 306 ino 4407 off 2137825280 csum 0xa9684958 expected csum 0x1b9ce995 mirror 1
      63. Jan 31 11:06:15 omv kernel: [ 586.289846] BTRFS warning (device mmcblk0p2): csum failed root 306 ino 4407 off 2137825280 csum 0xfa059580 expected csum 0x1b9ce995 mirror 1
      Display All
      I can upload the complete log somewhere but since i updated the system recently and also i corrected the timezone in the meanwhile its kinda nasty, tell me how do you guys handle log uploads or what logs do you guys need and ill do it asap...thanks in advance for any help.
    • Trash_Can_Man wrote:

      Is it really just a warning or should i be worried about the SD card health?
      This is filesystem corruption maybe related to a broken or counterfeit SD card. Anyway, the first thing is to see how severe your rootfs is corrupted:

      Source Code

      1. sudo btrfs scrub /
      If you see here more than 10 entries you need to start over from scratch anyway since a corrupted rootfs leads to all sorts of strange problems that only increase (kernel panics followed by reboots included -- any more diagnosis is a useless waste of time once the rootfs is corrupted)

      I hope you carefully followed these steps (checking for counterfeit SD cards and only using Etcher to write the image)?
    • maybe some typo?


      Source Code

      1. root@omv:~# sudo btrfs scrub /
      2. btrfs scrub: unknown token '/'
      3. usage: btrfs scrub <command> [options] <path>|<device>
      4. btrfs scrub start [-BdqrRf] [-c ioprio_class -n ioprio_classdata] <path>|<device>
      5. Start a new scrub. If a scrub is already running, the new one fails.
      6. btrfs scrub cancel <path>|<device>
      7. Cancel a running scrub
      8. btrfs scrub resume [-BdqrR] [-c ioprio_class -n ioprio_classdata] <path>|<device>
      9. Resume previously canceled or interrupted scrub
      10. btrfs scrub status [-dR] <path>|<device>
      11. Show status of running or finished scrub
      12. verify checksums of data and metadata
      Display All
      I didnt do the counterfeit check since the package and all about the card seemed legit but i guess ill do it anyway now, i did format complete and then write it with etcher tho...only one question, either of those apps overwrites the system?

      no flash plugin, i have the option to add it, i though that it came installed on sbc images by default but apparently not...

      The post was edited 2 times, last by Trash_Can_Man: i was wrong, i dont have the flashmemory plugin, for some reason i though it came by default on these images ().

    • Trash_Can_Man wrote:

      maybe some typo?
      No, not remembered correctly but the error output already pointed you in the right direction:

      Source Code

      1. btrfs scrub -B start /

      (the '-B' is explained in the manual page as well). In case you create a separate user and login as this user you could also check the SD card on the OMV images for ARM in a running system with

      Source Code

      1. armbianmonitor -c $HOME
    • hum, again? the / simply replace the device?

      Source Code

      1. root@omv:~# btrfs scrub -B start /
      2. btrfs scrub: unknown token '-B'
      3. usage: btrfs scrub <command> [options] <path>|<device>
      4. btrfs scrub start [-BdqrRf] [-c ioprio_class -n ioprio_classdata] <path>|<device>
      5. Start a new scrub. If a scrub is already running, the new one fails.
      6. btrfs scrub cancel <path>|<device>
      7. Cancel a running scrub
      8. btrfs scrub resume [-BdqrR] [-c ioprio_class -n ioprio_classdata] <path>|<device>
      9. Resume previously canceled or interrupted scrub
      10. btrfs scrub status [-dR] <path>|<device>
      11. Show status of running or finished scrub
      12. verify checksums of data and metadata
      Display All

      After jumping in a nasty way over linux permissions hell (i created an user but armbianmonitor asked for the home folder, created the folder with root but had no permissions to write to it on the user, anyway, ill clean up the mess after, lol) i got after a long wait:


      Source Code

      1. Gabriel@omv:~$ armbianmonitor -c $HOME
      2. Starting to fill /dev/mmcblk0p2 with test patterns, please be patient this might take a very long time
      3. Free space: 4.71 GB
      4. Creating file 1.h2w ... OK!
      5. Creating file 2.h2w ... OK!
      6. Creating file 3.h2w ... OK!
      7. Creating file 4.h2w ... OK!
      8. Creating file 5.h2w ... OK!
      9. Free space: 255.66 MB
      10. Average writing speed: 7.50 MB/s
      11. Now verifying the written data:
      12. SECTORS ok/corrupted/changed/overwritten
      13. Validating file 1.h2w ... 2097152/ 0/ 0/ 0
      14. Validating file 2.h2w ... 2097152/ 0/ 0/ 0
      15. Validating file 3.h2w ... 2097152/ 0/ 0/ 0
      16. Validating file 4.h2w ... 2097152/ 0/ 0/ 0
      17. Validating file 5.h2w ... 880514/ 0/ 0/ 0
      18. Data OK: 4.42 GB (9269122 sectors)
      19. Data LOST: 0.00 Byte (0 sectors)
      20. Corrupted: 0.00 Byte (0 sectors)
      21. Slightly changed: 0.00 Byte (0 sectors)
      22. Overwritten: 0.00 Byte (0 sectors)
      23. Average reading speed: 10.26 MB/s
      24. Starting iozone tests. Be patient, this can take a very long time to complete:
      25. Iozone: Performance Test of File I/O
      26. Version $Revision: 3.429 $
      27. Compiled for 64 bit mode.
      28. Build: linux
      29. Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
      30. Al Slater, Scott Rhine, Mike Wisner, Ken Goss
      31. Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
      32. Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
      33. Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
      34. Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
      35. Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
      36. Vangel Bojaxhi, Ben England, Vikentsi Lapa.
      37. Run began: Wed Jan 31 15:54:06 2018
      38. Include fsync in write timing
      39. O_DIRECT feature enabled
      40. Auto Mode
      41. File size set to 102400 kB
      42. Record Size 4 kB
      43. Record Size 512 kB
      44. Record Size 16384 kB
      45. Command line used: iozone -e -I -a -s 100M -r 4k -r 512k -r 16M -i 0 -i 1 -i 2
      46. Output is in kBytes/sec
      47. Time Resolution = 0.000001 seconds.
      48. Processor cache size set to 1024 kBytes.
      49. Processor cache line size set to 32 bytes.
      50. File stride size set to 17 * record size.
      51. random random bkwd record stride
      52. kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
      53. 102400 4 607 656 3083 3401 2385 648
      54. 102400 512 4261 4250 9029 9221 10653 5977
      55. 102400 16384 6342 5764 11327 11097 11453 8527
      56. iozone test complete.
      57. The results from testing /dev/mmcblk0p2 (btrfs):
      58. Data OK: 4.42 GB (9269122 sectors)
      59. Data LOST: 0.00 Byte (0 sectors)
      60. Average writing speed: 7.50 MB/s
      61. Average reading speed: 10.26 MB/s
      62. random random
      63. reclen write rewrite read reread read write
      64. 4 607 656 3083 3401 2385 648
      65. 512 4261 4250 9029 9221 10653 5977
      66. 16384 6342 5764 11327 11097 11453 8527
      67. Health summary: OK
      68. Performance summary:
      69. Sequential reading speed: 10.26 MB/s
      70. 4K random reading speed: 2385 KB/s (low)
      71. Sequential writing speed: 7.50 MB/s
      72. 4K random writing speed: 648 KB/s (too low)
      73. The device you tested seems to perform too slow to be used with Armbian.
      74. This applies especially to desktop images where slow storage is responsible
      75. for sluggish behaviour. If you want to have fun with your device do NOT use
      76. this media to put the OS image or the user homedirs on.
      77. To interpret the results above correctly or search for better storage
      78. alternatives please refer to http://oss.digirati.com.br/f3/ and also
      79. http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card
      80. and http://thewirecutter.com/reviews/best-microsd-card/
      Display All
      So i guess i do have a fake one after all, or a very bad one (is a Kingston C10 with no guarantied speed marks on the blister, if not fake it must be barelly c10)
      But apparently have no errors, im going to replace it anyway for some sandisk 80mb/s, im not sure if i can get samsung EVO+ locally, probably not...for now im gonna rule this as kernel panics because of slow card i guess and im gonna report in a few days when i install all back from scratch on a new card...thanks in advance for the help :D
    • Ok that last one worked:

      Source Code

      1. root@omv:~# btrfs scrub start -B /
      2. scrub done for 6d0d4c98-6bbf-418c-9501-7667708a6fe7
      3. scrub started at Wed Jan 31 16:38:51 2018 and finished after 00:03:48
      4. total bytes scrubbed: 2.21GiB with 1 errors
      5. error details: csum=1
      6. corrected errors: 0, uncorrectable errors: 1, unverified errors: 0
      7. ERROR: there are uncorrectable errors
      Anyway im going to replace the card but i wanted to post the result just in case someone else wanders around here in the future, again, thanks for all the help.
    • Im back to report that changing the SD card did solve my original post problem, its been 6 solid hours runing overnight, i need to pay attention to it just to be sure but apparently its solved, but i have a doubt now, i was unable to install docker on 3.x (it was giving some error about not having available an arm64 version of docker in the repos and i really need docker) so i went to 4.x once again, first i tried to upgrade from the 3.x image and i was getting weird repos errors after runing omv-release-upgrade, using the ui i installed a few packages at a time until everything was installed so i have the feeling that the problem is some weird package order problem, anyway it felt a dirty installation so i started all over again using the armbian-config-softy-omv method (burn armbian server, run armbian-config) the script is kinda weird but runs without errors, the install went smooth, no errors, installed the docker plugin, my dockers everything was fantastic, i have only one issue with this method, for some reason it dont install zram, left me with a 128mb swap partition, im not sure if you guys now set the script that way or not (and imho these toy boards as tkaiser call em need zram) but i did some google fu and did this:

      Source Code

      1. wget https://mirrors.kernel.org/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb
      2. dpkg -i zram-config_0.5_all.deb
      restarted twice and i now have double swap aparently, the normal 128mb (with -5 swappines) and zram (with 0 swappiness), i have no problem with having double, maybe for extreme situations it would help (and yes, after 6 hours swapon reports 0mb swap used and 90mb on zram (22mbx4)), and my question is: do i need to set up zram in any particular way or leaving it this way is the most efficient way i can use it? does it have the best compression method set by default? and another one, after 6 hours the ui report 65% memory usage, is it safe to move it to about 80% adding another docker?

      News: just got a massive slowdown, letting it stay to see if temporary or permanent, reporting in a few mins

      Followup: the base os kept runing apparently all night as its uptime reports 6:50 but there are massive slowdowns apparently, and i got 2 of the dockers stopped, im not sure if the problem is within the os, in the docker engine or in some of my dockers, var/logs/messages dont show anything to mention at about the last slowdown hour tho i keep getting those weird macvlan <info> lines and no more btrfs csum warnings anymore...i was opening the omv webui when this slowdown happened (a second before i loged in and was loading the dashboard screen) (and i think i was browsing or doing stuff on the ui the last few times i had problems) so i wonder if im seeing some super random bug with the ui...also its a slowdown, can the ui cause a big enough memory spike to put the board on swap hell for a pair of minutes? it have to be a very big spike since the board on my setup stays at about 60% memory used...

      The post was edited 2 times, last by Trash_Can_Man ().

    • So i left htop open on a terminal window to watch it now and then while i work and do other stuff, and catch the exact moment when a massive slow down happened, (why in hell every weird problem happens to me? makes me feel like Bad Luck Brian) and seems like the culprit is sickrage, the exact moment the problem was starting sickrage peaked on memory usage to very crazy levels and puts the board on some form of swap hell (tho it still never touches disk swap), im going to let it run a few hours without sickrage to see if something else triggers it, also i found this wich appear to be my problem, going to report back in a few hours, sorry for wasting everyones time, my luck really stink with this board apparently, maybe its destiny telling me to buy an odroid xu4 lol
    • Trash_Can_Man wrote:

      maybe its destiny telling me to buy an odroid xu4
      How should exchanging hardware fix software (whatever sickrage is)? If you're running low on memory then switching to a device with more DRAM is a good idea if the software can not be fixed. But then I would better look for boards that allow a bit more than just 2 GB (eg. ROCK64)
    • It was just a joke but yea, opipc2 have 1gig and xu4 have 2 gig so my joke does apply in this contexts, also if i understand the armbian lists correctly the xu4 is in a stable state while the rock64 is a work in progress, maybe im wrong but "work in progress" dont mean that it have nasty bugs yet?

      ps: ive been looking at reviews, the hardware, distros and even checked for local retailers (offering the 4gb version ofc) and im REALLY liking the idea, in all honesty, the rock64 is even cheaper than the xu4, how stable is omv on this board? any nasty (or at all) bugs i should know of? what about docker? does it work on it?
      ps2: answering my own question: Docker GUI plugin for armhf on OMV 3 and @tkaiser dude you are a genious, seriously tyvvvvm, now i need to get myself a rock64, seems super solid for what i need...

      The post was edited 3 times, last by Trash_Can_Man ().