znoxx

Members
  • Content Count

    87
  • Joined

  • Last visited

About znoxx

  • Rank
    Advanced Member

Recent Profile Visitors

868 profile views
  1. Well, my "demand" is quite exotic. Not so many people use wifi dongle inside LXC container. Not sure one should invest his own time into _such_ investigation. Regarding the speed - container runs "TorBox" (http://tbng.ml), and TOR does not give you super-fast connection. But well, indeed it's time for upgrade to something more 2019 related.
  2. Igor, thanks for confirmation. Looks like pure driver issue. I put good old ralink 5370. Works like charm and my macos started to connect to AP, instead of password loop on Realtek 8188EU. One small thing, not indeed rockchip related - diode on ralink usb wifi does not blink =). Bad thing - my heap of unused Realtek 8188eu adapters just got bigger.
  3. Hi all. Need help. Updated today from 4.4.180 -> 4.4.182 Now getting permanent problem with bypassing network interface to LXC container (worked flawlessly on 4.4.180). sudo lxc-device -n tbng add wlx0092d00ddb46 command failed: Operation not supported (-95) lxc-device: tbng: tools/lxc_device.c: main: 172 Failed to add wlx0092d00ddb46 to tbng Same for trying to pass phy0 to network namespace zno@armbox:~/_working_kernel$ sudo iw phy phy0 set netns 7094 command failed: Operation not supported (-95) I will definately try with another non-realtek dongle, since I see only one difference - driver in dmesg has prefix RTW for debug messages. Previously it was 8188 or RT8188 (not sure). Thanks in advance for your help.
  4. Yet another answer to myself. According to this (valued opinion of @tkaiser) - USB3@ARM SBC + USB3 Hub is totally bad idea: https://forum.openmediavault.org/index.php/Thread/24145-OMV-rock64-problem-with-USB-Hub/ Still yet another problem with USB2. Both ports works ok with directly connected devices. Attaching usb2 hub to lower USB - still ok. To upper USB - gives a lot of errors in dmesg with periodic device reset. Actually attaching usb voltmeter to hub showed BIG undervoltage (4.4v). Powering USB hub partially resolves situation, but still errors if using upper port. Older usb hubs (let's say before-AliExpress-era) work slightly better. In my opinion, it's not a problem of kernel, but hardware itself. Situation is much more clear now. I need to connect 2 HDD drives (one for system + one for data). Time to give up SSD idea, since my box ( 8882:009d http://en.sharkoon.com/product/1686/10066) does not pass "TRIM" command, which is probably vital for SSD.
  5. Update... It was guilty USB3 hub. I'm willing to have more than one USB3 port on rock64, but look... Hub works fine on standart PC, but adding it to Rock64 gives this weird effect. Can anyone confirm, that USB3 HUB is not recommended to use for connecting boot USB3 SSD ? It's not a question of power - I'm using good PSU. And drive is SSD (consumes not too much). Thanks in advance.
  6. Hi all! I'm having strange issue with Rock64. I downloaded latest Armbian 5.88 with 4.4.180 kernel. Installation and boot are ok, but when I try to do apt-get install lvm2 Package installs, configures and... update-initramfs: Generating /boot/initrd.img-4.4.180-rockchip64 update-initramfs: Converting to u-boot format Then I do root@rock64:~# sudo reboot And I'm getting a boot loop... Same effect, if I move system to SSD. At first I thought it was issue with ssd transferred system... But it clearly reproduced on freshly written with uSD only boot. I've dumped armbianmonitor output (just in case) on freshly flashed OS. MicroSD is old 2GB one (I'm planning to use SSD drive and use uSD only for boot). But same effect on other cards. Another one issue (which I probably can live with, but you may find this interesting). I install hostapd-rt along with using rtl8188eu dongle. Hostapd starts, but here are two points: Everything works with android It fails to authenticate with MacOS... But weirdest thing here - when I stop hostapd with systemctl, then start - it shows "Oops, SMP error" and reboots. Still not sure about revision (not v3 definately Thanks in advance for looking into it.
  7. Oh. My. God. Thanks...
  8. Igor, thanks for your prompt reply :). I think I will not rush a transition for new hardware, however I will try to simulate load and perform similar tasks, which I do on Cubieboard2. Thanks again for a caution. Anyway, any tips for heatsink size ? =) Does this one look applicable ? http://znoxx.me/shop/data/uploads/images/products/heatsinkpi.jpg size is like 16mm X 20 mm x 16 mm, aluminium
  9. Igor, thanks for reply. I see in download section "legacy kernel 4.4.y" -- marked as stable and supported. And I guess you are talking about 4.17+ regarding "mainline". I will start with 4.4 anyway, hope it has docker support... One thing which confuses me a LOT: "Rock64 V3 is not supported". If I booted, installed system to USB hdd (ssd)... Does it mean I'm not on V3 version ? Cannot find any description of V3 vs not-a-v3.
  10. Hi all. In download section i do see "large heatsink required" for Rock64. Can anyone post any links to eamples of good heatsink with proper size ? I will be migrating "home server" from Cubieboard2 to Rock64 and chasing long-term stable operation. When board just booted and "does nothing", cpu remains pretty cool. However i'd better be prepared. thanks in advance for tips.
  11. First of all, thanks for sharing your opinions. My shortlist is: 1) Odroid HC-1 - due to known stability 2) Rock64 - it has USB3 on board and recently I purchased USB3 dock for 2 drives. Works nice, uas supported, but no trim. So idea was to connect 2 drives -ssd for system and rotational for data, but looks like trim support is not for me. That's not good, but, well. Nothing stops me for rotational drive for system. Or leave system on _good_ _expensive_ microSD, or make the "read only root", which is promising, but I guess kernel updates will suffer while changing "/boot" data. 3) Orange Pi Prime. Good for it's price, has wifi onboard (hope it supports host mode for hostapd in latest kernel), but no USB 3.0. (2) and (3) are 64bit I guess. Not sure I do have 64 bit tasks (e.g. Apache/nginx large file upload), but still good to have. Also I'm quite sure they both consume less power then HC1. The case is not electricity bill, but requirements for PSU. I run my "rig" from 10A 5V psu, which powers cubie, usb hub, couple of orange pi's (pc2 and pc) without any issues. Probably HC-1 will be ok with this setup also. Personally I really like coming Allwinner H6 boards. They are colder on same Mhz's, but Armbian is in testing stage for them and quite far from stable version.
  12. Thanks a lot for clarification. Looks like shipping it from reseller in USA will be much cheaper than from official Korean store. Will think about it one more time =) Waiting for more opinions
  13. One point still here - about "not too power hungry". What about consumption ? It requires quite solid PSU as far as I see. Does it really consumes 3 amperes ?
  14. Hi all! I'm happily using Armbian on Cubieboard2 working as home server (samba, 4(!) LXC containers with Deluge, tor, owncloud and some other small apps) + VPN client. Pretty happy with it, especially for internal SATA. Recently found that Cubietech releases Cubieboard6 on S-500 CPU with same form-factor and SATA. That means, that all casing/housing can stay intact. LXC containers also can be migrated since CPU is still ARMv7. But at the same time found somewhere on this forum, that board is not really good quality... Cannot argue or agree with this since I don't have a board and it looks costly. So my question - what is advised for home server like my one described above ? Main requirements are: 2Gb RAM, Armbian full support, not-too-power-hungry. Still not sure about SATA -- it's really handy, but USB drive with UAS support speeds are comparable I guess ? Also thought about Odroid HC-1, but is it worth it's price ? What is on your mind ?
  15. I've already tried on my "probaly fried" OpiPC2 described earlier. It works. And it's funny. Since my temperature is about 80C due to h/w fault - Opi is throttled to 120Mhz permanently . Atmega MCU can even compete with this. Anyway, workaround works. Not sure it will survive kernel update via apt (in case it won't be included into).