Bug 1218787 - gdm-wayland-session fails to present login screen after successful installation [NEEDINFO]
gdm-wayland-session fails to present login screen after successful installation
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
Depends On:
Blocks: WaylandRelated
  Show dependency treegraph
 
Reported: 2015-05-05 17:17 EDT by Chris Murphy
Modified: 2016-07-19 09:59 EDT (History)
27 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 09:59:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
awilliam: needinfo? (rstrode)


Attachments (Terms of Use)
journal live media boot (371.55 KB, text/plain)
2015-05-05 17:18 EDT, Chris Murphy
no flags Details
journal first boot (286.98 KB, text/plain)
2015-05-05 17:18 EDT, Chris Murphy
no flags Details
journal wayland gdmdebug (337.19 KB, text/plain)
2015-05-06 23:22 EDT, Chris Murphy
no flags Details
lspci -vvnn (67.15 KB, text/plain)
2015-05-06 23:28 EDT, Chris Murphy
no flags Details
photo of screen (151.44 KB, image/jpeg)
2015-05-06 23:39 EDT, Chris Murphy
no flags Details
syslog (187.76 KB, text/x-vhdl)
2015-05-11 16:25 EDT, Didier G
no flags Details
journalctl of boot with debugging-kernel (151.00 KB, text/plain)
2015-06-07 06:00 EDT, matthias.rambausek
no flags Details

  None (edit)
Description Chris Murphy 2015-05-05 17:17:28 EDT
Description of problem:
USB stick with Fedora-Live-Workstation-x86_64-22-TC1.iso booting EFI Mac (Macbook Pro 8,2) boots and installs Fedora successfully. First boot results in black screen, no plymouth or gdm/login window.


Version-Release number of selected component (if applicable):
gdm-3.16.1.1-1.fc22.x86_64
libwayland-server-1.7.0-1.fc22.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Boot USB media works, installation successful.
2. Reboot


Actual results:

Black screen, can switch to tty2.


Expected results:

I should have a graphical login screen per release criteria:
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. 


Additional info:

The live USB boot does not use wayland, while first boot does, and ultimately gdm-wayland-session fails to produce a login windows, but I can't tell why not from the logs.


