On 2013-02-07 15:50 (GMT-0800) Jordan Uggla composed:
Felix Miata wrote:
If it wasn't already there or available, how could a user edit cmdline at boot time to delete it or change it to something temporarily preferable?
They wouldn't edit the linux cmdline, they would add "gfxpayload=foo" (on its own line).
They maybe, not me: # lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) # cat /etc/os-release | grep ETTY PRETTY_NAME="Mageia 3" # rpm -qa | grep grub2 grub2-2.00-17.mga3 # ll /boot/grub2/i386-pc/core* -rw-r--r-- 1 root root 26473 Feb 4 17:36 /boot/grub2/i386-pc/core.img # cat /disks/realboot/grub/menu.lst | grep core.img kernel (hd0,21)/boot/grub2/i386-pc/core.img ## BEGIN GRUB2 TEST BOOT ## From (hd0,msdos22)/boot/grub/grub.cfg @ http://fm.no-ip.com/Tmp/Linux/Mdv/grub.cfg.04 I selected menuentry 'Mageia GNU/Linux, with Linux cur' to edit, and the Grub 2.00 edit screen when I finished editing looked like: set gfxpayload=text insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos22' linux /boot/vmlinuz root=/dev/hda22 ro noplymouth splash=verbose nomodeset vga=794 3 initrd /boot/initrd when I keyed Ctrl-X. # uname -r 3.8.0-desktop-0.rc5.1.mga3 # mount | grep "on / type" /dev/hda22 on / type ext3 (rw,noatime,errors=continue,user_xattr,acl,barrier=1,data=ordered) # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-cur root=/dev/hda22 ro noplymouth splash=verbose nomodeset vga=794 3 # stty -a | grep rows speed 38400 baud; rows 64; columns 160; line = 0; ## END GRUB2 TEST BOOT ## Of course it is much simpler when just booting the default kernel/initrd directly via the (openSUSE Grub Legacy's GFXboot) master bootloader: title Mageia Cauldron default kernel on sda22 root (hd0,21) kernel /boot/vmlinuz root=LABEL=22cauldrn noresume splash=verbose vga=794 video=1152x864@60 3 initrd /boot/initrd that highlights the active selection but leaves cursor at end of kernel cmdline waiting for edits, where to match the above test boot I'd s/video=1152x864@60/nomodeset/ before proceeding to again find included in /proc/cmdline the string vga=794. Maybe now you can see when I write "cmdline" I'm referring to anything that results in inclusion in the file /proc/cmdline regardless whether "on its own line" in the process. I don't see the need for "on its own line" in order to reach /proc/cmdline any more than I do for the deprecation message about the still and for as long as gfxchips without KMS support exist quite useful vga= cmdline option.
Vga= for such chips does still do what it did pre-KMS. As long as kernels still respond to it, people don't need deprecation warnings from their boot loader about a kernel video function.
The kernel does not respond to it, and never has. It has always been the bootloader that responded to it, as documented in https://www.kernel.org/doc/Documentation/kernel-parameters.txt .
So what you're saying is that a boot loader after accepting a menu selection from the user is altering the video mode prior to loading the kernel and initrd? What business is this for a boot loader? I sounds like a Trojan vector to me, and even if not, a way to swell the boot loader code beyond available space to install it. Does Lilo produce such a message? Syslinux? AiR-Boot?
How nice it is (not) to have new "improved" versions of init systems and boot loaders tell us we must change to using cmdline options or similarly obtuse configuration options that require 2-10 times as much typing and recollection power to perform same function as required in the past. 1024x768x24 may be a bit easier for n00bs to wrap their brains around, but it's not helpful to those of us who learned what vga= itself referred to and what relevant vga= options meant last century and who prefer less typing to more typing.
Yes, gfxmode=1024x768x24 takes more typing than "vga=792". That is true.
So why not video=, same as the kernel uses, not to be confused with any mode specified for X? Gfx is about graphic effects, not expected in the production of vtty text.
And it's certainly not welcome without adding desirable new function in the process to consume more of the precious resource that is the kernel cmdline.
I don't understand this comment.
Try to put more than 254 chars or whatever the limit is on the cmdline and the excess is truncated (the kernel never gets it). With a full pathname of the kernel plus a UUID, it can be difficult to observe a complete cmdline statement on a single line, and at times, it can be impossible to give everything needed to the kernel. That is yet another instance of bloat (more content than required to do its job). -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
