Bug 799401

Summary: after install I see SYSFONT=True rather than a font name
Product: [Fedora] Fedora Reporter: Tom Horsley <horsley1953>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 17CC: anaconda-maint-list, andrew.g.dunn, awilliam, ehemdal, eparis, genes1122, gilboad, g.kaviyarasu, i18n-bugs, ipilcher, jafb, jaroslaw.gorny, jdunn, johan.spee, jonathan, kassabon14, kevinc, kparal, liblit, lkundrak, lmedinas, madhu.chinakonda, mads, mail, michael.monreal+bugs, mst, mzdunek, pjones, ptalbert, rahulbhadana084, shaun.ren, stanley.king, tabloid.adroit, thomas, vanmeeuwen+fedora, vonbrand, xset1980
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Unspecified   
URL: http://forums.fedoraforum.org/showthread.php?t=277213
Whiteboard:
Fixed In Version: anaconda-18.3-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 827229 (view as bug list) Environment:
Last Closed: 2012-05-31 10:10:33 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Tom Horsley 2012-03-02 11:36:21 EST
Description of problem:

After installing from f17 alpha x86_64 DVD, my /boot/grub2/grub.cfg
file, /etc/default/grub, and /etc/sysconfig/i18n files all say
SYSFONT=True rather than the normal SYSFONT=latarcyrheb-sun16 I
normally get all previous Fedora versions.

If it should say True, that raises the question of how the devil I
set the console font to something else (like latarcyrheb-sun32).


Version-Release number of selected component (if applicable):
whatever anaconda is on the f17 alpha DVD

How reproducible:
I only installed once, but I image the same thing would happen
every time

Steps to Reproduce:
1.see above
2.
3.
  
Actual results:
SYSFONT=True

Expected results:
SYSFONT= some console font name

Additional info:
Comment 1 Tom Horsley 2012-03-03 08:46:53 EST
Experimenting does reveal that I can say latarcyrheb-sun32 instead of True
and it will really use that big enough to see font, but True still seems
weird.
Comment 2 Dan Mashal 2012-03-14 15:26:45 EDT
This happens in 16 and 17, both x86 and i386 archs. 

Can someone in the grub team look at this?
Comment 3 Tom Horsley 2012-04-17 20:45:48 EDT
I just installed the F17 Beta DVD and still see this.

I do wonder if this has something to do with the kbd change to include
the latarcyrheb-sun32 along with the latarcyrheb-sun16 font (just a thought since that was a change for f17).
Comment 4 Chris Lumens 2012-04-18 09:35:43 EDT
*** Bug 801552 has been marked as a duplicate of this bug. ***
Comment 5 Jayes 2012-04-19 07:25:27 EDT
This problem just showed up here after an update of F17 (i.e. not an fresh install).
 
I certainly would not rate the severity as "low", though, because it keeps grub from booting and consequently renders the entire system useless. That's more like "urgent".
Comment 6 Tom Horsley 2012-04-19 08:01:03 EDT
Hmmm... It didn't prevent the boot for me back when it first happened on f17 alpha, maybe preventing boot is new in f17 beta (I always fix it and a bunch of other junk before I firstboot now anyway, so I wouldn't have noticed).
Comment 7 Andrew Dunn 2012-04-21 08:46:30 EDT
(In reply to comment #5)
> This problem just showed up here after an update of F17 (i.e. not an fresh
> install).
> 
> I certainly would not rate the severity as "low", though, because it keeps grub
> from booting and consequently renders the entire system useless. That's more
> like "urgent".

This also appears to render my entire system useless. I ran into it yesterday and re-installed F17 completely thinking it was something I did.

The system will not boot.
Comment 8 Mads Kiilerich 2012-04-21 09:05:19 EDT
/etc/default/grub is generated/overwritten by anaconda ... and it did apparently for some reason put a bad value there.

It might be a dracut bug that this bad value prevents booting.
Comment 9 Tom Horsley 2012-04-21 09:19:30 EDT
It also puts it in the /etc/sysconfig/i18n file, just to complete the list of files that need attention when you fix things.
Comment 10 Tom Horsley 2012-04-22 20:27:06 EDT
Here's a new variation on this bug: In my f17 Beta partition, I had manually
changed grub.cfg, /etc/default/grub, and /etc/sysconfig/i18n to all say
latarcyrheb-sun32 instead of "True".

I just got a kernel update for f17 to kernel 3.3.2-8.fc17.x86_64 and the new entry in grub.cfg says SYSFONT=True instead of latarcyrheb-sun32.

I then looked at /etc/sysconfig/i18n and something somewhere seems to have changed it back to "True" as well (which is probably where the kernel update got it from).

I have no idea what package updates /etc/sysconfig/i18n because it isn't marked as being owned by any package.

I suppose there is a small chance that the original change to the i18n file didn't work, but I used the same sed script for that file as for all the others.
Comment 11 Tom Horsley 2012-04-22 20:34:20 EDT
OK, I take it back - comment #10 is a red herring. The sed script wouldn't have worked on the i18n file the way it was written (it will work now). So the reverting to True for new kernel is because that was still in the i18n file.
Comment 12 Horst H. von Brand 2012-04-26 18:06:49 EDT
I see the same as comment #5 (kernel-3.4.0-0.rc4.git1.1.fc18.x86_64), but AFAICS the "system not booting" (really falling into dracut shell) is due to not finding the LVM volumes. Just deleting the nonsense "SYSFONT=True" gets kernel-3.4.0-0.rc3.git0.1.fc18.x86_64 to  boot OK (haven't tried others, machine isn't at hand to fool around).
Comment 13 Ian Pilcher 2012-05-10 16:51:36 EDT
I'm seeing the same thing when I install kernel updates on my system, which is still using grub 0.9.  This happens even though I've removed the SYSFONT=... bit from the kernel command line in grub.conf.

AFAIK, grubby is responsible for updating the config for both grub 2 and grub 0.9, so doesn't that make this a grubby bug?
Comment 14 Mads Kiilerich 2012-05-10 17:48:25 EDT
(In reply to comment #13)

grubby will do what anaconda told it to do.

I assume you still have a wrong SYSFONT=True setting somewhere - probably /etc/sysconfig/i18n .
Comment 15 Ian Pilcher 2012-05-10 23:41:12 EDT
(In reply to comment #14)
> I assume you still have a wrong SYSFONT=True setting somewhere - probably
> /etc/sysconfig/i18n .

Spot on.  And that file was presumably created by anaconda.

Back to my hole now.

Thanks!
Comment 16 Alen Siljak 2012-05-11 12:14:59 EDT
Same here. F17 Beta installed from LiveUSB.

Applying solution at 
http://forums.fedoraforum.org/archive/index.php/t-277213.html
solves the issue.
Comment 17 Chris Lumens 2012-05-11 12:55:15 EDT
This will be fixed in the next major release of Fedora.  If you need a fix in F17, at this point the bug needs to be made a blocker and discussed in the weekly meetings.
Comment 18 Mads Kiilerich 2012-05-11 13:16:52 EDT
I thought this already had been fixed?
Comment 19 Tom Horsley 2012-05-11 13:22:58 EDT
So, we're dying of curiosity: Where did the True come from versus a valid font name?
Comment 21 Michael Monreal 2012-05-11 16:20:11 EDT
So for those of us with affected installations, what is the correct way to fix this, to get to the same state the fixed anaconda would get you after a F17 final installation?
Comment 22 Mads Kiilerich 2012-05-11 16:26:30 EDT
You should fix it manually. You helped testing anaconda and unfortunately it made a minor error. It is easy for you to fix and there is no way anaconda can fix it on your system now.
Comment 23 Tom Horsley 2012-05-11 16:49:29 EDT
Just manually change True every place it is used as a font name in the
following 3 files:

/boot/grub2/grub.cfg
/etc/sysconfig/i18n
/etc/default/grub

Typically it was latarcyrheb-sun16 on most systems.

You could use latarcyrheb-sun32 if you want a bigger font for boot messages
and in console screens.
Comment 24 Mads Kiilerich 2012-05-12 07:08:53 EDT
*** Bug 821108 has been marked as a duplicate of this bug. ***
Comment 25 Mads Kiilerich 2012-05-12 07:10:21 EDT
I assume this would be a f17 blocker if it was something all users saw. What decides when it shows up?
Comment 26 Sheldon Hearn 2012-05-30 06:03:04 EDT
(In reply to comment #22)
> You should fix it manually. You helped testing anaconda and unfortunately it
> made a minor error. It is easy for you to fix and there is no way anaconda
> can fix it on your system now.

This happened to me with a fresh install of F17 Release, from the x86_64 Live CD. I'm surprised this wasn't deemed worth fixing; it's visually jarring.
Comment 27 Gilboa Davara 2012-05-31 05:02:26 EDT
Reopening bug.
I hit it on two freshly installed machines. (The only two that didn't go through pre-upgrade).

- Gilboa
Comment 28 Tom Horsley 2012-05-31 05:28:19 EDT
Yep. I did a fresh install of f17 from the DVD iso and got the same old True value in the grub.cfg file, the /etc/default/grub files and the /etc/sysconfig/i18n file.
Comment 29 Gilboa Davara 2012-05-31 08:21:43 EDT
I should point out that at least in my case, as far as I could see it prevented dracut from booting.
Now, I'm not sure if the SYSFONT is the culprit (for the no-load), but the last dracut message was "bad font" and then console and when I fixed the problem and rebuilt the menu, the machine managed to boot (or semi-boot-and-then-blow, curtsy of 3.3.7-1.fc16/17 bug)

- Gilboa
Comment 30 Gilboa Davara 2012-05-31 08:27:53 EDT
I should stress that I greatly doubt that its the cause of the no-boot. Most likely Anaconda left me with a completely busted grub + dracut.
... But in case someone else sees this, etc.

- Gilboa
Comment 31 Chris Lumens 2012-05-31 10:10:33 EDT
And it will be fixed in the next major release of Fedora, hence the closed->rawhide status.
Comment 32 xset1980 2012-05-31 18:36:35 EDT
Fedora 17 Final release KDE spin, has the same bug, additional to bug 827187
Comment 33 Mads Kiilerich 2012-05-31 19:27:26 EDT
*** Bug 827229 has been marked as a duplicate of this bug. ***
Comment 34 Chris Lumens 2012-05-31 22:53:31 EDT
*** Bug 827258 has been marked as a duplicate of this bug. ***
Comment 35 Juan 2012-06-03 12:02:46 EDT
Happened to me in a fresh install from the final release DVD.
As additional data, I installed grub in the boot sector of the active partition instead of the MBR.
In notebook I have I installed in the same way (boot sector) and it just didn't boot (can't find file or can't find partition or something similar) and I was obligated to install grub in MBR. It was LXDE spin from live CD. I'll post this as a separate bug, but I mention it here as this version of anaconda doesn't look to deal well with installing grub in the boot sector, which might (or might not) have anything to do with this font bug.

Any official workaround? The one in the forum? The one in comment 23?

Thanks.
Comment 36 Juan 2012-06-03 12:03:49 EDT
Sorry, where I say "In notebook" I meant "In a netbook".
Comment 37 Mads Kiilerich 2012-06-11 20:50:38 EDT
*** Bug 831013 has been marked as a duplicate of this bug. ***
Comment 38 Gene Snider 2012-06-15 19:17:55 EDT
After reading this bug, I'm still confused.  Every time I do a kernel update, SYSFONT=True gets added to the new entry in grub.cfg.  Running grub2-mkconfig removes that entry, and the new entry in the advanced section doesn't have the bogus SYSFONT=True.  The fix in Comment 23 seems broken for /etc/sysconfig/i18n.  The new definition of SYSFONT in the git commit described by Chris Lumens in Comment 20 doesn't support a font name, SYSFONT is now a boolean.   What is the correct way to keep dracut from generating the bogus grub entries on kernel updates?  

Thanks,
Gene
Comment 39 Juan 2012-06-15 19:26:03 EDT
Yes, I remember seeing errors related to applying fix in comment 23 to /etc/sysconfig/i18n.
When I see this error again, I'll post it (now I don't remember it exactly).
Unfortunately, I tried grub2-mkconfig in one of my computers and entries for some kernel versions just disappeared.
Comment 40 Gene Snider 2012-06-15 20:04:58 EDT
Ok, I see what's happening.  The file /usr/sbin/new-kernel-pkg runs when yum installs a new kernel.  Lines 698-711 follow:

# add dracut i18n, keyboard and plymouth kernel args if requested
if [ -n "$dracut" -o -n "$adddracutargs" ]; then
    [ -r /etc/sysconfig/keyboard ] && . /etc/sysconfig/keyboard
    [ -r /etc/sysconfig/i18n ] && . /etc/sysconfig/i18n

    for i in SYSFONT SYSFONTACM UNIMAP LANG KEYTABLE; do
        val=$(eval echo \$$i)
        [ -n "$val" ] && kernargs="$kernargs $i=$val"
    done

    if [ -n "$KEYBOARDTYPE" -a "$KEYBOARDTYPE" != "pc" ]; then
         kernargs="$kernargs KEYBOARDTYPE=$KEYBOARDTYPE"
    fi
fi

So perhaps this bug can be reopened and changed to the appropriate package?

Thanks,
Gene
Comment 41 Mads Kiilerich 2012-06-16 08:43:59 EDT
Gene, have you done the fix in comment 23? Does it not work you?

This is assigned to the right package and is fixed for f18.
Comment 42 Gene Snider 2012-06-16 16:52:51 EDT
I modified the fix in Comment 23.  I copied /usr/sbin/new-kernel-pkg to /usr/local/sbin and removed SYSFONT from the for statement shown in Comment 20.  Now, the bogus SYSFONT=True isn't added to the command line generated when a new kernel is installed by yum.  Shouldn't my patch be put in grubby for F16 and F17?  The git commit in Comment 40 explicitly redefined SYSFONT to a boolean.  I'm guessing there's a reason for SYSFONT="True" being in /etc/sysconfig/i18n besides the broken reference from new-kernel-pkg.  If this isn't the case, then I'll fix /etc/sysconfig/i18n.

Gene
Comment 43 Juan 2012-06-16 17:06:33 EDT
About my comment 39, the error happens when installing kernel rpm.
It complains about SYSFONT not being a command, in i18n file.
May be it has anything to do about what Gene Snider says in the previous comment that, if I didn't misunderstand, SYSFONT=True is right in i18n file?
I changed it as suggested in comment 23.
Sorry if I'm a bit newbie about all this and I say nonsense sometimes :)
Comment 44 Gene Snider 2012-06-16 17:10:47 EDT
Oops, reverse Comment 20 and Comment 40 in Comment 42.  Sorry about that.

Gene
Comment 45 Mads Kiilerich 2012-06-16 18:19:08 EDT
(In reply to comment #42)
> I modified the fix in Comment 23.  I copied /usr/sbin/new-kernel-pkg to
> /usr/local/sbin and removed SYSFONT from the for statement shown in Comment
> 20.  Now, the bogus SYSFONT=True isn't added to the command line generated
> when a new kernel is installed by yum.  Shouldn't my patch be put in grubby
> for F16 and F17?  The git commit in Comment 40 explicitly redefined SYSFONT
> to a boolean.  

> I'm guessing there's a reason for SYSFONT="True" being in
> /etc/sysconfig/i18n besides the broken reference from new-kernel-pkg.

No, there is no reason. It is just a bug in the f17 installer. F17 has been released and it is too late to fix it.
Comment 46 Mads Kiilerich 2012-06-16 18:21:04 EDT
(In reply to comment #43)
> About my comment 39, the error happens when installing kernel rpm.
> It complains about SYSFONT not being a command, in i18n file.

You must have introduced a syntax error in that file - probably a space before '='.
Comment 47 Juan 2012-06-16 21:06:27 EDT
Right, there were spaces before and after =, but I don't remember at all touching that...
Well, hope it'll work now, thanks :)
Comment 48 Lukáš Nykrýn 2012-06-18 04:50:33 EDT
*** Bug 832814 has been marked as a duplicate of this bug. ***
Comment 49 Rahulbhadana 2012-06-19 12:39:59 EDT
still in the problem .............................after making the change in grub (mention here http://forums.fedoraforum.org/archive/index.php/t-280626.html replacing the True by latarcyrheb-sun16) .. unable to start fedora 17 and i get this error "Failed to start recreate volatile file and directories"
Comment 50 Lukáš Nykrýn 2012-06-22 01:21:36 EDT
*** Bug 834476 has been marked as a duplicate of this bug. ***
Comment 51 J. Erik Hemdal 2012-07-08 15:58:27 EDT
I encountered this issue upon start up of F17 after installing from the KDE live CD; but this did not prevent boot.  After my first round of updates, including kernel 3.4.4-5.fc17.i686, I cannot get the system out of emergency mode, even after applying the fixes for latarcyrheb-sun16.
Comment 52 Mads Kiilerich 2012-07-31 16:16:01 EDT
(In reply to comment #51)
> even after applying the fixes for latarcyrheb-sun16.

Please tell exactly which fixes you applied and what you did.
Comment 53 J. Erik Hemdal 2012-07-31 20:48:46 EDT
I applied only the fixes in Comment 23.  I wanted the system for coursework, and had to abort my efforts to try to find the cause -- I ran out of time to try to troubleshoot the system and needed to get some kind of Fedora system running, even if it were back-rev.

I still have the machine at hand, never got around to resuscitating it.
Comment 54 Mads Kiilerich 2012-08-03 07:30:04 EDT
(In reply to comment #53)

It works for others. If it doesn't work for you then the best guess would be that something wasn't done correctly. Rephrasing and showing yuor changes would be the best way to find out what is going on.
Comment 55 Kamil Páral 2012-09-17 12:17:44 EDT
This is fixed, removing CommonBugs tag.
Comment 56 The Old Man 2013-09-11 15:28:04 EDT
well, fixed...

using FedUp upgrading (sep 11, 2013) from F17 to F19 dracut-install says:

-------
dracut-install: ERROR: installing 'usr/lib/kdb/consolefonts/True.*'
E: /usr/lib/dracut-install -D /var/tmp/initramfs.Kn1K60 /usr/lib/kdb/consolefonts/True.*'
------


so it is a dracut thing see comment 3

@ comment 19: seems to me that 'True' is referring to the Truetype font, and not to be interpretated as "True or False"
Comment 57 John Ellson 2013-10-03 03:48:22 EDT
Bug still occurs with FedUp upgrade fron F19 to F20
Comment 58 Adam Williamson 2013-10-10 05:25:53 EDT
yeah, I think I saw the same as John Ellson: my laptop which I fedup'ed from F19 to F20 has 'SYSFONT=True' even in /etc/default/grub . I guess we should open a new bug.
Comment 59 Adam Williamson 2013-10-10 05:26:24 EDT
Correction: I went from F18 to F20.
Comment 60 Adam Williamson 2013-10-10 05:29:45 EDT
John: I filed https://bugzilla.redhat.com/show_bug.cgi?id=1017640 - do you want to add any details you have there? Thanks!
Comment 61 Adam Williamson 2013-10-10 05:39:49 EDT
*** Bug 1017640 has been marked as a duplicate of this bug. ***
Comment 62 Adam Williamson 2013-10-10 05:41:27 EDT
Actually, it looks like I just hit the original incarnation of this bug and never noticed till now. John, yours is probably the same. If you happened to install with the bad anaconda, no upgrade will ever fix it: you'll have to do it manually. But it's 'fixed' in that people who install now don't have the problem.