Monday, September 14, 2009

GRUB 2, graphical boot tips to set the desired VGA console mode.

Yes, everyone wants graphics, or better, the ability to customize things to suit different situations. I have always suggested programmers regarding interfaces and programs in genre to let the user be comfortable to set and change almost every aspect of program GUI, at least icons, fonts, backgrounds and often ii found some programs being too customizable, on the contrary.

Let's take a look at GRUB 2, also called grub-pc by updates that the Debian distro suggests. GRUB 2 is the successor of the GRUB bootloader, commonly shipped within the majority Linux distributions. Basically i will cover only some graphical aspects that GRUB 2 seems to be strong with: customization of fonts, background, console modes directly set by GRUB 2 itself, no more limitation to the resolution of 640x480 pixels at startup, can be used bigger background pictures also at the resolution of 1650x1050 pixels.

Our favorite kernel parameter vga=791 for example, is now deprecated (if using GRUB 2), and it's a little tricky to set correctly the console mode. The configuration file for GRUB 2 is now called grub.cfg in place of the old menu.lst whose we were addicted, but resides in the same directory /boot/grub. Things are very distribution specific i think, but remain the fact that configuration changes rely on the grub.cfg file that we have to alter in some way. Debian is putting the defaults into /etc/default/grub where you can find and set common used parameter easy to understand.

"For example i use Debian within VirtualBox at a resolution of 1280x800 for the console and also for the Xorg server. If you want you to start with this resolution also for GRUB 2 (remember in the past was very limited this feature, and if you are using VirtualBox or other virtualization programs the annoying result was in resizing the window and than enlarging upon the system goes into graphical mode, for example, with the splash screen: usplash, splashy and others), very nice, no more discrepancies between modes: the line to change into the /etc/default/grub file is GRUB_GFXMODE=1280x800 and then issuing update-grub. The resulting action is to write the line set gfxmode=1280x800 into the grub.cfg file."

We are half a way to our objective, to change also the resolution of our console. We need two conditions, the terminal must be set to insmod vbe line MUST be present in your configuration file (this ensure correct console mode settings, if you note this instruction is almost identical to load a kernel module) and the option gfxpayload=keep MUST be set. This will keep our 1280x800 resolution also for the console, YEAH! no more resizing on VirtualBox! and this is not the end. Someone reported that adding gfxpayload=my_resolution will be able to set a different resolution for the console instead of having the same of the GRUB 2 menu, sincerely i have not tested it. Why i have not tested it? The strong point is that to change grub.cfg requires a little more effort than editing it with a text editor, because all your changes will be discarded when you run the command update-grub.

/boot/grub/grub.cfg excerpt :

set gfxmode=1280x800
set gfxpayload=keep
insmod gfxterm
insmod vbe

update-grub reads the configuration stored in the /etc/default/grub file an the scripts that resides into the /etc/grub.d directory at least on Debian (i suppose is the same for other distributions). To set the option gfxpayload=keep i had to modify one of this file cause i discovered that this line MUST be the next after the gfxmode one, like you can note above.

You have to find the file or script responsible to change the content of your grub.cfg configuration file and append the appropriate line, after the gfxmode sentence, gfxpayload=keep to keep the same resolution of the GRUB 2 menu for the console (wider resolutions result in smaller console fonts). In my case i had to edit the script 00_header stored into the /etc/grub.d directory.

There are other scripts into this directory, responsible to set other parameters, like theme (background picture an font color), distribution and custom OS. To change the background image of your GRUB 2 menu is almost the same process, find the script or configuration file that change the attribute of the background_image instance of the grub.cfg, and change the line pointing to the image (usually a .png or .tga file) with the one you like, i have tested it with a resolution of 1650x1050 pixels modifying the script 05_debian_theme, in my case, stored into /etc/grub.d directory as well.


Due to request, i will add the correct edit made to the 00_header script in order to maintain settings, just a clarification:

1. We are on Debian and we are talking about GRUB 2 (NOT GRUB, GRUB 2), on other Linux distributions may vary.

2. Your grub resolution must be set through the variable GRUB_GFXMODE=my_resolution into /etc/default/grub file, to avoid the loss of our settings on every update-grub command. And for the GRUB 2 menu its done. Let proceed for the console VGA console modes resolution, cause someone may be more comfortable with different settings despite the GRUB 2 menu ones, just to understand: if the GRUB 2 menu is set to 640x480 and the console mode is 1024x768 could lead into an aesthetic issue, is not a mistake at all.

3. VGA console modes: At the moment of writing, for the console, we can only keep the resolution we set for the GRUB 2 menu. This is due by the instruction set gfxpayload=keep, that, in order to be inserted into our /boot/grub/grub.cfg configuration file we have to hardcode to the 00_header script, in this way:

/etc/grub.d/00_header excerpt :

set gfxmode=${GRUB_GFXMODE} <-- FIND THIS LINE
(as you note GRUB_GFXMODE is the variable we set before through /etc/default/grub)
set gfxpayload=keep <-- THIS IS FOR THE VGA CONSOLE!
(as you note the statement keep, obviously, keeps, what?, the resolution we set before through GRUB_GFXMODE variable set into /etc/default/grub)
insmod gfxterm

4. What I tested and what I not: set gfxpayload=keep MUST be UNDER the set gfxmode=${GRUB_GFXMODE} statement, i tried to put it at the end of the grub.cfg file through other scripts that Debian explicitly define custom, like 40_custom (always in our GRUB 2 scripts dir /etc/grub.d), but nothing worked, so like any well made worker i found my way.

So, I hope to have been more "exhaustive" this time and i excuse me if have missed something, that's it. I salute remembering you that Linux is "you won't find nothing to work if you don't made it to work" (like other few things).

Thanks to the Arch Linux community for the gfxpayload=keep input that has permitted this post. Someone reported that gfxpayload=my_resolution also worked on some configurations. I remember that the vga=console_mode_(HEX_or_DEC) kernel parameter is deprecated (don't know until when), when using GRUB 2.


ULIX said...

Very help full, I was thinking those people where working backwards, your article help me consolidate my toughs

harrison3001 said...

Thanks ULIX! I really appreciate you like this post. If you want also to share something else, feel free to do it! Keep in touch and happy customizing!!!

the tentmaker said...

Can you provide the edits to 00_header? The correct edit is not readily apparent to me. I have edited the grub.cfg file to include "set gfxpayload=my_resolution" and it works, but I know it will be wiped the next time I run update-grub. Thanks.

harrison3001 said...

ADDENDUM to the post to be more clear, i hope.

kay said...

Thanks! Very helful and worked!

harrison3001 said...

Thanks kay! :)

