GhostBSD and NVIDIA

abpp

GhostBSD 25.x install ISO complains of my NVIDIA card and stops installation and takes me to the Fish shell. How can I bypass it and/or use generic video?

vimanuelt

sudo xconfig manual

abpp

vimanuelt But how ? This happens during installation. Should I do that when the installer drops into the Fish shell ?

abpp

vimanuelt it's funny how older versions do that automatically.

abpp

Your trick worked. But then the Live Image installer hangs and crashes on GhostBSD release 25 and 24. It works well with 23, though.

vimanuelt

Yes. It appears that newer drivers have dropped support for many legacy devices. The most robust long term solution, in my view, is to reduce reliance on DRM KMS altogether.

FreeBSD currently depends heavily on the facilities provided by DRM KMS, rather than offering a first class non DRM KMS graphics path. While this approach works well for modern hardware, it significantly narrows the options available for older, embedded, or otherwise atypical devices.

I have begun work, outside of GhostBSD, on a non DRM KMS graphics solution that can coexist with DRM KMS when available. Development is ongoing, but commercial commitments currently take priority, so it may be some time before the project is ready for broad public use. That said, the effort has already been publicly announced, including an initial discussion on Hacker News.

abpp

vimanuelt but that even happened when I selected VESA.

vimanuelt

abpp
What you are encountering is not a configuration mistake and it is not caused by selecting the wrong video option during installation. In newer GhostBSD releases, choosing VESA no longer guarantees a DRM free graphics path. The kernel now initializes DRM KMS very early in the boot process, before Xorg or installer level configuration is applied, which means the graphics hardware is already probed and partially driven by DRM regardless of the selected option.

In older releases such as GhostBSD 23, the system could fall back to legacy framebuffer behavior when DRM failed. Xorg could start using VESA without the kernel forcing DRM drivers, and the installer would continue even if graphics initialization was imperfect. That fallback path began to weaken during the FreeBSD 13 lifecycle, as devmatch more aggressively auto loaded graphics drivers and DRM KMS became the assumed default. VESA still existed, but it stopped being a reliable escape hatch.

The decisive structural change occurred during FreeBSD 14 development, when DRM KMS transitioned from an optional acceleration layer into a foundational subsystem. Graphics probing moved earlier in the boot process, and failure cases were no longer expected to recover into legacy modes. By the time GhostBSD rebased onto FreeBSD 14 and early 15 snapshots, this behavior became unavoidable in the installer and live environments.

This is why GhostBSD 24 and 25 fail on older NVIDIA hardware even when VESA is selected, while GhostBSD 23 continues to work. VESA now only affects how Xorg attempts to start after the kernel has already made its decisions. Once DRM fails, the graphical installer cannot recover and drops to a shell. In short, DRM now loads before user level configuration can intervene, the legacy fallback path has effectively disappeared, and what you are seeing is the accumulated result of DRM KMS becoming the default truth of the graphics stack rather than a user error.

I have been working on drawfs and Semadraw to provide a kernel level graphics solution that offers users a viable alternative to the current DRM KMS dependent model, and is designed to operate both with DRM KMS when available and independently of it when it is not. In the near term, it is likely that conditions in FreeBSD will continue to tighten rather than loosen, as existing assumptions around modern hardware and DRM centric workflows deepen. In practice, this means that meaningful change often does not originate upstream, but instead comes from end users who decide to address the problems they experience directly and build the solutions they wish existed.