Yeah. So fsck balks if the time stamp on the superblock is In the future. Which it probably would be in you’re case because when your host machine sets the “clean flag”, it will also update the superblock time stamp.
Sent from my iPhone > On Nov 12, 2021, at 1:55 PM, Rob Kossler <rkoss...@nd.edu> wrote: > > > 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