Crimperman said...

Thanks for posting this - very helpful.

Instead of hardcoding gfxpayload=keep into 00_header I adopted the variable system already employed by Debian..

So I added the bold line below to /etc/default/grub

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'

and I then added these two emboldened lines to /etc/grub.d/00_header

if [ "x${GRUB_TIMEOUT}" = "x" ] ; then GRUB_TIMEOUT=5 ; fi
if [ "x${GRUB_GFXMODE}" = "x" ] ; then GRUB_GFXMODE=640x480 ; fi
if [ "x${GRUB_GFXPAYLOAD}" = "x" ] ; then GRUB_GFXPAYLOAD=keep ; fi


if loadfont `make_system_path_relative_to_its_root ${GRUB_FONT_PATH}` ; then
set gfxmode=${GRUB_GFXMODE}
set gfxpayload=${GRUB_GFXPAYLOAD}

That way you can set gfxpayload by editing /etc/default/grub like everything else.


tz said...

You can have it check several modes in order of preference:

set gfxmode="1024x768x32;800x600x32;640x480x32;1024x768;800x600;640x480"

Also you can use grub-mkfont to use someth like Terminus (e.g. the 12x6)

harrison3001 said...

Thanks tz!!!

Stefan Hellmann said...

The gfxpayload dariable didn't worked for me. Every time i boot my grub crashed. I used the vga=794 variable instead of gfxpayload. It's deprecated but it works.

harrison3001 said...

Thank you very much to everyone to the appreciation! :)

michan said...

I tried both yours and Crimperman's solutions. Neither worked. :(

The resolution I want, 1280x800, is listed when I run vbeinfo within grub (other resolutions fail to load too).

Might I be missing any package(s)?

harrison3001 said...

... in reply to michan:

it's possible you have not loaded the modules for the framebuffer console into the kernel (someone is blacklisted).

Try this:

hwinfo --framebuffer
(look if your desired resolution is listed, you have to install hwinfo package), if nothing happen is almost sure that you have no framebuffer module (do lsmod to control).

.. (on Debian)
1. edit /etc/initramfs-tools/modules
2. add fbcon and vesafb modules

(vesafb is blacklisted on Debian)
3. /etc/modprobe.d/blacklist-framebuffer
4. commenting vesafb
5. update-initramfs -u

Then your grub configuration should work:
set gfxmode=1280x800
set gfxpayload=keep (if you want to keep 1280x800 for the console)

Let me know. Hope this help.

harrison3001 said...

.. another thing:

is it possible (with new kernels like 2.6.31), that some distribution is no more compiling fbcon and vesafb as module.
A solution is to use uvesafb module adding:

uvesafb mode_option=1280x800-16 to /etc/modules
update-initramfs -u

IMPORTANT: When using uvesafb module be sure to install the v86d package and take a look at the README for the correct configuration of kernel parameters.

Tested with VirtualBox at 1280x800-16 and on Debian on a real machine at 1680x1050-8.

michan said...

Thank you for your answer. I'm on Debian testing with the 2.6.30 kernel. I made it all the way to

3. /etc/modprobe.d/blacklist-framebuffer.

That file does not exist. So vesafb can't be blacklisted, can it?

michan said...

Hmm… I think something is b0rked, because my /boot/grub/grub.cfg isn't being updated wile running update-grub.

harrison3001 said...

... in reply to michan:

you are right /etc/modprobe.d/blacklist-framebuffer is on Ubuntu, i think it was present in older debian distros.

But i think you are missing some framebuffer module, try to change something into /etc/default/grub and then issue update-grub, then control /boot/grub/grub.cfg for changes, i hope you have the grub2 (grub-pc) package installed and not the old one. Let me know if you find the solution.

michan said...

I changed the value of GRUB_TIMEOUT in /etc/default/grub and indeed the value of set timeout was changed in /boot/grub/grub.cfg.

However, the lines

set gfxmode=1280x800
set gfxpayload=keep
insmod gfxterm
insmod vbe

are not being added.

harrison3001 said...

... in reply to michan:

to let "set gfxmode=1280x800" to appear into /boot/grub/grub.cfg, you have to set GRUB_GFXMODE=1280x800 into /etc/default/grub, and then issue update-grub, as you done before with the timeout. The others, i mean insmod gfxterm ... is the default. Let me know, then we will see the keep "trick" if you really need it.

harrison3001 said...
This comment has been removed by the author.
michan said...

You were right. It works now. I think it started to work when I ran

dpkg-reconfigure linux-image-`uname -r`

but I'm not sure.

Thank you for helping me.

Steve said...

Worked for me on an old IBM ThinkPad 600E. (PII 366, 96 megs of RAM, running a minimal install of Ubuntu Server with LXDE) I made the following changes.

In /etc/default/grub, I added:

In /etc/grub.d/00_header, I changed
   set gfxmode=${GRUB_GFXMODE}
   insmod gfxterm

   set gfxmode=${GRUB_GFXMODE}
   set gfxpayload=keep
   insmod gfxterm

Added the following to /etc/initramfs-tools/modules. This laptop has a Neomagic video controller. Thought I might try the neofb driver before vesafb.

Commented out fbcon and neofb in /etc/modprobe.d/blacklist-framebuffer

Ran the following commands:
   sudo update-initramfs -u
   sudo update-grub

Rebooted, and voila! Framebuffer at the same resolution as Xorg. Thanks for the pointers!

And it couldn't have been simpler. I don't understand why anyone would miss appending vga=791 in menu.lst once they see how simple, how effortless, how intuitive the process is now! ;)

Anonymous said...

i have works:

cat /etc/grub.d/01_my_header
#! /bin/sh -e



. ${libdir}/grub/grub-mkconfig_lib

# from the 00_header

cat << EOF
if loadfont `make_system_path_relative_to_its_root ${GRUB_FONT_PATH}` ; then
set gfxpayload=keep

