Set3

Yes : removing 02-armbian-preupdate did the trick ! Since I automatically modify/override/repair some files in /etc/apt/apt.conf.d, on an regular basis, the preupdate file got restored, while it is not there in the standard install Thanks. Still wondering about the certicifate, but that is another issue now ;-)

Well, that was interesting Online update / upgrade : ok install/purge ntp :ok offline, changed in etc/apt/ the sources.list and armbian.list to local repo Suddenly got a signature error, never seen before W: GPG error: http://.../mirror/apt.armbian.com bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5 wget armbian.key apt-key add armbian.key Warning: apt-key is deprecated. normally I use signature references in /etc/sources.list and armbian.list, but as a test it is ok anyway I count install / purge ntp needs further investigation, perhaps my repo was damaged a few weeks ago when there were mirror problems ? I think I renewed the armbian repo Have to do more checking/testing, Ill keep you informed.

Thanks for the quick reply tried it , but got on my running hosts ( debian_12_bookworm_6.6.16-current-sunxi ) --> Failed to disable unit: Unit file armbian-live-patch.service does not exist. I am not aware, that I uninstalled anything like that. my next steps: Let me try with a fresh new image Armbian_24.2.1_Orangepione_bookworm_current_6.6.16.img.xz Update/upgrade online, then go offline and use local repo check every step with I guess " systemctl show armbian-live-patch.service" ?

Hi, since a few weeks I get these errors in multiple Orange pi-s unattended-upgrades-dpkg.log:3:E:Sub-process /usr/lib/armbian/armbian-live-patch apt returned an error code (127), E:Failure running script /usr/lib/armbian/armbian-live-patch apt unattended-upgrades.log:7:2024-04-11 11:00:58,211 ERROR Installing the upgrades failed! I have a local repos for debian and armbian, and the Orange pi-s have no internet access. Has been working fine in the past years Did a fresh install having internet access : ok Armbian_24.2.1_Orangepione_bookworm_current_6.6.16.img.xz then changed to offline, using my local repos as example tried to install ntp and docker.io All failed, with above like errors So, Q1 : is it no longer possible to work offline using local repos ? Q2 : Or is there a work around for this ? Set

Let me try again : Did you say you pulled .de out or the mirror rotation ? In my humble opinion : I think that is a mixup stpete should be taken out of the mirror rotation .de mirror is ok stpete stil has the wrong file So users still can get the error message mentioned. For now I stay on the .de mirror, that is working fine

Hmm, Not sure I understand you, but I think you pulled the wrong one. Just to be clear : I think mirror.armbian.de is ok stpete-mirror.armbian.com has the wrong InRelease file Few days ago I made a wget script to pull all InRelease files from all mirrors in the mirrors list you referred to, all match, except the one from stpete Now don't get confused below : ( please read twice :-) I don't mirror stpete directly (yet), I currently I mirror apt.armbian.com mirror.armbian.de Just ran a compare again, and there is a mismatch only in the InRelease file I guess that I got that file from stpete via apt.armbian.com allocating me to stpete :-)

