malvcr

Members
  • Content Count

    106
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by malvcr

  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 the RACK case from above, I was forced to let the side with buttons near the back border and later I added a plaque with a hole to be able to power up the machine with my fingers ... I am working the machine by myself, but it is complicated to assemble a customer's solution with the current behavior ( press 7 seconds on so small button and to wait for the green light to be continuously on for two seconds ). In fact ... I think that this type of hardware extensions could be useful for any other future SBC. Just think ... some pins for power, reset, power led and hard disk led ...
  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 kernels.
  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, if I like to create a NAT fortified Router/Firewall, I can't depend on NetworkManager alone and I need to tweak here and there with some iptables rules, some systemctl modifications and to cross my fingers expecting that everything be OK. And when you check on the Internet, there is a big salad of options, many of them "mixing" incompatible things to have a result. Would be wonderful to have a tool where I just describe in almost plain english what I expect. Something like this (light idea, being tired at 11:23 p.m.). eth0 = iface( --ipaddress/netmask:gateway-- ) eth1 = iface( --ipaddress/netmask:gateway-- ) eth2 = iface( --ipaddress/netmask:gateway-- ) public = alias(eth0) dmz = alias(eth1) lan = alias(eth2) webserver = address(10.x.x.x) database = address(192.168.y.z) forward port 80 from public to dmz(webserver) open port 3610 from dmz(webserver) to lan(database) route lan to public(any port) close any other port from public to dmz close any port from public to lan close any other port from dmz to lan Everything together, without surprises. All details covered by the tool. Who knows, maybe I work that some day :-)
  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 you have no guarantees about what could happen if you break something. Also, it is more complex that other machines because it has an exotic networking equipment... in those cases, when it works it is better not to try strange things on it unless it is laboratory hardware (I have other machines for that). The specified instructions work for standard Ubuntu on a very regular machine, but not necessarily will work perfectly in a constrained SBC computer where the OS has been fine-tuned to perform well. --- I would prefer if Armbian let me "choose" what networking method I like to use, and in an orderly way disables all other ones. However, I understand that such thing would involve a lot of work and it is not a priority.
  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 connectors) ... I know this is as a 12 cylinder engine in a Beetle :-) ... The enclosure has 3 fan, so no machine arrive to 50C degrees. It can be improved. There are details, but in the future things will be better. In this moment only the power led it is attached to something, and the Power Supply has a wire in the CPU connector to "simulate" something there (if not, the Power Supply will not work). The machines are located in a presentation cardboard piece painted with temperature resistance silver paint, as no screw post in the enclosure match the SBC machines holes. They are suspended on the board with metal posts. One if my "nightmares" with this machine has been the internal networking. Basically the old style ifup-ifdown doesn't work. Armbian it is a complex thing because it keeps the ifup-ifdown together with the NetworkManager and the SystemD.NetworkD, all at the same time. So, sometimes you do something but it doesn't work because "the other guy" works against you and you really have no idea what it is happening, and things go wild when working three machines at the same time. At the end, The M2+ and the Zero were configured with NetworkManager and the R2 with SystemD.NetworkD ... in this respect, they are not compatible in the Armbian setup methodology. -- The Zero and the M2+ take their power from the R2 (later I will use the Power Supply directly). I remember when having the legacy 3 kernels and the zero was possible to use the USB cables for networking with the g_ether module. But I never was able to do this to work well with the 4 series kernels. In fact, now Armbian comes loaded with the g_serial instead. Could be interesting to recover that functionality, as this could reduce the complexity with this type of machine combinations. By now, I am relying in the old friend RG45.
  6. There are many changes between 4.14 and 4.19 ... in particular with the mt7530 driver. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/drivers/net/dsa/mt7530.h?id2=v4.14.81&id=v4.19.2 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/drivers/net/dsa/mt7530.c?id2=v4.14.81&id=v4.19.2 And I saw the tread about the "trick" to make the second interface go up http://forum.banana-pi.org/t/missing-nics-eth2-eth4/4571/15 These days (a little each time, as I am a little busy), let me check how the patch can live with the other changes, to see if it can be applied. Also, as I understand on the BPI forum, that patch can't go to mainline because it is not an official change from the main DSA maintainers that are looking for that type of functionality in the DSA future improvements.
  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 well". Purge NM, as it can't be 100% disabled (why? ... I really don't know ... you disable it and one or two reboots later it is alive again). NM was designed to deal with complex networking scenarios where things can change. However, it depends how you design your routers and what is their purpose. In a big quantity of opportunities for servers or IoT, you live in a 100% static scenario where NM it is just an extremely complex piece of software for a very easy task. Maybe ... and this is just an opinion ... when installing, could be better to let the user to choose what option to use and not to include the other options in the running environment.
  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 without the SD. However, there are differences between 1.1 and 1.2 that must be taken into consideration. In the 1.1 version, there is no switch to choose between emmc or sd; instead there is a connector for a battery. As this is not a very supported bring-up effort, my recommendation it is to forget the 1.1 version. I have it because I was an early adopter, but the second time I purchased cards I received already 1.2 version cards. I am not really aware of what other hidden differences could be between 1.1 and 1.2. My feeling is that will have more headaches in the trip. I will use my 1.1 cards for laboratory and mechanical construction (design and test cases), not for production. And I can do crazy things on the configuration if needed for my specific cases; just that I won't use that version for production or to provide systems to my customers. It is a little risky. -- Frank has a nice 4.14 kernel. It works well and can be used for routing needs. I fully understand about applying minimum things on the Armbian case, as the distribution it is used by a lot of people with many different hardware options. I think that both efforts are important because they will help to understand more machines based on this particular type of SoC. I am still grasping my head with the DSA thing, to see how I can help there, and checking about a modular installation method. And this is Linux, a lot of people helping here and there :-)
  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 router machine). So, the wan port must have a different address than the lanX ports.
  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" things as hardware cryptography, as them must be worked in a detailed particular (non generic) way, a chapter for each configuration and customization in the online documentation seems to be enough. The normal method will not use that capacity but a well tested methodology must be available (and the forum it is just a light unstructured reference). To bring-up a new machine, that work it is not required and could be available "later" if it is possible to do so. In the menu case, the interactive method must be the "default", but also some type of "batch" must be available. Could be possible to install from an image but also to re-create the image from an existing installation. Sometimes it is necessary to install many similar machines as pre-configured images.
  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 GPIO and some specialized ports. HDMI it is not needed everywhere. Although the R2 has an HDMI port, seldom people will use that machine with a monitor. Several Zero - Level devices lack of a video port because their focus it is not to have a desktop. The same happens with LCD, even with cameras. A NAS and many headless systems don't need many of these elements and can work with a web based setup (as openmediavault, mediawiki or openkm do). And, of course, there is the "desktop", although with the small machines seems to be a specialized desktop because they are not powerful enough to do "everything" a current standard PC usually do. My point is that maybe it is better to figure how the machines could be used instead of trying to resolve 100% problems at once. The comment about HDMI in the R2 Armbian unsupported page it is right; maybe the HDMI never will work well, because really, almost nobody needs an HDMI port in a router, bridge or these types of machines.
  15. This thread seems important on this theme ...
  16. I recommend to have one of two "extra" cables. I have some purchased directly from sinovoip (not their online shop) ... and one of them was defective in a RAID configuration, making the RAID to fail erratically. This gave me a lot of headaches for several weeks, making me to doubt about several things that were not in fault (this happens when you are not sure about many things at the same time) ... sometimes, the problems are not in the complex area but they are derived from simple things.
  17. I think that the R2 it is a good machine. It is not the fastest, doesn't have the maximum RAM, could have some compromises the way the use the SoC data lines, but in general has enough good points to make it attractive for some usages that would need a lot of extra stuff, wiring or similar problems. Right now I don't have my data at hand, but the other alternatives had some negative elements when checking them that the R2 doesn't have (I made my homework). Also, Mediatek it is an important SoC producer. This is similar to Qualcomm, why there is no Armbian for Qualcomm? ... there must be reasons, one of them is the limited time to work on a voluntary basis, but both are important and will continue being important in the future. In fact, from my perspective, the R2 works better than the OPI Zero 2+ H5, even having a semi unknown Mediatek SoC vs an H5. And yes, the mainline it is becoming better on this area, together with some individuals hard work here and there. -- A theme on a different thread it is about the installation process. There are particular wired elements in some points that make difficult (or more work intensive) to deal with new SBCs. But something must be taken into consideration is that this area it is not just limited to Xunlong, Sinovoip or a hand of particular producers ... these machines are becoming very important and they are taking new novel areas in the computing landscape, so it is important to pay attention to other options. If we can improve/generalize the installation process and other bring-up details, could be possible to add even completely unknown specimens to the distribution world. Armbian it is wonderful. I am very happy that I can use it to resolve many different working scenarios. But the Linux success it is based on the fact that everything can be improved. In fact, the R2 exercise it is important for me because I can use the machine in real world problems, but also because I can check, "first hand", how Armbian bring-up process work. Will this be easy or not? .... I really don't know, but hard problems are usually the most rewarding ones, and permit you to have a deeper understanding on some gray areas.
  18. AF_ALG has some CPU bounded limitations, because there is a big quantity of sequential operations must be performed before asking the "engine" to work each block. Each time, it is important to fill a control block, to program the "socket" and to provide the IV (Interference Vector), something that usually you only do once when working with software encryption. So, before 256 bit size, the overhead it is just too much to use AF_ALG. Let me try something with my own software to encrypt and decrypt some data with different block sizes to compare numbers. In fact, the problem with openssl is that you can's specify different block sizes when asking for encryption and decryption, so the testing numbers are just "evidence" but without any usage. You can define different "buffer size", but that it is a different thing. The problem with Cryptodev is that it is not an official kernel component (as AF_ALG). But this is what we have on Linux. Maybe a basic and clean encryption library capable of working directly with the hardware could be a better solution, but usually they are very cryptic. You need some time to figure what is the right way to use them; this happens not only with AF_ALG (with a terribly confusing documentation), but also with Cryptodev, Botan, Openssl .. what I do is to fight once and then to create my own standard interface. Then, I just provide the parameters and things work. Let me check this part carefully. It is important, because with the R2 and Sinovoip kernel the AF_ALG didn't work as expected. The ciphered material was undecipherable (so, something was wrong). In that case I was forced to work with software encryption. Then, here, there are two things to do: 1) To verify that it works and that it is compatible with any other AES implementation. 2) To check what effect the configuration can have in the algorithm speed. This is important for me ... thanks for the extra test. When I have something about this I will provide some feedback. Anyway, let me try my own test also in an H2+ CPU ... it is supposed to work well there.
  19. Understood ... in fact, several times and with different machines, even disabling the NetworkManager, it recovers itself (I really don't know why; could be a hidden dependency in some place) ... my only trustworthy solution has been to erase it completely (purge). So ... no NM around, not even program files neither configuration, just /etc/network/interfaces and a clear easy life. Could be NM an "optional" feature instead of the standard one? In fact, when having small machines with not so small tasks (enough for them but without a lot of extra margin), having useless services running has no sense. Another option could be to have a "canonical" option without any of these services around, more suited to IoT environments. What do you think? ... right now I will configure a basic OPIZ without NM; the easiest method is to open the image and to edit /etc/network/interfaces before the first boot ... then to purge NM :-) ...
  20. Usually, when I configure SBC devices (in particular headless as the OPI Zero), what I do is to disable NetworkManager (even uninstalling it) and to provide a basic standard configuration on /etc/network/interfaces. However, I am noticing that the NetworkManager it is becoming more and more interleaved on the standard Linux configuration (as it is happening with systemd). In fact, my thought is that NetworkManager it is more a desktop thing than a server one. My question is: What is the right method to configure static servers, having unmovable IP addresses, routes and these types of things, with current and future Armbian releases? If it is necessary to live with NetworkManager, then I must work it correctly for not having it destroying my intentions with the machines; but if the right way is to discard it, could be nice to have a "standard" method to do so. Thanks
  21. First. Thanks for so great work in the ARMBIAN community. Any word of gratitude will not be enough. I have been installing Linux on different SBC. Some of them are supported by ARMBIAN, others not. There are some that never will be supported (as the Parallella 16). And the ARMBIAN process it is very clean for the already refined machines. However, when trying to bring up some other machine, it is complicated to understand what to do, how and where, as the process have been evolving for a long period of time. Recently I began to work with @chwe on the BPI-R2, and my first job is to make the nand-sata-install to work. So, I prepared an image to check this, to study the internal parts of the script and what is the purpose of it. For my surprise, the script do several things, but it seems to accumulate also old stuff, maybe about previous ways to do certain things. How to work this without breaking something else? There, I realized how important is the /etc/armbian-release file, but also the /usr/lib/nand-sata-install directory (for all possible cards, as the ones are not a10 or a20 receive the a20 treatment). And there is also the /usr/lib/u-boot directory with some operations that could be used in ... I suppose u-boot ..., although I am not sure in what way, as u-boot it is the first thing to run in the machine. As a "reader", my perspective is that the vital system information it is not well organized. At least it doesn't follow a unified standard, and carry the possibility of side effects as some elements could be located in not well known places. I still need to make a catalog for all possible system parameter sources, and I figure that I will find some redundant elements in some place. And redundancy it is not only about saving resources, but about breaking something when not following a referential methodology where any change must be system wide (i.e. universal). Maybe ... and this is the reason for the discussion ... it is important to create a unified system information backbone where all processes in the system can obtain trustworthy information to work with (/proc only works with the kernel stuff). This could also reduce the complexity of the different processes, as it could provide reusability of some information gathering functions (instead of repeating them in different scripts and or programs). To install a system in a disk looks similar to reconfigure it in an already installed place or even to query how it have been installed. What is the opinion of people here? There are related discussions but they seems to be a little lost in time. I am not really interested in the historical solutions (this can be written in some book), but in the actual problems and how to resolve them correctly. There is a related thread about naming, although this one is about operating. Thanks
  22. Nop ... check /usr/sbin/nand-sata-install.sh Line 19: [ -f /etc/default/openmediavault ] && echo '/srv/*' >>"${EX_LIST}" Line 290 That's the main nand-sata-install file without any OMV there. I don't think this is an example as it is an integral part of the script. I agree 100% with you in that major changes on these scripts can't be part of a bring up a particular machine. Yes, it has no sense to increase complexity on an already complex work. Let me see ... my original plan was minimal changes. I will work that way for R2, but I will also include the suggestions as a github issue. There is an extra option. After these two steps, I can develop a different nand-sata-install system "around" the Armbian base (without changing the already existing one). If the community thinks it could be useful, it will be there. In general the worst thing I could do is to promote another "systemd" psychosis .
  23. I have been reading the script to write on the disk ... It really looks as a mixture of attempts. For example, you have references to A10, A13, A20 and particular directories for them with some data, but the rk3328 it is wired in the script. Also, why the openmediavault it is there? I know some people at Armbian are very involved on that nice product, but openmediavault it is not Armbian and not always Armbian will be used to install an openmediavault product. The script it is also difficult to follow because of all the wizardry on obtaining bits of information to define what to do and how to do it (in this moment not, but in my future proposal I will deal with this). From my point of view, the right method is to let different parameter files (as was done with A10, A13 or A20), but depending on /etc/armbian-release LINUXFAMILY varible and, without any particular reference to any type of card or SOC inside the script. Then, the script only would have the generic stuff and every address or particular direction would be in these parameter files. Then there is the openmediavault. That thing must be out of the script ... maybe within "optional" things that could or not be executed depending if they exist or not. If you have openmediavault, then you add your sub-scripts, but if you don't have it, why to deal with that? The last thing is about the static list for running services. In my particular case, my first R2 it is not running these but other services, so that script it is useless. The running services must be requested to the operating system, they can't be statically specified. Maybe using lsof or something similar, let me check it ( if this becomes very complicated in the script, I can write some C or C++ tool for that). -- Before making this to run with the R2, let me order it a little. I don't like to work in a mine-field ;-) ...
  24. Ready, R2 image built ... this night I will check the image to see how it works. By now, I will check the discussion about the writing to internal storage. Also, before providing any changes, I will triple check. I know your work it is very important :-)
  25. A question ... after installing and running thee script for compilation, I must choose a machine ... but the R2 it is not there. Did I make a mistake or do I need to follow something special here? ( I suppose I forgot some parameter somewhere ). -- by the way, I have a beautiful Parallella 16 that I wanted to use for neural network processing. After the R2 I could try it to see how far it is from a normal Armbian distribution. (p.s. I know the P16 was discarded early by somebody in Armbian, although it is a very interesting device)