jba

I just updated my odroid hc2 from bookworm to trixie. Everything went find and the system is running. However, I now get the following message from "apt-get update": W: https://github.armbian.com/configng/dists/stable/InRelease: Policy will reject signature within a year, see --audit for details W: http://apt.armbian.com/dists/trixie/InRelease: Policy will reject signature within a year, see --audit for details Using the --audit option I get: W: https://github.armbian.com/configng/dists/stable/InRelease: Policy will reject signature within a year, see --audit for details A: https://github.armbian.com/configng/dists/stable/InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on DF00FAF1C577104B50BF1D0093D6889F9F0E78D5 is not bound: No binding signature at time 2025-10-06T08:29:30Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z Missing key 8CFA83D13EB2181EEF5843E41EB30FAF236099FE, which is needed to verify signature. W: http://apt.armbian.com/dists/trixie/InRelease: Policy will reject signature within a year, see --audit for details A: http://apt.armbian.com/dists/trixie/InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on DF00FAF1C577104B50BF1D0093D6889F9F0E78D5 is not bound: No binding signature at time 2025-10-07T19:06:52Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z Missing key 8CFA83D13EB2181EEF5843E41EB30FAF236099FE, which is needed to verify signature. So a key is missing. Where can I get it? And how to install it? Jürgen

Finally found the better answer to my initial question. The process is described in the wiki: https://docs.armbian.com/User-Guide_Recovery/#flashing-boot-loader However, there is one mistake. Instead of the last line ~ $ bash pack/usr/lib/u-boot/platform_install.sh pack/usr/lib/linux-u-boot-nanopineo2-current /dev/XXX # replace XXX with the actual device you need to run ~ $ source pack/usr/lib/u-boot/platform_install.sh ~ $ write_uboot_platform pack/usr/lib/linux-u-boot-nanopineo2-current /dev/XXX # replace XXX with the actual device /dev/sdb In addition it is important to start the partition at block 8192 (at least for my odroid HC2, may be a differnet number on other devices). This way you can easily write your backups to an sd. Regards, Jürgen

I am using an odroid HC2 as home NAS for some years now. Software is armbian/XU4 in debian flavour. At the moment I am running bookworm (which was updated from buster to bullseye and then to bookworm - I know its not supported but it worked fine. And the problem described here started only some month after the last update). Some days ago I wanted to reboot the unit but it was stuck in the boot process. Not available by ssh or any other services. I then found out that the boot stopped because my hard disk could not be mounted from ftsab (while the sd card as root file system could be mounted). After commenting out the line it boots normally. And when logged in by ssh I can mount the hard disk without any problem. As a workaround I put the "noauto" option in fstab and mount the drive after a sleep of some seconds from rc.local. That works fine but I am wondering what is causing the problem? Has something in armbian changed so that mounting on boot time doesnt work anymore? Maybe some problem with initializing the sata controller? Or is this a sign of degrading hardware? Any hints welcome. Juergen

I take regular backups from my linux boxes (rsyncing the file system). To resume, I boot from usb, copy the files to the disk of the box and then make it bootable by chrooting into the box and executing grub-install or update-grub. That works fine. But how can I do this on my odroid hc2 running armbian/bullseye? I cannot boot from usb. So I need to make the sd card bootable on my debian-amd64 pc after copying the files on it. Is there some command like "update-uboot" I can execute on amd64? Or do I need a virtual host running arm architecture to do so? Jüregen

On my odroid hc2 with armbian/bullseye I found some of the logs (both in /var/log and /var/log.hdd) empty, while they should have some contens (i.e. afpd.log, kern.log, user.log, ...). The empty files all have the timestamp of a run of armbian-ramlog at a recent reboot. In armbian-ramlog.log I found this for the run that created the empty files: rsync: [receiver] write failed on "/var/log/journal/0d4b1c13b9a14b6d9c746402b7d7ef6f/user-1000@0005d37f46f9961b-23c015a66b68d086.journal~": No space left on device (28) rsync error: error in file IO (code 11) at receiver.c(378) [receiver=3.2.3] rsync: [sender] write error: Broken pipe (32) Seems that journal has become too big to fit on the log/ramdisk. That is strange, as I defined a maximum of 20MB for the journal and the ramdisk has 50MB. I guess this is what happened: When syncing to sd armbian-ramlog uses rsync without --delete. So if some older files have been already delete by journald (because of the 20 MB limit) on the ramdisk, they will still stay in the log on sd. Therefore the journal on the sd will become bigger and bigger. Which is not a problem because there is plenty of space on the sd. However, when rebooting everything is copied from the sd to the ramdisk. Including the bloated journal. Thus the ramdisk is full and additional files will not fit (see error message from rsync). I think in this case rsync just creates empty files and that is the reason for my empty logs. And on next sync the empty files are copied back to sd so both versions are empty. There is another potential problem I see in the implementation of armbian-ramlog: on reboot only recent files (so no *.gz or *.[0-9]) are copied to ramdisk. After som runtime logrotate will rotate the logs and create new *.gz or *.[0-9]. However, these might already exist on the sd. They will be overwritten when the logs are written back to sd. So you loose old logs. I think both problems are due to the fact that simple rsync is used without --delete and without copying even the old files to the ramdisk. To overcome these problems I see two ways: use rsync --delete and dont exclude *.gz and *.[0-9]. Then the ramdisk holds all logs and when copying to sd nothing is lost. But this may requier a bigger ramdisk dont use rsync but use an overlay fs instead. I found this discussion on the topic. The described solution looks superior to me than what we are using now: https://unix.stackexchange.com/questions/424341/mount-var-logs-as-tmpfs-with-help-of-overlayfs-to-save-changes-sometimes What do you think about it? Would it make sense to use an overlay fs? I am not that deep into linux hacking and therefore are not sure if I would be able to implement it in a nice way. But I would like to support this process and do some tasks. Regards, jba