tparys

How about this? NetworkManager htop dispatcher changed to only write to one root-owned file in a read-only spot, say /etc/armbian/htoprc (or whatever) Script detects if that global file doesn't exist yet, and executes a one-shot delete/replace that updates existing user htoprc files and replaces w/ symlink to that global location User's don't have access to global directory, so can't redirect or change dispatcher script behavior Users do have access to delete the symlink and replace with whatever they'd prefer in it's place Though, reading through the posts here, the simplest solution is to delete the dispatcher script altogether, and add it via an optional package if users would still want that functionality.

As entertaining as this thread is so far, I suggested to @TCB13 to post here to get more eyes on the problem. I can confirm that enabling the overlay in question didn't do the expected thing. And "armbianmonitor -u" is here: http://ix.io/3nS8 Interestingly, the overlay seems to be disabling the spidev? fragment@4 { target = <0xffffffff>; __overlay__ { #address-cells = <0x01>; #size-cells = <0x00>; spidev { compatible = "spidev"; status = "disabled"; reg = <0x00>; spi-max-frequency = <0x989680>; }; }; }; Offhand, I'm not sure what's required to switch between multi-function pins, but figured there would be far more eyes on the problem here rather than Peer to Peer Support.

So the M4V2 is a supported board. that the SPI isn't working is probably worth a post by itself in the Rockchip 3399 Subforum. At a glance, I tried turning on the SPI on my M4V2 and didn't see any spidev devices pop up, but might need to pull out the serial console to see if u-boot is throwing any warnings about the overlay. Taking a look at the overlay, I'm not sure it looks correct, as it looks like even if it applies the SPI channel is disabled. fragment@4 { target = <0xffffffff>; __overlay__ { #address-cells = <0x01>; #size-cells = <0x00>; spidev { compatible = "spidev"; status = "disabled"; reg = <0x00>; spi-max-frequency = <0x989680>; }; }; };

If I know your username/password, if doesn't matter what the encryption key is or where it's stored. Your data is unprotected the second it boots.

Unless I've hallucinated it, Igor seemed open in the past to supporting other architectures in Armbian, provided there was someone to maintain new toolchains in the build system. But as I've seen elsewhere, the "missing ingredient is time", and such efforts would take time away from other development efforts. Though, it's not the first time ARM was relabeled to be something else ... https://en.wikipedia.org/wiki/Acorn_Computers

There might be, but offhand I don't have any experience with this tablet. Try it and see if you get further? It is possible that a GPIO might control USB power, or hold the USB PHY in reset. Chasing these issues is sometimes difficult.

If it is possible, it's a little like taping the key to your house in the lock of your front door. It will do nothing to prevent you from being hacked.

So, armbian-add-overlay adds the overlay to /boot/overlay-user, which are processed in the bootloader before the kernel starts. The process I pointed uses sysfs to actually tells the kernel to add the overlay *after* the system starts, and doesn't affect future boots.

I suppose my comment is more that it comes across as the person screwed up and the post will be locked, rather than they've not yet provided the proper information they need to get help. Perhaps it's just my impression reading the standard response.

> setting ethaddr in /boot/armbianEnv.txt does not change anything This sets a u-boot environment variable. It is up to the boot script used for your board whether or not anything is done with it. What boot script you're using is a mystery as you've not provided any information about your board (armbianmonitor -u). >same with modifying /etc/network/interfaces - no effect. Per "man 5 interfaces", the option is "hwaddress". Whether or not this takes effect is determined by what network software is running (NetworkManager or ifupdown). Given that poking NetworkManager files created a change, it's probably the former. > Just for sake of documentation: setting mac address in /etc/network/interfaces works on TwisterOS And it's probably using ifupdown. You can switch if you'd like. I bet it works on Armbian too, but you need to be running it first. $ sudo systemctl stop NetworkManager $ sudo systemctl disable NetworkManager $ sudo systemctl start networking $ sudo systemctl enable networking

I'd wager it's a DTB difference, which is telling the kernel that there's substantially different hardware than is actually there. I'd suggest starting with the provided software image. See if you can disassemble it, extract the device tree / DTB, and start looking for differences. It might be as simple as telling the kernel that there's a USB controller at address XXXX, but might need to specify resets, regulators, etc ...

Not that I've tried this debounce, but you can try to load them dynamically after boot? https://forum.armbian.com/topic/17842-dynamic-device-tree-overlays/ Unless it crashes the kernel on sight, it might dump a useful message to dmesg about what's wrong?

Would it be helpful to pin / sticky a forum post of "Why was my post marked Invalid?", and just have the standard response point to that? Have a quick run down of why posts might be marked that way, and what to correct in the post to get help? I understand why the standard response is why it is, however I've also run across end users who don't grasp why all that information is necessary, and may just come across as the forum mods being sticklers. They literally don't understand the severe boot differences that may exist between otherwise identical looking boards.

