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.

At a glance, there's no output after control passes from bootloader to kernel. I know of two things that would cause that: Kernel output is going to VGA instead of Serial (or vice/versa) Kernel does not actually start and just hangs

For 2, the haveged service is not terribly reliable on ARM architectures. There are other threads on the subject. Not sure about 1. May be a boot race condition, looking for activity on a cryptographic device that hasn't been started yet?

In that case, it looks like I misunderstood you. Apologies for that.

Looks like the offending code is HERE. Maybe better to grep for the DTB / FDT file out of /boot/armbianEnv.txt if it exists, and throw an error if it doesn't? Not sure if there's a rock solid way to determine where the DTB was loaded from. Maybe file a bug HERE, and provide the armbianmonitor log so it can be tracked?

Happy to help here and there with bash shell scripting, however I believe that @Igor and @lanefu had mentioned that the armbian-config refactor was desired in the Ansible tool, which unfortunately is not in my bag of tricks. Not sure if that's still the case, but maybe worthwhile asking @Werner nicely to update the description to include that desired experience?

Unless someone else has your exact combination of hardware and setting, or this is a known issue, no one else will be able to diagnose this issue for you. NTFS support under Linux has historically been poor. The in-kernel driver does not support safe I/O, and the userspace ntfs-3g package can be quite slow. There are many well supported filesystems (ext4, xfs, jfs, etc ..) under Linux, and this is not one of them. Samba also has it's own issues, and may need to tweaked to get better performance. I seem to remember it defaulting to the very slow SMB1 protocol in the past. Though this may have changed with newer versions. You might need to consult the documentation, or try a different remote access software such as NFS or FTP to see it's your hardware limiting your performance. You also may want to try to benchmark your drive without a filesystem via hdparm or dd, and your network via iperf, and see what your combination of hardware can do as an ideal upper limit. You can further benchmark each filesystem via iozone, bonnie++, or many other tools. Just note that USB drives are asynchronous, so writes seem quite fast initially, but quickly slow down as the internal memory buffers fill up and wait for the hardware to catch up. If you do need faster speed, you may need to invest in one of the supported boards that has a dedicated SATA port (non-USB) and is more suited for that purpose.

1 - Did you disable hardware flow control on the serial port? Minicom enables it by default, and you won't get data via 3-wire 232 serial, unless you did. 2 - Are you using the right voltage level for your serial port? They might be 3.3V, 5V, or full RS232 (8-15V) ranges.

If you can pop an SD card out and access it, easiest is to edit kernel command line via /etc/armbianEnv.txt and add "systemd.debug-shell=1", which adds a root level shell the next time you boot that you can use to reset your password over vga/keyboard. Think it's on tty12 (ctl-alt-F12) if memory serves? Might have to check. Another alternative if you have binfmt-support installed on your PC, is to chroot in to the mount point, and reset the account as root. Either way should give you a way to run "passwd <USER>" and reset the account. I would not recommend copying the OS without passwd/shadow files as user and group information is stored as numbers and those files map them to names. They are also assigned dynamically, so depending on the order you install stuff, the user and group IDs between multiple computers may differ. If you do feel like playing with fire, those password hashes are stored in /etc/shadow in a colon separated text file. The password hash (SHA hashes generally start with $6$) if removed, removes the password requirement from the account. Keep backups before touching this file. See "man shadow" for more details.

To be honest, I'm not sure what board you mean. The NanoPC-T3 is no official support (CSC), and I'm not aware of any supported Motorola CPUs. If the hardware vendor has made patches, it may be a lot of work to resolve any code changes between mainline 4.14 and their customized 4.4. Device tree formats do change over time, and may contain hacks that correspond to nonstandard kernel changes. The Armbian devs spend a lot of time resolving these differences. Cross compilers may or may not be a problem, depending on your environment. Certain versions of Linux or u-boot may require much newer compilers than you currently have. You can take a look HERE to see how Armbian manages these.

https://github.com/armbian/build All links to the original source code and all Armbian patches are in this repository. You will probably not receive help porting this work to Denx, but everything is available for your reference.