This line does not appear when booting the installed system:
[   44.271323] f22m.localdomain /usr/libexec/gdm-x-session[1758]: X.Org X Server 1.17.1
Comment 1 Chris Murphy 2015-05-05 17:18:33 EDT
Created attachment 1022320 [details]
journal live media boot
Comment 2 Chris Murphy 2015-05-05 17:18:51 EDT
Created attachment 1022322 [details]
journal first boot
Comment 3 Fedora Blocker Bugs Application 2015-05-05 17:22:49 EDT
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.
Comment 4 Adam Williamson 2015-05-05 18:42:37 EDT
Did you create a user during installation, or not?
Comment 5 Chris Murphy 2015-05-05 20:24:10 EDT
Yes.
Comment 6 Adam Williamson 2015-05-06 15:10:53 EDT
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.
Comment 7 Chris Murphy 2015-05-06 23:22:48 EDT
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.
Comment 8 Chris Murphy 2015-05-06 23:28:59 EDT
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
Comment 9 Chris Murphy 2015-05-06 23:39:25 EDT
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.
Comment 10 Adam Williamson 2015-05-11 12:38:24 EDT
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?
Comment 11 Dan Mossor [danofsatx] 2015-05-11 15:29:04 EDT
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/
Comment 12 Didier G 2015-05-11 16:24:37 EDT
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
Comment 13 Didier G 2015-05-11 16:25:54 EDT
Created attachment 1024341 [details]
syslog
Comment 14 Adam Williamson 2015-05-11 16:32:45 EDT
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!
Comment 15 Chris Murphy 2015-05-11 16:44:30 EDT
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?
Comment 16 Chris Murphy 2015-05-11 16:51:02 EDT
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.
Comment 17 Adam Williamson 2015-05-11 17:06:14 EDT
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.
Comment 18 Adam Williamson 2015-05-11 17:12:24 EDT
Chris: have you checked that switching to X via custom.conf actually works?
Comment 19 Chris Murphy 2015-05-11 17:14:44 EDT
(In reply to Adam Williamson from comment #18)
> Chris: have you checked that switching to X via custom.conf actually works?

Yes.
Comment 20 Adam Williamson 2015-05-11 17:28:56 EDT
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...
Comment 21 Chris Murphy 2015-05-11 17:51:13 EDT
(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.
Comment 22 Didier G 2015-05-12 05:43:04 EDT
(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...
Comment 23 Bojan Smojver 2015-05-12 19:47:10 EDT
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...
Comment 24 Stephen Gallagher 2015-05-13 11:24:23 EDT
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.
Comment 25 Chris Murphy 2015-05-13 12:18:46 EDT
(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.
Comment 26 Ray Strode [halfline] 2015-05-14 08:32:58 EDT
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 ?
Comment 27 Chris Murphy 2015-05-14 11:35:43 EDT
> 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.
Comment 28 Ray Strode [halfline] 2015-05-14 14:21:50 EDT
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 "$@"

?
Comment 29 Chris Murphy 2015-05-14 14:40:59 EDT
(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.
Comment 30 Kamil Páral 2015-05-14 14:44:23 EDT
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
Comment 31 William Brown 2015-05-14 19:40:55 EDT
Affects systems booting directly to Xorg in F20, F21 and F22 Beta as well. Identical symptoms and hardware.
Comment 32 Chris Murphy 2015-05-14 20:09:18 EDT
(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*...
Comment 33 Chris Murphy 2015-05-14 21:12:39 EDT
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.
Comment 34 Stephen Gallagher 2015-05-15 07:49:36 EDT
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
Comment 35 M. Edward (Ed) Borasky 2015-05-15 19:42:01 EDT
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?
Comment 36 Adam Williamson 2015-05-15 20:10:04 EDT
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.
Comment 37 Chris Murphy 2015-05-15 22:05:22 EDT
(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
Comment 38 Adam Williamson 2015-05-16 01:40:02 EDT
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.
Comment 39 M. Edward (Ed) Borasky 2015-05-16 03:20:46 EDT
(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.
Comment 40 Adam Williamson 2015-05-16 03:28:30 EDT
That's why I referred to 1218688. Look at that.
Comment 41 Jaroslav Reznik 2015-05-18 08:17:37 EDT
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.
Comment 42 Stephen Gallagher 2015-05-18 11:31:56 EDT
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
Comment 43 Petr Schindler 2015-05-18 12:48:15 EDT
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
Comment 44 forbisc 2015-05-19 13:24:23 EDT
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.
Comment 45 Jan 2015-05-27 07:23:38 EDT
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
Comment 46 matthias.rambausek 2015-06-05 10:38:54 EDT
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
Comment 47 matthias.rambausek 2015-06-07 06:00:53 EDT
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
Comment 48 David Timms 2015-06-09 08:56:16 EDT
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).
Comment 49 matthias.rambausek 2015-06-10 03:04:23 EDT
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.
Comment 50 Adam Williamson 2015-06-10 18:43:06 EDT
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.
Comment 51 Kayvan Sylvan 2015-06-16 18:41:35 EDT
Seeing this on a Thinkpad T420 as well. Sitting in its dock, connected to dual monitors.
Comment 52 Fedora Blocker Bugs Application 2015-06-16 19:55:19 EDT
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.
Comment 53 Adam Williamson 2015-06-22 12:14:50 EDT
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?
Comment 54 Kamil Páral 2015-06-22 12:30:25 EDT
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/
Comment 55 Adam Williamson 2015-06-22 20:37:24 EDT
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!
Comment 56 Sam Bristow 2015-08-05 22:06:05 EDT
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
Comment 57 Fedora End Of Life 2016-07-19 09:59:47 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.