windysea

I am seeing the same issue on a Pine64+, with 4.19.y, 4.20.y, and 5.0.y kernels. After some time of running OK, setting the date by any means fails as above. I also noticed that the actual date on the system suddenly goes way off (as in year 2114, for example). I've added this to my list in trying to get my pine64 back as an authoritative NTP server.

Thanks! I've submitted the a PR with two separate commits, one each for -dev and -next, with the exact same change. I didn't know if you would accept PRs on -next and meant to create two PRs but the second commit was merged with the first PR that had already been submitted. . .

I had submitted a PR last year that was committed to the tree at https://github.com/armbian/sunxi-DT-overlays but this doesn't seem to have made it to the mainline nor is it included in any pine64 pre-built kernels. It is a very simple one-line correction from For now I've been using a local user patch when rebuilding kernels. Would I need to submit a separate PR for the linux mainline as well? Or would a PR to add a bundled patch in the armbian build tree be better/preferred?

I've noted that 'armbianmonitor -u' will obfuscate some detail such as IPv4 addresses prior to uploading, but it misses similar additional detail: IPv6 addresses, specifically 'global' scope, are left intact. These are on interface configurations and in resolv.conf configurations at least. 'domain' and 'search' directives in resolv.conf are left intact. These can (would) include local domain names, which may be sensitive outside of a given environment. username is exposed in showing group membership. This may be minor but in some cases may be sensitive outside of a given environment, and perhaps can be shown anonymously such as '### Group membership of (logged in user) : <group1> <group2> <group3>"? It looks like the IPv4 obfuscation is very basic. Are there plans or thoughts to improve this? Would there be any reason to not obfuscate the additional items above, if someone wanted to give implementing this a shot?

This would be a function of sysfs. You'lll note that you are able to write to /sys/class/gpio/export without error (after changing permissions). This triggers the new creation of /sys/class/gpio/gpioXX using default sysfs permissions. You would need to do the chmod after writing to the export, and not before (IE: during boot). The gpio sysfs module would need to support configuration of ownerships and permissions for new creations to change this.