Description of problem: F23 live/install hangs after grub menu on late 2015 iMac Version-Release number of selected component (if applicable): Fedora-Live-Workstation-x86_64-23-10.iso, Fedora-Workstation-netinst-x86_64-23.iso How reproducible: always Steps to Reproduce: 1. create and insert boot media (DVD/USB) of F23 Workstation live or netinst images listed above 2. boot to Fedora media from boot manager of latest model of 2015 iMac 3. select any option from grub menu Actual results: screen goes blank, DVD (if used) stops spinning, and nothing else happens until hard power-down Expected results: initiation of Fedora installer Additional info: specs of iMac are as follows: iMac (Retina 5K, 27-inch, Late 2015) 3.2 GHz Intel Core i5 32 GB 1867 MHz DDR3 AMD Radeon R9 M390 2048 MB I tried adding earlyprintk=efi to the linuxefi grub boot option at the request of Kellin in #fedora, but I didn't get any output.
If it gets to grub possibly a kernel problem either way not a fedora-release problem
Might be related to https://bugzilla.kernel.org/show_bug.cgi?id=107161. Will check on Monday when I get back to the office.
Created attachment 1091860 [details] Console Output with Debugging Collaborated with pjones and jforbes - on their suggestion had Andrew try removing rhgb and quiet bits from the boot and add --earlyprintk=efi. Image attachment shows output; "Console: colour dummy device 80x25" points to an issue with detecting the console. Next step being taken is adding ,keep to the earlyprintk argument for more information.
Created attachment 1091862 [details] Console Output with added 'keep' flag Kernel panic after adding the ",keep" option to earlyprintk. See attachment for stacktrace output after the panic.
Does this boot if you pass intremap=no_x2apic_optout to the kernel?
Created attachment 1091910 [details] no_x2apic_optout_KernelPanicStackTrace kernel parameters: ro rd.live.image earlyprintk=efi,keep intremap=no_x2apic_optout
See attachment - using new kernel parameters yields kernel panic in similar place within the boot sequence.
Thanks, the only other thing to try off the top of my head would be intel_iommu=igfx_off but I do not expect that to make a difference here. I am guessing it is either a bios issue with the new iMac, or perhaps there is something new that we are not properly supporting there. I will do some more digging.
Disabling virtualization in the firmware should get you to a booted system in this case, though I don't consider that a real solution.
Created attachment 1091962 [details] intel_iommu=igfx_off KernelPanicStackTrace kernel parameters: ro rd.live.image earlyprintk=efi,keep intremap=no_x2apic_optout intel_iommu=igfx_off adding the intel_iommu parameter also yields a kernel panic (attached). I'm interested in testing your firmware virtualization idea, but I don't how to interact with Mac firmware. If you have any resources for how to do that, I'd certainly take a look.
Unfortunately I can't be of much help here, I haven't actually booted a mac system in many years. Passing intel_iommu=off should do the same thing from kernel command line. Very curious though why this imac is misbehaving in this regard.
Revisited this a week ago and found that intremap=off let the machine boot into Anaconda and install Fedora. Not sure how much of a Good Idea it is, but for the time being, it's a perfectly adequate workaround.
*********** 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 23 kernel bugs. Fedora 23 has now been rebased to 4.7.4-100.fc23. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 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.