Description of problem: A Toshiba P55t-A5202 laptop (not to be confused with the P55 Intel chipset; this series has units labelled P55 & P55t) fails to boot Fedora 19. I have tried both USB and CD-ROM installs. This is an UEFI laptop; but disabling secure boot does not help. How reproducible: Always Steps to Reproduce: 1. Boot a Fedora LiveCD or Live USB stick by holding F12 during startup to choose an alternate boot device. 2. Grub will start; edit grub settings as desired. 3. Select a boot option and let grub do it's thing. Actual results: Failure to boot after the grub countdown completes or a boot option is selected. Grub will tell you that the binary to boot has a valid signature (secure boot enabled) or that secure boot is disabled. But without grub debugging turned on this is all that is seen, even when "quiet and rhgb" is removed. If Grub debugging is turned on a lot of malloc messages are displayed which seem related to reading from USB and/or parsing the boot command list. However at least with the CD-ROM it is implied that Grub closes the CD-ROM device near the end of these messages. Expected results: Linux kernel boots and Fedora' installer or Live environment starts. Additional info: Adding "nomodeset" and/or "i915.enable=0" as suggested at http://askubuntu.com/questions/326192/laptop-boots-to-black-screen-on-13-04-but-works-when-an-external-monitor-is-plu does not help. I personally know how to reach the grub commandline; but do not know enough about early debugging to figure this out.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.