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:
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.
This happens in 16 and 17, both x86 and i386 archs. Can someone in the grub team look at this?
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).
*** Bug 801552 has been marked as a duplicate of this bug. ***
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".
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).
(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.
/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.
It also puts it in the /etc/sysconfig/i18n file, just to complete the list of files that need attention when you fix things.
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.
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.
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).
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?
(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 .
(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!
Same here. F17 Beta installed from LiveUSB. Applying solution at http://forums.fedoraforum.org/archive/index.php/t-277213.html solves the issue.
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.
I thought this already had been fixed?
So, we're dying of curiosity: Where did the True come from versus a valid font name?
http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=92d596fb667b43024986d18a20e1eb50d7e7fd0e
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?
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.
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.
*** Bug 821108 has been marked as a duplicate of this bug. ***
I assume this would be a f17 blocker if it was something all users saw. What decides when it shows up?
(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.
Reopening bug. I hit it on two freshly installed machines. (The only two that didn't go through pre-upgrade). - Gilboa
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.
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
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
And it will be fixed in the next major release of Fedora, hence the closed->rawhide status.
Fedora 17 Final release KDE spin, has the same bug, additional to bug 827187
*** Bug 827229 has been marked as a duplicate of this bug. ***
*** Bug 827258 has been marked as a duplicate of this bug. ***
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.
Sorry, where I say "In notebook" I meant "In a netbook".
*** Bug 831013 has been marked as a duplicate of this bug. ***
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
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.
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
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.
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
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 :)
Oops, reverse Comment 20 and Comment 40 in Comment 42. Sorry about that. Gene
(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.
(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 '='.
Right, there were spaces before and after =, but I don't remember at all touching that... Well, hope it'll work now, thanks :)
*** Bug 832814 has been marked as a duplicate of this bug. ***
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"
*** Bug 834476 has been marked as a duplicate of this bug. ***
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.
(In reply to comment #51) > even after applying the fixes for latarcyrheb-sun16. Please tell exactly which fixes you applied and what you did.
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.
(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.
This is fixed, removing CommonBugs tag.
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"
Bug still occurs with FedUp upgrade fron F19 to F20
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.
Correction: I went from F18 to F20.
John: I filed https://bugzilla.redhat.com/show_bug.cgi?id=1017640 - do you want to add any details you have there? Thanks!
*** Bug 1017640 has been marked as a duplicate of this bug. ***
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.