Tim Makarios

Thanks for the suggestion, but it didn't work for me. Both /var/log/postgresql and /var/log.hdd/postgresql reverted to their pre-intervention ownership and permissions when I rebooted.

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