Tim Makarios

It's possible that the above (which was on kernel 6.12.9, I believe) was a misdiagnosis of In any case, the 6.12.11 kernel does boot the Renegade from eMMC, though with the limitation noted in that linked topic.

I can confirm that the LEDs still aren't flashing on the 6.12.11 kernel. This doesn't bother me much, but just to be helpful, here are the armbianmonitor -u outputs for Kernel 6.6.47, where the LEDs flash: https://paste.next.armbian.com/suporamoqe Kernel 6.12.11, where they don't: https://paste.armbian.de/cuxaxoweci

I have an encrypted root partition, and on booting, it asks me for the passphrase to decrypt it. This was shown on the screen when I was using the 6.6.47 kernel, but on the 6.12.11 kernel, nothing is shown on the screen at all until I've successfully typed the passphrase and it's started booting. Here's the armbianmonitor -u output for the working 6.6.47 kernel: https://paste.next.armbian.com/suporamoqe And here's the output for the not-quite-so-working 6.12.11 kernel: https://paste.armbian.de/cuxaxoweci This isn't a huge deal for me, since I usually close my eyes while typing the passphrase anyway, but it means I have to guess when it's ready for me to type the passphrase, and guess how long to wait before concluding that I typed it wrong, and need to try again. Also, it might bother other people more than it bothers me.

My Libre Computer Renegade wouldn't boot from its pluggable eMMC this morning. I worked around the issue by booting from an SD card, setting up a chroot environment for the eMMC card, and switching to an older kernel on the eMMC. Obviously, it would be better if the current kernel supported booting from eMMC. This may be related to and

It does, indeed, seem to have reverted to the problematic permissions after a reboot.

I seem to have successfully worked around this problem by changing the permissions on /var/log/postgresql. I'm not sure why the cron job, which looks like it's set up to run as root, couldn't truncate the file in that folder; and I'm not sure whether my solution is durable, or whether a reboot or something might reset the permissions at some stage, but it works for now.

One of my Armbian machines (24.5.5 bookworm) is running PostgreSQL. I don't think I've changed any of its default settings relating to PostgreSQL's log files or their permissions, but I'm occasionally getting emails from the armbian-truncate-logs cron job saying: The directory /var/log/postgresql is owned by root (and group postgres) and has permissions drwxrwxr-t, and the file /var/log/postgresql/postgresql-15-main.log is owned by postgres (and group adm) and has permissions -rw-r-----. In /var/log.hdd/postgresql the ownership and permissions are the same, and there are also files postgresql-15-main.log.1, postgresql-15-main.log.2.gz, postgresql-15-main.log.3.gz, ..., postgresql-15-main.log.10.gz (with the same ownership and permissions as postgresql-15-main.log). The file postgresql-15-main.log.1 is a prefix of postgresql-15-main.log. I have this problem only with PostgreSQL's logs; armbian-truncate-logs doesn't complain about any other log files. Is there something I need to do to fix this, or is this a bug that will be fixed in future?

I'm using a few Libre Computer Renegades as headless servers, and they're working well (thank you!), but I'm wanting to set one up for personal use, and I've discovered that when I plug headphones into the analog audio jack, the left and right channels are reversed. (Also, the default volume, (for example, from speaker-test in a terminal) is too loud for headphones.) sudo armbianmonitor -u Says: System diagnosis information will now be uploaded to https://paste.armbian.com/Error adding document. so I've attached armbian-hardware-monitor.log instead. armbian-hardware-monitor.log

I used this tutorial as the basis of my own script, which is heavily adapted for my own needs. It worked for me, getting a bookworm CLI image to run on a Libre Computer Renegade. Although I made lots of changes, I think the only ones necessary for getting it to work on a bookworm image were replacing "etc/dropbear-initramfs" with "etc/dropbear/initramfs" twice in step 9.4, and replacing "etc/dropbear-initramfs/config" with "etc/dropbear/initramfs/dropbear.conf" twice in step 9.7. Perhaps this was the problem @Vasir encountered?

I'm pretty sure my LTS's CPU had "A64" (or possibly "A64-H") on it, not "R18", but I've attached a heatsink to it now, so I can't check just by looking at it. I guess the information might be accessible via software, but I can't immediately see where. Also, my board does have a microSD card slot, but it's under the board, where the pluggable eMMC socket is on top. The power jack is a barrel socket, with 3.5 mm outer diameter. I tried the .dts file and amixer commands in this comment but still didn't get any audio coming out of my headphones. I'm willing to help, but I don't have much experience with .dts files or amixer; and, as you may have guessed by now, I can't promise to respond quickly.

