Copies from:
on 15 May 2003 -- please consult the master site

This file was last modified on: May, 07 2003 @ 01:05 am EDT

GRUB Splash Image Howto

Quick tip for the impatient:

convert -geometry 640x480 -colors 14 image.png image.xpm && gzip image.xpm
Quick tip for debian users: Use "unstable" packages in your /etc/apt/sources.list in order to get the latest GRUB with splashimage support

News about this howto

The GRUB splashimage Howto

0. About

0.0 History of this howto

This tutorial was written right after RH 8.0 was released. Red Hat 8.0 was the first distribution out there that included the "splashimage" feature. This feature, as many of you are aware of, allows you to have a nice image to display at boot time while you select the OS/kernel image you'd like to load. Fortunately for you readers I didn't read the info page which did have information regarding this feature on Red Hat 8.0. Here is part of the old Changelog for Grub for Red Hat 8.0 back then:
* Mon Jan 21 2002 Jeremy Katz <> 0.91-1
- update to 0.91 final
- add documentation on splashimage param (#51609)
Thanks to Jeremy Katz, from Red Hat, for pointing this out. Originally I had said here that there was no documentation at all out there for the splashimage feature back and I actually flamed Red Hat for it ;) Good to hear I was wrong :-)

It's been a while now since I started doing splash images, and I guess I really got the hang of it now. Anyway here's my latest splash image:

It really took me a lot of trial-and-error to figure out how to make one at first and then I confirmed the requirements by asking the developer of the feature by e-mail. I'd like go give credit to the designer of our LUG's (Penguin) logo. The original author of the penguin logo for our LUG is Jonathan Gaynor, he's one responsible for the original RUSLUG penguin artwork back in November 2001.

This particular image was designed by me for use at the EIT Lab, for our custom RedHat Install. The EIT Lab is now the new home of RUSLUG, our LUG. The Lab's computers dual-boot between win2k and Linux. The snowy background image you see is a picture I took of the College Avenue Campus in New Brunswick.

0.1 History of splashimage feature

I've done my research and have confirmed through e-mail that the author of the splashimage hack is:
Name:		Paulo CÚsar Pereira de Andrade
E-mail:		pcpa[at]
Company:	Conectiva
Paulo wrote the vga 16 patch (splashimage) for GRUB for Conectiva because he was asked to. Red Hat then just took it and used it for its distribution since it was cool. I remember I looked at the man pages and info pages of that time and there was no documentation of the splashimage feature. I have been informed by Jeremy Katz from Red Hat (May 5, 2003) that Red Hat now provides documentation in the info pages about the splashimage feature. Way to go for them!

0.2 Distrubtions using it

Red Hat 8.0 and Red Hat 9.0 definitely include the patch and use GRUB by default. Gentoo uses it too and they actually have their own splashimage. Mandrake (9.1) does not use GRUB by default. Slackware (9.0) does not use GRUB by default. Debian (3.0) has this feature enabled but you have to install it from the "unstable" branch. You do this by changing your /etc/apt/sources.list and instead of using "stable" use "unstable". Then `apt-get update && apt-get install grub`. YOU MUST THEN CHANGE THE sources.list file and use again "stable" and do `apt-get update`, otherwise your system might break! You have been warned! Unstable is bleeding edge packages and by definitioncan break. If you know of other distributions using GRUB as the default boot loader, please let me know.

0.3 Splashimage patch history

