On 2021-11-12 13:14, Rob Kossler wrote:
I will try soon, but such experiments are "expensive" because when it
fails I have to re-burn the file system and then reconfigure stuff
afterwords since I don't know how to recover from the issue. My guess
was that either the mount or the eject was writing a date (perhaps an
"accessed" date in some metadata) that was much in the future relative
to the file system "Aug 6 2021" date that it gets and somehow this
date mismatch was causing the fsck failure. But I am not
knowledgeable on this.
Regarding your NTPD comment, perhaps it isn't accessing any RTC.
Perhaps it is storing the time in the file system somewhere such that
it can access it on next boot?
Your comments indicated the resulting time after reboot in this case was
*correct*, which would mean that something would have to be "keeping
time" across the
reboot. Or did you mean just that the time after reboot, without the
network cable connected, but with NTPD turned on, was "closer" to
correct than without?
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
