• Content Count

  • Joined

  • Last visited

About malvcr

  • Rank
    Elite member

Recent Profile Visitors

1107 profile views
  1. I am not sure for current versions, but the R2 has a very annoying problem without a clear solution (just some dangerous hacks that I am not very happy to apply). Could be possible to have a different method to power up/power down and to reset the machine? I don't know, maybe some pin headers where be able to add some buttons or something like that. And to have the possibility for power up by default when needed instead of having it off when providing electricity (this last convenient when creating routers or similar networking stuff where the R2 looks promising). In
  2. About the g_ether / g_serial issue. The g_ether it is a very nice option. No networking infrastructure, just a good quality USB data cable ... and you obtain more than fast ethernet throughput. When using g_serial it is very slow (obviously they have different purposes). As you can see in my machine, there are several SBC making a tiny private network. Having g_ether working correctly it is very useful in such scenarios. Anyway, I already have the standard networking equipment there. Maybe in another setup I could try g_ether again, but with latest kerne
  3. Hi Martin I really prefer the clear and simple things. The GUI tools hide many things and this makes me to be worried about the final results. You know, a tiny detail and then I let a hacker to play with my stuff. I used the Armbian TUI just to check where the things were located, but then I modified the configuration files directly to understand them better. Maybe the big problem with all this (just a comment for not to be far from the R2 context) is that there is no "network framework" to justify any of the tools. They are just incomplete. For example,
  4. Hi Guidol ... I have been doing a loooot of things as the ones you are describing for years by now. However, things are becoming more complex and the solutions are not so crystal clear anymore. When working them with the OPI-Zero, latest Armbian version (no problem in legacy ones), to remove the network managers resulted in so unstable environment that I was forced to reinstall the OS. And ... as Armbian is oriented to NetworkManager, I preferred to learn how to work it. About the R2, what happens is that it is a "work in progress" unsupported device. So
  5. This is a picture with an R2 located in a RACK assembly. The set has an Orange Pi Zero as a "communication/firewall device", together with a Banana Pi M2+ as the Application Server and the Banana Pi R2 (v1) as a Database/NFS/ClamAV server. I am configuring a Moodle on the machine. As a recommendation from TKaiser in a previous post, the R2 it is managing two 2TB hard disks with BTRFS and not RAID1 (really it is smoother and easier to configure than a software RAID). The disks power it is provided directly by the 430W power supply (not the R2 power connect
  6. There are many changes between 4.14 and 4.19 ... in particular with the mt7530 driver. And I saw the tread about the "trick" to make the second interface go up These days (a little each time, as I am a little busy), let me check how
  7. Understood ... then we must make everything to work ... ... When I have a chance, let me check the differences between DSA in 4.14 and 4.19. I have been reading the code but it is not so easy to catch what is not working.
  8. About the mt7623 I know that the DSA requires some extra work. However, this could be done in stages. 1) As it is now, no secondary networking element (this is just a 4 core machine with 2 gb RAM) 2) As the original 4.4.70 BPI kernel. WAN in one side and everybody else in the OTHER one (as a switch) 3) Full DSA with the capacity to separate all 4 ports in the CPU interface and full routing capacity in all 5 ports. 4) Everything and WIFI. 5) USB-OTG networking 6) Whatever the user connect in the PCI port.
  9. Hi ... I must be sincere. Network Manager have been extremely unstable for me when dealing with complex networking configurations. The problems appear because it seems wrong to configure "by hand" things while the NM it is working. Basically, NM doesn't pay attention to your manual definitions (/etc/network/interfaces file) and decides to change things dynamically, breaking your own definitions in any moment. And for that there are only two solutions: Don't do anything by hand (use everything as NM dictates it) ... "this is something I need to learn carefully how to do we
  10. Hi people ... I was trying the nand-sata-install in one of my R2 1.1 ... It seems to work, but I lost my serial console. I was figuring what could be the problem, if the R2 was bricked or something. But just the serial doesn't work anymore (could be an unrelated issue, but it is important to indicate it). So, I supposed it really didn't work ... then I attached an ethernet cable to one of the bridged ports and located the DHCP assigned address to connect there using SSH. It is working from the emmc so the process really it is writing the OS there and the R2 boots wi
  11. There is something strange with the R2 1.1 version (tomorrow I will check with more care, even with a 1.2 one). For checking this I updated the source code and produced a fresh image. Just boot the image and when checking I noticed that the MAC addresses are someway mixed. wan, eth0, lan0, lan1, lan2, lan3 ... all them share the same address. Then, the br0 (bridge?) has the other address. For this type of machines, it is supposed that the "wan" port it is the one is isolated, while the lan ones are the ones sharing the MAC address (this is some type of rou
  12. Let me try ... I have 1.1 and 1.2 version boards. I will check both.
  13. Let me see ... 1) New way ... no NAND support. 2) Priorities ... SD first (if available) others, on demand. Maybe calling "sub-scripts" if extra/different functionality it is required. 3) Normal ... same file system, just raw copy to final storage. As option, and for special cases, new file system rsync or similar. 4) boot partition must work always, although, the particular model can change (now u-boot, later other methods) ... this means, boot must be also a sub-script that can be easily replaced or updated as required. About "extra", "exotic" thing
  14. Thinking on a layered configuration. What could be an Armbian core? ... Maybe basic kernel with file systems and networking? How difficult is to bring only this up on all known machines? How to do it with unknown machines? Is mainline safe enough to play on new devices? The store systems (SATA, SD, EMMC ... etc ... ) must be here, together with the capacity of moving the OS to these types of store. I need hardware cryptography support, but not everybody needs that. The most of the people can have a happy life with software based cryptography. The same goes on with
  15. This thread seems important on this theme ...