As explained above, the splashimage feature is a patch that can be applied onto the GRUB source. It is not a bugfix, but a new feature added for GRUB. Because of this, only the upstream source mantainers for GRUB, (Yoshinori K. Okuji Gordon Matzigkeit) could decide whether to incorporate the patch (written by Paulo CÚsar Pereira de Andrade) into the source (since they're the ones receiving patches or adding new features; just like with the linux kernel where Linus receives patches and addons) so that they can also mantain it should other people patch on to it, etc.

What it comes down to is that the GRUB upstream source mantainers do not want to make non-bugfix or new-feauture enhances/changes to the GRUB 1.0 source base. "Why oh why", you may be asking right? Well I think I know the answer: there things the mantainers deem more important for a 1.0 release. Because of this, should distributions currently want to have GRUB with splashimage support, they have to grab the patch and incorporate it into the sources themselves. For example, thanks to Jeremy Katz now two large distributions have GRUB splashimage support. Katz currently is the Red Hat GRUB mantainer and took off working on the patch from where Paulo left off. He offered to accept bug fixes that the debian community found. How and why did this happen?Well I wasn't sure to take credit for this at first, but after going through my inbox thoroughly I am now sure that I did play a major role for this to occur. I was basically the messenger. My e-mail to Jason Thomas, which is Debian's GRUB package mantainer, and to Paolo, the author of the splashimage patch got forwarded to the the GRUB bug-brug mailing list and that seemed to get things rolling. Now, how Gentoo, or Slackware, or any other distribution supports it, I do not know. If you have insight as how it works with these distributions, please drop me a line.

What follows is the story of how my e-mail got Debian unstable to get splashimage support. Initially, I had thought that the reason why the splashimage feature was not in any of the other distributions I was trying out while Red Hat 8.0 was out, was the big fun legal mess I figured patch contributers had to go through to submit patches to go as upstream for software designed for the GNU project. Why was I to think this? Well When I had first e-mailed Jason Thomas regarding my wish to see the splashimage feature on debian, I was told I had to contact the original patch developer and see to it that he would be willing to sign the papers to transfer copyright rights to the FSF if it were to be incorporated into GRUB upstream. Through my massive googling, I then found what seemed to be the main developer of the patch, Paulo CÚsar Pereira de Andrade. It was like finding a needle in a haysack, trust me! I then contacted Paolo regarding this and he replied willing to submit the paperwork. What was left in the picture was the Mantainer for the patch, that according to Jason, would be required, should it go to upstream. Jason then e-mailed the bug-GRUB mailing list asking Okuji if the patch could be incorporated into upstream. In that thread, Jeremy Katz then immediately replied and mentioned how should the patch go upstream, he would be willing to mantain it. In that e-mail, Katz also supplied the patch he had currently be working on for Red Hat. Following Katz notice that he would be willing to be the upstream mantainer, Paolo then sent out to the mailing list the patches used by Conectiva (for GRUB 0.92). What you may think might might have ended in a nice happy ending with the upstream mantainers accepting the patch into upstream is really not what happened. Okuji then replied with an authoritive, but yet simple "No". This was January 2, 2003. I then got notice from Jason the same day that he would be incorporating Jeremy's patches into debian's GRUB unstable package. I'd like to quote here for future reference that Okuji has said that he "would add graphics support into GRUB after 1.0". By this time, GRUB should become PUPA, it seems. On January 9, 2003, Jason informed me that he had uploaded a GRUB package to debian unstable with splashimage support. Yay! And that was the end of that long thread.

It has recently been brought to my attention by Yoshinori K. Okuji, that the GNU Project developers "strongly recommend that contributors assign or disclaim their copyrights, but that that is not a requirement" and that "if [the contributors/patchers] don't want to do that", GNU developers will still "accept them" (the patches, contributions, etc). So let the myth be dispelled that patches/contributions to the GNU project do not have to be solely copyrighted by the FSF. This is just a recomendation. The reason has to do with lawsuits so that should a company/entity violate GPL software belonging to the GNU project, the task of the FSF to carry out a lawsuit would be easier. Should a big lawsuit come up for certain GPL'd software that has tons of developers accross the globe who have not submitted their copyrights to the FSF, the FSF (or someone willing to take the challenge) would have to contact all contributors/patchers to the specific application in question for a successful lawsuit.

0.4 The future/death of this feature

Well "what future, what are you talking about?" you may be asking... I'm actually talking about this feature's death. :) Let me explain: according to Paulo this allowing-a-14-colored-image-hack is pretty lame (well he didn't say that, but you get the idea) compared to the apparantly_now_supported code in GRUB now that allows VESA modes (which increases the number of colors supported and larger resolutions). Here's the comment in his own words:
"[...] GRUB 0.92 has code for setting vesa modes, that would be pretty better to display images, think no limits in the number of colors and screen resolution. In that case the only reason to support vga16 would be for floopy boot disks as the 14 colors images are quite smaller than a true color one."
I've played with VESA modes on GRUB but it seems you can't really load any images.. it seems its more of a test-functionality currently supported on GRUB. My guess is that you can load images using these VESA modes but you gotta hack the code and another guess it that PUPA (future GRUB 2.0) will support these modes and image loading!

Today's date is May 5, 2003. I just finished updating this howto and I would now like to say here that I do not think that there currently are enough GRUB developers interested enough in getting VESA graphics support going. Jeremy Katz, from Red Hat seems to me the best developer candidate that would be able to put forth this effort. The reason, being that he is the current main splashimage patch mantainer. Let me invite all you GRUB hackers out there who really wish to see this feature become a reality to start hacking away! Please Okuji, don't step on me like an ant :-) Should I have more time I'd probably check the code out myself too, but right now I am busy graduating from school. I can start collecting names of people willing to contribute and all that other fun stuff... but I rather you guys just start hacking away and get on with it. If none of you do so, I will try to do it myself after this semester in May, after finals.

