Welllllp,
I sure didn’t expect this sudden disaster. Updates bricking an OS has been extremely rare for me, especially since I quit Ubuntu and it’s derivatives. I [try to] only do rock-stable, mega-reliable software on my home computer, even if it’s a little dated and it isn’t what all the cool kids are using. First priority is reliability and stability. Second priority has been “ethics,” for lack of a better word, meaning I want to avoid the crazy woke stuff that Free and Open Source Software (hereafter: FOSS) has become lately. But such purity has it’s price, I guess.
A previous update to GhostBSD wiped away LibreOffice, Xournalapp, and some other software. But it reinstalled easily and no data was lost. No big deal. But yesterday’s update bricked the whole system. It freezes eternally just before the Login screen should appear. Normally I would simply boot from a previous Boot Environment and all would be well. I had never needed to try that option until after yesterday’s update, but even the older Boot Environment locked up at the same point and never loaded the Login screen even with multiple attempts.
So I searched the great GhostBSD forums for some explanation and help. I did find an explanation, but not any help.
“Vimanuelt” in this thread wrote:
In my experience, OpenBSD and NetBSD mostly avoid this problem, and on FreeBSD an AMD or Intel GPU usually fixes it. These systems achieve stability because they use conservative graphics models. They avoid aggressive power management, frequent mode changes, and complex recovery paths. By limiting what the graphics stack can do, they reduce failure modes and gain predictability.
FreeBSD chose a different approach. It adopted DRM KMS as a central graphics layer and followed a Linux style model that expects frequent transitions and resets. FreeBSD, however, never fully implemented the recovery mechanisms that this model assumes. When a failure occurs during a state transition, the system often has no reliable way to recover. On hardware that integrates tightly with DRM this problem appears less often. On other hardware it becomes obvious.
Because of this, GPU choice matters in practice. AMD and Intel GPUs use in kernel DRM drivers and fully participate in the DRM KMS model that FreeBSD implements. The kernel and the driver agree on GPU state, which makes limited recovery possible and greatly reduces freezes.
NVIDIA behaves differently on FreeBSD. It uses a parallel and proprietary kernel graphics stack that only partially intersects with DRM KMS. When a transition fails, the kernel, Xorg, and the NVIDIA driver can disagree about GPU state. Once this happens, the system loses recovery paths, and the display freezes while the rest of the system may continue to run.
My experience with MATE supports this explanation. MATE uses few GPU features and behaves conservatively. Once the desktop starts and remains in a steady state, it places little stress on the graphics stack. The absence of freezes so far does not mean the issue is gone. It only means the triggering conditions have not occurred yet.
That explains it. DRM KMS is the culprit, whatever that is, whether on the MATE desktop or Xfce, which I use. FreeBSD’s “different approach” that “never fully implemented the recovery mechanisms” used by their different approach to the graphics stack is unrecoverable.
GhostBSD would do well to reconsider FreeBSD’s “different approach” and use what has been reliable in the other BSDs.
Perhaps I’ll mess around with those other BSDs a bit, but the next time I experiment it likely be with the most “ethical” Linux distribution I can find rather than with any desktop BSD at all.
Robin's Rants and Raves 