i have only one problem, but it is maybe VirtualBox related - the window is in desired resolution, but the visible part is only with original VirtualBox size (partialy visible image and menu)

The Crimperman's suggestion do not works, because customizing the grub-mkconfig is needed...

harrison3001 said...

In reply to the latest comment, I think there are two possibilities, one is to add a custom console mode to your VirtualBox Virtual Machine (only linux of course), with the command VBoxManage setextradata "Debian" "CustomVideoMode1" "1280x800x16". As you can see i added 1280x800 so when VirtualBox starts and grub 2 is configured with the same resolution the windows remain "sticky" at this resolution, also i have configured Xorg to start too at 1280x800 pixels and i think this is your case.
Be sure you have the right kernel modules for the vga console properly configured. Hope this help!! Thanks for the comment. Andrea.

Solveig said...

Hi everyone,
first of - thanks for this helpful discussion of this rather tricky problem: this is actually one of the very few really helpful threads I found.

Now to "business" ;-)
On my (x)ubuntu 9.10 machine I ran into the same problems michan described earlier: changes made in /etc/default/grub and /etc/grub.d/00_header were not written to /boot/grub/grub.cfg , thus being ineffective. After uncounted trials and the use of strong language ;-) I was ready to let the thing go and opt for a quick and dirty hack (like using the vga=xxx option) or even reverting to legacy grub, when I remembered the one thing, I had not tried was a 'dpkg-reconfigure grub-pc' ... to my utter amazement that did the trick (opting for keeping the edited files when asked, of course).

I did not examine the thing further, but I suspect that the problem is with the update-grub(2) script, although now (i.e. after reconfiguring the grub-pc package) it seems to work fine...

