Re: no Real-Time Clock
Likely the same thing that the Pi would do a lot of the time: use the wrong, cached time, which is still later, and boot successfully.
But yes, one of the tradeoffs of the strict verification is that, if there is no RTC, the power is lost so the cached time is out of date, and packages were verified during the running session, then they will not verify during boot. Those prerequisites are pretty rare with a server that generally has an RTC that works most of the time and generally isn't losing power unexpectedly given that they often have UPSes and automatic shutdown scripts if power is going to go down. That's less common with a Raspberry Pi which doesn't have an RTC at all and is most often connected to a less reliable power source with no prediction if it is going to fail. With every program, you end up building in assumptions and tradeoffs.
For instance, the same RTC lack can mess with programs that start before a Pi gets a network connection. It's well-known as something you have to consider. Some things that use wall clock time may report odd behavior when it switches from saved, wrong time to real time. Results get reported as applying to huge time periods. Scheduled tasks end up running because the time they were supposed to run was in the middle of that period that really doesn't exist. For better or worse, a lot of programs that are running as normal userspace programs have decided that they will have a clock available and if the clock acts oddly such as skipping entire hours, that's the user's problem. Not every program needs to write special cases for that not being the case, especially since most of them will be unable to tell between a clock acting oddly because the hardware makes it necessary and a clock acting oddly because there's an actual bug or hardware failure causing it. The user on a server will deal with this by a) disabling the verification so boot completes, b) adjusting the clock before the operating system is booted, c) replacing the faulty RTC battery, or d) preemptively doing A because they've decided they don't care. That doesn't mean that it should be preemptively disabled for everyone because some people may choose to do it for themselves. One of the typical attitudes of the Linux community is that you should be trusted to know how something will affect you if you change it and to let you get on with it. Defaults are defaults for a reason, but you're free to change them as you wish.