> > > I think that my overall issue is related to writing files with bad time > stamps. I don't know why this can cause the file system check "fsck" to > fail, but when that happens, the /data partition doesn't mount and I don't > know how to recover (short of re-burning the file system). > > I can say that if I start with a fresh file system, I can boot multiple > times successfully if the eth0 is connected one-to-one to my host and is > unable to acquire a network time. On the other hand, if I connect eth0 to > our network such that it gets a network time, the network time is preserved > on subsequent boots, even if I have no network cable connected on the > subsequent boots such that it acquires no network time. But, in this case > I seem to somehow run into the same corruption related to not being able to > mount the /data partition at bootup (which I am unable to clear short of a > file system re-write). > > So, for now, I can use the system as long as I don't hook up to a network > time server. > > In terms of the booting issue, I wonder if the "eject" on your host isn't > actually clearing the "filesystem is dirty" flag. That would be unusual, > but not out of the question. > If you instead "sudo umount /dev/sdbXX" and THEN pop the sd card, does > the behavior change? > > I'm at a loss to explain how NTPD can apparently find and set the RTC > clock when "hwclock" cannot. >
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?
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
