Bug 961533 - grub2 menu entry shows Schr?dinger?s Cat after a 'yum update'
Summary: grub2 menu entry shows Schr?dinger?s Cat after a 'yum update'
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 19
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
: 963150 (view as bug list)
Depends On:
Blocks: F19-accepted, F19FinalFreezeException 1044061
TreeView+ depends on / blocked
 
Reported: 2013-05-09 20:35 UTC by Reartes Guillermo
Modified: 2015-01-09 19:40 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1044061 (view as bug list)
Environment:
Last Closed: 2015-01-09 19:40:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screen-shot of grub2 (26.10 KB, image/png)
2013-05-09 20:35 UTC, Reartes Guillermo
no flags Details
screen-shot of grub2 (GNOME Base Environment) (24.53 KB, image/png)
2013-05-09 20:36 UTC, Reartes Guillermo
no flags Details
F19b RC4 (25.35 KB, image/png)
2013-05-26 15:56 UTC, Reartes Guillermo
no flags Details
grub.cfg updated with grubby (5.91 KB, text/plain)
2013-06-01 18:21 UTC, Chris Murphy
no flags Details

Description Reartes Guillermo 2013-05-09 20:35:39 UTC
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 :-)

Comment 1 Reartes Guillermo 2013-05-09 20:36:44 UTC
Created attachment 745819 [details]
screen-shot of grub2 (GNOME Base Environment)

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

Comment 2 Reartes Guillermo 2013-05-26 15:51:08 UTC
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.

Comment 3 Reartes Guillermo 2013-05-26 15:56:40 UTC
Created attachment 753332 [details]
F19b RC4

Comment 4 Matthias Andree 2013-05-30 08:04:01 UTC
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?

Comment 5 Chris Murphy 2013-06-01 18:21:07 UTC
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.

Comment 6 Chris Murphy 2013-06-01 18:28:21 UTC
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

Comment 7 Chris Murphy 2013-06-02 02:44:24 UTC
*** Bug 963150 has been marked as a duplicate of this bug. ***

Comment 8 Mads Kiilerich 2013-06-05 17:55:54 UTC
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.

Comment 9 Vít Ondruch 2013-06-10 08:33:43 UTC
(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?

Comment 10 Fedora Blocker Bugs Application 2013-06-10 08:37:03 UTC
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.

Comment 11 Mads Kiilerich 2013-06-10 08:51:25 UTC
(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.

Comment 12 Adam Williamson 2013-06-10 18:35:00 UTC
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.

Comment 13 Adam Williamson 2013-06-10 18:36:45 UTC
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...

Comment 14 Johan Vromans 2013-07-09 08:35:53 UTC
(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

Comment 15 Adam Williamson 2013-07-09 23:01:16 UTC
F19 was released a week ago. There's really no point voting on blocker status.

Comment 16 Johan Vromans 2013-07-10 11:06:51 UTC
After the latest updates (july 10), the systemd/getty prompt on the ttys show "SchrÔdingerūs Cat".

Comment 17 Alexei Podtelezhnikov 2013-08-10 02:39:21 UTC
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.

Comment 18 Alexei Podtelezhnikov 2013-08-12 21:28:04 UTC
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.

Comment 19 reescf 2013-08-20 23:53:30 UTC
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.

Comment 20 Mark Harfouche 2013-08-21 17:52:15 UTC
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

Comment 21 aaronsloman 2013-10-14 16:56:36 UTC
(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).

Comment 22 aaronsloman 2013-10-15 22:51:01 UTC
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

Comment 23 Adam Williamson 2013-10-16 11:35:31 UTC
aaron: Bugzilla is not your blog. Please stop posting irrelevant comments. Thanks.

Comment 24 Zamir SUN 2014-02-10 15:52:08 UTC
How is

Comment 25 Zamir SUN 2014-02-10 15:55:30 UTC
(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

Comment 26 Fedora End Of Life 2015-01-09 18:05:38 UTC
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.

Comment 27 Adam Williamson 2015-01-09 19:40:44 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.