Bug 1218787
Summary: | gdm-wayland-session fails to present login screen after successful installation | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Murphy <bugzilla> | ||||||||||||||||
Component: | gdm | Assignee: | Ray Strode [halfline] <rstrode> | ||||||||||||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||
Priority: | unspecified | ||||||||||||||||||
Version: | 22 | CC: | airlied, ajax, awilliam, bmourelo, bojan, bugzilla, danofsatx, didierg-divers, dtimms, esteban.xandri, forbisc, jreznik, kayvansylvan, kparal, matthias.rambausek, mclasen, mgautier, mzdunek, pschindl, rhughes, robatino, rstrode, sam.bristow, satellitgo, sgallagh, spljaa, william, znmeb | ||||||||||||||||
Target Milestone: | --- | Keywords: | CommonBugs | ||||||||||||||||
Target Release: | --- | ||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||
Whiteboard: | https://fedoraproject.org/wiki/Common_F22_bugs#wayland-gdm-dual-gpu-macbook RejectedBlocker | ||||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||
Last Closed: | 2016-07-19 13:59:47 UTC | Type: | Bug | ||||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||
Embargoed: | |||||||||||||||||||
Bug Depends On: | |||||||||||||||||||
Bug Blocks: | 1277927 | ||||||||||||||||||
Attachments: |
|
Description
Chris Murphy
2015-05-05 21:17:28 UTC
Created attachment 1022320 [details]
journal live media boot
Created attachment 1022322 [details]
journal first boot
Proposed as a Blocker for 22-final by Fedora user chrismurphy using the blocker tracking app because: A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility. Did you create a user during installation, or not? Yes. OK, so the thing that should've come up on first boot was gdm. It's supposed to try Wayland and if that fails fall back to X; so it seems like it never hits the fallback, in your case. The logs really don't tell us much, AFAICS, the system basically thinks the gdm-on-wayland session is working fine and is just waiting for you to do something, but as you say, you're just seeing a black screen. Wayland doesn't seem to log anything useful (or, really, at all). I'm no expert on how to get more info out of Wayland yet, but http://wayland.freedesktop.org/building.html suggests that if you can somehow get WAYLAND_DEBUG=1 set, it might help. I think the bug's as likely (or more likely) to be in wayland as in gdm, so let's pull in some wayland/gfx people. Created attachment 1022887 [details]
journal wayland gdmdebug
Edited /etc/gdm/custom.conf, to uncomment the debugging line. Piles of gdm messages are now in this journal.
Created attachment 1022888 [details]
lspci -vvnn
This is a computer with two GPUs. Complete lspci attached, below is the summary for the two GPUs.
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Apple Inc. Device [106b:00dc]
Kernel driver in use: i915
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] [1002:6741] (prog-if 00 [VGA controller])
Subsystem: Apple Inc. MacBookPro8,2 [Core i7, 15", Late 2011] [106b:00e2]
Kernel driver in use: radeon
Created attachment 1022909 [details]
photo of screen
I think useless, but attaching for completeness. This is a photo of the display at the point boot hangs. This is with rhgb quiet removed as boot parameters.
afaics all the debug messages you got are from gdm itself, not wayland. airlied, ajax, anyone, could you advise how to get any useful debugging info here? Discussed at the 2015-05-11 blocker review meeting[0] where it was agreed to await further information before voting. #agreed 1218787 - punt (delay decision) one week - this is a bad bug but so far known to affect only one system; we're inclined to reject it as too hardware-specific, but will wait to see if any info appears indicating it affects more than this particular laptop/graphics adapter combination [0]: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-05-11/ It seems I have similar problem on Dell D600 with AMD RV250/M9 GL FireGL 9000/Radeon 9000 I installed Fedora 22 32 bits using Fedora-Live-Workstation-i686-22_Beta-3.iso Just after installation, Fedora boots fine and I get gdm prompt. If I update only gnome-shell* and after reboot I do not longer get gdm prompt but only black screen. In this situation I am able to switch to text login using Ctrl-Alt-Fx Created attachment 1024341 [details]
syslog
Didier: can you confirm if you see the same problem when installing from Final TC1 and/or TC3? https://dl.fedoraproject.org/pub/alt/stage/22_TC1/ https://dl.fedoraproject.org/pub/alt/stage/22_TC3/ Chris: can you see if your case is a regression from Beta (i.e. if an install from Beta is OK on your system)? Thanks! Baring data to the contrary, I expect all AMD+Intel dual-GPU MacbookPros to be affected by this bug. And keep in mind this is a particularly bad regression, not merely working with Fedora 21, but it works when booting install media giving the impression it will work post-install yet it doesn't. I kinda think it's a bad idea that install media boot uses X by default, while post-install boot uses Wayland by default. The user could change /etc/gdm/custom.conf to have GDM use X instead of Wayland (or disable one of the GPUs at boot time), but those workarounds require user intervention so it's still a regression from F21 and live media booting. Is GDM on Wayland by default worth it right now for Fedora 22 if even a significant minority of users run into seeming showstopper (or rabbit hole) bugs like this? Problem occurs on MacbookPro with: Fedora-Live-Workstation-x86_64-22_Alpha-TC8.iso Fedora-Live-Workstation-x86_64-22_Beta-TC8.iso Seems improbable it would work with Beta TC3 but I will test on request. Didier: in that case, your bug is probably not the same as Chris'; could you file a separate report? Thanks. Otherwise we're going to get confused. Chris: have you checked that switching to X via custom.conf actually works? (In reply to Adam Williamson from comment #18) > Chris: have you checked that switching to X via custom.conf actually works? Yes. I'm guessing you still don't see Plymouth (bootsplash) in that case? I'm guessing X init involves some kind of forced mode reset or refresh or something that gets stuff going, but Wayland/Plymouth don't do that... (In reply to Adam Williamson from comment #20) > I'm guessing you still don't see Plymouth (bootsplash) in that case? No. I get the text based status bar at the bottom. (In reply to Adam Williamson from comment #14) > Didier: can you confirm if you see the same problem when installing from > Final TC1 and/or TC3? > > https://dl.fedoraproject.org/pub/alt/stage/22_TC1/ > https://dl.fedoraproject.org/pub/alt/stage/22_TC3/ If I was able to run Live then install form Fedora-Live-Workstation-i686-22_Beta-3.iso , I get screen "Something has gone wrong" when booting Live on Fedora-Live-Workstation-i686-22-TC3.iso so I am unable to go further with this version... Don't want to muddy the waters too much here, but there is also the case of flickering of gdm/wayland on various Intel GPU machines (bug #1200581), which then requires commenting out of wayland in gdm's config file. Maybe this thing is not ready yet for prime time... Chris, do you have the ability to boot with an external monitor? I've seen interesting bugs on certain (dual-GPU) hardware where the driver incorrectly assumes that it's attached to an external monitor even without a cable present. If it boots with an external monitor, that would be useful information. (In reply to Stephen Gallagher from comment #24) > Chris, do you have the ability to boot with an external monitor? Yes. It mirrors what's on the laptop display whether I boot with it connected, or boot and then connect it. mutter/wayland, indeed, only works with single GPU systems at the moment, but it should be falling back to X (mutter will exit early unable to initialize and gdm fallback logic should kick in) Chris, 1) do you know off hand if the kernel fbconsole is using /dev/dri/card0 or /dev/dri/card1 ? 2) does the behavior change if selinux is put in permissive mode? (please remember to change custom.conf back to turn wayland back on) 3) if you run # mv /usr/libexec/gdm-wayland-session /usr/libexec/gdm-wayland-session.real # echo << EOF > /usr/libexec/gdm-wayland-session #!/bin/sh [ -e /dev/dri/card1 ] && exit 1 exec /usr/libexec/gdm-wayland-session.real "$@" EOF # chmod +x /usr/libexec/gdm-wayland-session does the problem go away ? > 1) do you know off hand if the kernel fbconsole is using /dev/dri/card0 or > /dev/dri/card1 ? No. When I boot normally (no tricks to force disable one of the GPUs) I see this: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/graphics/fb1 /sys/devices/pci0000:00/0000:00:02.0/graphics/fb0 /sys/devices/virtual/graphics/fbcon /sys/class/graphics/fb0 /sys/class/graphics/fb1 /sys/class/graphics/fbcon [ 0.458465] efifb: framebuffer at 0x90010000, mapped to 0xffffc9000ab00000, using 7088k, total 7087k [ 0.463219] Console: switching to colour frame buffer device 210x65 [ 0.467649] fb0: EFI VGA frame buffer device [ 1.695168] Console: switching to colour frame buffer device 160x50 [ 1.696933] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 3.230504] radeon 0000:01:00.0: fb1: radeondrmfb frame buffer device > 2) does the behavior change if selinux is put in permissive mode? (please > remember to change custom.conf back to turn wayland back on) No. > > 3) if you run > > # mv /usr/libexec/gdm-wayland-session /usr/libexec/gdm-wayland-session.real > > # echo << EOF > /usr/libexec/gdm-wayland-session > > #!/bin/sh > [ -e /dev/dri/card1 ] && exit 1 > exec /usr/libexec/gdm-wayland-session.real "$@" > EOF > > # chmod +x /usr/libexec/gdm-wayland-session > > does the problem go away ? No. With this change I can no longer switch consoles, machine quickly gets hot and fans start to run high. I can ssh in to reboot and revert the change. can you run find /sys -name 'boot_vga' also, are you sure your exec line has exec /usr/libexec/gdm-wayland-session.real "$@" versus say exec /usr/libexec/gdm-wayland-session "$@" ? (In reply to Ray Strode [halfline] from comment #28) > can you run > > find /sys -name 'boot_vga' /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/boot_vga /sys/devices/pci0000:00/0000:00:02.0/boot_vga > > > also, are you sure your exec line has > > exec /usr/libexec/gdm-wayland-session.real "$@" > > versus say > > exec /usr/libexec/gdm-wayland-session "$@" > > ? I'm sure because I created it with copy/paste but I started from scratch and did it again and get the same results and this time even get a bunch of CPU temperature and throttling warnings from the kernel. Discussed at the 2015-05-14 blocker review meeting.[1] Voted as punt (delay decision) on blocker, AcceptedFreezeException - this is a bad bug when encountered, but we still don't have sufficient data on its prevalence to make a definite call. We will request more testing on lists and forums. Accepted as a freeze exception, it's certainly bad enough that we should take a sufficiently safe/tested fix if one appears [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-05-14 Affects systems booting directly to Xorg in F20, F21 and F22 Beta as well. Identical symptoms and hardware. (In reply to William Brown from comment #31) ? F21 and F22 with X works for me (although for my personal standard it runs far too hot and fan runs on low continuously and often high). But the failure happens only with gdm+wayland which is F22 only. I haven't tested F20 recently enough to remember clearly, I'm pretty sure the kernel gpu switching wasn't working well with that kernel. The work around I've been using is under "and for the intel chip" here: https://bugzilla.redhat.com/show_bug.cgi?id=765954#c62 The one supplement that needs is "dnf install grub2-efi-modules" since the needed module has been split out since those instructions were written. i915 graphics runs fairly cool, radeon does not even with boot param radeon.dpm=1 and 'cat /sys/class/drm/card0/device/power_dpm_force_performance_level' But to run an external display requires radeon, so it's *sigh*... William sent me this out of band http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html It says in part "On MBPs, the panel is not connected to one of the gpus, but to the gmux chip" So it makes me wonder if this is confusing mutter, or whatever is responsible for the fallback mechanism. I attempted to reproduce this on another dual-graphics laptop (a DELL XPS 15). I did not hit this issue. Right now, it sounds like this may only be an issue on certain Mac hardware, which to me is not a blocker (but I'd take it as a Freeze Exception if a fix is discovered). -1 Blocker/+1 FE Can we disable Wayland use in the gdm configuration for the F22 release and wait till F23 to give this bug the attention it deserves? So far, reports from the testing I requested have mostly been that people don't see the bug. It's still only definitely known to affect Chris' laptop. William's bug also looks bad but doesn't actually look like quite the same bug, and that's the only other report I've seen yet. Other testers with hybrid graphics have said it worked OK for them. (In reply to Adam Williamson from comment #36) The issue clearly affects only AMD+Intel graphics. There are 4 models of Macbook Pros with that combination built for a bit over one year. Bug 1199890 affects i915 graphics on this and other systems. The commonality is Wayland. I think it's curious to push for an optional change that causes such regressions, while simultaneously lamenting adoption state of affairs discussed in threads like this: https://lists.fedoraproject.org/pipermail/desktop/2015-May/012022.html It's not a question of 'pushing for' an optional change, the change was already proposed, approved, and implemented. For the purposes of release validation, the 'change' is the current state of affairs. Assuming 1199890 is the same as 1218688, we already have a fix for that pending. Regardless, the process is based around individual bugs: in *this* location we are discussing whether *this* bug is a blocker, not whether 1218688 is. The appropriate time to consider reverting the GDM-on-Wayland Change was several weeks ago, at the second 'change checkpoint', via FESCo, which owns the Change process. Not via the FE/blocker process, now. (In reply to Adam Williamson from comment #38) > It's not a question of 'pushing for' an optional change, the change was > already proposed, approved, and implemented. For the purposes of release > validation, the 'change' is the current state of affairs. > > Assuming 1199890 is the same as 1218688, we already have a fix for that > pending. Regardless, the process is based around individual bugs: in *this* > location we are discussing whether *this* bug is a blocker, not whether > 1218688 is. The appropriate time to consider reverting the GDM-on-Wayland > Change was several weeks ago, at the second 'change checkpoint', via FESCo, > which owns the Change process. Not via the FE/blocker process, now. Looking at bug 1199890 I don't see a proposed fix. There may be a Rawhide kernel that doesn't exhibit those symptoms but I didn't see anything for F22. That's why I referred to 1218688. Look at that. I'm not sure I'll be able to attend blocker review meeting, thus I'm voting -1 blocker. From the public call, it looks like even Macs do work. I tried it with Intel/NVidia combo (T520) and it worked. So seems like less frequent bug. For the change process - FESCo is responsible for it and FESCo can mark revertion as blocker if they decide it's worth release delays. It's unfortunate that we may be isolating some Mac owners, but I don't see this as being sufficiently urgent to justify a blocker. -1 blocker Discussed at today's blocker review meeting [1]. This bug was rejected as blocker: This bug doesn't appear often enough to warrant blocking release. If this bug starts to show up on more platforms please repropose. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-05-18 I have this problem too. I used fedup to upgrade (fedup --network 22) and it hanged when unmounting (another different bug i guess). When I reboot, it never made it to the login screen. I attempted to use the beta installation cd and the same issue occured, it completed installation successfully and then it doesn't present the login screen after reboot. (I kept the old home partition). Each time I am presented with the "conflict with stolen region" message, but I guess that may be unrelated as I have been seeing that since f20 or so. The machine is a desktop. Single nvidia gpu, intel sandy bridge cpu. If there is anything I can do to help, just let me know. The system has the integrated intel graphics but the monitor is using the nvidia card. Problem observed on my workstation. Dual seats, one set with build-in intel card and other seat on added nvidia. Worked smoothly in F21. After upgrade, Only monitor connected to intel card shows login screen. No gdm on nvidia. With some messages: (gnome-shell:1238): Cogl-WARNING **: Failed to set crtc mode : Permission denied Workaround, as in https://fedoraproject.org/wiki/Common_F22_bugs : uncomment #WaylandEnable=false in /etc/gdm/custom.conf I have an HP laptop with an intel haswell chip and a radeon graphics card. I also suffer from a successful live run/installation process, after which I can't login -> gdm never appears.... In my case it does not matter if I enable/disable wayland. The only thing that helps is to boot with "nomodeset". Removing the xorg-x11-drv-ati package did not help. Interestingly I can boot to lightdm without the "nomodeset" flag, but after authentication in lightdm (fro a gnome session) the system gets stuck. The same happens even when I boot to *runlevel 3*. After the tty-login I never reach a usable shell. Does this also apply to the macbook cases or is my issue different ( should I file a separate bug?)? I tried to find an obvious (I am not an expert in these issues) error message with journalctl etc. but without success.... Best regards Matthias Created attachment 1035851 [details]
journalctl of boot with debugging-kernel
here is a journalctl log of my system with debugging-kernel from booting to runlevel 3. There is some output towards the end of the log mentioning snd_hda_intel things that does not occur when booting with nomodeset. I hope this is useful, or helps to figure out whether my problem belong to this bug report or something different.
Greetings
Looks like my HP notebook 470 G2 (also with dual graphics, intel + ati) is hitting this problem: boots but get the "oh no" something went wrong screen. Note that in windows, this machines define this as switchable graphics, and by my understanding are supposed to use the intel for basic graphics stuff (which keeps power consumption down to like 17-25 W), and offload and ramp up the ATI part for tasks that need more performance (via either auto settings or manual user configuration). My device is a HP EliteBook 840 G1, so it seems that not only MacBooks with dual graphics but also other dual graphics hardware has some problems (even if they are not absolutely identical). To protect others to run into this bug(s) that is(are) unfortunately not detected during install and/or a live session, I would suggest to update the "Common Bugs" page for Fedora 22. And maybe also highlight that the nomodeset boot flag might have to added "permanently" and consequences of that. I suggest this, because that some users might upgrade their installations some weeks after the release in expectation that then such bugs are either fixed (which might be difficult here) or mentioned somewhere outside bugzilla pages. Clearing F22 accepted / nominated freeze exception status as F22 has shipped, per https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers . You may nominate as an Alpha, Beta or Final freeze exception for F23 if desired using the web application - https://qa.fedoraproject.org/blockerbugs/propose_bug (though it is not currently set up for F23) - or by marking the bug as blocking AlphaFreezeException, BetaFreezeException, or FinalFreezeException. Seeing this on a Thinkpad T420 as well. Sitting in its dock, connected to dual monitors. Proposed as a Blocker for 23-alpha by Fedora user chrismurphy using the blocker tracking app because: Alpha: A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility. Kayvan, when you say 'seeing this', can you please provide more details? "I don't see GDM" is not sufficient data to indicate this is actually the bug you're seeing. For all reporters since #c45, please first check if disabling Wayland (via /etc/gdm/custom.conf ) helps; if not, then you have a different bug. If you see something other than a black screen at boot, you also (most likely) have a different bug. Ray, what do we need to start making progress on this? Do we need to get you or a Wayland dev an affected system? Discussed at today's blocker review meeting [1]. This bug was rejected as blocker: We still don't see any data indicating this is a wide spread problem. If more hardware profiles can be found to reproduce this bug, please repropose with that data. People seeing "very similar" problems, please report them individually and attach full logs. Most probably the "oh no" screen is not the same problem as the original issue. Thank you. [1] http://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-06-22/ For a bit more detail - if you see anything other than the symptoms Chris saw, i.e. the system boots to a black screen but you can reach a console with ctrl-alt-f2, it's unlikely your bug is actually the same. Please also check that disabling Wayland makes things work for you. To do this, edit the file /etc/gdm/custom.conf and uncomment this line: #WaylandEnable=false that is, change it to: WaylandEnable=false then reboot. If you don't now see GDM, you definitely don't have the same bug we're dealing with here. For clarity, if booting to GDM doesn't work for you obviously you *do have a bug*, and we will try to fix it - but we need to track separate bugs separately to avoid conclusion. So if you don't meet *ALL* of the following criteria: 1) You have multiple graphics adapters 2) Fedora 22 Workstation live boots fine 3) After install, when booting the installed system, you see a black screen (*NOT* the 'Oh no!' screen) 4) By pressing ctrl-alt-f2 you can see a console 5) If you edit /etc/gdm/custom.conf as described above and reboot, GDM works properly then you don't have this bug, you have a different bug (most likely): please file a new bug separately (or find another report that more closely matches your symptoms). Thanks folks! I have seen these exact symptoms on my non-Mac desktop machine. Intel CPU with onboard graphics + AMD graphics card. 1) You have multiple graphics adapters --> Yes, Intel + AMD 2) Fedora 22 Workstation live boots fine --> Yes 3) After install, when booting the installed system, you see a black screen (*NOT* the 'Oh no!' screen) --> Black screen with some console output at the top 4) By pressing ctrl-alt-f2 you can see a console --> Yes 5) If you edit /etc/gdm/custom.conf as described above and reboot, GDM works properly --> Yes, GDM seems to be fine following this change Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |