Created attachment 745818 [details] screen-shot of grub2 Description of problem: As the title says, i get Schr?dinger?s Cat in the grub2 entry after the first reboot right after the first '# yum update'. I have seen this in the past on a physical system, but it went away. Version-Release number of selected component (if applicable): F19a TC3 (19.24-1) How reproducible: always Steps to Reproduce: 1. Install 'Minimal' Base Environment 2. Boot, do a '#yum update' 3. reboot, grub2 menu reads: Schr?dinger?s Cat Actual results: Schr?dinger?s Cat as the release name on the boot entry Expected results: normal release name :-)
Created attachment 745819 [details] screen-shot of grub2 (GNOME Base Environment) This is different from a system which installed the Base Environment 'Minimal'.
RE-Tested with F19b RC4 Example #1: A- Install 'Minimal' Base Environment B- Grub2 Menu is OK. There are no '?' characters in the release name. In fact, the Release Name is not displayed at all, just 'Fedora'. C- Result is: OK Example #2: A- Install 'Minimal' Base Environment, and the 'Standard' Add-on. B- Grub2 Menu is OK. There are no '?' characters in the release name. In fact, the Release Name is not displayed at all, just 'Fedora'. C- Result is: OK Example #3: A- Install 'Minimal' Base Environment B- Grub2 Menu is OK. There are no '?' characters in the release name. In fact, the Release Name is not displayed at all, just 'Fedora'. C- Boot the installed system. D- Perform a 'yum update' and reboot. E- Grub2 Menu is BAD, the new kernel entry contains '?' characters. The new entry has a different structure. F- Result is: BAD, 'Schr?dinge?s Cat' is shown. Example #4: A- Install 'Minimal' Base Environment, and the 'Standard' Add-on. B- Grub2 Menu is OK. There are no '?' characters in the release name. In fact, the Release Name is not displayed at all, just 'Fedora'. C- Boot the installed system. D- Perform a 'yum update' and reboot. E- Grub2 Menu is BAD, the new kernel entry contains '?' characters. The new entry has a different structure. F- Result is: BAD, 'Schr?dinge?s Cat' is shown.
Created attachment 753332 [details] F19b RC4
In case this cannot be resolved, the two incurred characters should be replaced by the two ASCII "oe" characters as proper paraphrase for the German-language "ö" character, and by an ASCII apostrophe for the 's-genitive, respectively. Note that the octets used are \xc3\xb6 for the ö, and \xe2\x80\x99 for the other Unicode character, apparently Unicode points in UTF-8 encoding. Does GRUB2 support these? Or would it expect ISO-8859-1? 0000000: 6d65 6e75 656e 7472 7920 2746 6564 6f72 menuentry 'Fedor 0000010: 6120 2833 2e39 2e34 2d33 3030 2e66 6331 a (3.9.4-300.fc1 0000020: 392e 7838 365f 3634 2920 3139 2028 5363 9.x86_64) 19 (Sc 0000030: 6872 c3b6 6469 6e67 6572 e280 9973 2043 hr..dinger...s C 0000040: 6174 2927 202d 2d63 6c61 7373 2066 6564 at)' --class fed 0000050: 6f72 6120 2d2d 636c 6173 7320 676e 752d ora --class gnu- To reproduce, also check if your /etc/default/grub contains a line GRUB_TERMINAL="console". Do we need to do anything about /boot/grub2/locale/*.mo?
Created attachment 755594 [details] grub.cfg updated with grubby The grubby produced entry for an updated kernel (in this example 3.9.4) appears to be correct, but it's incorrectly displayed in the GRUB boot menu, and the separate message when the kernel/initrd are being loaded. Also I think this bug is improperly assigned to the anaconda team, probably should be assigned to pjones.
Still reproducible with grub2-2.00-18.fc19.x86_64 after: grub2-install /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg yum update kernel
*** Bug 963150 has been marked as a duplicate of this bug. ***
Console mode uses the bios to output text and can thus only use 7-bit ascii. The solution would either be to change the spelling in /etc/system-release or to start using the default graphical mode instead of console - which would be a change in anaconda and probably not feasible to change in upgrades.
(In reply to Mads Kiilerich from comment #8) > start using the default graphical mode instead of console Start using? Wasn't it enabled for F18?
Proposed as a Blocker and Freeze Exception for 19-final by Fedora user vondruch using the blocker tracking app because: This is first thing to see after computer is switched on. Although it is just cosmetic problem, it looks amateurish, therefore, it should be fixed.
(In reply to Vít Ondruch from comment #9) > (In reply to Mads Kiilerich from comment #8) > > start using the default graphical mode instead of console > > Start using? Wasn't it enabled for F18? I don't know. It is possible that the problem only occurs on upgraded (BIOS) systems. The upgrade tool should IMO always reinstall the boot loader. Grub is still too unstable to rely on it to remain backwards compatible between code and configuration and theme ... especially in the Red Hat fork.
Re-installing the bootloader causes as many problems as it cures - probably causes more, in fact. We had all sorts of trouble doing it as part of the grub->grub2 migration.
Discussed at 2013-06-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-10/f19final-blocker-review-4.2013-06-10-16.01.log.txt . Rejected as a blocker: upgraded systems work fine, this is a mere polish issue, but accepted as a freeze exception issue, it would be nice to print our own release name properly if we can manage it...
(In reply to Account for Fedora Blocker Bugs Application from comment #10) > Proposed as a Blocker and Freeze Exception for 19-final by Fedora user > vondruch using the blocker tracking app because: > > This is first thing to see after computer is switched on. Although it is > just cosmetic problem, it looks amateurish, therefore, it should be fixed. +1
F19 was released a week ago. There's really no point voting on blocker status.
After the latest updates (july 10), the systemd/getty prompt on the ttys show "SchrÔdingerūs Cat".
For what it is worth, Windows 7 Boot Manager is able to output "Fedora 19 (Schrödinger's cat)" just fine. So people who talk about 7-bit ascii in bios are wrong.
Make grubby follow grub2-mkconfig convention. grub2-mkconfig does not pick up on the release name and the menu looks great: "Fedora, with kernel-3.10.5-201....". It is grubby that updates grub.cfg and inserts "Schr?dinger?s". So it is easy to remove "Schr?dinger?s" in grubby.
For whatever it is worth, I did a new installation to upgrade rather than using fedup and grub uses console - not graphical mode - as it did in fedora 17 on a bios booting system. I can't reproduce this but only because updating the system fails to update /boot/grub2/grub.cfg at all and grub2-mkconfig ignores the release name. I also did a fresh install an a system which was using the graphical mode to boot fedora 17 in EFI mode. In that case, too, the installer set up grub to use console mode but probably because it also switched the machine to bios booting.
Seems like this might be an issue in F20 if a name with an accent get voted through https://admin.fedoraproject.org/voting/about/relnamef20
(In reply to Matthias Andree from comment #4) > In case this cannot be resolved, the two incurred characters should be > replaced by the two ASCII "oe" characters as proper paraphrase for the > German-language "ö" character, and by an ASCII apostrophe for the > 's-genitive, respectively. A good suggestion. There are too many things in linux unnecessarily becoming eye-candy (to compete with more popular, but more tightly controlled products??) with the consequence that they don't work in all reasonable circumstances, although this one is just a superficial annoyance that gives the impression that developers are not sufficiently professional. A better alternative would be just to have the Fedora release (F19) and kernel version displayed in the menu since those are relevant and sufficient items with a clear meaning for a boot menu -- as suggested in comment #18 I encountered the bug when I upgraded a PC from F16 to F19 a couple of days ago, using the Fedora-Live-XFCE-x86_64-19-1.iso for a lightweight installation. After I had got it running I did 'yum update' and found this problem at the next boot, exactly as in examples 3 and 4 in Comment #2. In fact there were much worse problems in grub.cfg arising from my use of an existing /boot partition to enable me easily to go back to the earlier linux while using a new partition as root for the new system. (I've done that often in the past, e.g. when upgrading or trying different distros). The 'worse' problems arise from attempts by the grub2 installer (grubby??) to re-use information from the old grub.cfg and getting it badly wrong. I'll report those problems separately. Apart from that and fetchmail not yet working I am very pleased with F19. In particular pm-hibernate works perfectly on my Desktop machine, at last, and so did pm-suspend when I tried it (once only).
I wrote in comment #21 > Apart from that and fetchmail not yet working I am very pleased with F19. In > particular pm-hibernate works perfectly on my Desktop machine, at last, and > so did pm-suspend when I tried it (once only). Just to tie up a loose end: the problem with the fetchmail failure (about which there are many complaints on the internet) turned out to be the need for additional configuration of sendmail, over and above what sufficed for sending mail. It's not relevant to this grub-menu bug, but just in case it's helpful to anyone else, I've described the problem and the solution that worked for me here: http://www.cs.bham.ac.uk/~axs/laptop/#fetchmail2
aaron: Bugzilla is not your blog. Please stop posting irrelevant comments. Thanks.
How is
(In reply to Zamir SUN from comment #24) > How is sorry for this update. How is this bug now? Just some information from my side. I installed a Fedora 19 i686 XFCE (from XFCE livecd) and then do yum update kernel -y and then my grub shows like the bug title says
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
solved for F20 by the cunning expedient of not having such a goddamn messy release name, and for F21+ by not having release names any more. we r good at this! I don't think anyone's going to try and fix F19 any more at this point.