Well, looks like I should have followed Jonathon's advice and tried "dd" from the start. After writing the file system with "dd" I cannot get the problem to reappear. The fsck completes fine and the partitions are mounted - no matter the various time stamps. Rob
On Fri, Nov 12, 2021 at 2:21 PM Marcus D Leech <patchvonbr...@gmail.com> wrote: > 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
