On Fri, Nov 12, 2021 at 1:17 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote:
> 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? > You're right. I just meant that it was today's date on reboot. I didn't check to see if it was actually keeping time in between. It would have only been a few seconds anyway.
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