Hi Igor, As said, "can be done more intelligent", but sync is not the main issue here I now realize. My problem is solved for now I switched to the .de mirror, and changed all apt files, in my Orange Pis, via my DIY bash based distribution system and all works. But we should use the apt-armbian.com as much as possible right ? so until solved. But lets repair this for all. Problem So if today ( file is still in error ) someone does apt update bionic armhf or arm64 and get this stpete mirror, they cant update/upgrade/install Somewhere in the creation/sync process on stpete mirror, something went terribly wrong Same for the InRelease and Release file I guess that this specific error might be solved when a new InRelease /Release is created, fingers crossed ? It is a different file : differences: 1- the date in the content of the file does not match the file datetime in file Date: Mon, 15 Nov 2021 14:22:59 UTC vs file date 2021-11-28 18:57 3. Complete different file sizes inside the InRelease / Release file, look like 2 - 3 times larger ? e.g. file Contents-arm64 : 559420517 vs 204947365 That is what apt update is complaining about : wrong file size how did this happen, Is InRelease / Release created locally on stpete ? Are they using a different source to copy / run a different program to create this file ? --------------------------------------------------------------------------------------------------------------------------------------- on .de mirror -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Origin: Armbian Label: Armbian Suite: bionic Codename: bionic Date: Sun, 28 Nov 2021 18:57:36 UTC Architectures: arm64 armhf Components: bionic-desktop bionic-utils main Description: Generated by aptly MD5Sum: 713f40b776be3e429bf4d490078fcebb 204947365 Contents-arm64 62aa28ca7533d9b851cee738e05aeb0c 11483603 Contents-arm64.gz 12b178bf3f7b725bd794dab5a91ac53f 192630392 Contents-armhf 420271a676b17787f5e066bca4b802d5 11234465 Contents-armhf.gz ... --------------------------------------------------------------------------------------------------------------------------------------- on stpete -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Origin: Armbian Label: Armbian Suite: bionic Codename: bionic Date: Mon, 15 Nov 2021 14:22:59 UTC Architectures: arm64 armhf Components: bionic-desktop bionic-utils main Description: Generated by aptly MD5Sum: c352cdecd45eaea57e1487fcff099476 559420517 Contents-arm64 870b03f3bcba70dfaba9c91ba1e4ea78 31939133 Contents-arm64.gz 8da79c257b6cf1d57b25d8126d2a773c 543748921 Contents-armhf aa6b322f000304e98f0d4f3b218988f0 32387711 Contents-armhf.gz ... --------------------------------------------------------------------------------------------------------------------------------------- So who can solve that ? Hope this helps.

So, well, yes, someone could every night (or more often as you wish), run apt-mirror on all mirrors (works incremental) , then run a compare files on content and presto, you have your mirror health in one go. at least until the problems are solved an apt-mirror on one mirror take s a few minutes, until an update is needed 60GB includes arm32 and arm64 brute force : file compare with ffs takes 1.5hr on a network share 80-100 M Byte p s can be done more intelligent

Hi ( Had some account problems, long time not logged in.... ) I found mismatches in at least one mirror I use apt-mirror to get a local apt copy so I can run without internet access and still update/upgrade/install at will apt-mirror uses file date for comparison and that is where it goes wrong Every now and then my Orange Pi One devices complain that there is a problem in file size : Err:8 http://MYLOCALREPO/mirror/apt.armbian.com bionic/main armhf Packages File has unexpected size (153052 != 303677). Mirror sync in progress? A few times I deleted the whole armbian mirror folder and reloaded ( 60GB :-( few hours) , which solver the problem Not this time Did some digging Normally I mirror apt.armbian.com So nowI also mirrored the http://mirror.armbian.de/apt/ ( Another yes 60GB download ) and found a difference in CONTENT in 1 file, but they had the same time stamp : problem ! That is a problem in at least this mirror : https://stpete-mirror.armbian.com/apt/dists/bionic/ That site has an InRelease file dated 28-11 but inside the file it says Date: Mon, 15 Nov 2021 14:22:59 UTC All these mirrors are OK, at least for this specific file, this time that is.... http://armbian.12z.eu/apt/ http://armbian.hosthatch.com/apt/ http://armbian.systemonachip.net/apt/ http://armbian.tnahosting.net/apt/ http://imola.armbian.com/apt/ http://mirror.12z.eu/pub/linux/armbian/apt/ http://mirror.armbian.de/apt/ http://mirrors.bfsu.edu.cn/armbian/ http://mirrors.dotsrc.org/armbian-apt/ http://mirrors.nju.edu.cn/armbian/ http://mirrors.tuna.tsinghua.edu.cn/armbian/ http://mirrors.ustc.edu.cn/armbian/ http://stpete-mirror.armbian.com/apt/ http://xogium.performanceservers.nl/apt/ So now trying : Just entered the URL apt.mirror.com/dists/boinic then we get forwarded to one of the mirrors, then downloaded InRelease and checked no others found yet Hope this helps you find the error !

