By the way, I just removed my working SD card from the E310 and inserted it in my host (Ubuntu 20.04) SD card reader and issued the "umount" commands. Nothing else. When I reinserted into the E310, boot issue appears (fsck fails for /data and thus won't mount and puts me in some maintenance mode). Rob
On Fri, Nov 12, 2021 at 1:49 PM Rob Kossler <rkoss...@nd.edu> wrote: > 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
