Ce n’est pas seulement GRUB2 qui définit la résolution de la console. Je m’explique.
Lorsqu’on allume le PC, le BIOS est lu et exécuté.
Le BIOS est un mini système d’exploitation qui contient des pilotes universels permettant d’utiliser les fonctions basiques du matériel (mais vraiment le minimum de chez minimum). Il contient entre autres des routines (= des fonctions) qui permettent d’utiliser une résolution faisant (normalement) partie d’un standard. Ce standard est généralement VESA.
Or, les écrans actuels sont généralement des 16/10 avec des résolutions bâtardes qui n’existaient pas à l’époque où le VESA a été standardisé. Du coup le BIOS n’est pas capable d’utiliser la bonne résolution native pour ton écran. Il va donc utiliser celle qui lui semble la plus universelle, et elle est généralement très pixelisée.
Une fois que le BIOS a fait ce boulot, il va lancer le code qui se trouve dans le MBR du périphérique que tu as défini comme bootable par défaut dans le BIOS. C’est là que GRUB2 se trouve (ou au moins une routine de redirection vers le code de GRUB2 qui est trop gros pour tenir dans le MBR je crois). Donc GRUB2 s’exécute et il va lire le paramètre de résolution dans son fichier de configuration. S’il n’y en a pas, il conserve la résolution définie précédemment par le BIOS. S’il y en a un, il va modifier la résolution selon ce paramètre que tu as définis dans le fichier de configuration. Cette résolution est forcément une des résolutions gérées par le BIOS. Autrement dit si le BIOS a choisi une résolution très pourrie, on peut demander à GRUB2 d’utiliser une meilleure résolution gérée par le BIOS, mais elle sera généralement imparfaite puisque la résolution native de ton écran ne fait pas partie du standard VESA.
Ensuite, GRUB2 va exécuter le code qui permet de charger le kernel. Et là, 2 solutions :
[ul][li]soit le kernel intègre un pilote pour ta carte graphique (c’est le KMS : Kernel-based Mode-Setting = définition du mode basée sur le kernel) : dans ce cas, le kernel va charger ce pilote qui va remplacer la routine graphique utilisée par le BIOS. Le pilote va ensuite demander à la carte graphique d’utiliser la résolution la plus adaptée pour ton écran, comme l’a fait le BIOS, sauf que le pilote en question est capable de gérer d’autres résolutions que celles du VESA. Ainsi, si tu as un écran vraiment hors du commun avec une résolution énorme et que ta carte graphique n’est pas capable de supporter cette résolution, tu ne pourras bien évidemment pas accéder à cette résolution maximale. Mais ça c’est une limitation matérielle, le pilote KMS, lui, est censé gérer toutes les résolutions de ta carte graphique ;
[/li]
[li]soit le kernel n’intègre pas un pilote pour ta carte graphique : dans ce cas soit tu continues à utiliser le routine du BIOS et tu conserves une résolution pourrie avec des performances plus que dégueulasses, soit tu installes un pilote dédié sous forme de module. Dans les 2 cas, le kernel sera d’abord chargé, et comme c’est le kernel qui charge les modules, ton pilote sera chargé un peu plus tard. Or, la console fait partie du kernel, donc elle est chargée en mémoire avant le chargement du module graphique qui contient le pilote dédié. Donc lorsque la console se charge, elle utilise encore la résolution définie par le BIOS. Puis plus tard le chargement du pilote s’effectue, et le serveur X se lance en utilisant une des résolutions proposées par le pilote dédié qui vient d’être chargé. C’est pour ça que le serveur X a généralement une résolution sympathique et pas la console. Mais si tu n’as pas de pilote dédié, alors le serveur X utilisera la résolution définie par le BIOS (beurk).[/li][/ul]
Fort de cela, il faudrait déterminer quel type de pilote tu utilises (KMS ou pas).
Mais ce n’est en réalité pas le fond du problème.
J’ai eu le même problème que toi il y a quelques semaines et à force de chercher j’ai fini par comprendre que ce n’était pas un problème de résolution mais un problème de taille de la zone d’affichage. Autrement dit, un problème de taille de buffer graphique.
Quelle que soit la résolution de ta console (que tu peux changer avec xrandr je crois), tu verras que tu auras toujours ce problème de zone d’affichage trop petite. Il faut donc en réalité redéfinir non pas le nombre de pixels à afficher par unité de surface (= la résolution) mais le nombre de pixels maximum en hauteur et en largeur (= la taille du buffer). Lorsque je dis pixels, c’est valable pour le mode graphique ; la console étant en mode texte, on va en fait indiquer au système le nombre maximum de lignes et de colonnes de caractères.
Pour cela, on utilise la commande :
Je te laisse le soin de chercher comment ça fonctionne, tu as toute la documentation nécessaire pour apprendre à t’en servir sur le web. Une fois de plus (on ne le dira jamais assez) : lis le manuel en premier !! C’est généralement la meilleure source d’information sur une commande (normal, c’est fait pour…).
Remarque : vous pouvez reprendre tout ou partie de ce post pour l’intégrer dans le wiki si vous le souhaitez, ça m’évitera d’avoir à réexpliquer la même chose encore et encore… 
