This expands to twice sysctl -n.

If /boot is a separate filesystem, then this may well be the only thing writing to it regularly. This might affect reliability negatively.

Oops! Will fix!

I'm not sure I understand you completely here. Do you mean this may be the only thing stashing entropy regularly, and this will therefore affect random(4) reliability? If so, I'm not sure you are right; there is a cron job adding stuff to /var/db/entropy/ which I intend to extend.

Do you mean that this may be wearing out /boot by excessive writing? If so, is one file write per reboot really that onerous? If so (again), could it go somewhere else?

I mean that this very slightly increases the risk of /boot getting corrupted. A rather minor issue given the importance of /.

Also, /boot might be read-only, especially in systems that are more like embedded systems.

Erm, OK, the system owner does have override powers, including the ability to disable its altogether if they wish. Is this acceptable?

This reminds me - I need to ensure the loader scripting is OK too.

Can we leave this a system-owner configurable?

The '' part can't happen because of the ${var:=value} expansion. Either remove it or use ${var=value} instead of ${var:=value}.

Yes.

Fixing similar elsewhere.