Wrong log file - that has nomodeset. Can you also please attach the dmesg, preferrably with drm.debug=6?

(In reply to comment #0)
> Booting from UEFI without secure boot.

Please also try CSM, or legacy, boot.

> With acpi_backlight=vendor boot parameter, black screen problem goes away,
> encryption screen works, 'f bubble' on boot (or boot messages after pressing
> 'esc') visible, but hangs on boot.

Odd. Can you ping or ssh into the machine?

Please also include what Chris asked.

Created attachment 85730 [details]
/var/log/messages

Turns out that, without nomodeset, the machine does not boot up far enough to write the xorg.log (or so I surmise). Also can't ssh into it or ping it in this state. I will upload /var/log/messages; maybe something there. I guess dmesg doesn't persist past reboot so not sure how to get that info uploaded short of hand writing a bunch of stuff. Physical photo of screen with boot messages maybe? Dual boot system with win8; will have to mess with bios to try legacy boot and I may not be skilled enough with grub2 etc to do it, but iirc the behavior was the same. Will give it a try, though.

Ok, there is nothing in there to go on. What I would try first is booting into a VT rather than the desktop, so try appending 3 to your grub boot command (or maybe "single" -- it's been a while, but at a last resort you could use init=/bin/bash). If that at least gets us to a non-VGA console (i.e. native resolution set on the panel) it means the kernel driver is more or less functional.

OK, booted with nomodeset removed, acpi_backlight=vendor, and single.

I think it's failing in basically the same way as it was in runlevel 5 (?); I'm getting a bunch of errors of the form (transcribed onto another machine by hand)

[          ] status: ( DRDY )
[          ] failed command: WRITE FFDMA QUEUED
[152.451388] ata1.00: cmd 61/80:f0:70:a8:ac/00:00:19:00:00/40 tag 30 ncq 4096 out
...                   res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
...          ata1.00: status ( DRDY )
...          INFO: rcu_sched detected stalls on CPUs/tasks: ( 0) (detected by 1, t=60002 jiffies, g=404, c=403, q=1102)

first 5 lines of that repeated with some varations, numerous times
last line repeating every few minutes, no further activity

That smells a lot like the kernel has a hard time with the sata drives. As long as you can still see something on the screen we're not to blame.

To test this can you please put a fc19 image onto an usb stick (to avoid any issues with sata cdrom, just in case)? If that works please file a new bug at bugzilla.kernel.org against the sata drivers (grab a picture of the message so you can attach it there).

No CD on this machine (USB Blueray available but not attached)

All previous info is from win8/f19 dual boot installation to SSD (sda) from full F19 install media, dd'ed onto a USB stick.

I'm in way over my head on this, but it seems like nomodeset kernel parameter wouldn't fix a problem with SATA drives... but really, I don't know.

Results with Fedora 19 Live Desktop, downloaded today, dd'ed onto a usb stick (I am mostly running xfce, but gnome d/l'ed first):

straight boot, nothing added: black screen

add kernel parameter nomodeset: boots, seems to run OK.

add kernel parameter acpi_backlight=vendor, do not add nomodeset, press esc during boot. Starts booting, looks like the graphics driver is working (full res on the 'f bubble', rather than big and stretchy), but never finishes. errors of significance, as transcribed by hand, include:

starts stalling out with messages about systemd-udevd:worker terminated
and A start job is running for Trigger Flushing of Journal to Persistent Storage INFO: rcu_sched detected stalls on CPUs/tasks: { 0}
and ...Tell Plymoth to write out runtime data

[FAILED] Failed to start GNOME Display Manager
See 'systemctl status gdm.service' for details
         Stopping GNOME display manager.
[  OK  ] Stopped GNOME display manager.
         Starting GNOME display Manager
[FAILED] Failed to start GNOME Display Manager
See 'systemctl status gdm.service' for details.

above sequence repeated at least 4 times

[...] (2 of 2) A start job is running for RealtimeKit Scheduling Policy Service [   67.079034] INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 2, t=60002 jiffies, g=436, c...
[67.xxx] SQUASHFS error: squashfs_read_data failed to read block 0xblah
[      ] SQUASHFS error: unable to read data cache entry...
[      ] SQUASHFS error: unable to read page...
these last two repeated several times
[FAILED] Failed to start RealtimeKit Scheduling Policy Service...


If there is a way to make this info persist past a reboot, I'd be happy to try to post it.

No but fs corruption would explain both the errors and the failure to start X with a particular driver.

This is probably the 3rd or 4th attempt at installing on this particular machine, and I think I was getting similar behavior with previous installs (but not sure I knew about the backlight thing before this install). Any conjecture whether it might help to reformat/reinstall, or is this likely to be a hardware problem? (or as has been suggested an SATA driver problem)? Getting out of the realm of xorg, I know...

OK, tried same procedure with another usb stick, this time with f19 xfce spin. Substantially same results; boots OK with nomodeset, otherwise hangs with similar errors. 

In none of these cases do I find any of the sata related errors in the log files if I boot with nomodeset. Am I correct in my understanding that nomodeset forces the kernel to use a generic VGA driver instead of any kind of graphics acceleration? Seems like that would be an xorg issue, but could be kernel I guess. Not sure why it would have any effect on SATA hardware?

Seems like file system corruption would not affect three different installs on 3 different devices (one sdd and two usb sticks) from 3 different downloads, but I may be missing the point. Now, bad graphics hardware, that seems like it might do the trick, but I would think it would show some kind of problem under win8, which I haven't observed.

Wish I had a second similar machine to test it on; might be able to exonerate the hardware at least, but alas I have but the one.

Please advise if there is any other info I might be able to provide, or if y'all still think I need to file the bug against the kernel SATA driver.

Sorry for the delay, but I haven't seen anything here that appears to be actionable for the ddx (i.e. I haven't seen anything that looks like a driver bug).

I have a similar peoblem in Dell xps 13 (i7 fhd).

With nomodeset the system boots, but gnome cannot init.

without modeset, the screen is very dark, and the resolution seems incompatible, so not usable status.

It works perfectly in kernel 3.9, but not in 3.11

(In reply to comment #13)
> I have a similar peoblem in Dell xps 13 (i7 fhd).

Similar, but not the same. Please do file a separate bug with a dmesg from boot with the kernel command line parameter drm.debug=6. I suspect this is a known backlight issue, but until we have that debug log I cannot be sure.

Same hardware, fresh install, Fedora 20, default gnome instead of xfce. 'Insecure' boot. Just works now. Shrug.

Any clues? Is there still a setup that fails?

Can't resume from suspend or hibernate if booted in secure mode. I imagine that is more of a acpi/secure boot interaction issue, or related to encrypted partition. Otherwise seems to 'just work'.

Yeah I guess until there's further evidence we need to shrug this off. Thanks for your report.