• Content Count

  • Joined

  • Last visited

About barish

  • Rank

Recent Profile Visitors

378 profile views
  1. I just tried a manual install according to , but with the same result. So I guess it's got nothing to do with softy and I'll dig further on their pages.
  2. Hi there, I just tried to use armbian-config's softy to install OpenMediaVault on my rather new EspressoBin (v5), but it ended up with a bunch of errors (this is from the terminal at second try of installation - didn't record the errors at first try): --2019-06-30 22:12:53-- Resolving ( Connecting to (||:443... connected. HTTP request sent, awaiting response... 200 OK Length: 3134 (3.1K) [application/pgp-keys] Saving to: '/etc/apt/trusted.gpg.d/openmediavault-archive-keyring.asc' /etc/apt/trusted.gpg.d/openmediava 100%[================================================================>] 3.06K --.-KB/s in 0s 2019-06-30 22:12:53 (19.4 MB/s) - '/etc/apt/trusted.gpg.d/openmediavault-archive-keyring.asc' saved [3134/3134] OK Executing: /tmp/apt-key-gpghome.aOQVltMEVs/ --keyserver hkp:// --recv-keys 7AA630A1EDEE7D73 gpg: key 7AA630A1EDEE7D73: "OpenMediaVault Plugin Developers <>" not changed gpg: Total number processed: 1 gpg: unchanged: 1 /usr/sbin/softy: line 611: [: 36576: unary operator expected Now installing OMV packages. Be patient please (Reading database ... 33546 files and directories currently installed.) Preparing to unpack .../tmp.9lMoxmevYT/omv_extras.deb ... Unpacking openmediavault-omvextrasorg (4.1.15) over (4.1.15) ... /var/lib/dpkg/info/openmediavault-omvextrasorg.postrm: 22: .: Can't open /usr/share/openmediavault/scripts/helper-functions dpkg: warning: subprocess old post-removal script returned error exit status 2 dpkg: trying script from the new package instead ... /var/lib/dpkg/ 22: .: Can't open /usr/share/openmediavault/scripts/helper-functions dpkg: error processing archive /tmp/tmp.9lMoxmevYT/omv_extras.deb (--install): subprocess new post-removal script returned error exit status 2 /var/lib/dpkg/ 22: .: Can't open /usr/share/openmediavault/scripts/helper-functions dpkg: error while cleaning up: subprocess new post-removal script returned error exit status 2 Errors were encountered while processing: /tmp/tmp.9lMoxmevYT/omv_extras.deb /usr/sbin/softy: line 636: /usr/share/openmediavault/scripts/helper-functions: No such file or directory /usr/sbin/softy: line 640: xmlstarlet: command not found /usr/sbin/softy: line 641: xmlstarlet: command not found /usr/sbin/softy: line 642: xmlstarlet: command not found /usr/sbin/softy: line 643: xmlstarlet: command not found /usr/sbin/softy: line 644: xmlstarlet: command not found /usr/sbin/softy: line 645: xmlstarlet: command not found /usr/sbin/softy: line 646: xmlstarlet: command not found /usr/sbin/softy: line 647: xmlstarlet: command not found /usr/sbin/softy: line 648: /usr/sbin/omv-rpc: No such file or directory /usr/sbin/softy: line 649: /usr/sbin/omv-rpc: No such file or directory sed: can't read /etc/init.d/rrdcached: No such file or directory --2019-06-30 22:13:57-- Resolving ( Connecting to (||:443... connected. HTTP request sent, awaiting response... 200 OK Length: 20466 (20K) [text/plain] Saving to: '/usr/lib/python3.5/' /usr/lib/python3.5/ 100%[================================================================>] 19.99K --.-KB/s in 0.02s 2019-06-30 22:13:57 (1.03 MB/s) - '/usr/lib/python3.5/' saved [20466/20466] /usr/sbin/softy: line 732: /usr/sbin/omv-initsystem: No such file or directory Any suggestions are welcome, thanks in advance.
  3. Just to let you know: I sent back the V7, got a refund (I had it ordered at Amazon, so it wasn't an issue) and ordered a V5 directly at Globalscale, which arrived quickly. It's running on conservative 800MHz Armbian for now (I am more interested in stability than excessive speed) and seems stable (uptime 37h by now), giving me good speeds over GBitEthernet of almost 80MB/s with an old SATA HDD. So I guess this will be the prototype for my Simple Home Server start-up!
  4. To sum up my not too excessive tests of the new kernel on the Lime2 - I did not encounter any read/write errors up to now. Right from the start I switched to nightly builds and still had a reasonably stable system. What I found dissapointing were the speeds over network (SMB): I did never exceed 44MB/s in any condition (reading, writing, HDD, SSD, SD card, SATA, USB, always GBit-Ethernet). If there's any procedure of testing read/write over SATA excessively - please let me know. Does a benchmark apply? OT: So this board might be a good update to my first generation Raspberry Pi (which makes 6MB/s ;-) ) but compared to the EspressoBin V5, which I obtained a couple of days ago and which is stable (other than the V7 I had to send back), it is about half as fast. And I am running the EspressoBin at a conservative 800MHz.
  5. Thanks @Tido for this link, I hadn't seen it and it gives quite a good explanation to why it took so long and why it's so difficult to have a decent SATA speed on Allwinner boards. :-) So I think testing should include all different kinds of transfer block sizes, verifying the write result on the fly, just to be sure that one trial-and-error-finding is as good as the previous trial-and-error-finding, which has already been tested since 2014.
  6. I just got an Olinuxino Lime2 and will soon get a cheap SATA SSD. What would be a good way of testing if the patch messes up read/write access or does any other harm to the system? I remember a message in another thread talking of edge cases of some sort - is there a way of artificially creating them or having a higher probability for those? I am willing to let the board run on tests for some weeks if necessary to find out.
  7. @Anders I am happy for you that the u-boot and kernel work for you. I did exactly what you did with all different u-boots and never got a stable board, not even a stable pre-kernel prompt (marvell>>). The only thing that was (mostly) stable was the pre-u-boot prompt (>)... but even then I had crashes during upload with WtpDownload, which may also be due to the fact that Prolific PL2303 drivers for MacOS (and for Windows) are quite buggy and lead to system crashes of the host (I had twice a detached process of MacOS with 100% cpu on one core, completely un-killable, I had to reboot the machine). I can't really understand why the EspressoBin uses this very cheap USB-serial-chip. OT: For me, it's not a good sign that the very only and first GlobalScale-board I ordered is so completely unreliable (I was thinking of using it for a series, this idea is more than dead now).
  8. Ok, that's it. Twice more the board crashed when I tried to set the env parameters. BTW I tried three different 12V power supplies, all have operated reliably in the past, one delivers about 11,5V, one 12,1V, one 12,5V, all 2A or more. The board is sitting on the bottom part of the original housing, which includes a large heat sink, so it has never become hot (I'd say below 30°C). I am not sure if I should try another specimen or get a refund... or try a V5, they are supposed to be more reliable, are they.
  9. Thanks for your replies. I spent many hours today to upload a recovery image onto the EspressoBin, but no success. Usually, after a few seconds, the upload stops (no error message), longest was about 30s till stop. I am not sure if this has to do with the fact, that I am using a Virtual Box Debian guest on a MacOS host, so that the serial connection might not be as perfectly timed as necessary? I have never had any problems with this and a serial connection at 115200 baud is not rocket science really (I tried lower baud rates too...). If I can't find a solution for this, the EspressoBin is going to take its way back to GlobalScale. Update: Ok VirtualBox is one part of the problem. I installed the Prolific drivers for MacOS, I compiled WtpDownload for MacOS (which went really smoothly), and *most* of the time, I can now accomplish a recovery upload. The 600_600 from 18.12v2 got me back to the Marvell>> prompt, which I really welcomed when I saw it. So I "bubt" the 600_600 u-boot and started setting the env parameters, but in the middle of that the board crashed and rebooted...! I am about to give it up. I will try once more setting the env and booting from SD, but that's the last chance I am willing to give to the V7 board...
  10. I got my EspressoBin-V7 yesterday and spent most of today to get it "stable" with Armbian. I haven't succeeded so far, although with your patch @ebin-dev, I got an uptime of almost 10 mins, which is an absolute record for now... I tried 1000-800 and 800-800-Mhz so far. I am running the Armbian provided Debian kernel on it (4.19.20). I tried what @Anders describes above and replace the kernel and dts file, but for me, it doesn't work: The kernel gets stuck at the very beginning [ 0.000000] bootconsole [uart0] enabled was the last message of boot process. Update: I just tried the flash-image-ddr4-1g-1cs-1200_750.bin and this broke u-boot completely. I will have to do a rescue with WtpDownload_linux tomorrow...
  11. This is indeed the case. Thanks for this information, the change must have crept in lately. If I had the energy I could find out which of the i2c adapters on the Olinuxino were labeled as "hdmi", but right now, since I don't need to know, I won't...
  12. I did the following upgrades this morning libcurl3:armhf (7.52.1-5+deb9u8, 7.52.1-5+deb9u9), libgd3:armhf (2.2.4-2+deb9u3, 2.2.4-2+deb9u4), armbian-config:armhf (5.72, 5.74), linux-headers-next-sunxi:armhf (5.70, 5.73), linux-image-next-sunxi:armhf (5.70, 5.73), curl:armhf (7.52.1-5+deb9u8, 7.52.1-5+deb9u9), libcurl3-gnutls:armhf (7.52.1-5+deb9u8, 7.52.1-5+deb9u9), linux-dtb-next-sunxi:armhf (5.70, 5.73), base-files:armhf (9.9+deb9u6, 9.9+deb9u7) and found my I2C bus not working anymore. I did a scan on the 4 buses (Olinuxino Micro A20) and found a device on i2c-1 instead of i2c-0, changed my settings and all worked again, so I guess one of the updates must have changed the labeling of the busses? Is this by accident or on purpuse?
  13. Ok, I get the RUN instad of PROGRAM part, but where's $DEVPATH set? This variable is nonexistent/empty on my system.
  14. Hi @lagerschaden, you're right, for each user of a specific machine, it's easy to find out. But I was thinking about a more general udev rule that could be integrated into Armbian. In that case, the path would need to be set correctly for each board and kernel or whatever the path depends on.
  15. @lagerschaden, I did the same with my Olinuxino Micro A20, and had to change one path in the udev rule: SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\ chown -R root:gpio /sys/devices/platform/soc@01c00000/1c20800.pinctrl/gpiochip0/gpio && chmod -R 770 /sys/devices/platform/soc@01c00000/1c20800.pinctrl/gpiochip0/gpio;\ '" This seems to work well, I tested with GPIO pins 1, 2, 3 and 112, 114, 116, 118. As a pure user of GPIO (and not really a programmer) I've no idea on what the path name depends, why it's sunxi-pinctrl in your case and soc@01c20800.pinctrl/gpiochip0 in my case (I am using mainline kernel).