| Summary: | GTK apps without text | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Renato Dali <mkare> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
WHisker menu -- no chars.
Xfce Configuration manager -- no chars. Xfce desktop without chars with KDE Systemsettings with chars. journalctl errors in red. Nouveau /var/log/Xorg.0.log fbdev driver Xorg.0.log |
||
I'm closing this bug as it no longer applies to RC3. The fact really happened and can be reproduced by re-installing RC1 (at last for a time, I suppose, changes in packages might make it non-reproducible). Thanks. Status:
NEW =>
RESOLVED Sorry, it seems I was a little too eager to close this bug.
Tonight (March,11), I added the repos to my fresh RC3 installation and installed some updates (more than 20, I believe) after receiving a notification to do so.
The bug is back. I'm reopening it and attached some illustrative screenshots, one of them with error messages at the end of journalctl's output (the letters were in red).
As can be seen, gtk apps have no chars while Qt ones appear as usual.
Since nouveau is repeated in all red lines, I decided to try an alternative: edit xorg.conf and replaced the line:
Driver "nouveau"
with
Driver "fbdev"
The characters then reappeared in gtk apps.
I'm also attaching the Xorg.0.log outputs, fbdev's and nouveau's.
That's what I have now. Please ask for more data if needed.Status:
RESOLVED =>
REOPENED Created attachment 6043 [details]
WHisker menu -- no chars.
Created attachment 6044 [details]
Xfce Configuration manager -- no chars.
Created attachment 6045 [details]
Xfce desktop without chars with KDE Systemsettings with chars.
Created attachment 6046 [details]
journalctl errors in red.
Created attachment 6047 [details]
Nouveau /var/log/Xorg.0.log
Created attachment 6048 [details]
fbdev driver Xorg.0.log
Well, when it rains, it pours. The computer wouldn't boot after a night "resting". The monitor would cycle from analog to digital input until it quit and told me to check the cable. A hard reset would make the computer do the power-on self-test, show the kernel options and then... die. Probably the video card could not be initialized, as I couldn't switch to text mode consoles (e.g. Ctrl_Alt_F3). I thought, hey, might be the hardware after all. But two live distributions (Handylinux and SolydX, both from 2014) booted and work as expected. The second option, boot Cauldron in Safety mode did reach text mode root login; I then tried the F3 boot options (no acpi, no local apic...). When using "safe configurations", the boot seemed to freeze, too, but finally I could switch to other consoles. "startx -- :1" failed and I saw a message like "fbdevhw: devices encountered but none match configuration file". Hmm, I thought, let's change from fbdev to nouveau in xorg.conf. And then Mageia 5 RC3 would boot normally again. If possible, I'll reinstall RC3 on weekend and try to update individual packages to see where it goes sour. Since the plan is to re-install and test each package to see which made the letters disappear, I installed NVidia's proprietary "304" driver to see how things would go (it was hard to remove, so it's not an easy decision unless one is going to reformat everything). The good news is that characters reappeared with the closed driver. It's a good of workaround for this video card and the present problem -- at least, for the moment. Also, that makes this bug less critical and no longer a showstopper, IMHO. Since it's closed software for which one day support will be dropped, we got to find what made Nouveau stop working. Tried to reinstall RC3 and updated the stronger candidates (in my view) to messing up things: kernel nonfree..., gtk+ 2.0, gtk+ 3.0 and libfreetype6. Text was not affected and things went on normally. Since it's 610 packages to test, I had the idea of installing again -- this time just Xfce, leaving KDE out of the frame. Installation went uneventfully. Just for the record, I install with no additional (online) media, no individual package selection, no closed driver (it's a Nvidia card) and no updates at the end of the installation. I then reboot, include online repos, remove the CDROM ones and then update the system. Choosing KDE and Xfce, after the updates my system showed gtk apps without text. Yesterday, I did the same without installing KDE and everything is perfect. I shall reinstall with KDE to confirm the problem persists. I really don't know much; I supposed in case of a problem with Freetype that both gtk and Qt apps would be equally deprived of text. If anyone has a better way to find the problem, please advise me. The bug is gone; something probably was changed in some package for whatever reason and, as result, the current problem no longer arises. I did install KDE alone: the bug didn't reappear (as with Xfce as the only desktop). I then reinstalled Xfce+KDE and no problem whatsoever. Therefore, I'm closing this bug. It's now invalid, because cannot be reproduced. Status:
REOPENED =>
RESOLVED |
This is actually a bug which happened with M5 RC1. Updating to RC3 "solved" it. I have an old CPU (AMD Sempron 2300+: i686, ~1.6GHz, !SSE2) which I'm testing with a Geforce 6200 (NV44A). This combination worked satisfactorily with Mageia 3 in the past and for some hours with Mageia 5 (using the Nouveau driver). By way of experimentation, on the 7th of March, I decided to try the Nvidia provided closed driver ("304" series). At the time, an incredibly obnoxious bug occurred: all characters disappeared from GTK+ applications. The Firefox window would be correctly drawn but all text would be missing. Only underline in shortcuts would be shown. Xfce menus, panel and configuration would be equally without any text. But icons were available, so it was possible to guess the leave/terminate session option. KDM's login screen was normal, so I decided to choose KDE4 and log back in. The entire desktop was produced without error: menus worked, configuration (systemsettings) etc. But Firefox would present the same problem: no chars whatsoever. Thus, I concluded, the problem was restricted to GTK apps. I also thought it was due to my attempt at using Nvidia closed drivers, so I proceeded to remove its rpm packages as well as changing xorg.conf back to nouveau (and I removed that DKMS thing, too). Of course, there may be other things which might be needed. On March, 9th, concluding my attempts to restore nouveau were less than successful, I decided to reinstall RC1 -- keeping my home directory intact (it was in a separate partition). The problem remained. I then proceeded to reinstall RC1 again, this time wiping also the home partition. RC3 was already available, but I had the RC1 disk at hand and it seemed highly probable that a fresh install would remove the problem. With RC1 installed (after choosing NOT to use nonfree drivers), all things boot quite well (into KDE, IIRC) and I did the necessary updates -- over a thousand packages, which take some 2-4 hours to complete (I went to sleep, actually). The problem (GTK apps without text) came back again, much to my dismay. I then decided to download and install RC3, which no longer presents that problem. Actually, now is the other way around: Xfce works nicely while KDE seems to have problems with that h/w configuration (bug 15462 ). My conclusion is -- for the moment :-/ ... something, probably unrelated to the Nvidia drivers, went wrong in an update done on the days immediately before March, 8th. The problem may be or not related to the graphics card or to the CPU. I even don't know if it was solved by installing RC3 or by some condition which went away as fast as it appeared. I'm filing this bug to document it; since the bug affected an obsolete version and since I now have another serious one to deal with in RC3 ( 15462 ), I'd rather leave the machine with RC3 installed. I won't close it immediately, so that it is read by someone, but I strongly suggest closing the current one as RESOLVED WORKSFORME or WONTFIX, so as to focus on more pressing issues. Of course, people who deal with bugs on a daily basis, are more able than me to tell what is important from what is not. Again, thanks everyone for an amazing job. This distribution has saved my professional life more than once.