GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset video=uvesafb:mode_option=1280x800-24,mtrr=3,scroll=ywrap"

What does this line mean?

Can anybody explain it word by word?

1 Answer 1


quiet disables most of the log messages(shown by dmesg command).

I think the splash option starts the plymouth service from the initial ram-disk after the kernel goes through some initialization code.Plymouth is to show you the logo of the distribution or the logs of the systemd initialization.

nomodeset is to disable the Kernel Mode Settings(a.k.a KMS) during bootup .Mode settings enables the kernel to control the graphics hardware itself and change the modes of GPU (graphical or text mode , resolutions, rotations and so on) and it's for making a smooth and flicker-free splash screen (the option above) , but it may cause some problems in some graphics hardwares or even blackscreen.Disabling it forces the kernel to use the BIOS modes.For more information see this answer.

video option is to mention the video mode option.Some global options to be used in the underlying GPU.And the uvesafb is actually a generic framebuffer driver which makes use of the standards set by the VESA association. mode_option=1280x800-24 means the resolution 1280x800 with 24 as the Color Depth or a.k.a Bits Per Pixel (8-bit for Red , Green and Blue channel each).

The mtrr=3 means the write-combining attribute.It's actually a caching technique to buffer the Read/Write requests to later release them in burst mode to better utilize the bandwidth and prevent consistent Read/Write cycles and resource exhaustion perhaps.

Because the Read/Write operations aren't released in-order , it can cause sever bugs and problems if gets utilized in most of the programs(Thread-safety is based on the assumption that those operations are done in-order) , but in framebuffers out-of-order memory operations is not a problem(You don't care whether the top-left corner of the image on your screen gets drawn first or the bottom-left one when a frame is rendered in less than 50 msec).So using it in the framebuffer operations (we're talking about the framebuffer driver uvesafb) makes sense.It can increase the performance quite a lot.

However using the MTRR API in the kernel is phased out almost completely in favor of the Page Attribution Table.Because with PAT you have finer control over the memory areas that you want to cache and it has more attributes than MTRR.

And finally the scroll= option gets one of the three possible values :

ypan : Enable display panning using the VESA protected mode interface. The visible screen is just a window of the video memory, console scrolling is done by changing the start of the window. This option is available on x86 only and is the default option on that architecture.

ywrap : Same as ypan, but assumes your gfx board can wrap-around the video memory (i.e. starts reading from top if it reaches the end of video memory). Faster than ypan. Available on x86 only.

redraw : Scroll by redrawing the affected part of the screen, this is the default on non-x86.

In fact it's there to set the mode of the scrolling operation operation when you're in the text mode(e.g text-mode console not graphical)

You can read more about that driver here.

If you want to read more about kernel command-line options , take a look at the official documentation.

Hope it helps.

  • 1
    When you say that MTRR option is obsolete, does it mean that there's an option to actually set up corresponding PAT entries? If not, then it can't be obsolete from the point of view of the kernel command line.
    – Ruslan
    Commented Jun 19, 2020 at 21:23
  • @Ruslan I have to admit that the command-line option still can be used for uvesafb , but the usage of the MTRR API is almost completely phased out from the kernel and drivers in favor of PAT.And you're right in the sense that there's no exact alternative of MTRR for PAT in the uvesafb options so it shouldn't be obsolete. I did a tiny mistake there and mixed those up.However thanks for pointing out.I updated my post. Commented Jun 19, 2020 at 23:00
  • @isanae Yes, you're right . Thanks for pointing out . Updated. Commented Jun 20, 2020 at 11:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .