Plus the time to learn a few modprobe commands. Perhaps run a few commands echoing numbers to random sysfs files. Perhaps learn WTF a 'Device Tree Overlay' is - a concept that's completely absent on x86 systems. You see, this is an 'I2C' device, so it doesn't plug and play like USB and PCIe devices do. It is much simpler, and hence for some reason more difficult. Perhaps your device tree overlay needs to be complied? Or maybe not. Perhaps you'll edit your modules file and your kernel command line. Of course that won't involve update-grub, why would you think that?
Don't forget to periodically check on your settings, just in case an OS update or something has disabled one of those settings.
Oh and of course you won't be able to fully test this over SSH, if the network is up NTP will have set your clock whether the RTC is set up right or not. As we've learned from the article, if you run into clock problems you might not be able to connect remotely.
Then simply invent a time machine so you can do all of this in the past, before the pi SD card fails and it drops off the network.
Ah yes the Raspberry Pi, a charitable project intended to get young kids into coding, which comes with kid-friendly projects, brightly coloured beginners' guide books, and pre-installed with Scratch, is truly only a tool for experienced professionals.
Yes, if he/she was using it for that (kid projects, Scratch, etc.) it would have been the right tool. Maybe it's because she skipped all those steps in his/her IT education is the reason he/she is having troubles now.
I learned about the devicetree on a RPi too, but I didn't complain about it in a blog. When I bought my first RPi I expected to encounter problems and learn a lot from solving them. In fact, I expected it to be much much worse - so much worse that I even bought the RTC module even before the RPi arrived in the mail. Why didn't he/she think of that? It's because he/she is lacking the basics, the kid project with gpio leds and i2c sensors.
(a bit more money for the GPS to be fair) not even mentioning the fact that you should have clear-ish access to the sky, the time taken for you to receive the time data, and the possibility of jamming. I could go on but the two methods have differing modes of operation and failure despite ultimately being capable of fulfilling the need for a reasonably synchronized clock
Plus the time to learn a few modprobe commands. Perhaps run a few commands echoing numbers to random sysfs files. Perhaps learn WTF a 'Device Tree Overlay' is - a concept that's completely absent on x86 systems. You see, this is an 'I2C' device, so it doesn't plug and play like USB and PCIe devices do. It is much simpler, and hence for some reason more difficult. Perhaps your device tree overlay needs to be complied? Or maybe not. Perhaps you'll edit your modules file and your kernel command line. Of course that won't involve update-grub, why would you think that?
Don't forget to periodically check on your settings, just in case an OS update or something has disabled one of those settings.
Oh and of course you won't be able to fully test this over SSH, if the network is up NTP will have set your clock whether the RTC is set up right or not. As we've learned from the article, if you run into clock problems you might not be able to connect remotely.
Then simply invent a time machine so you can do all of this in the past, before the pi SD card fails and it drops off the network.