In the request you wrote logrotate.service ? I dont have that in ubuntu;18.04.3;lts 5.90 on OPiZ You mean armbian-ramlog.service ? now has [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-ramlog start ExecStop=/usr/lib/armbian/armbian-ramlog stop ExecReload=/usr/lib/armbian/armbian-ramlog write RemainAfterExit=yes TimeoutStartSec=30sec

One question Dysmas on implementation, I don't see in your request : "On a working system, it is better to copy this file from /lib/systemd/system to /etc/systemd/system to prevent possible overwriting during an update." So somehow magically /etc/systemd/system overrules /lib/systemd/system ? or do I need to change something else ?

until redesigned I will try your solution on a few OPiZeros, see if it lasts :-) So do we need another request for a possible redesign or a discussion on a more worked out plan here first ?

By the way, while searching for this problem, I think I read somewhere that there is a command that tells syslog and other apps to restart logs using new logs, cant remember where/which command Is that not postrotate / sharescript?

yes understood, I will try it, thanks so far.

rsync is preferred when it comes to reduce traffic to sd card and that is what this was all about anyway right ? I tried rsync -aXWv /var/log.hdd/* /var/test/ --exclude *.[0-9] --exclude *.[0-9].gz looks good to me, or am I missing something ? is the var/log/syslog updated inbetween so that rsync sees /var/log/syslog as a newer file than the just empty /var/log.hdd/syslog ? But I now also don't understand is that in the middle of the day, I can overwrite syslog with the version of last night, and I cant see updates when I use logger. Hmm strange. Probably needs a log restart. I see discussions here on disabling ramlog, where the idea is very good. That is a shame. The current solution is not easy to understand for the end user. And it is just about something as simple as logging :-) Perhaps a stupid idea while we are might be redesigning anyway ? why don't we - do a standard logrotate in /var/log as designed, described and same as on other ( eg x86) installations - probably do a kind of custom rotate on /var/log.hdd to move .1 to get .2.gz etc - "rsync without --delete" to /var/log.hdd which then holds latest files and previous rotated .1 - remove all rotated files from /var/log to use as little RAM as possible - do a cleanup of old compressed rotated files in /var/log.hdd according to logrorate settings ? or just leave the rotate files on .var.log, makes it more simple, have users decide to change logrotate as per manual Yes there may be complications, but that is for experts to point out. To me looks less error prone, as log-rotate on /var/log then works as designed and described in all manuals. And to avoid confusion, put a small text file with explanation /var/log/Where_are_the_rotated_files.txt for the end user (without being rotated out :-) , explaining on how it works and where we can find the rotated files and why. Including the 75% mechanism explained. As end user I would be happy to see that. Logging is not a sexy subject, but I have a few OPiZero (256MB) with docker apps and memory is a challenge so having logs running up to 50MB is a lot. (although I know about the 75% monitoring which does work well, and I can change that to less % etc etc)

Thanks Dysmas, removing one of the 2 --delete solved the problems indeed in /var/log.hdd/syslog, I now see the syslog.1 2.gz etc on a daily basis. Problem I still have , is that the log/syslog is not emptied, but keeps growing. Any ideas on that ?

Hi martinayotte On var/log and var/log/.hdd : Done that, every hour, it works, obviously :-) . also using sed to remove the "IR event FIFO is full" lines But now, for a while or perhaps since then, my warning system, based on what df under /var/log reports gives false warnings : df misreports the real size eg : in WinSCP, the calculate button says 2.2MB, where df says 75% of 50MB Perhaps the varlog scripts are not happy with the delete/modify ? Reboot repairs the mismatch Edit : Moved to using du iso df, du is reporting correctly. so that is solved, but perhaps a point of attention for the developers ?

I guess you are right, at least for what I tried with Rock64 and Armbian I have USB3.0 problems mentioned elsewhere on this forum and on https://forum.pine64.org/showthread.php?tid=5137&pid=37535#pid37535 I used tips above for an el cheapo USB3.0 JMS597 SATA adapter cable 0x152d:0x0578 In Armbian 5.59 I had read/write speed around 80MBps ish using samba (varying between 109 and 70) But with read, after a few seconds full speed, it froze for 10-15 sec, no errors in the transferred data, but with "ERROR Transfer event for disabled endpoint or incorrect stream ring" in dmesg every time it froze. With above tips I don't have freezes anymore, and using samba as server and W10 client, write speed still 80MBps ish, but read speed down to 50MBps. And as you predicted, I have now another error : "reset SuperSpeed USB device number 3 using xhci-hcd" But not in red :-) and without any noticeable delay. Hopefully the USB "ERROR Transfer event for disabled endpoint or incorrect stream ring" gets solved soon. Ill do some more testing on Pine and Armbian. Also always interested if you have better fixes.

Hi guys, Using the Pine images from ayufan for a while, I still longed back to Armbian, so all SBCs look and feel the same :-) Not that the Pine images are bad, just a bit different. The latest Ubuntu (non desktop) image 5.59 now work also on Rock-64 1GB, thanks ! Reboot is also ok. It is only confusing that the HDMI does not show anything, so initially I missed that they work, but SSH works, and that is all I need anyway. Issue closed

Ok, although I did see strange results earlier today, I now can say that the patch works, tested about 10 times from scratch so I can login, update/upgrade/install some stuff I see error messages in the boot : ** File not found /boot/dtb/rockchip/overlay/-fixup.scr ** and Starting kernel ... ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) Loading, please wait... starting version 229 and [ OK ] Started User Manager for UID 0. [FAILED] Failed to start Network Manager Wait Online. See 'systemctl status NetworkManager-wait-online.service' for details. [ OK ] Reached target Network is Online. Is that "normal" ? But reboot does not always work, hangs on one sbc, succeeds on another sbc, both show like : Starting kernel ... ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) Loading, please wait... starting version 229 [ 2.080920] Internal error: Oops: 96000004 [#1] SMP [ 2.081455] Modules linked in: [ 2.081810] CPU: 3 PID: 212 Comm: udevadm Not tainted 4.4.124-rk3328 #24 [ 2.082522] Hardware name: Pine64 Rock64 (DT) [ 2.082989] task: ffffffc037833600 task.stack: ffffffc027510000 [ 2.083627] PC is at __rmqueue.isra.7+0x84/0x3f4 [ 2.084120] LR is at get_page_from_freelist+0x20c/0x774 [ 2.084674] pc : [<ffffff800819550c>] lr : [<ffffff8008195a88>] pstate: 20000 1c5 [ 2.085447] sp : ffffffc027513a30 [ 2.085802] x29: ffffffc027513a30 x28: 0000000000000001 [ 2.086391] x27: 0000000000000010 x26: ffffffc03ff95d98 [ 2.086978] x25: 0000004036e79000 x24: ffffffc03ff95d88 [ 2.087565] x23: 0000000000000001 x22: 0000000000000001 [ 2.088153] x21: 0000000000000000 x20: ffffff800928a380 [ 2.0 etc etc

Ok, Yes 2 images (bionic/xenial)boot now with serial connected, I can login,change root password dhcp/ssh works Edit 1 ( now only using dhcp/SSH, serial disconnected) Bionic looks ok, did an update/upgrade/ installed a few packages : all ok. but HDMI : no sync, no output, no boot log and no prompt ( is that normal for bionic=development ? ) But shutdown -h now leaves red/white LEDs on, strange Also power usage does not go down, remains on 1.5W serial: Edit 2 ( now only using dhcp/SSH, serial disconnected) Xenial looks ok, did an update/upgrade/ installed a few packages : all ok. HDMI does not show a boot log, but does show Ubuntu....Login, usb keyboard login works shutdown red/white LEDs off, Also power usage drops to 0.03W Looking good man ! Good work ! Edit 3 : Hmm, we are not there yet, Xenial boot / reboot is unreliable. Once it boots it looks good, but only half-ish of the boots succeeds I need to do more testing,

So only 1 step to go then ? 1 : repair the boot script and get it into all Rock64 Armbian images Who can do that ?

Yep, 4.4.124 not stuck indeed, ls does work. It is just not what I expected :-) Edit : same with dev_4.17.0-rc6 4.4.124 not stuck, ls command works

Armbian_5.46.180611_Rock64_Ubuntu_bionic_dev_4.17.0-rc6.img also starts a boot, but is stuck even sooner

Ok, next steps ? 1 : repair the boot script and get it into the Rock64 Armbian images 2: Why does it get stuck after it boots ? I will try it on the other image too.