@Pander By the PI-2-bus, mine has this on it: Pine A64 LTS Version V2 2021-05-13

On Jammy (Gnome, current, Rock64), I had to manually install dkms before the script would work.

I did a little more experimenting, and found that it connects without a problem when I tell it to use WPA2, rather than WPA3. I don't know whether the problem with WPA3 is in my router or the client, but WPA2 is good enough for now. I can also confirm that your script works on an A64-LTS board, too, so thank you again!

Thanks! I can confirm that the script works on my Rock64 board, running bullseye CLI with the current branch. At first I thought it wasn't working, but then I moved it to a different spot and tried an open WiFi network. I'm still not sure if I can get it working with my normal WPA2/WPA3 network. Oh, and you might want to change "edge" to "$BRANCH" in the manual instructions, too.

Good timing! I had a couple of these arrive yesterday. In the script, it says sudo -E apt -y install linux-headers-edge-$LINUXFAMILY >> $logfile 2>&1 Is this because it's only expected to work with the edge kernel, or if I change "edge" to "current" in that line, should it work for the current kernel?

Thank you for the excellent tutorial! Just a little simplification: Instead of using the script in step 9.9, I put command="/usr/bin/cryptroot-unlock" at the start of the line in /etc/dropbear-initramfs/authorized_keys, to force that command when SSHing in using that key.

Another update, again in case it helps someone else: Thanks to this hint https://forum.armbian.com/topic/9402-ethernet-not-working-on-sopine-module/?do=findComment&comment=71544 I've managed to compile a kernel (and, more importantly, a .dtb file) that gets the Gigabit ethernet working on my Pine A64-LTS. I've attached the patch (which I placed in userpatches/kernel/archive/sunxi-5.15/) and board configuration file (which I placed in config/boards), to make it easier for others to use this fix. Would it be even better if I turned this into a pull request? arm-dts-pine-a64-lts-GbE.patch pine-a64-lts.csc

An update, in case this is useful to someone else: I've built an image by replacing `_plus` with `-lts` in the line of code @Igor linked to above (and changing the file name and comment). It boots, but the headphone jack and ethernet port still don't work. However, I can get the ethernet port to start working by running `sudo ethtool -s eth0 speed 100 duplex full`, which slows it down to 100 Mb/s. This is obviously less than ideal, but better than nothing. I'm still really puzzled about why the heaphone jack and gigabit ethernet work on Manjaro, but not on Armbian. In the process of trying to figure it out, I've been learning bits and pieces about `.dtb` files, but I'm still not confident I understand what's going on. I compared the relevant `.dtb` files I found in `/boot/dtb{,s}/allwinner` on Armbian and Manjaro, but I couldn't see any obvious relevant differences. In particular, it seems both have `phy-mode` set to `rgmii-txid`, and no rx or tx delays manually set. But I don't even know if I'm looking in the right places for the relevant differences. Unfortunately, I've had two laptops die of old age (both over ten years old, I think) in the space of a month, including the one I built that Armbian image on, so my ability to build new images to test is limited. I can compile kernels on an arm64 board, but it seems I would need a working x86_64 computer to build another full image.

Thanks for your reply. I am disappointed, of course, that there's no official Armbian interest in supporting my A64-LTS boards, but I understand your position. Based on a hunch, I tried the Pine64so bullseye image from https://au.mirrors.naho.moe/armbian/dl/pine64so/archive/ and it boots straight away, but the network and headphone jack are still not functioning correctly.

I recently bought a couple of A64-LTS boards from the Pine Store, but I couldn't get the official Armbian images to boot on them. https://www.armbian.com/pine64/ I could, however, get Manjaro to boot on them, and when I created an SD card with U-Boot from the Manjaro SD card, and the partition from the Armbian (Bullseye CLI) image, it booted into Armbian. I noticed, though, that Manjaro distinguishes between the Pine A64(+) and the Pine A64-LTS. Tow-boot also makes the same distinction. So I wondered if maybe Armbian wasn't booting on my A64-LTS boards because it wasn't making that distinction, but it should be. (I also noticed that the headphone jack and ethernet port aren't working properly on Armbian, though they do work on Manjaro, but perhaps it's best to focus first on getting an official Armbian image to boot on the A64-LTS.) Here's the output of `armbianmonitor -U`: http://paste.debian.net/1266079