Check the AllWinner device tree bindings in the kernel documentation? https://www.kernel.org/doc/Documentation/devicetree/bindings/pinctrl/allwinner%2Csunxi-pinctrl.txt

For what it's worth, I've hit this error when trying to mount a NFS share from a Windows system (no idea how it was set up), and had to use NFS v2 for it to work.

I hate to be the pedantic one here, but full SD card encryption is not generally possible. There's typically a boot partition that contains at least the kernel, initramfs, and DTB that's typically unencrypted. I've seen ARM CPUs that have signing keys used to authenticate these files so they are resistant to modification. Perhaps that is what you're referring to? They are generally asymmetric keys, which are burned to the CPU, but work substantially differently than the symmetric keys used in LUKS. They verify authenticity, rather than provide confidentiality. (Light Reading) You would then need to verify if your root filesystem has been modified, before passing the chain of trust to secure boot. All your kernel modules would also need to be signed. You'd probably be rolling your own kernel rather than using the Armbian provided one. Note that encrypted data is only secure when the data and key are separated. The second it's keyed, you're one OpenSSH zero-day vulnerability away from losing everything that's on it. If it boots by itself, or its online all the time, you've bought yourself exactly zero security for all that work. Cryptography is an interesting, but rather deep and detail oriented subject. If you're indeed looking to do this, you'll need to do some more reading on how best to set your system up. It may be easiest to make an encrypted folder with EncFS or eCryptFS to keep your important files, and only open those when needed. A LUKS encrypted root filesystem is helpful for other use cases (eg - theft), but not when it boots by itself.

Looks like a neat setup. I was not aware that M.2 to 5x SATA device existed. But before you reinvent the wheel, have you considered that you basically made a Helios64 without the nice enclosure?

I'm not familiar with these boards at all, but I suspect there'd be some interest in getting support in the build system. Have you considered seeing trying your hand at putting a PR to make automated builds? It's not too much work.

Though common, ifconfig was unmaintained for many years. The tool you want is ip, and is overall a much more capable. # Shows IP addresses for all devices ip addr show # Removes a particular address from a given device ip addr del 192.168.1.200/24 dev eth0 This doesn't really solve why DHCP is starting up and pulling a second address for you, but can help get rid of multiple addresses once you kill it.

The package management tools "dpkg" and "apt" are part of the Debian (and Ubuntu) Linux distributions. If CoreElec does not have apt, it is not a good idea to attempt to install it after the fact. You can run into situations where different package managers do not track each others installed dependencies correctly, potentially overwrite each other's files, and possibly leave your system in a non-working state. If you want a minimal system with the armbian tools, download the armbian images, as they are already minimal Debian/Ubuntu systems with some small quality of life changes. Also due to lack of time and resources, installation of armbian packages and tools are not supported outside the core images. All source code is available, and you're welcome to try it, but will not receive effort or support.

It looks like the Armbian TV images look like they might be using 5.10.27. The hard part of updating the kernel and u-boot may be done. The remaining work is likely identifying any DTB differences between the 3.x legacy kernel and the more modern 5.10. You can always drop in the old DTB and hope for the best, but I know there have been some format changes over the years to make things more standard and consistent.

https://www.go4b.com/usa/technical-support/product-manuals/t500-hotbus/rs485-wiring-guide.pdf 485 uses differential pair as a both a send and a receive. Both pins are both input and output. There's not really an RX pin unless you convert back to 232. If you take a look at example link. You can have multiple listeners using 485 to 232 converters attached to that differential pair, and may do what you want.

@cracker, I don't think those images that @balbes150 linked to were ready to go for the Radxa Rock, but were probably intended for RK3188 TV boxes. If you tried them and they booted, that's a promising start. However, there's almost certainly substantial board differences (like your LAN), which will need to be reflected in the DTB.

Bunch of examples for sunxi chips: https://github.com/armbian/sunxi-DT-overlays Documentation on how to use them: https://docs.armbian.com/User-Guide_Allwinner_overlays/ And a decent example that does multiple DTS edits (fragments): https://github.com/armbian/sunxi-DT-overlays/blob/master/examples/gpio-button.dts Note that the first fragment selects the target edit point by phandle, where the second selects the target by DTS path.

Not that I have experience with these sensors, but looks like the general flow is this: hit the sensor with a pulse (low/high) count cycles until a response (pulseIn) As it's a microcontroller, pulseIn will probably not return until there is a response. The second call to pulseIn() probably starts counting after you're done printing the value from the first. Considering your output pulses happen within 2-10 ms of each other, I bet this happens: digitalWrite(center_Trig, LOW); digitalWrite(right_Trig, LOW); a=pulseIn(left_Echo, HIGH) / 58.00; Serial.println(a); // <- 2nd, 3rd echos arrive here b=pulseIn(center_Echo, HIGH) / 58.00; // <- timeout Serial.println(b); c=pulseIn(right_Echo, HIGH) / 58.00; // <- timeout Serial.println(c); Maybe pulse the second sensor after you're done reading the return from the first? Then the third when the second is done?