Also, just as the splashimage was a very undocumented feature back around December 2002, around the release of Red Hat 8.0, I believe that right now the VESA graphics support is in the same position. Despite VESA Graphics support not being of primary interest to the main goals for GRUB 1.0, I do realize there is an interest from aesthetic nazies out there to get this going. If you have any insight as to the VESA graphics support in GRUB, please let me know as much as you know and I will gather the information into a new section in my HOWTO.

1. Instructions

1.0 Requirements for GRUB splashimages:

1. xpm.gz file type
2. 640x480
3. 14 colors only

1.1 I have my image, now what?

1. Gzip your xpm file and put it into your /boot/GRUB directory (or to any directory of a /dev/hda1 partition). (do: `gzip myfile.xpm`)
2. Edit your GRUB config file (aka /etc/GRUB.conf) and add this line:
NOTE: Change the partition and directory according to your system's setup.
3. reboot and cross your fingers

1.2 It doesn't work you suck!

Too bad. Screw you =-) No really, if it didn't work or if this text needs clarification you can e-mail me and I can try to help you/ourselves out. I can't promise anything though, since school forces me to be a busy person.

1.3 Tips and tricks

1.3.0 Test all your images with only one reboot :)!

As you can imagine rebooting every time to test just one freakin' image can be painful and frustrating... With GRUB you don't have to! I'd recommend creating several xpm images you'd like to try out and after that, reboot to interact with GRUB to test each and everyone one of them one by one (don't forget to gzip each one and to put them in /boot/GRUB or so). So just reboot using the default splashimage given to you (don't edit the GRUB conf file).

After your reboot, when the menu for GRUB pops up, just hit "c" to go into the command-line prompt. At the prompt, load the partition with the GRUB images. Please try to make it your /dev/hda1 (which is (hd0,0) in GRUB-partition-nomenclature). I tried using some other partition several times and I only got GRUB to lock itself sometimes. You load partitions by doing:

root (hd0,0)

Then try to load the splash images, one by one:

splashimage /GRUB/myfile.xpm.gz

Do this command for each image you have... Cool huh? Once your satisfied with the splashimage just go ahead and boot up and edit to your GRUB conf file to use it. You may want to keep in mind that GIMP sometimes makes a file look a bit ugly when converting it to 14 colors... and it may take you a long time to re-edit it to make it look priiiiity. That's what happened to me. I used a friend's ruslug tux image and I ended up having to edit the file pixel by pixel... (not fun, it took me about 2-3 hours). What works nice is actually starting a file using 14 colors only and then creating your original artwork from there.
NOTE: it makes it even easier if you have two computers. You can have one on the GRUB prompt and use the other one to edit the xpm files and save them onto floppy disks. Then you just load the floppy instead of a hard drive partition ;) (fd0) I think. Yes, there's a GIMP version for windows too ;) It's a shame that running GRUB from the prompt, once Linux starts, it doesn't allow you to use the `splashimage` command. Otherwise you'd be able to test all these images without even restarting :P (I tried running it from both terminal and virtual terminal).

