• Posts

  • Joined

  • Last visited

 Content Type 


Member Map




Everything posted by tparys

  1. 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
  2. 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.
  3. tparys


    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.
  4. tparys


    Perhaps the documentation is useful?
  5. First hit on Google for "reset password chroot". Come on. You don't need to touch the bootloader.
  6. 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.
  7. Maybe better to use scp to remotely copy an existing file to another system?
  8. 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.
  9. 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
  10. 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?
  11. In that case, it looks like I misunderstood you. Apologies for that.
  12. 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?
  13. 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?
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. Another option is to hack libc6, and just straight up remove that check. You won't be running a signed package, but you should be able to install the package, regardless of your kernel version. ~ $ mkdir -p work/libc-hack/DEBIAN ~ $ cd work work $ apt-get download libc6 work $ dpkg -x libc6_2.31-0ubuntu9.2_arm64.deb libc-hack work $ dpkg -e libc6_2.31-0ubuntu9.2_arm64.deb libc-hack/DEBIAN < open up unpack/DEBIAN/preinst with a text editor and remove/comment that "exit 1" (line ~149), save > work $ fakeroot dpkg-deb --build libc-hack dpkg-deb: building package 'libc6' in 'libc-hack.deb'. work $ sudo dpkg -i libc-hack.deb The most correct fix is renumber the kernel version with the last number 255 or less. But unless it starts using debian epoch numbering (ie - 1:linux-image-4.9.XX), upgrading from 4.9.280 without the last number going above 255 is going to be hard. It's kind of a kernel bug, but really a glibc problem. Ultimately, it's Armbian kernel problem, falling on whomever is maintaining that kernel version, and how they want to best tackle that problem.
  20. Ooooh, that's a good problem ... So this apparently the part of the pre-install script that's killing your update. Which is as a result of glibc storing part of the Linux kernel via unsafe assumptions as part of kernel version comparison code. if [ "$system" = "Linux" ] then # Test to make sure z < 255, in x.y.z-n form of kernel version # Also make sure we don't trip on x.y.zFOO-n form kernel_rev=$(uname -r | sed 's/\([0-9]*\.\)\{1,2\}\([0-9]*\)\(.*\)/\2/') if [ "$kernel_rev" -ge 255 ] then echo "ERROR: Your kernel version indicates a revision number" echo "of 255 or greater. Glibc has a number of built in" echo "assumptions that this revision number is less than 255." echo "If you\'ve built your own kernel, please make sure that any" echo "custom version numbers are appended to the upstream" echo "kernel number with a dash or some other delimiter." echo exit 1 fi Presumably, this script is only run on update of the libc6 package. You might be able to downgrade your kernel from 4.9.280 to 4.9.255, reboot, and then resume your update? Another person suggested a slightly more hacky approach HERE, but apparently this issue has been known for some time. Also looks like the patch level is being deliberately applied via build system. Might be worth submitting a bug report? Perhaps @Igor knows more here?
  21. > mxq pro 4k 5g Not one of the listed supported boards. So wrong forum. You might find more help HERE. Logs from "armbianmonitor -u" would help ID where this build came from, but offhand most here aren't familiar with it. Sorry.
  22. This will find any debian repository entries on your system. You will need to fix, or remove these files. $ grep -l debian /etc/apt/sources.list /etc/apt/sources.list.d/* Best bet is to open these files with a text editor (nano is fairly simple if you're new), and comment any lines that have debian in them with a '#' at the start. $ sudo nano -w /etc/apt/sources.list.d/my-debian-file <make your edits> <hit Control-O, Enter to save> <hit Control-X to exit>
  23. Offhand, probably not a great idea to mix and match Debian and Ubuntu repositories. You may want to reinstall with the Debian derived Armbian before continuing. There's a very good chance you'll end up with library versioning issues, unless you know what you're doing. That said, it looks like you put "stable/updates" instead of "stable-updates" in your /etc/apt/sources.list ...
  24. For NetworkManager, those files are in /etc/NetworkManager/system-connections. For ifupdown, they are in /etc/network/interfaces and interfaces.d. Both are available. I think NetworkManager is the upstream default.
  25. As far as I'm aware, there is no OS level control to disable RTS/CTS pins. It's entirely in the user application accessing the UART/Serial Port, per my last post. Not familiar with the BPi at all, so you'll have to find that in the documentation. Past this, I cannot help you. Good luck.