xorinox
-
Posts
11 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by xorinox
-
-
Update: reboot issue on SD card using Armbian_20.05.4_Odroidc4_focal_legacy_4.9.224.img cannot be reproduced
-
Hello, I have just installed Armbian_20.05.4_Odroidc4_focal_current_5.6.18.img on my Odroid-C4, and encounter the same issue. The board doesn't come back up after rebooting. The ethernet controller is blinking in an interesting way. The right orange NIC LED blink about 5 times, then green and orange LED blink once together. This continues this way. The screen is not enabled after the reboot. Unpowering the board helps to reboot. The last thing you read from the screen before it turns black was: Reached target Reboot.
I am using a micro SD card, Samsung Pro 32G. Let me know what information you might want to have posted here. I do not have the same issue with Odroid's default image, but I prefer your tidy distro
-
On 8/23/2017 at 2:50 AM, tkaiser said:
usb5 interrupt (handling the USB3 port to which the USB Gigabit Ethernet adapter on ODROID XU3/XU4/HC1/HC2/MC1 is connected) from cpu3 (little) to cpu7 (big core):
Can you explain how you achieved this? I have tried a couple of steps including https://obihoernchen.net/1416/odroid-xu4-tune-network-and-usb-speed it doesn't seem to affect performance significantly when copying files from Win to HC1 through 1GE. It averages 55Mbytes/s which is think is too low. The same disk connected to my Odroid, I used with an USB/SATA cable before attached to my Win machine, the disk takes easily 130MBytes/s. I have tried that same disk with a rock64 (no tuning) and that same USB/SATA cable and Samba, it was twice as fast. I timed copying the same ~100GB of files.
-
The issue with sda vs sdb didn't come back since I am using the oversized power supply. I got a multi-meter and measured the voltage under normal conditions, when the HC1 is loaded with compiling code and used one of my utilities to create lots of files keeping the disk busy. The voltage stayed in between 5.19 and 5.17.
I noticed that my switch suddenly indicated that the Ethernet connection from it to HC1 is only of 100Mbit (orange light). I unplugged the cable and it changed back to 1Gbit. A little after it happened again. I am actually running Samba on the HC1 and indeed the connection seemed capped at 100MBit e.g. copying files from my Win machine didn't exceed 10Mbyes/s. After unplug and plug again it was back to 1GE and 50-70Mbytes/s transfer speed (from Win to it). I continue watching if I see the 1GE downgrade to fast Ethernet again.
-
Should have reviewed that earlier
-
My understanding is, when the connected device tries drawing more amps, than the PSU under specified voltage can provide, the voltage collapses. My PSU from Amazon (https://www.amazon.com/gp/product/B01K0608A0) have 20W, if the HC1 under some circumstances draws more than 4A the volts have to go down, since its max is 20W (thinking about the power law).
I will buy a multi-meter and do the measurements suggested. The one HC1 connected the Meanwell PSU didn't show the issue yet. Do know, I am not suggesting this 150W PSU as a final solution.
-
Ok, thanks. I will find out if my psu are the reason. I don't have the tools to measure my PSU's performance under load. Yet need to read through the add'l information.
Meanwhile, I got an LRS-150F-5 and changed over 2 of 3 HC1. It provides up to 22A. As you can see the cables are thick copper cables too.
-
Hi, I have 3 Odroid HC1. All have a 2TB SATA disk attached. I am using Armbian_5.35_Odroidxu4_Ubuntu_xenial_next_4.9.61.img, and the armbian-config to copy the rootfs to the SATA disk. I have used ext4 and btrfs. Actually used btrfs from the start, but I got some weird error after running the HC1 for a couple of days, so that my open command, would return -bash: /sbin/blkid: Input/output error on any input. This is just an example. Didn't really know what was going on, I rebooted, and then could not login through ssh anymore. I assume rootfs gone, and reinstalled the HC1 again, copied over rootfs with armbian-config using btrfs.
Few days later I had the same issue again, so reinstalled again but changed to ext4 (to see if this makes a difference). Now I have that same issue also with ext4 as the rootfs. So it's unrelated to ext4/btrfs I assume. I noticed that the SATA disk from originally sda changed to sdb. Have a look at lsblk below. I restarted the node and it came back working, but now using sda again. You also find the dmesg outpout from when the node wasn't working properly anymore.
I think the trouble started at line: [ 7432.871964] usb 4-1: USB disconnect, device number 2 (maybe these disks go sleep)? I am not running any big computations on them. The power supplies are 5V/4A
I have 2 HC1 with a 2TB Seagate Barracuda and the 3rd HC1 with a 2TB Seagate Firecuda. Both HC1 with each the Barracuda had that issue so far. One with ext4, one with btrfs. The disks are new. The setup with the Firecuda didn't break yet.
I have tried to read SMART but didn't get that working: smartctl -a -d usbjmicron /dev/sda
Any help much appreciated.
root@hc1-node-1:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
zram7 253:7 0 124.6M 0 disk [SWAP]
zram5 253:5 0 124.6M 0 disk [SWAP]
sdb 8:16 0 1.8T 0 disk
└─sdb1 8:17 0 1.8T 0 part /
zram3 253:3 0 124.6M 0 disk [SWAP]
zram1 253:1 0 124.6M 0 disk [SWAP]
mmcblk1 179:0 0 14.9G 0 disk
└─mmcblk1p1 179:1 0 14.7G 0 part /media/mmcboot
zram6 253:6 0 124.6M 0 disk [SWAP]
zram4 253:4 0 124.6M 0 disk [SWAP]
zram2 253:2 0 124.6M 0 disk [SWAP]
zram0 253:0 0 124.6M 0 disk [SWAP]
root@hc1-node-1:~# blkid
-bash: /sbin/blkid: Input/output error
root@hc1-node-1:~#
-
On 11/28/2017 at 2:08 AM, tkaiser said:
This is a useless product targeting RAID/NAS novices that don't know what they do
RAID-1 was somewhat useful last century when we couldn't do better. On servers. That need 100% availability. It's useless at home, just an insane waste of disk capacity. Protection level is bizarrely low, it allows neither for data protection nor data integrity, you should really instantly try to test whether you can access your RAID-1 without this board (since it's a single point of failure and the board or the RAID controller on it can fail as well) and check data integrity (since those ICs are prone to overheating under load).
Everything I wrote here about mdraid RAID-1 applies to those external USB-RAID controllers too: https://forum.openmediavault.org/index.php/Thread/18637-Home-NAS-build-FS-info/?postID=146935#post146935
As written above: Don't trust this thing. Check for data integrity (use btrfs and scrub your data after you let a large resync run), check how the board signals that one disk has a problem (you bet on redundancy here and the goal is to be protected from one failing disk -- what if this thing doesn't tell you when one disk is failing, you lost your redundancy and then soon after the 2nd disk dies?).
Stop playing RAID, do backup instead (by using modern filesystems and their features, eg. snapshots sent to another disk or even host regularly, this can be done pretty efficiently). RAID is not backup, you have no data protection with this approach since it's only about availability.
Thanks for your feedback. I wasn't looking for a "backup" solution rather interested to find out how many disks can I operate permanently using that one USB3 port of the ROCK64. I only figured I I had to solder in order to use the board to just address two disks instead of using RAID, when I had in my hands already. I was expecting some kind of switch or jumper.. Well I should have read the manual. Since RAID1 is the default, and I didnt find anything about this board here, I shared. The board already made it into the trash. I am waiting for these cheap usb3-sata pcb boards.. https://www.amazon.com/gp/product/B01N5J63RT that is going to be my next test. Btw, somewhere here I read about the rock64 power cable assemblies, I am running my boards with these: https://www.arrow.com/en/products/10-01072/tensility-international connected to that https://www.arrow.com/en/products/lrs-150f-5/mean-well-enterprises
Back to several disks per usb3, I am not considering SSDs (trying to keep the cost low), I am going to try http://www.oricostore.com/index.php?route=product/product&path=399_405&product_id=6655 I am interested to see if I can get 200mb/s out of two disks and utilizing the second 1GE over usb3.
-
I found this thread very interesting. I am experimenting myself with several different NAS options.
Today I connected a Cubie HDD RAID sub-board to a Rock64 and two HGST travelstar 7.2k 1TB each. I copied over some 100GB using the samba server that just comes along with Rocks Linux rock64 4.4.77-rockchip-ayufan-118
For large files peeks were at 112MB/s when I copied over from a Win PC through 1GE, but kept a constant rate over 100MB/s. The Cubie sub board uses RAID 1 per default. I tried the copy process again and disconnected one of the disks. Just took it off. Active copy process died. I had the RAID volume mounted as /dev/sda1, but /dev/sda disappeared. That was not expected behavior.
I rebooted the Rock64 and was able to mount my volume now only supported by one disk. I started my 100GB copy job again. At first it kept the rate of at least 100MB/s. Then I reconnected the second disk. The rate went down to about 60MB/s. I would think the decrease is due to re-syncing of the volume. I think it's ok to still have 60MB/s while it's doing that.
I like this sub board, but I didn't like it disliked removing one disk at run time. I like it gives through USB3 enough IO to max out the 1GE of the Rock64. I don't like I need to solder in order to change the RAID mode. I would rather just have two targets e.g. /dev/sda & /dev/sdb
Any other tests I should be doing?
Odroid C4
in Amlogic meson
Posted
Right after booting Armbian_20.05.4_Odroidc4_focal_legacy_4.9.224.img on a SD card and then running apt update && apt upgrade -y leads to this "Operation not permitted" error message. Not sure if that's important. After the upgrade the board still reboots and comes back online.
Processing triggers for systemd (245.4-4ubuntu3.1) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for libc-bin (2.31-0ubuntu9) ...
Processing triggers for ca-certificates (20190110ubuntu1.1) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for initramfs-tools (0.136ubuntu6.2) ...
ln: failed to create hard link '/boot/initrd.img-4.9.224-odroidc4.dpkg-bak' => '/boot/initrd.img-4.9.224-odroidc4': Operation not permitted
update-initramfs: Generating /boot/initrd.img-4.9.224-odroidc4
update-initramfs: Converting to u-boot format
Reading package lists... Done
Building dependency tree
Reading state information... Done