1.3.1 Only 14 colors... How do I do that?

To get GIMP to use only a 14 color palette, right click on your file and press ALT+I and put 14 where it says "Generate Optimal Palette:" on the top of the menu. If ALT+I doesn't get you there then right click on the image and go to:


Specify you want 14 colors and then if you want (*recommended*) select NO DITHERING. This will tell the gimp not to try to guess colors in between areas. It is also possible that you tell them gimp what colors you want in your 14-color pallete, I actually had to do this for one of my images and I replaced a dark color for a light one. :) The GIMP ROCKS!

1.3.2 Does it have to be filename.xpm.gz? Not really. GRUB just provides automatic unzip'ing functionality. How you think your bzImage kernel images get's loaded? Heh. So that's just a feature and it's good practice. According to `info GRUB` it does loads quicker. The reason for loading quicker is that -believe it or not- compressed files load quicker on today's computers than uncompressed files. Why? Well because the amount of time it takes for today's average computer to read from the hard drive an uncompressed (thus bigger) file is longer than the amount of time it takes for it to read a smaller hard area on the hard drive + pass it onto main memory + uncompress it with CPU power. Well anyway, you can still leave your xpm images uncompressed, they should work fine (they did when I tested them).

1.4 File size... ?

There doesn't seem to be any file size limiation on the splash image file (well yes, maybe the size of your RAM)...

1.5 Who are you? || Thanks!

I'm Batman! Who cares really? But please let me know if this howto was useful. Thanks for all those e-mails I've received so far in support :] E-mail me

2. Splashimages

2.0 View images of currently available splashimages

2.1 Download working publically available GRUB splash images

2.2 I made a cool splashimage I want to show the world

Well I can't promise you the world will see it, but if you e-mail me the image, maybe a few people can view it. Send me your images and I will put them up for viewing.

3. Detecting/adding splashimage support onto GRUB

3.0 Do I have a GRUB with splashimage support?

Good question. Joseph Monti, main developer of the GRUBconf project asked me the same thing to see if he can detect this for his GRUBconf application. I did ask the bug-GRUB mailing list but got no replies. Unsatisfied without a reply back to Monti, I started playing around with stuff and finally wrote a script that seems to check if you have the splashimage feature in your GRUB stage files. You can get the script here and you should run it as root. If you have a better suggestion for how to detect if you have splashimage support, please let me and Monti know.

3.1 Adding splashimage support for your GRUB

I haven't myself added the splashimage patch onto the sources myself, but what I can provide for you is a link of all the patches that I have available, along with the current debian source tree: I will try to get the most recent patch. Where would I find this? I'd look into the Debian source tree or the Red Hat GRUB source RPM.

A. Section for Hackers and distributions developers

A.0 I want to hack the splashimage feature

Go ahead, by all means 8^D, go hit the GRUB sources. You might want to check out the Historic patches and the current Debian source tree, the Red Hat source RPM for GRUB and gentoo's sources for GRUB. If you have patches, I can recommend you submit them to the author which is probably Jeremy Katz, from Red Hat. If you add nice new features you can also e-mail me and I guess I can post about them here.

A.1 I'd like to add splashimage feature onto GRUB fo my distribution

Cool, I'd say you get Jeremy Katz's latest work on the splashimage patch and just incorporate that into your source. That is my advice.

B. This HOWTO's availability, license

B.0 Download this howto, tar.gz, bz2

I've found it useful before to download tutorials or HOWTO's before. This can be useful, for example, on laptops. Also, you may want to incorporate this into your source, or site, or something.. I don't. For whatever reason, you can grab the tarballs here:

This file was last modified on: May, 07 2003 @ 01:05 am EDT

Coplyeft 2003 by GPL - Luis R. Rodriguez