PDA

View Full Version : [SOLVED] F25 > F26 upgrade goes smooth but can't get graphical login or desktop



PabloTwo
26th October 2017, 06:03 PM
I usually wait at least a month before doing a "dnf system-upgrade" to the next release to give time for the smoke to settle. But seeing all the issues on the forum with F26 at release time I decided to wait a bit longer. Last night I pulled the trigger on that on my desktop PC system (W10/Fedoraxx Xfce/Mint18.1).

Downloading and installing the F26 packages went just fine. On the final reboot, grub2 came up without any issue. At the end of the "details" mode boot into the F26 kernel, nothing further happened (the point where it should bring up the X server and the lightdm login screen.

Ctl+Alt+F2 allowed me to log in to a console tty. Trying "startx" failed. Trying "dnf isolate graphical.target" had the same result as "startx". I searched the forum and internet in general for clues.

Also tried:

Adding nouveau.modeset=0 to the cmdline ( have nvidia card using nouveau driver)
Adding selinux=0 to the cmdline.
Installing another desktop manager (slim) and making it the default.
Booting into both of the remaining two F25 kernels.

Nothing worked. The slim login screen does come up (but it's not running in true graphical mode I believe), but fails with correct username/password. The slim log is pretty sparse, just showing "Waiting the X server to begin accepting connections." and "Waiting for X server to shut down" repeated for each login attempt.

Checking /var/log/Xorg.log.0 and /home/paul/.local/share/xorg/Xorg.log.0 after attempting "startx" from the console as a regular user gives no clue. There are no (EE) and only a couple of miner (WW) items that should not be fatal. The last line in the log is "Server terminated successfully (0). Closing log file". It would seems the Xserver fails to remain running.

Also, failed "startx" attempts prints:

"xf86EaableIOPorts: failed to set IOPL for I/O (Operation not permitted)"
"lib/64/libharfbuzz.so.0: undefined symbol:FT_Get_Var_Blend_Coordinates"
"xinit: connection to xserver lost"

And a failure to find "/home/paul/.serverauth.nnnn", where nnnn is a different number on each attempt and not the one that currently exists.

Also tried downgrading the Xorg-server with dnf (a downgrade doesn't exist for F26). Suggestions and clues are welcome. Fortunately, I still have a perfectly functioning F25 system on my laptop.

nsnbm
27th October 2017, 12:06 AM
Dunno, and sounds like a very frustrating problem. I guess I would try the kernel parameter: xdriver=vesa, just to see if it gets X up, though there's not much reason to have faith in this given what you have tried. I expect your "dnf isolate graphical.target" was a typo for "systemctl ...". Another thing I'd try is to generate an xorg.conf file with: Xorg -configure to see what it comes up with. You could try using it of course, but I haven't had much success with that recently, but it may throw up some variables of interest. There's reinstalling of all the xorg-x11... packages but I guess you may have been through that.

Another suggestion is to write your own .xinitrc and try and start with: xinit instead of startx. But it sounds like the problems are deeper. Maybe try: acpi=off ... really scratching around here on this one.

kldixon
27th October 2017, 11:16 AM
F26 switched to using the modesetting xserver driver by default instead of the nouveau driver and it gave me problems with a network install:
https://bugzilla.redhat.com/show_bug.cgi?id=1470710
You could be seeing a similar issue.
You could try forcing the nouveau driver using the xorg.conf.d file I showed in the bugzilla.

PabloTwo
27th October 2017, 03:03 PM
Yes, I meant "systemctl" instead of "dnf". Sleep deprivation makes it easier to miss those typos. Also tried using dnf to reinstall everything Xorg and lightdm releated packages. The kernel parm "xdriver=vesa" also gave no success. And I tried kldixon's suggestion with the /usr/share/X11/xorg.conf.d/10-nouveau.conf file. No joy as yet with anything tried.

Grepping journalctl -b for "fail" after a failed graphical boot and a console login gives me a screen full of lightdm failures. I can determine the X server is running, but nothing seems to be able to connect to it, which leads me to think that the line:

"xf86EaableIOPorts: failed to set IOPL for I/O (Operation not permitted)"

might be relevant here. Though that line only appears on the console after a failed "startx" as user attempt. Guess I need to do more google searches on that particular error message for a possible clue to a fix.

bob
27th October 2017, 03:58 PM
A few years back, I used to love to spend hour after hour glitch-busting, but I've found that there's less time involved in copying my data over to a working partition or another backup and then burning a fresh copy and re-installing. Sure, there's hundreds of updates to do, but the machine can handle it while I'm off having a couple of brews with friends.

PabloTwo
27th October 2017, 05:05 PM
A few years back, I used to love to spend hour after hour glitch-busting, but I've found that there's less time involved in copying my data over to a working partition or another backup and then burning a fresh copy and re-installing. Sure, there's hundreds of updates to do, but the machine can handle it while I'm off having a couple of brews with friends.

Yes indeed bob, I've certainly given the idea of a fresh clean install of F26 (Xfce spin) on my desktop PC some thought. And it may well eventually come to that.

But here's another observation on the problem that just came up. I've been creating my own rpm packages of pianobar (a console client for pandora.com) for several years now. And though it is now recently available on rpmfusion, I continue to build the package myself to keep it fully up to date. One of the things I do prior to any "dnf system-upgrade ....." is to uninstall any self produced rpm packages.

Since pianobar is a console only package and I can run F26 in console mode, I decided to build the package for F26. The build bombed almost right away with:

"/usr/lib64/libharfbuzz.so.0: undefined reference to `FT_Get_Var_Blend_Coordinates'"

That ties in strongly with:

"lib/64/libharfbuzz.so.0: undefined symbol:FT_Get_Var_Blend_Coordinates"

from my first post here. Just how the compiling of pianobar is dependent on harfbuzz eludes me at present. I checked and there are 55 packages that require harfbuzz, none of which appear to be related to pianobars' requirements. But obviously, some requirement of pianobar requires a call to the harfbuzz lib. It's enough to make your head "buzz".

Edit: Though compiling pianobar doesn't require the harfbuzz-devel package (or so I thought, but found it installed so I added it as a build dep in the pianobar spec file), checking from my working F25 install on the laptop:

$ ldd /usr/bin/pianobar | grep harfbuzz
libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007efe1f63a000)
Might try installing F27 versions of harfbuzz packages, which most likely won't fly due to so many dependency chains.

Edit2: The 1.5.1-1.fc27 versions of harfbuzz, harfbuzz-icu and harfbuzz-devel upgraded the 1.4.4-1.fc26 versions without incident, but still threw the same error out. I downgraded back to the F26 versions. Maybe I need to go in the other direction, down to F25 versions.

PabloTwo
29th October 2017, 04:32 PM
The 1.5.1-1.fc27 versions of harfbuzz, harfbuzz-icu and harfbuzz-devel upgraded the 1.4.4-1.fc26 versions without incident, but still threw the same error out. I downgraded back to the F26 versions. Maybe I need to go in the other direction, down to F25 versions.

Well, this morning I did just that. Used highest version for F25 found on koji. Packages downgraded the F26 packages without complaint. First test was to try and build the pianobar package again. No problem. Next test was to reboot. Was pleasantly presented with the lightdm greeter screen, with subsequent boot into the Xfce desktop.

harfbuzz* is now excluded from updating. Guess I should file a bug report again harfbuzz @ Bugzilla.