grub2 menu cannot display Unicode characters in text mode

Steps to Reproduce:
1. Open /etc/default/grub in your favorite text editor.
2. Add "Shadowman’s" before string in "GRUB_DISTRIBUTOR" variable.
3. Save file and run: grub2-mkconfig -o /boot/grub2/grub.cfg.
4. Reboot computer and explore Grub boot menu.

Actual results:
"Shadowman?s...."

Expected results:
"Shadowman's...."

Additional info:
Using "GRUB_TERMINAL=gfxterm" in "/etc/default/grub" workarounds the issue.

+++ This bug was initially created as a clone of Bug #961533 +++

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

--- Additional comment from Reartes Guillermo on 2013-05-09 16:36:44 EDT ---

This is different from a system which installed the Base Environment 'Minimal'.

--- Additional comment from Reartes Guillermo on 2013-05-26 11:51:08 EDT ---

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.

--- Additional comment from Reartes Guillermo on 2013-05-26 11:56:40 EDT ---



--- Additional comment from Matthias Andree on 2013-05-30 04:04:01 EDT ---

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?

--- Additional comment from Chris Murphy on 2013-06-01 14:21:07 EDT ---

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.

--- Additional comment from Chris Murphy on 2013-06-01 14:28:21 EDT ---

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

--- Additional comment from Chris Murphy on 2013-06-01 22:44:24 EDT ---



--- Additional comment from Mads Kiilerich on 2013-06-05 13:55:54 EDT ---

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.

--- Additional comment from Vít Ondruch on 2013-06-10 04:33:43 EDT ---

(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?

--- Additional comment from Fedora Blocker Bugs Application on 2013-06-10 04:37:03 EDT ---

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.

--- Additional comment from Mads Kiilerich on 2013-06-10 04:51:25 EDT ---

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

--- Additional comment from Adam Williamson on 2013-06-10 14:35:00 EDT ---

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.

--- Additional comment from Adam Williamson on 2013-06-10 14:36:45 EDT ---

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

--- Additional comment from Johan Vromans on 2013-07-09 04:35:53 EDT ---

(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

--- Additional comment from Adam Williamson on 2013-07-09 19:01:16 EDT ---

F19 was released a week ago. There's really no point voting on blocker status.

--- Additional comment from Johan Vromans on 2013-07-10 07:06:51 EDT ---

After the latest updates (july 10), the systemd/getty prompt on the ttys show "SchrÔdingerūs Cat".

--- Additional comment from Alexei Podtelezhnikov on 2013-08-09 22:39:21 EDT ---

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.

--- Additional comment from Alexei Podtelezhnikov on 2013-08-12 17:28:04 EDT ---

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.

--- Additional comment from  on 2013-08-20 19:53:30 EDT ---

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.

--- Additional comment from Mark Harfouche on 2013-08-21 13:52:15 EDT ---

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

--- Additional comment from aaronsloman on 2013-10-14 12:56:36 EDT ---

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

--- Additional comment from aaronsloman on 2013-10-15 18:51:01 EDT ---

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

--- Additional comment from Adam Williamson on 2013-10-16 07:35:31 EDT ---

aaron: Bugzilla is not your blog. Please stop posting irrelevant comments. Thanks.