It took way too much time to figure out how to override the automatic setting of the system console resolution of Fedora, RHEL, Rocky and AlmaLinux 10 Server installations, which is a good reason to write a blog post! Note that this post has nothing to do with X11 or Wayland, it concerns the resolution of the kernel’s framebuffer device console.
The default console resolution is probably the highest supported resolution by the video card and display. In some cases, however, this is highly undesirable. For example if the determination of the maximum resolution fails.
The following was tested on a clean AlmaLinux 10 (v2) UEFI boot install with an old AMD video card supported by the radeon kernel built-in and amdgpu kernel module. The first framebuffer device loaded at boot is the simple-framebuffer, then replaced by the radeon frame buffer device.
TL;DR
The system console resolution can be set at boot by adding a suitable video kernel parameter to the GRUB2 command line, which is probably best done using grubby. Lowering the resolution can be as simple as adding something like video=800x600.
Adding GRUB Kernel Boot Parameters
On a standard installation it may be difficult to change the resolution after boot. On Debian there is the fbsetcommand but this was not available by default on Alma. (This and this link are related to fbset.) To change the console resolution at boot time, however, it needs to be set on the GRUB (GRUB2) boot command line, using the video kernel parameter.
On AlmaLinux 10 and similar systems, a kernel boot parameter can be added in /etc/default/grub file and the command sudo grub2-mkconfig -o /boot/grub2/grub.cfg then takes that file and re-creates the grub.cfg file that is used at boot by grub. This works with legacy boot, but by default it does not work with UEFI boot: In AlmaLinux 9 and later, the EUFI boot GRUB reads /boot/efi/EFI/almalinux.grub.cfg, which is just a wrapper that makes the UEFI GRUB read /boot/grub2/grub.cfg. In addition, and this is important, the boot entries are by default taken from the /boot/loader/entries/*.conf files, because the /etc/default/grub file enables this with GRUB_ENABLE_BLSCFG=true by default.
Changes to /etc/default/grub, such as modifying the boot line to something like GRUB_CMDLINE_LINUX="resume=UUID=bd4adbc2-953e-4ee7-a8fe-1e21b5bad89b rd.lvm.lv=almalinux_server/root rd.lvm.lv=almalinux_server/swap video=800x600" does not change the *.conf files when using grub2-mkconfig.
The solution is either setting GRUB_ENABLE_BLSCFG=false, or adding the video parameter directly into the *.conf files. (Thanks to this post explaining the boot process!) The latter will might stop working after a kernel update when a new .conf file is added for a new kernel. It is unclear if the first method is more reliable long-term. Hopefully the parameters from /boot/grub2/grub.cfgare included in boot lines for newer kernels. I have not tested that. When GRUB_ENABLE_BLSCFG=false, you will see additional lines in the output of grub2-mkconfig searching for linux images and adding the menu items one by one.
Another, likely better, solution is using the grubby command. This utility does update the *.conf files along with /etc/default/grub, and /boot/grub2/grub.cfg. For example, sudo grubby --update-kernel=ALL --args=video=800x600 will add or replace the video parameter in all boot lines in all files. Hopefully this persists across kernel upgrades too.
Setting the Console Resolution
Setting an arbitrary resolution using the video parameter works as long as the radeon driver supports the mode. A nonsensical video=1x1 would fail and result in a very high resolution that we were trying to avoid. A real one video=800x600-16@60 would result in 16/16 depth not supported error messages from both simple-framebuffer and radeon, but ended up with a low resolution console. I tested with video=1600x1200 and video=720x400 and the console resolution changed accordingly. Unplugging and plugging the display cable results in radeon drm complaining about mode not supported in the kernel log, but that does not change the video output.
I did manage to avoid the User-defined mode not supported message in the kernel log, even for the simple-framebuffer, by selecting one particular mode but this is not really important. The radeon driver just needs to be able to handle a similar mode to that specified with the video parameter.
It is possible to create your own EDID file and force the use of that instead of the data pulled from the display. But it is a hassle to capture or create an alternate EDID file, so if the solution here works, it is better to leave EDID alone. Specifying the EDID binary file will require adding another parameter to the grub boot lines and we now know how to do that.
Miscellaneous Notes for Debugging
To show relevant lines in the kernel log do: sudo dmesg | grep drm. (DRM stands for Direct Rendering Manager, which manages the GPU and is responsible for setting display modes.)
To check if the set value is a supported mode after booting, in the kernel log. If there is an error it will be listed there including User-defined mode not supported. It is okay if the simple-framebuffer does not support the mode. radeondrmfb does need to support it.
To check the latest GRUB boot command used to boot your system execute cat /proc/cmdline.
Common relatively low resolutions are 720×400, 640×480, 720×480, 720,576, 800×600, 1024×768, 1280×1024. Some examples of higher resolutions include 1600×1200, 1680×1050, 1920×1080, 1600×1200, 2048×1280, 2560×1440, and 3840×2160.
Discover modes looking at cat /sys/class/drm/card*/card*/modes but note that the list is limited or truncated by the video setting. (You can try something like video=6000x10000 to see if you get a longer list. The mode at the top of the list is probably the mode actually selected based on the video kernel parameter.
The video parameter portion must follow the format:
video=<driver>:<conn>:<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]
where
<driver> : Specify a video mode at bootup
<conn> : Specifies the video connection type, such as VGA, DVI, HDMI, etc., see /sys/class/drm/ for available connectors, The connector names also appear in the kernel log just below the lines including Connector.
<xres>x<yres> : resolution in pixels
M: Enables the use of VESA Coordinated Video Timings (CVT) to calculate the video mode timings instead of looking up the mode from a database
R: Enables reduced blanking calculations for digital displays when using CVT. This reduces the horizontal and vertical blanking intervals to save bandwidth.
bpp: color depth or bits per pixel (e.g., -24 for 24-bit color).
@: refresh rate in Hz
i: Enables interlaced (non-CVT mode)
m: Adds margins to the CVT calculation (1.8% of xres rounded down to 8 pixels and 1.8% of yres)
e: output forced to on
d: output forced to off
D: digital output forced to on (e.g. DVI-I connector)
You can override the modes of several outputs and multiple graphics cards individually, using multiple video parameters on the same line. Some references here and here and here.
Mode setting could be disabled altogether by adding kernel parameter nomodeset, and in addition any driver-specific parameters such as nouveau.modeset="0" for NVIDIA, radeon.modeset="0" for AMD radeon driver. Note, however, that amdgpu requires kernel mode setting (KMS) in order to work, so nomodeset will prevent the module from loading. It is very easy to end up with a dark screen, so nomodeset is not a solution.
This is a good overview of Kernel Mode Setting (KMS).
Published: 20250615