tkaiser

You might be talking about /etc/update-motd.d/40-updates? Please keep in mind that the information there might be outdated by 2 days since the count of available updates will be somehow cached since it migth delay any login attempt otherwise.
 
https://github.com/igorpecovnik/lib/blob/master/scripts/update-motd.d/40-updates#L139
 
So in case you really believe this is valuable 'information' then think about adjusting the script so that it updates /var/cache/apt/archives/updates.number anyway and call it from cron hourly or in case you love ultra slow logins modify the twodays_ago formula to your needs.

Simply do a
sudo touch /boot/.verbose /boot/.force-verbose

You compare cpufreq-utils 'policy' (contents of /etc/default/cpufrequtils) and kernel capabilities (contents of .dts file). Armbian usually sets identical minimum cpufreq policy for all boards of the same SoC family: https://github.com/igorpecovnik/lib/blob/master/config/sources/sun7i.conf#L26
 
And for whatever reasons DT contents for BPi vary (you can search linux-sunxi archives for specific reasons why this and that happens). From a practical point of view there is exactly no difference between 480 MHz and 528 MHz since these 48 MHz are simply negligible
 
You could adjust cpufreq-utils settings but why? Makes no sense unless you use 144 or 312 MHz (which has some drawbacks if you chose ondemand like overall lower CPU performance, should work better with schedutil governor but there are also some problems reported. IIRC audio pops when using schedutil)

The button is configured here and by default it is defined to enter suspend to RAM state. Unfortunately I forgot how to define the action (must have been back in February when we changed that). You could try to test acpid out and report back.

I've neither found this nor fixed the code -- I just sat in a beergarden watching others do the work, wrote a summary later and also informed affected vendors where possible (LinkSprite and CubieTech still ignoring the issue and SinoVoip as usual providing a fix in the most complicated way so 99,9% of their users are still affected by exploits targeting this vulnerability, same applies most probably to 100% of Xunlong/loboris OS image users).
 
So kudos to the people who discovered this and fixed it!
 
We should take this as a reminder why 'legacy' kernels should be avoided where possible. You never know how many of these issues are present there since vendor provided kernels are made without code/peer review by contractors/employees paid by SoC vendors that do not care about security at all. Expect the worst. Always!
 
And that's why the ability to use mainline kernel is that important. And why it's important to use a distro like Armbian that is actively developed. I would suspect that most if not all OS images for Orange Pis that are still available on orangepi.org download section will never be upgraded and that the users there not even know what's going on.