Hide Forgot
Description of problem: vga=319 and other values are not accepted correctly Version-Release number of selected component (if applicable): kernel = 2.6.35.11-83.fc14.i686 (current), also fails on other kernels grub = grub-0.97-66.fc14.i686 How reproducible: Always Steps to Reproduce: 1.add vga=317/8/9... 2.somehow these numbers are translated to 31d/e/f which is rejected as invalid 3. Actual results: see description Expected results: Additional info: Attachment is current grub.conf. I used to have vga=xxx with the values 317/8/9 but they are not getting translated correctly. 317 is translated to 13d, 318 is translated to 13e, and 319 is translated to 13f. Others fail as well but I did NOT test all of them. The problem exists for these other kernels as well: title Fedora (2.6.35.11-83.fc14.i686) title Fedora (2.6.35.10-74.fc14.i686) title Fedora (2.6.35.10-72.fc14.i686)
Created attachment 481266 [details] /boot/grub/grub.conf in current use. Somehow this attachment process failed when I created this bug. Sigh... A bug or UFU? :-) George...
Your attachment is using vga=31a
Chuck, This seems to fail as well. Do you need me to do something? Regards, George...
Howdy, Is there any status for this bug? The problem still exists. Now, any specification of vga= in the kernel line causes the problem and I get a prompt for correct values even though correct values ARE specified. Just a few minutes ago, I rebooted my system. Here are the grub kernel lines. The code chokes on 318 and gives me a prompt to respecify. When I enter 318, that is accepted and booting continues. George... title Fedora (2.6.35.11-83.fc14.i686) root (hd0,0) kernel /vmlinuz-2.6.35.11-83.fc14.i686 ro root=/dev/sda2 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us init=/sbin/bootchartd vga=318 nomodeset drm.debug=0x04 initrd /initramfs-2.6.35.11-83.fc14.i686.img
Looking closer at this, I don't think 318 is a valid mode unless maybe you meant 0x318, which would be decimal 794 (1280x1024, 16-bit color.)
Chuck, When I boot, I get a complaint about 13f and then the prompt, press enter to get a list... 318 is there and I type in 318 which appears to be accepted and the boot continues. Other ranges of 31x produce ranges of 13x, all of which are rejected but when typed in, most are accepted and the boot continues. George...
I think what is happening is that the kernel is assuming hexadecimal for vga modes typed at the prompt, and decimal when they're on the command line. Either "vga=0x318" or "vga=794" should work on the command line, and yield 1280x1024x16. "It's not a bug it's a feature."
Chuck, Hmmmm... A feature? So, how does one deal with this feature? Is there doc for the feature? Is there a standard for data entered into the kernel? I have set some parameters with a 0x0040 for example (drm.debug=0x04). Shouldn't there be an error message if a person enters the data incorrectly? One that is meaningful? George... (confused in the woods).
Chuck, Is there any status on this bug? The problem STILL exists. Is there doc to support this "feature"? Regards, George...
This behaviour can't be changed as existing configuration depends upon it. If you want to pass a value in hex, use vga=0x318. If you want to pass it in decimal, use vga=794. 318 is only meaningful in hex, but looks like a decimal value, so the kernel assumes you've passed a decimal value. This is, as far as I can tell, how grub has always worked. It's also certainly not an issue with the kernel, which never even parses vga= itsel.
Hi, Thanks for your response. I was fooled by the appearance of the values in the menu. There is no stipulation that values expected ARE hex. I'm a little confused by what you have written though. First you say the kernel assumes... then you say the kernel never even parses vga= values, I presume you mean values. My point, I think, is that the menu is misleading. Values chosen from the menu should also be acceptable in the kernel line OR some text making the distinction should be made. George...