Jump to content

Set3

Members
  • Posts

    48
  • Joined

  • Last visited

Recent Profile Visitors

2533 profile views
  1. 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
  2. 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 :-)
  3. 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.
  4. 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
  5. 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 !
  6. 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
  7. 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 ?
  8. 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 ?
  9. 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?
  10. 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)
  11. 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 ?
  12. 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 ?
  13. 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.
  14. 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
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines