tparys

  • Posts

    177
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

tparys's Achievements

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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?
  7. > 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.
  8. 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>
  9. 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 ...
  10. 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.
  11. 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.
  12. Depends on what program you're accessing the serial port. For minicom, you disable the "Hardware Flow Control" as above via "minicom -s". If you're using stty, it's the crtscts flag (see "man stty"). For C programming, it's the CTSRTS flag (see "man tcsetattr"). Past that, I don't know what software you're trying to drive your printer, so can't tell you what parameters you need.
  13. Not familiar with the Npi-GPIO package. However ... Standard newer way to access GPIO pins is with gpiod package: gpiodetect gpiofind gpioget gpioinfo gpiomon gpioset Standard older way is to use /sys/class/gpio interface to export pins and then read/write them. This has been deprecated as it requires either root access or custom udev rules to set ownership so normal users can access them. GPIO pin numbers are also subject to change between kernel versions. But documentation on this interface is far more common online, and still works fine. Also, questions regarding Smart6818 should go in Peer-to-Peer support as is not a supported board.
  14. Unfortunately, there's not really enough here to go on. How much data are you recording, how frequently, and what sort of processing do you need? Also, "batteries" is also ambiguous. Most of the supported boards would probably run for a month off a 12V car battery. As a general rule, I'd browse the download page and look for smaller boards without heatsinks, and check the datasheets for typical power usage, and what sort of I/O is available. Honestly, you might just need to get a few and try them. Most aren't that expensive. I'd also leave off WiFi and Ethernet unless you really want it. Those will drain far more power than a 232 serial connection.
  15. Couple of thoughts: 1 - You probably mean RS232 serial, and not 485. Both are 3 wire serial. Just FYI. 2 - The setserial application is exclusively for ISA bus based serial ports. I doubt you have one of these. You can look at stty if you want, but generally whatever software you run will set those parameters for you at run-time. There's no system-level configuration you'll need to do aside from making the port active. If it's showing up in the kernel log, that's a good start. 3 - The big parameters you'll want to worry about are baud rate, and disabling HW flow control. There's a bunch of other settings too which are more rare, such as number of data bits, parity, and stop bits. Unless you have documentation that says otherwise, assume 8 data bits, no parity, 1 stop bit (sometimes listed as 8N1). 4 - If you want to test with minicom, be aware it enables HW flow control by default. You can change this default by doing: $ sudo minicom -s <Select "Serial Port Setup"> <Hit 'F' to set "Hardware Flow Control" to "OFF"> <Hit Esc> <Select "Save setup as dfl"> You may also want to add your user to the "dialout" group. You'll probably want to log out/back in afterwards. $ sudo usermod -aG dialout <username> Then you can launch minicom on that port by doing this: $ minicom -D /dev/ttyS3 -b <printer baud here>