tparys

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.

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?

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

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>

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

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.

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.

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.

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.

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.

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>

I think this qualifies as a hardware hack? Certainly amuses me. Hopefully others enjoy it as well. So never quite got my 3.5 mm audio jack working properly on my M4V2 (though others reportedly did). But did find a way to get audible tones from the PWM fan control by playing with the PWM period, so decided to see if I could get music out of my M4V2 in another way ... What follows is interesting exploration of: Finding interesting ways to repurpose NanoPi M4 Cases Loading MIDI files in python3 Brushing up on music theory Finding some free and appropriate Halloween Music $ sudo install pip3 $ sudo pip3 install MIDIFile $ sudo ./fanplay.py Bach.\ Johann\ Sebastian\ -\ Toccata\ And\ Fugue\ \(Bwv\ 565\)___WWW.MIDISFREE.COM.mid This little diversion brought to you by: Armbian FriendlyElec Python A few spare hours on a weekend Might try to play around with this a bit more at some point. Notably does not play Backstreet Boys (was asked to try). But does more or less work, at least on this one track. Enjoy fanplay.py

This is generally a warning. Kernel taint generally means that you've done something unsavory, and it may have affected the status of a pristine kernel (such as a closed source license). You might check to see if the module actually loaded with the output of " lsmod "? Regarding the Ethernet status, it looks like the OPi Zero is listed as a "supported" board, so you're welcome to post a topic in the appropriate subforum with armbianmonitor output. However, if the board has had a known issue for years, it may not be a simple fix, and unpaid devs may not have gotten to this issue yet.

More than likely an error with ncurses, which figures out what control characters need to be sent to your terminal / console to move the cursor around and place stuff at particular spots on the screen. Depending on how you start your shell (eg - serial console), the Linux system may have no idea what to send. You can manually specify something doing something like this: $ sudo -i # TERM=linux nano /etc/network/interfaces ... or .. # export TERM=linux # nano /etc/network/interfaces But you may have to specify what terminal you're using with the TERM variable, and may have to try other options (eg = TERM=xterm). Offhand, not enough information here to determine what you need.

EspressoBin is currently in CSC support, so best to submit bugs/questions in in Peer to Peer Support. Also need to submit armbianmonitor output. It seems dumb, but there's a lot of necessary information in there. However, in this case, it tells you exactly what died. You've somehow uninstalled busybox (directly or indirectly), and initramfs-tools can't work properly without it. Not advisable. The initramfs-tools package generates the initrd file for the kernel, which is generally a required part of the boot process. You'll want to get this fixed, and probably not reboot in the meantime until you do.

Just took a look. I don't see ArmbianEnv.txt on the stock image on the download page. Might be a bug? Might be this one? Not clear on the rationale. https://github.com/armbian/build/issues/1538 You can do one of these things: Create ArmbianEnv.txt with the options you need? Modify boot.ini, and accept it will eventually break on some upgrade You can also ask the Subforum for XU4 Support to see if anyone has any insight on why that's missing from the stock build? I would phrase it in terms of why that file is missing from the official build, not yours. But expect the answer might go for both.

https://forum.armbian.com/topic/18583-encrypted-image-no-prompt/?tab=comments#comment-126748

Took a quick look on my system doing that. Doing "systemctl status", I don't see any obvious services that were started or stopped. You might learn more reading up on the options in the NetworkManager command line tool: $ man nmcli Or check with the XFCE guys over at https://forum.xfce.org/ what exactly that network widget does.

Unfortunately, it depends on what you did to disable networking? By default, I think that networking services are managed by NetworkManager. You can check to see if the service is disabled with: $ systemctl status NetworkManager If it's disabled, you can re-enable with: $ sudo systemctl enable NetworkManager $ sudo systemctl start NetworkManager If you touched one of the network configurations, You can manually poke at the configs like this: $ sudo -i # cd /etc/NetworkManager/system-connections # ls my_connection # nano -w my_connection <Hit Control-O, Enter, then Control-X when done>

Pssst ... If you cat the trigger file, it'll tell you the valid options, and which one is currently selected. tparys@laptop:~$ cat /sys/class/leds/input4\:\:capslock/trigger none usb-gadget usb-host rfkill-any rfkill-none kbd-scrolllock kbd-numlock [kbd-capslock] kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock ACAD-online BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid disk-activity disk-read disk-write ide-disk mtd nand-disk cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 panic mmc0 rfkill0 phy0rx phy0tx phy0assoc phy0radio rfkill1 audio-mute audio-micmute I'd wager the correct trigger is "mmc0", unless there's a both a SD card and eMMC slot on that board?

Interesting. Doing some more digging into the debian postinst scripts. May be useful for you in the future if this becomes a continuing issue. The resolvconf package touches this file after installation (/var/lib/dpkg/info/resolvconf.postinst), but only once (tracked via a file you can pre-place, and disable any action on its part). # Linkify /etc/resolv.conf if appropriate if [ ! -e /var/lib/resolvconf/linkified ] ; then ... <snip> ... ln -nsf ../run/resolvconf/resolv.conf /etc/resolv.conf # Make a record that we have created it :> /var/lib/resolvconf/linkified fi Looks like network-manager does too (/var/lib/dpkg/info/network-manager.postinst), but only if it's already a link. SystemD appears to poke this file on a fresh installation (/var/lib/dpkg/info/systemd.postinst), but not on upgrade. Might be useful to find out what /etc/resolv.conf is pointing to, and look for that pattern in /var/lib/dpkg/info? Might tell you which package is tripped you up, and how to prevent it from doing that in the future?

Per https://repo.zabbix.com/zabbix/5.4/raspbian/pool/main/z/zabbix/, it looks like they only publish .deb packages for Raspbian. You might be able to use the Debian 10 images if you're running that flavor of Armbian. If you're running the Ubuntu variant, you might be on your own, and may have to compile it yourself.

If it's a TV box, you might get better results in the TV box forum. But some systems have the DTB embedded in the kernel image. If you can get to a shell, you can dump it from a running system sorta like: dtc -I fs -o devicetree.dts /sys/firmware/devicetree/base Keep in mind that there are periodic changes to the DT format over time, and some vendors put in nonstandard hacks. Keeping these DTB files current is a major issue for Armbian devs. If it's for an unsupported box, it'll almost certainly require changes for everything to work properly.

If you know you're only using ifupdown, and never NetworkManager, you can always just disable it? sudo systemctl stop NetworkManager sudo systemctl disable NetworkManager

Not that I'm aware of. Longer passwords are generally encouraged. Though you will eventually hit a point where longer passwords aren't buying you any more security. Of course, that depends on the cipher / key size you're using, how long your password is and what sort of characters it's made of (read: entropy).