windysea

An ntp stratum is not related to accuracy nor precision - it is simply an indication of how many "hops" a given NTP server is from a reference clock.  A stratum-0 is a reference clock (IE: atomic clock, GPS receiver, etc).  A stratum-1 is the NTP server directly using that reference clock for time synchronization.  An SBC with a serial GPS indeed can be a stratum-1 (the GPS would be stratum-0), and there are many public postings on doing this.  In fact the NTPsec team is doing "research" on this topic and has published documentation regarding this.
 
The nature of the reference implementation of NTPd is specifically to maintain accurate time regardless of any hardware timers.  Today's "50-cent" parts are still more stable than those orders-of-magnitude more expensive decades-ago when NTPd was first developed.
 
Google's NTP project may use their own "atomic clocks", but their public NTP servers tend to be on the poor end with respect to jitter.  They're intended to be "close-enough", stable, and highly-available.  They are not intended to be highly accurate.  Their public NTP servers, for instance, implement leap-smearing rather than advertise a leap-second (when appropriate).  For this reason Google strongly recommends not mixing their public NTP servers in a configuration with other NTP sources (bad things can happen, and in fact have happened in the past).  Google's NTP servers also are behind anycast load-balancers.  While this improves availability and end-device configuration simplicity it actually degrades performance.
 
In my own testing google's ntp servers typically have higher jitter than most of the larger NTP pool project pools, the latter of which are already commonly used as defaults in many OS distributions.
 
Configuring and building a non-tickless kernel is required in order to enable kernel-pps (aka "hard pps"), which typically has far less jitter than "soft pps".  However, doing so even with the latest 5.1.y (DEV) kernels results in an unstable platform where the issue noted in this thread will manifest fairly frequently.  It may just be that A64-based SBCs are not suitable to host NTP reference clocks and stratum-1 NTP servers but earlier kernels did not seem to have this issue so it may just be that a previous mitigation got lost along the way.
 

An ntp stratum is not related to accuracy nor precision - it is simply an indication of how many "hops" a given NTP server is from a reference clock.  A stratum-0 is a reference clock (IE: atomic clock, GPS receiver, etc).  A stratum-1 is the NTP server directly using that reference clock for time synchronization.  An SBC with a serial GPS indeed can be a stratum-1 (the GPS would be stratum-0), and there are many public postings on doing this.  In fact the NTPsec team is doing "research" on this topic and has published documentation regarding this.
 
The nature of the reference implementation of NTPd is specifically to maintain accurate time regardless of any hardware timers.  Today's "50-cent" parts are still more stable than those orders-of-magnitude more expensive decades-ago when NTPd was first developed.
 
Google's NTP project may use their own "atomic clocks", but their public NTP servers tend to be on the poor end with respect to jitter.  They're intended to be "close-enough", stable, and highly-available.  They are not intended to be highly accurate.  Their public NTP servers, for instance, implement leap-smearing rather than advertise a leap-second (when appropriate).  For this reason Google strongly recommends not mixing their public NTP servers in a configuration with other NTP sources (bad things can happen, and in fact have happened in the past).  Google's NTP servers also are behind anycast load-balancers.  While this improves availability and end-device configuration simplicity it actually degrades performance.
 
In my own testing google's ntp servers typically have higher jitter than most of the larger NTP pool project pools, the latter of which are already commonly used as defaults in many OS distributions.
 
Configuring and building a non-tickless kernel is required in order to enable kernel-pps (aka "hard pps"), which typically has far less jitter than "soft pps".  However, doing so even with the latest 5.1.y (DEV) kernels results in an unstable platform where the issue noted in this thread will manifest fairly frequently.  It may just be that A64-based SBCs are not suitable to host NTP reference clocks and stratum-1 NTP servers but earlier kernels did not seem to have this issue so it may just be that a previous mitigation got lost along the way.
 

Beware that 'b' will literally trigger an immediate reboot without even attempting to sync the disks.  That is possible, and even likely in some cases, to cause corruption.  For the OP case this would not be an issue since it looks like the root filesystem is already trashed, though perhaps there may have been others?
 
A sync may be triggered similarly, however, just before the reboot:
root@host# echo s > /proc/sysirq-trigger root@host# echo b > /proc/sysirq-trigger  
The 's' can also be handy when /bin/sync is also missing, to help prevent corruption on additional filesystems that may be mounted when faced with forced poweroff/reboot.
 
For the OP:  If your disk is already overwritten then simply removing and re-applying power should not be an issue, unless you don't have physical access.
 
If /bin/systemctl exists (it sounds like it may not here), you can try 'systemctl reboot --force'.   That is the "modern" systemd replacement for 'reboot -f'
 
Otherwise the step noted above using /proc/sysirq-trigger would be the next option, followed by just pulling the power.
 
 

Presuming this is not a brand-new install, correct?
 
How are you able to edit /etc/shadow?
 
If you are already logged in as root you can just use 'passwd' to change the passwd.  When running as root you do not need to provide the existing password to change a password.
 
If you can login as a user with 'sudo' access, you can use 'sudo -i' to gain a root shell then follow the step above.
 
If you have mounted your SD card on another linux instance, you should be able to use:
passwd -R <path_to_mount_point> root <path_to_mount_point> is where you have your SD card mounted (not the full path to the passwd/shadow files)