Virtual console size increased after upgrading to RHEL 6.8

After updating some VMware virtual machines to RHEL 6.8 (kernel 2.6.32-642) it appears that the size of the virtual console has been increased -- it is huge.

No X server is running in the console, i.e., it is a classical text-based linux console.

When I log in through the virtual console, the values of LINES and COLUMNS variables are:

COLUMNS=160
LINES=48

How can I resize the console?

Thanx in advance

update 1

I googled this issue and found a lot of solutions using the vga= kernel option in grub.conf. I have tried that but it does not work; although that option does appear in /proc/cmdline after the reboot -- it is not ignored.

I have found these two lines in the dmesg output:

Console: colour VGA+ 80x25
console [tty0] enabled

but a lot of lines below, I have found:

[drm] DMA map mode: Using physical TTM page addresses.
[drm] Capabilities:
[drm]   Rect copy.
[drm]   Cursor.
[drm]   Cursor bypass.
[drm]   Cursor bypass 2.
[drm]   8bit emulation.
[drm]   Alpha cursor.
[drm]   Extended Fifo.
[drm]   Multimon.
[drm]   Pitchlock.
[drm]   Irq mask.
[drm]   Display Topology.
[drm]   GMR.
[drm]   Traces.
[drm]   GMR2.
[drm]   Screen Object 2.
[drm]   Command Buffers.
[drm] Max GMR ids is 64
[drm] Max number of GMR pages is 65536
[drm] Max dedicated hypervisor surface memory is 163840 kiB
[drm] Maximum display memory size is 8192 kiB
[drm] VRAM at 0xd8000000 size is 8192 kiB
[drm] MMIO at 0xd0800000 size is 256 kiB
[drm] global init.
[TTM] Zone  kernel: Available graphics memory: 8167096 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
[drm] Screen Objects Display Unit initialized
[drm] width 1280
[drm] height 768
[drm] bpp 32
[drm] Fifo max 0x00040000 min 0x00001000 cap 0x0000077f
[drm] Using command buffers with DMA pool.
[drm] DX: no.
fbcon: svgadrmfb (fb0) is primary device
Console: switching to colour frame buffer device 160x48
[drm] Initialized vmwgfx 2.9.0 20150810 for 0000:00:0f.0 on minor 0

You can see how the drm module sets up the graphical screen size (1280x768@32) and text scree size (160x48). I know nothing about this drm module. The following command line shows something about it:

# lsmod|grep drm
drm_kms_helper        127219  1 vmwgfx
drm                   362893  4 vmwgfx,ttm,drm_kms_helper
i2c_core               29132  3 i2c_piix4,drm_kms_helper,drm

I will look for information about drm module.

update 2

I confirm that this issue is introduced in RHEL 6.8. I had updated a RHEL 6.1 box up to RHEL 6.7 and console size had suffered no change.

Later, when I have updated to RHEL 6.8, the console has become huge.

In a nutshell:

Try disabling VMware's svgadrmfb framebuffer driver. I had the same change in resolution and discovered that the framebuffer became enabled after an update on one of my virtual machines.

Now for the long answer...

I came across your question in search of an answer to the same exact issue, although in my case the display resolution had changed when I did a reboot after automatic updates on a TurnKey Linux appliance (Debian-based). Let's call this vm1.

After digging through the kernel log (dmesg) and comparing it to the log of another VM, vm2 (which still had the original resolution), I found vm1 had the additional following lines.

[    2.033291] [drm] width 1280
[    2.033305] [drm] height 768
[    2.033318] [drm] bpp 32
[    2.050045] [drm] Fifo max 0x00040000 min 0x00001000 cap 0x0000007f
[    2.085691] fbcon: svgadrmfb (fb0) is primary device
[    2.088207] Console: switching to colour frame buffer device 160x48

I checked vm2 and confirmed that it had not loaded the svgadrmfb driver (from the absence of /dev/fb0).

I found the following article on how to disable the framebuffer: http://kb.digium.com/articles/FAQ/How-to-disable-the-Linux-frame-buffer-if-it-s-causing-problems

I tested the suggested kernel boot parameters:

• vga=normal
• nofb
• nomodeset
• video=vesafb:off (Actually, I tried video=svgadrmfb:off instead, but it didn't work anyway.)
• i915.modeset=0

In my case it was nomodeset that worked for me. Once I made this discovery, I made it permanent as follows (I deviated from step 4 in the linked page). After looking at the /etc/grub.d/10_linux file, I realized that the GRUB_CMDLINE_LINUX_DEFAULT variable in /etc/default/grub was all that needed changing. (Also suggested in AskUbuntu #19486.)

In my case the variable was:

GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=0"

I changed this line to:

GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=0 nomodeset"

After making that change, update GRUB's configuration:

sudo update-grub

Then issue an init 6 to reboot.

If your system was previously not loading svgadrmfb either, then the screen resolution should now return when the framebuffer is disabled.

root@server:~# tput cols
80
root@server:~# tput lines
25

Also, once your system is booted, you can verify the effective kernel boot command:

root@server:~# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/turnkey-root ro consoleblank=0 nomodeset