Red Hat Bugzilla – Bug 840179
Latest grub2 update broke "system" theme
Last modified: 2013-01-28 04:26:06 EST
Created attachment 598215 [details]
Description of problem:
The name of the background image used by the theme in /boot/grub2/themes/system/theme.txt has changed to background.png, but /boot/grub2/themes/system/theme.txt still refers to this image as "fireworks.png". Thus, if the theme is activated, an error message appears instead of the fancy menu.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Append the following line:
grub2-mkconfig -o /boot/grub2/grub.cfg
When booting, an error message appears about /boot/grub2/themes/system/fireworks.png missing, prompting the user to hit enter. After hitting the enter key, a plain grub2 menu appears.
A fancy grub2 menu.
The theme used to work until the latest update to grub2. Applying the attached patch seems to fix the problem.
I can confirm this problem. I changed my theme to the starfield theme until this is resolved.
Here the latest grub2-tools package 0.37.beta6.fc17 broke the system theme with errors about missing both the fireworks.png background picture and the dejavu.pf2 font.
The package does not ship with a background.png file as the reporter seems to see.
(In reply to comment #2)
> Here the latest grub2-tools package 0.37.beta6.fc17 broke the system theme
> with errors about missing both the fireworks.png background picture and the
> dejavu.pf2 font.
> The package does not ship with a background.png file as the reporter seems
> to see.
Agreed on all counts. The file /boot/grub2/themes/system/background.png comes from the fedora-logos package.
Also reproduced on installed 18 Alpha TC2
Yep, it affects Alpha TC2 too using text installer which probably does not install fedora-logos (as it seems to be minimal text installation). As I can't log into the system, I can't confirm it.
Adding Jesse to CC confirm it.
(In reply to comment #5)
> Yep, it affects Alpha TC2 too using text installer which probably does not
> install fedora-logos (as it seems to be minimal text installation). As I
> can't log into the system, I can't confirm it.
> Adding Jesse to CC confirm it.
1) grub config on boot media
2) grub config /after/ install
1 has nothing to do with text/graphical mode.
2 can have something to do with text mode, since text mode currently only installs the minimal package set. However anaconda can (and will soon) force the install of fedora-logos package, regardless of your package selection, which will fix problem 2 on text mode, once problem 1 gets fixed so that the config is pointing to the right file.
I just hit this after graphical install using a custom boot.iso (containing what will eventually be in F18 Alpha TC3).
The theme.txt is specifying a 'fireworks.png' image which doesn't exist. fedora-logos provides a 'background.png'.
When I change the theme.txt file to point to 'background.png', the theme shows up without issue.
I don't know if the bug is in grub2-tools or in fedora-logos but something is named wrong.
Proposing as a blocker for Fedora 18 alpha due to violation of the following Fedora 18 alpha release criterion  :
The default Fedora artwork must either refer to the current Fedora release under development (Fedora 18), or reference an interim release milestone (e.g. Alpha or Beta). If a release version number is used, it must match the current Fedora release under development. This includes artwork used in the installer, graphical bootloader menu, firstboot, graphical boot, graphical login and desktop background.
I think we decided for F17 that that criterion didn't require artwork actually *show up*, but that if artwork did show up it must be correct.
Please take bureaucracy out of this for a second.
This bug can be fixed with the one-liner patch that is already attached to this bug. It can be fixed in either grub2 or fedora-logos. Please... someone just take 10 seconds out of their busy schedules and apply the patch or change the name in fedora-logos.
Michael: the blocker process 'bureaucracy' is really orthogonal to work on fixing the bug, but it has to happen, because F18 is frozen for Alpha. Even if someone applies the patch and does a build, it can't go into the f18 repo and hence the Alpha compose unless it is considered a blocker or NTH bug. If it isn't, then it will stay in updates-testing until Alpha is shipped.
I'm not looking for this to be in F18 Alpha.
It's broken in F17+. It would take less than 10 seconds for someone with commit access to grub2/fedora-logos to fix this. It's been sitting here for over a month untouched. Can someone just push a fix for this? Worry about your QA labeling of this bug /after/ it has been fixed.
Q: What's less productive than bureaucracy?
A: Bugzilla arguments.
When a bug gets proposed as a blocker it has to get reviewed. We have the blocker process for a reason. You denigrating it as 'bureaucracy' and me defending it is wasting your time and my time, and ironically, making me less likely to fix the bug because now it's pissing me off and I want to spend my time doing something else.
The blocker process is not bureaucracy. Insulting it is not a good way to convince anyone to fix a bug. Please leave it alone.
I've put in for commit access. I'm putting my money where my mouth is. First person to grant me will see this bug fixed.
I think the release criterion mentioned in comment #7 as a reason for blocking on this bug isn't well chosen, others are violated much more clearly:
16. In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied. The firstboot utility must be able to create a working user account
18. When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should boot to a state where it is possible to log in through at least one of the default virtual consoles
IMO, grub2 not booting linux without someone hitting "Return" violates 16 and at least "scratches" 18 (depending on interpretation). Is this sufficient to get the formalities out of the way?
(In reply to comment #13)
> I've put in for commit access. I'm putting my money where my mouth is. First
> person to grant me will see this bug fixed.
This is modern times. Better send a link to a git repo where it has been fixed.
Discussed at 2012-08-20 QA meeting, acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting/2012-08-20/fedora-qa.2012-08-20-15.00.html . Accepted as a blocker per criterion "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode."
Tom, Peter, can you guys look into this one? The fix _seems_ obvious - change theme.txt (which is in theme.tar.bz2 in the grub2 build) to say background.png not fireworks.png . But the thing that worries me is that, AFAICT, the file was _never_ fireworks.png in any build of fedora-logos, it's always been background.png. So how did this ever work? Makes me worry I might be missing something, so I don't just want to poke this unilaterally. Thanks.
My only thought here is that if we left it as "background.png", i think would be simpler to update the grub2 image at dist-upgrade time.
That said, I don't see any reason why we can't have fireworks.png as a symlink to background.png.
fedora-logos-17.0.2-5.fc17 has been submitted as an update for Fedora 17.
fedora-logos-17.0.2-5.fc18 has been submitted as an update for Fedora 18.
The problem was introduced in grub2 between beta4 and beta6 in http://pkgs.fedoraproject.org/cgit/grub2.git/commit/?id=8c81c575874abe8193a2ef6c71b47b7efe6b2bdc where the theme for unknown changed from
It would be better if the issue also was fixed in grub2.
(This whole 'system' theme in an unversioned tarball (but heavily based on the grub2 starfield theme) is a bit odd. If it is considered separate and fedora specific artwork it should be a separate or different package. If it is an improvement of the upstream project it should be upstreamed. If the upstream theme just need a bit of patching to make the fedora theming optional then it should be done in a separate patch. And in any case it shouldn't be installed in /boot/grub2/themes; that location is usually managed by grub2-install when installing from /usr/share/grub/themes/.)
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing fedora-logos-17.0.2-5.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
fedora-logos-17.0.2-5.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
fedora-logos-17.0.2-5.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 902886 has been marked as a duplicate of this bug. ***