Issues after installing Ubuntu Studio Natty 64-bit

Matt Wheeler m at
Fri Jun 3 22:57:12 UTC 2011

On 28 May 2011 19:21, Ralf Mardorf <ralf.mardorf at> wrote:
> I wish to be able to configure everything. Individual names, sub-menus,
> no splash-videos, screen resolution for the messages etc. and the way I
> do it, by editing grub.cfg is the easiest way and perhaps only way too.

As has been mentioned, you need to be editing the files in /etc/grub.d
instead of editing grub.cfg directly. Those files are used to generate
grub.cfg whenever update-grub is run.

I find that working with computers is often more pleasant when "going
with the grain" -- i.e. using the systems that are provided to make
changes instead of trying to do it the way that seems simplest to
begin with :)

> The temporarily grub.cfg for my new Ubuntu install isn't ok until now.
> It might be that I just need to command out something, e.g. 'set
> gfxpayload=$linux_gfx_mode' and 'quiet splash vt.handoff=7', but perhaps
> I need to edit much more.

See the file /etc/grub.d/10_linux -- it is a Bourne shell script. At
around line 98 you will find the part of the script that inserts the
"set gfxpayload=" line, so you can comment the line out there and it
will be commented out after update-grub runs.

Notice in grub.cfg there are lines like "### BEGIN
/etc/grub.d/00_header ###" (and the corresponding END lines). These
tell you which script in /etc/grub.d generated each part of grub.cfg

All of your changes, such as where you've commented out function
load_video { etc.

> Once I edited update-grub2 to save 'grub.cfg.date_and_time' instead of
> 'grub.cfg'. But this isn't reliable, regarding to upgrades, it's better
> to have a backup of grub.cfg. Btw. it's also annoying that when
> installing upgrades, that update-grub2 is launched several times, taking
> minutes to detect imaginary Linux installs or existing kernels, that
> should be excluded from the menu.

Files in /etc are treated specially by system upgrades -- they won't
be overwitten by new versions if any change has been made by the
system owner; which is another good reason to edit /etc/grub.d/*
rather than grub.cfg.


Hopefully this makes the way update-grub works (and is actually
useful:) a bit clearer. Sorry I don't have any suggestions about the
other issues you mentioned (but it's usually helpful to keep separate
issues to separate threads on mailing lists so everyone can follow the
discussion more easily).

Matt Wheeler
m at

More information about the Ubuntu-Studio-users mailing list