• Posts

  • Joined

  • Last visited

Recent Profile Visitors

1354 profile views

Set3's Achievements

  1. 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
  2. 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 ?
  3. 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 ?
  4. 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?
  5. 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)
  6. 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 ?
  7. 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 ?
  8. 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 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.
  9. 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
  10. 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
  11. 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,
  12. So only 1 step to go then ? 1 : repair the boot script and get it into all Rock64 Armbian images Who can do that ?
  13. 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
  14. Armbian_5.46.180611_Rock64_Ubuntu_bionic_dev_4.17.0-rc6.img also starts a boot, but is stuck even sooner