== Linux kernel mode setting on servers (and Ubuntu 22.04) In the abstract, Linux's kernel mode setting (KMS) is having the kernel configure the display resolution, depth, and frequency in the graphics hardware instead of leaving it to user level code like the X server. In practice, KMS is three things that are currently completely tied together; the kernel graphics driver handling the actual mode setting, [[the kernel console switching from VGA text mode to a framebuffer console TextAndFramebufferConsoles]], and the kernel changing the graphics hardware to what is supposed to be the ideal (display) resolution when KMS activates (usually as the graphics driver is loaded). On desktops, this has a clear usage case and success story. The GUI environment is normally going to use KMS to set the display to its theoretical ideal resolution as soon as it starts. Setting the display up before then results in a smoother boot experience with less flashing, and it makes LCD displays happy as fast as possible (some of them will nag at users with on screen displays of 'I am not at my ideal resolution'). And if modesetting fails, everything is out to lunch anyway (unless the login GUI can notice and invoke some sort of resolution fallback). (Display servers, login GUIs, and desktop environments are also by and large capable of coping with monitors coming and going, with potential adjustments to the settings in the graphics hardware via KMS.) The story is less clear on servers, which normally don't require graphics the way desktops do (large text consoles may be nice, but they're mostly not essential). That all three parts of kernel mode setting are connected together means that server text consoles are crucially dependent on the initial kernel resolution setting working correctly. If the kernel graphics driver sets a mode that the graphics hardware, the display, or both can't cope with, then you get a blank and unusable server console. Your only recourse is the giant hammer of the '_nomodeset_' kernel parameter, which turns of all three parts at once. ([[Even on Fedora 36 https://blog.dowhile0.org/2022/04/22/fedora-36-a-brave-new-drm-kms-only-world/]], '_nomodeset_' seems to leave the kernel using a VGA text console based on kernel log messages and other signs.) Unfortunately, [[the kernel's initial resolution setting doesn't always work on servers https://twitter.com/thatcks/status/1527656845623566337]] ([[also https://twitter.com/thatcks/status/1519003303203549190]]). The Ubuntu 22.04 normal server kernels appear to be extremely bad at this on our Dell 1U servers and some other servers here; the common element may be the use of Matrox video hardware, and [[there's an interesting recent Matrox driver change https://patchwork.freedesktop.org/patch/477617/]] that sounds like our issue. I don't know what the odds are of Ubuntu picking this up for a private patch to their 22.04 5.15 kernels. (The bug made it into 5.15, which is the Ubuntu 22.04 base kernel; the fix appears to be in 5.17. As far as I can tell, [[Ubuntu's 'jammy' 22.04 kernel repository https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy]] doesn't currently have this fix. The [[Ubuntu kernel bug tracker https://bugs.launchpad.net/ubuntu/jammy/+source/linux]] doesn't seem to have any bugs on this at the moment, and I'm not sure I'm energetic enough to file one given [[the probable low odds of useful success UbuntuBugReportsUseless]].) Using the giant hammer of '_nomodeset_' is in a way unaesthetic when all you really need is for the kernel not to change the display mode away from whatever the BIOS or EFI set it up as. And there are potential advantages to having a DRM enabled framebuffer console, such as better font handling, better speeds, and perhaps more text on the screen. However, I'm not sure how much difference it makes in practice even in general, and for us it's certainly not all that important. What we care about is the console working on our servers. PS: I'm not sure how EFI booting interacts with '_nomodeset_'. We have one machine that boots this way and it claims that the kernel console is a resized fbcon one (there are 'fbcon: Taking over console' and 'Console: switching to colour frame buffer device 128x48' kernel messages at boot time). This doesn't seem to come from the Matrox kernel driver, which isn't loaded. However I'm not at work to plug in a monitor and verify that it really is working with that text resolution. (Booting via EFI apparently activating the Linux framebuffer was an issue in [[my failure to migrate my office workstation to EFI booting MBRToUEFIBootFailure]]. At least these days you don't seem to get those obnoxious penguins when you boot with EFI.)