tparys

Serial port devices starting with tty are often times are owned by root, but group dialout. If that's the case, the easiest is to add your user to the dialout group. Should be something along the lines of (but check "man usermod" before running it): $ sudo usermod -aG dialout <USERNAME> If the device is user and group root, you'll need to write a udev rule to set permissions when the kernel registers the device. Some brief reading material: https://stackoverflow.com/questions/14291431/change-ttyusb-permissions-using-udev#14292077 https://www.linuxquestions.org/questions/slackware-14/udev-rules-and-ttys0-device-644237/ Short version is that there's a few udev/rules.d directories, and you'll need to make a new rule file to match your KERNEL ttyAML0 device, and either assign ownership to your user, change group to dialout, or just make it world writable.

If the sysfs pwm device is showing up, I'm not following why you'd need libmraa to access it? If you'd like to have fewer moving parts, you should be able to do this entirely via DTB. I posted something similar for the fan on the NanoPI M4 metal case. https://forum.armbian.com/topic/17022-automatic-kernel-control-of-nanopi-m4-m4v2-metal-case-fan/ It was based on some earlier work the Kobol guys did for one of their NAS systems. You basically define the PWM as a fan control, give it a few operating levels, and tell the kernel that it's a cooling device for the CPUs. I also learned that depending on the PWM frequency, it can also create audible tones, which may or may not be desirable. You can also have it play music too, should you be so entertained ... https://forum.armbian.com/topic/19050-playing-with-a-fan-on-an-nanopi-m4v2/

1. Identify which drivers you want to block # For PCI devices $ lspci -k # For USB devices $ usb-devices 2. Verify you can actually block them $ lsmod | grep <module name> 3. Add them to /etc/modules.d as blacklisted. See "man modprobe.d", and scroll down to "blacklist" or see /etc/modprobe.d for examples 4. You'll probably want to update your initramfs and reboot. $ sudo update-initramfs -u -k $(uname -r) 5. If your board uses uInitrd, you may need to re-run mkimage on it. (Don't have a C4 here in front of me) Also note that if for some reason the module is built-in, you'll need to rebuild without that driver, or as a module that can be blacklisted.

I hate to be the pedantic one here, but with cryptography, minor differences are very important. Root filesystem encryption is possible. Full disk encryption is generally *not* possible with Armbian (or ARM SBC's in general). So, technical issue that this doesn't exist. The problem is that software based cryptography, the system must be able to load the software before it can decrypt anything else. Your boot partition is generally unencrypted, which can be a major issue. Actual Full Disk Encrption uses special drives that can play magic tricks such as multiple boot sectors and modification-resistant boot images. Most ARM SBCs will not boot from these drives. You might be able to do it with the EspressoBin, as it can boot directly off SATA. But I think @Igor and the team have some broken glass they'd rather eat.

Interesting. Another option that I use commonly is to disassemble .dtb files into .dts, and then use "meld" to find (and merge) differences between files.

Depending on how different the u-boot sources are, the patches may or may not work. You can always make those changes by hand to create a new set of patches, but might be some work. Unfortunately, if it were simple, Armbian would not be dropping support for some boards.

The -c was there before. It's yelling about the extra file on the end which isn't a .sha file ... https://github.com/armbian/documentation/pull/160

Looks like you're passing both the checksum file and the image file to " shasum -c ". The checksum file looks to be loading correctly, but obviously the image file is not a text file with checksums, so it's failing. Maybe just call it like this? shasum -a 256 -c Armbian_21.08.1_Orangepipcplus_buster_current_5.10.60.img.xz.sha

My understanding is that the overlayfs package is provided by the Ubuntu upstream packages, and is not part of the Debian repositories. Armbian does not provide or directly support this software package. It's likely that with some minor work, it would be compatible with the base Debian image, however is out of scope of the Armbian project.

At a glance, overlays are "patches" to the kernel Device Tree, which tells the kernel what hardware is available. For example, it's helpful to do these sorts of things: Select the intended purpose of a multifunction pin on a ARM SoC Tell the kernel to use a PWM output as a fan, and how to use it to cool the system Tell the kernel to load an RTC device on an I2C bus, not native to the board In this case, those are probably activating kernel support for the devices present in your Cloudshell. USB is plug and play. I2C and SPI are not. So if you're curious what the other overlays are, decompile them with dtc. The man pages will tell you how to use it.

Perhaps the documentation is useful? https://docs.armbian.com/User-Guide_Allwinner_overlays/

First hit on Google for "reset password chroot". Come on. https://dzone.com/articles/uncommon-usages-of-chroot-password-resetting You don't need to touch the bootloader.

The bash PS1 variable (see man bash) may also be worthwhile looking into. You should be able to control how many directories are shown in the prompt, or even put them on the previous line, so you have more room to type commands.

Maybe better to use scp to remotely copy an existing file to another system?

The "softy" application is just a script. Open it up with a text editor to see what it is doing. The source is online HERE.