help-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grub2 almost does what I want


From: Jordan Uggla
Subject: Re: Grub2 almost does what I want
Date: Fri, 8 Feb 2013 11:00:00 -0800

On Thu, Feb 7, 2013 at 8:56 PM, Felix Miata <address@hidden> wrote:
> 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

A functionally equivalent entry (which would not produce a warning) would be:

gfxpayload=1280x1024x16
insmod part_msdos
root=(hd0,msdos22)
# I would use search --set=root --fs-uuid here instead
linux /boot/vmlinuz root=/dev/hda22 ro noplymouth splash=verbose nomodeset
# I would also use root=UUID= here instead
initrd /boot/initrd

> 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"

And you are still failing to understand that information about video
modes is *not*, and never has been, passed to the linux kernel via
cmdline. It is passed through other means in the linux boot protocol.
"gfxpayload=1280x1024x16" does not show up in /proc/cmdline as it is
not a kernel parameter. With the (very confusing) exception of vga=,
only kernel parameters are supposed to come after the "linux
/path/to/kernel". The fact that a non kernel parameter was stuck there
long ago has lead to many people being (rightfully) confused,
including yourself. To make it clear that gfxpayload is not a kernel
parameter, but rather a grub setting, the grub developers made it a
grub variable, which is why you need to set it on its own line, like
all other grub variables.

> 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.

gfxpayload=1280x1024x16 is functionally equivalent to adding vga=794
to the end of the "linux" line. Any hardware that worked with vga=
will work exactly the same way with gfxpayload=.

> 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.

I don't know, but changing it now would only add to any confusion
rather than reduce it. I think we'll just need to live with this
variable name. Also when I see "gfx" I think "graphics" rather than
"graphic effects".

> 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).

If you are concerned about running out of space in the linux cmdline
then gfxpayload wins again as it saves you 7 characters in the
cmdline. So gfxpayload is less "bloated" by your definition than vga=.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]