alexcp

  • Content Count

    11
  • Joined

  • Last visited

  1. Thank you for the link and for continuing support. I realize you cannot focus on Helios4 forever, but it is good to know there will be updates to the box that keeps my data safe.
  2. Hello, My Helios4's power brick died. What's a good replacement? I almost ordered a Mean Well GST120A-R7B but realized its Mini-DIN connector has a different pinout. Also, Helios4 is end-of-life. What does it practically mean in terms of software updates and support?
  3. Well, I have not been able to recover my data. Even though the RAID array was clean, the filesystem appeared damaged as you suspected. The curious 18Tb filesystem on a 32bit rig is no more, unfortunately; I cannot run any test on it anymore. The defective HDD was less than a year old and covered by a 3-year warranty, so it is on its way to the manufacturer; hopefully I will get a free replacement. I intend to keep the 4x 10Tb drives on my Intel rig and rebuild the Helios with smaller, cheaper HDDs. To me, the incident is a reminder that a RAID array is not a complete solution for data safety a
  4. The point about the 16Tb limit is an interesting one; I remember being unable to create, via OMV, the array that would take all available physical space, and had to settle to the maximum offered by OMV. I also remember that ext4 is not limited by 16Tb; the limit is in the tools. Here is lvdisplay: $ sudo lvdisplay [sudo] password for alexcp: --- Logical volume --- LV Path /dev/omv/public LV Name public VG Name omv LV UUID xGyIgi-U00p-MVVv-zlz8-0quc-ZJwh-tuWvRl LV Write Access read/write LV Creatio
  5. cp fails, as does SMB network access to the shared folders. A fresh Debian Stretch install behaves identically to the not-so-fresh, and the previously installed OMV3 on Debian Jessie, the SD card with which I still have around, shows the same "Internal error: Oops: 5 [#1] SMP THUMB2". At this point, I tend to believe this is a hardware issue of sorts, maybe something as simple as a faulty power brick. Too bad it's not the SPI NOR flash, the solution to which is known. Oh well. Over the next few days, I will assemble another rig and will try to salvage the data through it.
  6. No luck with rsync. With the faulty HDD physically disconnected, an attempt to rsync the array to either a local USB drive or a hard drive on another machine invariably ends up in segmentation fault and system crash as before. Would I be able to access the filesystem on the RAID if I connect the HDDs to an Intel-based machine running Debian and OMV? I have a little Windows desktop with four SATA ports. I should be able to set up Debian and OMV on a USB stick and use the SATA for the array.
  7. The array's re-building was completed overnight, see below. I will try rsync later today to see if the data can be copied. $ sudo mdadm -D /dev/md127 [sudo] password for alexcp: /dev/md127: Version : 1.2 Creation Time : Sun Feb 4 18:42:03 2018 Raid Level : raid10 Array Size : 19532611584 (18627.75 GiB 20001.39 GB) Used Dev Size : 9766305792 (9313.88 GiB 10000.70 GB) Raid Devices : 4 Total Devices : 3 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Fri Nov 9 05:34:14 2018 State : clean, degraded Active Devic
  8. Re-add worked. Note sda is now the USB drive, so what was sda before is now sdb, etc. $ sudo mdadm --manage /dev/md127 --re-add /dev/sdb mdadm: re-added /dev/sdb $ sudo mdadm -D /dev/md127 /dev/md127: Version : 1.2 Creation Time : Sun Feb 4 18:42:03 2018 Raid Level : raid10 Array Size : 19532611584 (18627.75 GiB 20001.39 GB) Used Dev Size : 9766305792 (9313.88 GiB 10000.70 GB) Raid Devices : 4 Total Devices : 3 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Fri Nov 9 04:59:43 2018 State : clean, degraded, rec
  9. Lacking a spare SATA cable, I swapped sda and sdc cables. dmesg still shows errors for sdc, so it must be a faulty HDD - a first for me, ever. mdadm -D /dev/md127 gives the following: I created the encrypted partition when I was originally setting up the Helios - it was part of the setting up instructions - but I never used it. I PMed to you the logs. Also, I disconnected sdc and tried to rsync the RAID array to a locally connected USB drive as before. After copying a bunch of files, I got the following; this the sort of messages I was getti
  10. Thank you for the quick reply. I confirm there is no mtdblock0 device listed by lsblk. My Helios is fitted with 4x WD100EFAX HDDs, each rated for 5V/400mA, 12V/550mA. The Helios itself is powered by a 12V 8A brick. I tried copying files over SMB with no devices connected to the USB ports, with the same result: one or a few files can be copied without issues, however and attempt to copy a folder crashes the system. armbianmonitor -u output is here: http://ix.io/1reV
  11. Hello, Is there an easy way of disabling SPI to get rid of ATA errors? I am running OMV4 on a pre-compiled armbian stretch. When I try backing up the RAID array, either to a locally connected USB drive using rsync, or over network using SMB, after copying a few files, I end up with ATA errors, segmentation faults, or system crashes.