(Oh and don't forget that you will probably need to add fb support)


Regenpak said...

While your howto is great, I can't get the "set gfxpayload=keep" command to work. If I hash it out then grub comes up fine with the chosen resolution (1024x768, 1280x1024) but then reverts to the old 640x480 resolution. If I uncomment it then the grub menu (which I enabled to try vbeinfo) freezes for a long time then gets replaced by my desktop. Only when switching to a console I get a scrambled desktop, in 640x480.

So far had two systems refusing to co-operate, a Asrock Ion 330 and a HP DC7k8 with NVidia G86 dual head graphics thingie. How can I fix this?

harrison3001 said...

Thanks for the comment Regenpak, i think your problem does not rely on grub 2 or so, you have to be sure first you have the corrected framebuffer modules loaded into the kernel, for example fbcon or/and vesafb, check my two posts.
When they are correctly configured try a command like command like hwinfo --framebuffer (from the console, not from a terminal, just to be sure) and see what is listed (your available resolutions for the framebuffer). If nothing is listed you have missed something related kernel framebuffer modules. A common mistake is to miss to regenerate the kernel with the command "sudo update-initramfs -u -k `uname -r`, on debian, or your distribution specific one, so kernel modules are loaded at startup.
You have also to find out what modules are available for your kernel and also if they are "as modules" or compiled into the kernel. At all modules you need are fbcon and vesafb. You can check if they are loaded issuing the lsmod command. Hope this help, thanks again for the appreciation and feel free to let me know about your progresses, i will be glad to answer. Andrea.

Regenpak said...

Thanx for the quick reply! Snag is that hwinfo --framebuffer shows all the resolutions I want, and that the Grub menu is already in the right resolution! Only when booting continues it starts out in 640x480, unless I uncomment the "set gfxpayload=keep" directive. Then my console displays a screwed-up desktop. Maybe it's an NVidia issue. Oh well, I've got a whole weekend ahead so I'll play with it some more. Maybe even remove the graphics card and try the onboard Intel video of the HP.

BTW- it's a bog standard Ubuntu 9.10 install.

harrison3001 said...

Thanks Regenpak, i wondered which distro you were using.
In my past experiences with Ubuntu and framebuffer console i had some kind of a same problem. Try to disable the splash or set your desired resolution like:
Edit /etc/usplash.conf resolution
xres= your_xres
yres= your_yres
sudo update-initramfs -u -k `uname -r`
if you are using usplash i think that the ... payload=keep is not mandatory or necessary ... could be also possible but I'm not sure that is the video card, I'm on NVIDIA too (9600 GT), try to use uvesafb module instead of fbcon/vesafb.
Let me know which module are you using and if you are you use the usplash just to understand better. I'm on Debian Sid. Ciao!

Regenpak said...

Well, truth is stranger than fiction. It turned out to be a hardware issue. I use a Black Box 4-port KVM between my new PC and my 19" CRT monitor, and it does not forward the I2C datasignal (ID) on the VGA 15-pin connector. And I should have known, the same thing bit me before. The coin dropped when X-window would not let me set a sensible resolution. In the meantime I already had removed the NVidia card and reinstalled Ubuntu to use the onboard i915 Intel video.

When connecting the VGA cable directly to the PC it works flawlessly. Now I only have to figure out a way to force Ubuntu 9.10 to use my required resolution...

Jack said...

I'm on Ubuntu 9.10, I can't get the console resolution to change. I've followed the description and it didn't change my resolution in virtual console but I did notice that in /boot/grub/grub.cfg "set gfxpayload=" wont stay "keep". Every time I use "sudo update-grub" it returns back to being blank instead of staying "keep", Does anyone know what I'm doing wrong?

harrison3001 said...

Thanks Jack for the comment. I noticed that on Ubuntu the problem could be the use of the usplash. The Ubuntu splash screen, i think, has some internal routine that tries to revert the console resolution to the one used by usplash itself, for example if you use 1024x768 for the Ubuntu splash into /etc/usplash.conf the console will be the same ignoring the "keep" parameter. I say so cause i have tested it temporary disabling the usplash end i had the desired console resolution. I haven't yet found a solution to have the best of both worlds. I think it's possible to set the same resolution for grub via /etc/default/grub, and usplash via /etc/usplash.conf, for example both at 1650x1050, but i know the console characters could result small than desired.

Finn said...

I just tried, first did the change, then the uvesafb stuff, then the /etc/usplash.conf stuff.
Im on ubuntu 9.10 64bit with a 2 screen setup (twinview) on an 8600gt.
grub is perfect, and if i boot through safe mode everything is perfect, but normal boot results in the console being the right resolution but the text starts half-way through the screen horizontally (it loops around so text past the right edge comes around to the left) and about 20% from the top (no looping vertically).

This is very weird. any idea how it could have happened?

i guess usplash has something to do with it? since usplash doesnt happen in safe boot. dont know if dual monitors could effect it, but my second monitor displays about 20% below the first and to the right, so attempting to center the console across both would probably place it about where it ended up...

also, first boot after the changes caused my monitor to give out of range, didn't happen after that, doubt its related though.

tbh, i dont expect a solution, this is a pretty wierd problem, but if you got any idea, id like to hear it.

harrison3001 said...

Thanks for the question Finn. I have to tell you that I'm not the most relevant person about (twinview) setups. Have you tried to temporary use only one screen or to use other modules like vesafb or disabling usplash to see what happens. Is the only thing i can say. I have to say that uvesafb, in my opinion, is far from perfect. Hope this help.

Finn said...

ok, I've investigated pretty much every combination of possibilities on here, and only 1 works for me:

1. I disabled splash (removed it from GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub).
2. I had uvesafb as described above (vesafb did not work, presumably because my kernel is 2.6.31 from what you said above).
3. I had the original fix (ie modifying 00_header) and setting gfxmode.

without these 3 it did not work, and anything other than these 3 proved either damaging or redundant in my setup. Hope this helps anyone else on a similar setup (all karmic users? maybe no. 1 can be avoided by most?)

turns out twinview was not to blame and was totally innocent, so theres nothing to blame except usplash.

anyway, everything seems good now, except if i want to nitpick, that grub is a tad blurry cos it runs at 60hz refresh rate and for some reason my screen doesn't like it, but thats really not a problem. and there seem to be some stability issues when changing between X and the console, but I'm not sure about that yet.

Keith said...

I have spent way too much time on this... I have read through all the posts and have tried them all with no joy. Ubuntu 9.10, Kernel 2.6.31-20, Nvidia card on Dell laptop. I want 1280x800 and I get that all through Grub and in X. The problem is with the VTs. I get either nothing but a cursor or graphic bar at the top left or a garbled screen when I use uvesafb in initramfs.conf. I have tried turning off splash, but get the same thing regardless. My splash resolution is already set to the correct 1280x800, and I get the same thing either way. The only way I get a terminal screen of 'reasonable' resolution is if I use the vga=792 to set it (I know it is 1024x768), but I get a VT this way and cannot otherwise. Since Grub2 is still beta (I am running 1.97), I am hoping this will get resolved in the *next* release. I have the same problem with this laptop that uses a nvidia subsystem and also a panel PC that uses an intel subsystem. On both, the only way I can initialize the FB for the VTs is to use vga=xxx. What am I doing wrong?

harrison3001 said...

Hi Keith! Try this, i haven't yet tested Ubuntu Lucid, i will test soon through VirtualBox, you have to add

set gfxpayload=keep into 00_header as follow (/etc/grub.d directory):

set gfxmode=${GRUB_GFXMODE}
set gfxpayload=keep <----------------
insmod gfxterm

set your desired resolution into /etc/default/grub (GRUB_GFXMODE), vga=... is now deprecated. Works on Debian, I'm sure. Hope this help. I will test on Ubuntu soon, as i wrote before it's possible that the splash reverts to its own resolution. Try to test disabling it for a while.

Keith said...


I appreciate the help. I had already tried that and just went and tried it again. IN /etc/devfult/grub, I have no parameters passed on the command line:

I have the line:

I also have the lines in 00_header:

if loadfont `make_system_path_relative_to_its_root ${GRUB_FONT_PATH}` ; then
set gfxmode=${GRUB_GFXMODE}
set gfxpayload=keep
insmod gfxterm

I "su update-grub" and reboot. With it set like this, I get nothing displayed until I get the X login page. I get Grub2 menu to be set to the resolution I select. In this case, it is 1280x800, but I get no VT and no boot messages displayed. If I , I see a white screen with some colored patches.

The only way I have been able to get messages and a VT is when I set it to vga=792. By the way, if I go to the grub prompt and type vbeinfo, 1280x800x32 shows as a valid configuration. This makes sense as Grub2 will display it at the menu.


harrison3001 said...

Sorry Keith. You are doing the correct way. I'm rearranging my virtual machines in the meantime. I know is a kind of strange problem cause on Debian, also experimental works. I remember in the past i was be able to do it work on Karmic, disabling usplash and managing some kind of dirty work through kernel parameters, like fbcon= ... modes etc (try to take a look at uvesafb parameters) . Sorry i don't remember precisely. Stay tuned I'm engaged too to make it work, i will post my results between three days. Sincerely, Andrea. Thanks again for the comments!!

harrison3001 said...

In response to Keith about console modes on Ubuntu Lucid.

I managed it to WORK!!! I'm very happy!! Hope this could be helpful everyone.

1. I installed a fresh copy of Ubuntu Karmic x64 on VirtualBox

2. add fbcon and uvesafb modules to /etc/modules as follow:

IMPORTANT!!! To make uvesafb work you need to install the v86d package.

/etc/modules excerpt:

uvesafb vbemode=vbemode=352 (i will explain further)

issue update-initramfs -u so this modules are loaded at startup.

352 is the Dec value of 0x160 (Hex), that is the resolution 1280x800x16, the one i use, you can simply convert the one you need with the calculator, and if you note is the value showed when you use the command vbeinfo through grub to get the available mode.

IMPORTANT!! is not the same value as the framebuffer one (hwinfo --framebuffer), don't ask me why.

3. I used GRUB_GFXMODE=1280x800x16, as usual in /etc/default/grub

4. I used set gfxpayload=keep in /etc/grub.d/00_header

5. That's it. With this setup works flawlessly with all your virtual consoles at 1280x800x16.

I think that will be no problems with Lucid i will install and test it as soon as possible. I retrieved informations about uvesafb through the related uvesafb kernel txt.

NOTE: The uvesafb configuration through /etc/modules is only needed if you have uvesafb NOT compiled into the kernel, OTHERWISE we have to pass a cmdline parameter to the kernel like we have done with vga=... In other words (i have not tested cause i haven't a kernel with the static uvesafb), but i think it should be something like: video="uvesafb:vbemode:352", I'm not sure about the double colon use, but I'm pretty sure about the first one, otherwise change the second with an equal, i hope.

This is what i discovered, hope this help, i will write a post soon. Let me know if works for you !!!

Keith said...

Well, firstly, thanks for digging into this. Secondly, It did not work. When I do vbeinfo from Grub, I do not have a 0x160, but I do have a 0x161 (353) mode. So I did what you suggested. I get the grub menu, still, but get a messed up VT and no messages on boot, still. It is 'different' because I get a full messed up VT instead of a nonblinking cursor. It looks like the wallpaper I have in X just skewed with a messed up vert or horiz timing. So, still no joy in getting a functional 1280x800 VT.



Keith said...

Ok, I did a little more poking around the web about uvesafb and figured that you had a typo in the commands. It is
uvesafb vbemode=352
uvesafb vbemode=vbemode=352.

Now I get a 1280x800 console *and* a 1280x800 grub menu. Yea! It works. Now if only the ubuntu docs would reflect this or update the grub2 and uvesafb somehow to work with this.

Thanks for the help. It is much appreciated.


harrison3001 said...

Yes Keith you are right, mistyped the most relevant thing. Sorry!
Following there is the corrected comment for everyone who followed the conversation. Thanks.

I will write a post soon:
Managing to work with console modes with grub and Ubuntu:

// Previous comment excerpt (CORRECT) //
1. I installed a fresh copy of Ubuntu Karmic x64 on VirtualBox

2. add fbcon and uvesafb modules to /etc/modules as follow:

IMPORTANT!!! To make uvesafb work you need to install the v86d package.

/etc/modules excerpt:

uvesafb vbemode=352 (i will explain further) <-- CORRECT

issue update-initramfs -u so this modules are loaded at startup.

352 is the Dec value of 0x160 (Hex), that is the resolution 1280x800x16, the one i use, you can simply convert the one you need with the calculator, and if you note is the value showed when you use the command vbeinfo through grub to get the available mode.

IMPORTANT!! is not the same value as the framebuffer one (hwinfo --framebuffer), don't ask me why.

3. I used GRUB_GFXMODE=1280x800x16, as usual in /etc/default/grub

4. I used set gfxpayload=keep in /etc/grub.d/00_header

5. That's it. With this setup works flawlessly with all your virtual consoles at 1280x800x16.

I think that will be no problems with Lucid i will install and test it as soon as possible. I retrieved informations about uvesafb through the related uvesafb kernel txt.

NOTE: The uvesafb configuration through /etc/modules is only needed if you have uvesafb NOT compiled into the kernel, OTHERWISE we have to pass a cmdline parameter to the kernel like we have done with vga=... In other words (i have not tested cause i haven't a kernel with the static uvesafb), but i think it should be something like: video="uvesafb:vbemode:352", I'm not sure about the double colon use, but I'm pretty sure about the first one, otherwise change the second with an equal, i hope.
// END of previous comment excerpt //

Thanks Keith!

Anonymous said...

Has anyone tried using the hex equivalent?

Replace vga=791

with vga=0x317

harrison3001 said...

Sincerely i don't like anonymous comments, please give a nick, just to be present. In reply to latest anonymous user: vga=xxx is deprecated by grub2. You can use the uvesafb through /etc/modules. Add the line uvesafb vbemode=279 to /etc/modules for 1024x768. You can find more information on "Fixing "black" framebuffer console in VirtualBox Linux Guest (Debian//Ubuntu)" post.

Bob-El said...

I am running Ubuntu 10.04 on my laptop. I set the grub resolution with the command "GRUB_GFXMODE=800x600" and the menu is displayed at that mode. However, when the boot process starts, the text display reverted back to 640x480. Following your advice, I edited /etc/grub.d/00_header with:

if loadfont `make_system_path_relative_to_its_root ${GRUB_FONT_PATH}` ; then
set gfxmode=${GRUB_GFXMODE}
set gfxpayload=keep
insmod gfxterm

Now when I boot, after the menu disappears, the screen is blank until just before the graphical "Ubuntu" display when text is displayed in 800x600 mode for about 2 seconds. I edited /etc/modules and added:

uvesafb vbemode=771 (which is 800x600x8)

When I rebooted it didn't make any difference. Do you have any more suggestions for me to try?

harrison3001 said...

Hi Bob-El thanks for the comment. I hope to be able to help you. First you have to see if your mode is supported. I think otherwise that may be some conflict with other framebuffer modules, like vga16fb. Try to investigate through dmesg output : "dmesg | grep buff" for example will give you an idea. Another thing could be that the framebuffer module is not loaded correctly, have you issued "update-initiramfs -u" to let the module be loaded through initrd. Read also my latest two posts about framebuffer. Hope this help.

Bob-El said...

I issued the "dmesg | grep buff" command and this is the output:

[ 23.340629] fb0: VGA16 VGA frame buffer device
[ 23.848773] Console: switching to colour frame buffer device 80x30

I can't honestly tell you I understand what it says but it looks error-free.

I read "Fixing "black" framebuffer console in VirtualBox Linux Guest (Debian//Ubuntu)" yesterday and didn't find it of consequence to my problem (or so I believed). I didn't try adding "video=efifb:off" because CTRL + ALT + F1 ... F6 works just fine for me. In fact, they were opening up fine when I was in 800x600 mode (I'm back to 640x480 at the present time).

I have no idea what "video=efifb:off" is/does, but if you think it's worth trying I can try it. I'm just a little bit paranoid about doing something that makes me not being able to boot to x-windows. Oh, yes, and I did issue "update-initramfs -u" before updating grub (assuming the latter was necessary) after editing modules.

As an aside, I Googled "What is efifb?" and this is the reply I got: "This is a generic EFI platform driver for Intel based Apple computers. efifb is only for EFI booted Intel Macs." Well that was useful...NOT... but, of course, it begs the question "What is EFI?" So I Googled that and got "electronic fuel injection". Somehow I think we're into another subject.

I also read "Plymouth Boot Themes on Lucid Lynx VirtualBox Linux Guest" which, I gather is the second article you wanted me to have a look at. It will be useful if I lose my splash.

If you think the above output looks okay, I can always give it another try just to be sure.

harrison3001 said...

Hi Bob-El! I think your console is OK if you can switch with F1 .. F6. The 640x480 could be the resolution of the splash that resizes before X startup. Are you using usplash? --> take a look in /etc/usplash.conf if i remember correctly. But, if you want to stick everything with 800x600. Grub must be 800x600 (and you are done), splash must be 800x600, and finally X must be configured at 800x600. I hope to have understood your issue .. hope this help. Le me know.

Bob-El said...

You seemed to indicate in your last post that if I wanted an 800x600 text console display I would have to set X-windows to 800x600. I'm running X-windows at 1024x768 which is the best configuration for my laptop. I don't know if it would go higher but I'm comfortable with 1024x768. Anyway, I decided to try the text at 1024x768 also. This is what I did:

1. Edited /etc/modules and added;
uvesafb vbemode=773

2. Executed;
sudo update-initramfs -u

3. Checked /etc/usplash.conf and it was/is set at;

4. Edited /etc/default/grub and set;

5. Edited /etc/grub.d/00_header and used;
set gfxpayload=keep
as shown below:
if loadfont `make_system_path_relative_to_its_root ${GRUB_FONT_PATH}` ; then
set gfxmode=${GRUB_GFXMODE}
set gfxpayload=keep
insmod gfxterm

6. Executed;
sudo grub-update

Then I rebooted. The changes didn't make any difference except that the screen blanked once the boot process started and stayed that way until the desktop loaded. It turns out that "set gfxpayload=keep" made the screen go blank. I commented it out and that restored the screen display but the boot text was again in 640x480 mode.

I fiddled with different settings until X-windows wouldn't load any more. I don't know why because I didn't do change anything in X-windows, I just tried different settings in grub, 00_header, etc. I finally got it going again and, here I am, right back to where I started.

One thing I'm sure of is putting "fbcon" and "uvesafb vbemode=773" in /etc/modules seems to do absolutely nothing.

This is a real head-banger.

harrison3001 said...

Hi Bob-El. I also encountered these problems. We need to proceed step by step.

1. Temporary uninstall usplash ans look at the console behavior.

2. Do the settings. gfxpayload and so on.

3. If they suit you need is something related the splash, but i have to tell you that it is normal when you have the usplash/plymouth installed that you don't see the console on boot. It boots directly into the GDM login.

4. If you have the black console again (with usplash uninstalled) there may be a framebuffer module that conflicts with uvesafb. I discovered that vga16fb could lead into problems. See the complete output of dmesg and pay attention to everything is related to the framebuffer. Take a look also at he output of lsmod to see if modules are properly loaded. In case vga16fb is the problem you have to blacklist through the proper file into /etc/modprobe.d/blacklist.framebuffer.conf.

5. In some cases i discovered that is not necessary to use uvesafb. Please be more specific about your configuration which distro are you using and which kind of splash and your desired behavior.

Bob-El said...


Thanks for your patience. I really do appreciate it.

1. I ran Synaptic Package Manager to uninstall "usplash" only to find it is not installed. The console behaviour is quite basic:
- After the boot starts I see the boot process text flash by at 640x480 res.
- The text scrolling stops.
- After a few seconds the word Ubuntu appears in the center of the screen and there are 5 white dots under it.
- The white dots alternate from white to red.
- After a few seconds of that the desktop appears.

2. I redid all the settings only this time I opted for 1024x768 instead of 800x600. What the heck!

3. Yes, I know it's normal now not to see the boot process. I want to be un-normal. :) Although usplash is not installed, plymouth is.

4. I didn't see much info relative to the framebuffer, however I did get these lines in the dmseg output:
[ 0.253165] efifb: probing for efifb
[ 0.253304] efifb: framebuffer at 0xe8000000, mapped to 0xf8080000, using 3072k, total 3072k
[ 0.253314] efifb: mode is 1024x768x32, linelength=4096, pages=1
[ 0.253320] efifb: scrolling: redraw
[ 0.253326] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 22.254517] uvesafb: failed to execute /sbin/v86d
[ 22.254578] uvesafb: make sure that the v86d helper is installed and executable
[ 22.254652] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
[ 22.254717] uvesafb: vbe_init() failed with -22
[ 22.254773] uvesafb: probe of uvesafb.0 failed with error -22
.....and then later...
[ 23.503753] vga16fb: initializing
[ 23.503763] vga16fb: mapped to 0xc00a0000
[ 23.503771] vga16fb: not registering due to another framebuffer present

Is vga16fb the problem or v86d?

FYI: The following is the lsmod output:
Module Size Used by
binfmt_misc 6587 1
ppdev 5259 0
vga16fb 11385 0
vgastate 8961 1 vga16fb
ipt_REJECT 1928 1
xt_comment 720 4
ipt_LOG 4542 5
xt_multiport 2378 4
xt_limit 1382 7
xt_tcpudp 2011 11
ipt_addrtype 1631 4
xt_state 1098 7
snd_intel8x0 25588 2
snd_ac97_codec 100646 1 snd_intel8x0
ac97_bus 1002 1 snd_ac97_codec
snd_pcm_oss 35308 0
snd_mixer_oss 13746 1 snd_pcm_oss
ip6_tables 11227 0
snd_pcm 70662 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss
nf_nat_irc 1124 0
snd_seq_dummy 1338 0
nf_conntrack_irc 3332 1 nf_nat_irc
nf_nat_ftp 1836 0
snd_seq_oss 26726 0
nf_nat 15735 2 nf_nat_irc,nf_nat_ftp
nf_conntrack_ipv4 10672 9 nf_nat
nf_defrag_ipv4 1073 1 nf_conntrack_ipv4
snd_seq_midi 4557 0
snd_rawmidi 19056 1 snd_seq_midi
nf_conntrack_ftp 5381 1 nf_nat_ftp

PART2 to follow...

harrison3001 said...

OK! I understand (i hope).

1. If you wand to use uvesafb, v86d MUST be installed. Could be the culprit.

2. vga16fb could lead into problem try to blacklist through /etc/modprobe.d/blacklist.framebuffer.conf:
blacklist vga16fb, and issue the usual update-initramfs -u.

3. Someone reported, thanks to Ubuntu forums guys, and i can confirm this behavior, that you have to create the /etc/initramfs-tools/conf.d/splash with FRAMEBUFFER=y in it if you have no splash at startup and issue the mandatory update-initramfs -u command.

4. Try uninstall Plymouth for a while to see the results.
, also try to use only one framebuffer you are using three of them. To skip efifb, add efifb=off to the kernel line into /etc/default/splash. Take always a look a dmesg as you done before. There must be only a framebuffer. At this point i don't think uvesafb is needed. Start using only efifb blacklisting vga16fb without uvesafb (uncomment it in /etc/modules).

I think we are near the solution. Let me know.

Bob-El said...

1. Booting with the kernel option efifb=off hangs generates an error and a boot option menu (rescue menu?).

2. Commented out "uvesafb vbemode=791" in /etc/modules. Rebooted. It didn't make any difference. Later, I commented out "fbcon" as well, rebooted and that didn't change anything either. (I ran "sudo update-initramfs -u" and "sudo update-grub" each time also.)

3. I blacklisted "vga16fb". Ran "sudo update-initramfs -u" and "sudo update-grub" and rebooted. No change. Looked at dmesg and found this line;
[ 23.493415] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver
I checked all the previous dmesg outputs which I'd saved and found the same line with the exception of the first one which I had saved yesterday morning. I don't know why it's different than the rest. I guess it depends on what I did after I saved it. But all it's doing is replacing the generic driver with inteldrmfb, at least as far as I can see. The following lines say;
[ 23.493566] Console: switching to colour dummy device 80x25
[ 23.499887] Console: switching to colour frame buffer device 128x48
[ 23.647545] fb0: inteldrmfb frame buffer device

4. At this point I thought I'd try the efifb=off option on the boot again and this time it didn't cause a problem. So I saved dmesg and had a look. Lo and behold! efifb didn't turn off as commanded. Why? Just so you know I'm not crazy, here's the kernel command line as reported by dmesg:
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-22-generic root=UUID=2dcd4ac1-9b97-4ef7-bf1d-d2dfa8b39a50 ro i915.modeset=1 splash ipv6.disable=1 noapic nolapic efifb=off

It came to me that EFI VGA, the generic driver, is efifb. So, in actual fact, from what I can tell from the dmesg output, inteldrmfb is, in effect, disabling efifb. So whether efifb=off worked or not, it doesn't really matter.

5. I had a look at plymouth in the SPaM and uninstalling it would remove 3 essential packages. I chickened out. Is there a way to disable it instead of uninstalling?

So, although I'm not exactly where I wanted to be with the boot process, I think I've wasted far too much of your time (and mine as well). Here's what I've done in summary and what's happening:
- I've uncommented "fbcon" and "uvesafb vbemode=791" in /etc/modules
- "vga16fb" is blacklisted
- everything still works - I think (I'm always worried that fooling around with settings too much ends up screwing something else up. I guess that's a bit of a fatalist attitude, eh.
- there has been a change to the boot process and I guess what I've done has had some effect. When I boot now, I get a blank screen which is replaced, not by scrolling text, but what you would see after the text has stopped scrolling. Then the Ubuntu splash appears followed by the desktop. I'm happy to live with that and move on to other, more important things. :)

Thank you, once again, for your patience and suggestions. While the boot process is not exactly where I was hoping it would be, I've at least learned more about what's happening in the process.

harrison3001 said...

Thanks! It's not our fault. Finally i think that if you want the console you have to forget the splash and viceversa since efifb runs the splash. uvesafb is responsible for the console but they coexists very badly. What about the inteldrmfb?

Lastly i was getting crazy too to get everything working on my Ubuntu Lucid on VirtualBox, it's the very last thing i can suggest you :(.

My GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub is: quiet splash nomodeset (nomodeset found today, otherwise anything worked)

i have into /etc/modules
uvesafb vbemode=752

blacklist vga16fb
(try to blacklist inteldrmfb)

!!!! Have you created /etc/initramfs-tools/conf.d/splash
with FRAMEBUFFER=y in it?

everything is working properly at 1280x800, grub,console,splash, but i have to tell you that the same configuration don't work on Debian.
It depends also on your hardware, you have to find the correct balance, i can't say anymore.

To temporary disable plymouth you have to remove the splash parm from the /etc/default/grub and re-issue update-grub.

Hope this help. I salute.

Bob-El said...

I guess inteldrmfb is the driver for the Intel graphics chips on the motherboard. nomodeset would not work for me since I had to put the i915.modeset in grub in order for the GUI to work properly after I upgraded to 10.04. It wasn't a problem with 9.10. I wonder what's in store with 10.10?

I forgot to mention that I did create /etc/initramfs-tools/conf.d/splash with FRAMEBUFFER=y in it but it didn't do anything. Wouldn't splash have to be running for that to be of consequence. The app "Splash" was never installed on my system. Or maybe they're two different things.(?)

You said, "To temporary disable plymouth you have to remove the splash parm from the /etc/default/grub and re-issue update-grub." Actually, I did disable/remove "splash" from the kernel boot command line. All that did was to remove the Ubuntu name with the funky dots under. I still got a blank screen when the boot started (still do). In the default 640x480 mode the text appears as soon as the boot selection screen disappears. I've never been able to achieve that in the 800x600 or 1024x768 modes. the latter, BTW, is the max. res. my laptop supports.

I had blacklisted vga16fb but hadn't tried inteldrmfb so I blacklisted it too. After updating I rebooted but it still loaded. How can that be?

So I will live with what I've got and if some other ideas come up at a later time I may try them.

Thanks again for your help. Cheers.

harrison3001 said...

I hope you find your best Bob-El, I'm sorry can't help about this issues. Ciao!

Anonymous said...

Thanks a lot
have been trying to find a way to change console resolution for a long time...
this finally worked for me.

Jacques said...

In Ubuntu, you can set the gfxpayload=keep in the /etc/default/grub by setting LINUX_GRUB_GFXPAYLOAD variable to keep.

Anonymous said...

Jacques, looking through /etc/grub.d/10_linux on Ubuntu 10.04, shouldn't that be GRUB_GFXPAYLOAD_LINUX instead?


gnumber9 said...

great help page, much appreciated!

harrison3001 said...

Thanks gnumber9! :)

Hosting Nuggets said...

Arggh, I tried it out and all I get now at loading is a Loading initial ramdisk ... and then nothing else happens :(

harrison3001 said...

in reply to Hosting Nuggets:
it looks like Grub can't find the kernel image, you have to deal with Grub tools at startup, try at the kernel selection of Grub to type e this let you edit the boot parameters and also initrd an kernel images, maybe a typo led you to this behavior, then if you find the error type b to boot with your made correction. If you can boot now correct your grub.cfg file to make it permanent ... otherwise (it's a little hard) you have to find the kernel image always with the Grub 2 commandline, i had this problem too and i make it only one time,it's difficult to me explain to you but it's well explained in this thread Debian User Forums • View topic - First boot - stuck on 'Loading initial ramdisk'. Good Luck!

Andrea Tavazzani said...

This is a test! DISQUS is now here!!! Hope you like!

Harry said...

VGA Console mode is useful in terms of technical process. Your blog is very informative. I like your blog. Thanks for information.

A64_128_256 said...

Thank you so much. I have been looking for this for a while now.

Andrea Tavazzani said...

Glad to be useful!

Oskrchile said...

Thank you! Now it's working ;)

Andrea Tavazzani said...


Bruce said...

This doesn't seem to be working after upgrading from Ubuntu server 11-04 to 11-10

Andrea Tavazzani said...

Hi, I'm sorry if it doesn't work. I just looked through my Oneiric Ocelot (11.10) on VirtualBox and everything is almost perfect as i wrote in the last post.

I think that the only thing you need is to set GRUB_GFXMODE=YOUR_RESOLUTION (for example 1280x800) and IMPORTANT!!! is to re-issue sudo update-grub after every modification to
the settings in /etc/default/grub.

On the Oneiric we don't need complicated settings to the
00_header in /etc/grub.d as long as you need to change colors and wallpaper of the GRUB startup screen.

Hope this helps.


Bruce said...

I already added the resolution there. It was working fine before the release upgrade. During the upgrade I was asked if I wanted to use the new grub 00_headers and I said yes because I didn't know whether it would work had I chosen not to.

I will probably install the latest version of VMware and reinstall my Ubuntu server.

Andrea Tavazzani said...

OK, let me know, sincerely i didn't understood if your problem is about resolution or about GRUB itself (for example it doesn't install properly) in this case try to reinstall GRUB on the MBR with grub-install /dev/YOUR_PARTITION (for example grub-install /dev/sda) it may fix. Have a nice time.

Bruce said...

Sorry, I wasn't very clear about the issue. I did set the resolution in the  /etc/default/grub file and grub is using the resolution I choose but the resolution isn't *sticking* after the transition to the console.

Adding gfxpayload=keep to the 00_header file did not help this time.

if loadfont `make_system_path_relative_to_its_root "${GRUB_FONT_PATH}"` ; then
  set gfxmode=${GRUB_GFXMODE}
  set gfxpayload=keep
  insmod gfxterm

Could the load_video funtion be messing things up? Not sure it matters since you mentioned Oneiric not needing 'complicated settings to the 00_header'?

load_video function:

Thank you for you help anyway. I mean, I can always access the console through ssh and I'd been using this fix for a long time. :)

Andrea Tavazzani said...

1. Try to use the default 00_header without our hack (set gfxpayload=keep) that was made on earlier distros and is different/changes often. But I'm on Oneiric Ocelot on VirtualBox and I'm sticky at 1280x800 so I want to help you. If you are using VMware it is possible you need other changes, I will explain later.

2. Firstly You need to be really sure your system is supporting your resolution. You told the console it's OK, right. It's only when you switch from the GDM and back that happens, right? Set the same resolution you set for GRUB_GFXMODE for X Windows, I suppose you use GNOME, set it through display settings, at the next restart it will keep that resolution. So if everything is right if you change the between the console CTRL+ALT+F1 and then CTRL+ALT+F7 (someone is using CTRL+ALT+F8 and also CTRL+ALT+F9 for X) you should have no resizing.

3. Another possible cause is your virtualization environment (or your system) is not supporting natively your desired resolution as mine 1280x800, I had to set it through VBoxManage, please take a look at this post, I remember that also VMware has something similar to set :
Adding custom console modes to VirtualBox Linux Guest.
Try to use a resolution available for both the console and the X Windows, look at the
hwinfo --framebuffer output (issue it on the console not in terminal).
I remember that also VMware has to set custom video modes in its configuration file, take a look at the help file.

4. On Oneiric I'm using also the good old vesafb module, be sure it is loaded into the kernel (lsmod) otherwise try to look at /etc/modprobe.d/blacklist-framebuffer.conf and see if it's blacklisted, to un-blacklist simply comment it --> #blacklist vesafb, then issue update-initramfs -u to regenerate the kernel initrd image so the module is loaded at next restart. That's It! ... Same resolution for console and X, vesafb module, GRUB_GFXMODE in /etc/default/grub, no more gfxpayload=keep through 00_header, and everything should work fine.

I hope you succeed. Greetings.

Bruce said...

It worked! Installing hwinfo and using the hex value in the  GRUB_CMDLINE_LINUX_DEFAULT did the trick. I was trying the values from grub's vbeinfo and they weren't working. (vesafb wasn't being loaded either)

Thank you very much.

Andrea Tavazzani said...

 I'm very happy, i will update some post about GRUB to meke them more distro specific. Cheers :)

GritNaTZ said...

Worked well on Deb Wheezy testing 3.2.0-2 -amd64.
Added "GRUB_VIDEO_BACKEND=vbe" into /etc/default/grub, so that  insmod vbe could be added to /boot/grub/grub.cfg after running update-grub

Usefull Post ; Thanks :o)

Andrea Tavazzani said...


Andrea Tavazzani said...

I did this precisely as you described, system boots with no display, scan out of range, tried a couple other displays same thing. 1078x768

Andrea Tavazzani said...

Hi Ben! Please give me more information about you System and Distributions and the steps you made. Is the 1078x768 correct? It may be 1024x768, be sure to reissue update-grub in order to rebuild the initrd image of the kernel, and be sure that the desired VGA modules are loaded at startup, please read more GRUB related posts, also on this blog. Let me know.

Andrea Tavazzani said...

Thank you for sharing! buyincoins, where you can buy good products from China directly without any shipping fee.

Post a Comment