Description of problem: This Fedora 18 system will not boot on new 3.9.2-200 Linux kernel. It kernel panics and must be hard-restarted. Version-Release number of selected component (if applicable): 3.9.2-200.fc18.x86_64 How reproducible: Boot into the 3.9.2-200.fc18.x86_64 kernel. Steps to Reproduce: 1. Boot into Fedora 18 2. In grub menu, allow the 3.9.2-200 kernel to boot 3. Actual results: Kernel panic Expected results: System boots normally Additional info: My hardware is an HP Pavilion g6-2210us laptop with AMD A4-4300M CPU. This is a Secure Boot install, and previous kernels, including 3.8.11-200.fc18.x86_64, boot without trouble.
Basically the same scenario as posted above: Fedora 18 64 bit kernel panics attempting to boot into the 3.9.2-200 kernel. Hardware: HP ENVY dv7-7240us with Intel i5-3210M cpu and Intel HD 4000 gpu. Secure Boot is enabled and "acpi_backlight=vendor" is only added kernel boot cmd. All previous kernels (3.8.11-200 was last) boot normally without issue.
*** Bug 964346 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > *** Bug 964346 has been marked as a duplicate of this bug. *** I would also like to further add comments about this system: Hardware: HP ENVY dv6-7302eo, Intel Core i7-3630QM, nVidia 635M with Optimus. Secure Boot is disabled on this system.
Also have this problem on HP Envy Sleekbook 6t-1100, Intel Core i7-3517U, and Intel Ivybridge Mobile graphics (with a secondary ATI card that I don't believe is enabled and I can't recall the specs for offhand.) I have Secure Boot enabled, but I have replicated the bug without it as well. I also compiled a version of the 3.9 kernel myself while on Debian, and got a kernel panic on boot (secure boot disabled). At the time I wrote it off as inexperience with compiling kernels, but that would lead to me suspecting that this is actually an upstream bug not specific to Fedora/Red Hat.
Same here on HP Envy m6 (Intel Core i3, Intel HD3000, Radeon HD 7670M). UEFI with secure boot enabled. Previous kernel works fine. Screen capture of trace at: https://www.dropbox.com/s/uzol971x8decz9i/IMAG0213.jpg
I guess I have a similar problem (thought I can't see the trace). I can avoid the panic if I add acpi=off. Can anyone verify that? Can someone build & test 3.9.3 as it seems there are several ACPI-related fixes?
(In reply to Michal Nowak from comment #6) > I guess I have a similar problem (thought I can't see the trace). I can > avoid the panic if I add acpi=off. Can anyone verify that? acpi=off makes no difference here. Same trace.
(In reply to Steven Rosenberg from comment #0) (In reply to Paul Miller from comment #1) (In reply to Luke Lockhart from comment #4) Is it possible for You to post an picture of the trace of the kernel panic and a transcript of it? I noticed that john5342's kernel panic is very different from the kernel panic trace I get.
Hardware: Toshiba c655-s5503, Intel® Core™ i3-2350M CPU @ 2.30GHz × 4, memory 4 GiB. Kernel Linux 3.9.2-200.fc18.x86_64, GNOME 3.6.3 System Settings > Power, does not detect notebook battery. No battery power management choices. No battery icon on top desktop bar. Battery power management functions normal under Kernel Linux 3.8.11-200.fc18.x86_64, GNOME 3.6.3. Screen dims when battery in use and system idle. Choices of Hibernate, Shutdown, on low power is available and function. Battery icon on top desktop bar indicates battery power level.
I am not able to see the trace. Even when I remove "rhgb quiet" from kernel GRUB2 line, all I see is just a nifty GRUB2 flame with frame in Fedora colors, can't get to the trace. Any idea?
Hi I am getting this too. UEFI enabled Secure boot enabled / disabled does not change the situation. I'll try to attach a picture of the messages seen on the display. BR Tom
(In reply to BBQdave from comment #9) This is not a kernel panic, and I believe it does not belong in this bug report. (In reply to Michal Nowak from comment #10) https://fedoraproject.org/wiki/Common_kernel_problems?rd=KernelCommonProblems You might want to try: "Slowing down the speed of text output with boot_delay=1000 (the number may need to be tweaked higher/lower to suit) may allow the user to take a digital camera photo of the last thing on screen." And/or: "Booting with vga=791 (or even just vga=1 if the video card won't support 791) will put the framebuffer into high resolution mode to get more lines of text on screen, allowing more context for bug analysis." Then you should have enough time take images of the boot process, and the trace when the kernel panics.
Created attachment 751662 [details] Kernel panic 1 of 2 Kernel panic photo 1 of 2 - console in lowres
Created attachment 751664 [details] Kernel panic 2 of 2 Kernel panic photo 2 of 2 - console in lowres
Hi Added 2 pics for whatever use they may be. Please note that I was unable to get my console in highres mode despite use of vga=791 or vga=1 . Probably I put those lines in the wrong places - it in't easy to know and it's not my area of expertise :) If You need other shots / info, let me know. Thanks! Tom
Just FYI, there's 3.9.3 kernel update in Koji (http://koji.fedoraproject.org/koji/buildinfo?buildID=420689), thought I had no luck with it. (Still working on the trace.)
Created attachment 752005 [details] Kernelpanic as text Seeing it on a Hewlett Packard Compaq CQ45 Notebook PC/1854. Attached text is message shown on screen.
Created attachment 752897 [details] kernel 3.9.2-200 panic w/ "rhgb quiet" parameters (In reply to lu.error from comment #8) After removing the "rhgb quiet" from the kernel boot parameters, the kernel now panics with a similar message as john5342. See the attachment.
(In reply to lu.error from comment #8) > (In reply to Steven Rosenberg from comment #0) > (In reply to Paul Miller from comment #1) > (In reply to Luke Lockhart from comment #4) > > Is it possible for You to post an picture of the trace of the kernel panic > and a transcript of it? I noticed that john5342's kernel panic is very > different from the kernel panic trace I get. Adding transcript of kernel panic from screen capture for kernel-3.9.2-200.fc18.x86_64
Created attachment 753128 [details] kernel-panic_3.9.2-200.fc18.x86_64.txt on HP Envy dv7- 7240us Hand transcribed from not-so-great photo of screen.
(In reply to Steven Rosenberg from comment #0) After upgrading and running kernel-3.9.4-200.fc18.x86_64, the oops and panic still occurs and the same trace is displayed as previously posted.
I'm having this issue in Fedora 19 Beta with kernel-3.9.2-301.x86_64
Created attachment 753989 [details] Screenshot from a kernel panic with HP intel i5 - RadeonHD 7600m series
(In reply to lu.error from comment #21) > (In reply to Steven Rosenberg from comment #0) > > After upgrading and running kernel-3.9.4-200.fc18.x86_64, the oops and panic > still occurs and the same trace is displayed as previously posted. +1 here.
I propose to set this bug as blocker for Fedora 19 Final.
In reading this I see "HP Envy" quite often. I hit this with 3.9.2-200 and 3.9.4-200 (fc18 x86_64) also on an HP ENVY dv7-7323cl 8 gig mem and Intel i5-3230M CPU @ 2.60GHz. Old kernel 3.8.6-203.fc18.x86_64 will still boot for me. Can provide lshw output if useful. I certainly hope bug is a blocker.
(In reply to Dale Mosby from comment #26) > In reading this I see "HP Envy" quite often. > I hit this with 3.9.2-200 and 3.9.4-200 (fc18 x86_64) also on > an HP ENVY dv7-7323cl 8 gig mem and Intel i5-3230M CPU @ 2.60GHz. > Old kernel 3.8.6-203.fc18.x86_64 will still boot for me. > Can provide lshw output if useful. > I certainly hope bug is a blocker. I can tell you that it is also occurring with 3.9.4-200.fc18.x86_64 on a Toshiba Satellite L855D-S5117 with UEFI. This kernel boots without panic on an older Toshiba and HP laptop without UEFI. Seems to be UEFI related. I can provide information or screenshots if necessary.
Actually I've UEFI disabled, but kernel panic still occurs. Maybe it's related to the presence of a Radeon adapter.
This community discussion could be related. http://marc.info/?t=136924016400007&r=1&w=2 If it is the same problem, it takes EFI with grub2 to hit it. The same kernel booted using grub or elilo does not hit the problem.
Proposed as a Blocker for 19-final by Fedora user deepsky using the blocker tracking app because: Fedora 19 Beta with kernel-3.9.2-301.x86_64 is not able to boot (kernel panic) on some systems with UEFI due to a kernel regression (kernel 3.8.11 is ok). We have same beahviour with kernel-3.9.3 and kernel 3.9.4. References: https://bugzilla.redhat.com/show_bug.cgi?id=964335 http://marc.info/?t=136924016400007&r=1&w=2
(In reply to Luke Lockhart from comment #24) > (In reply to lu.error from comment #21) > > (In reply to Steven Rosenberg from comment #0) > > > > After upgrading and running kernel-3.9.4-200.fc18.x86_64, the oops and panic > > still occurs and the same trace is displayed as previously posted. > > +1 here. +1 HP dv7 i7 HD4000 display fc18.
Please test this scratch build when it finishes and let us know if your machine boots again: http://koji.fedoraproject.org/koji/taskinfo?taskID=5445919
+1 on HP Envy dv6 on Fedora 18 Core i7, NVidia CPU UEFI enabled, Secure Boot disabled. Able to boot 3.8.11 kernel, unable to start with 3.9.2 and 3.9.4
OK, so assuming the scratch kernel in comment #32 actually makes people's machines boot again, we're back to bug 947142. The patches we added for that (and that went upstream) seem to be causing this issue, so reverting them fixes this bug but leaves us with the original problem. One of the alternatives for the original problem was to not do space checks at all, but that leaves us with the er... original original problem. Some machines will be susceptible to being bricked. So we have 3 scenarios at the moment: 1) Current state of affairs. We can install and protect against machine bricking, but some people can't boot. 2) Revert the patches causing people to not be able to boot (the scratch kernel), but then some subset of machines won't be able to install Fedora. That is bug 947142. 3) Revert the patches and boot with efi_no_storage_paranoia=1 by default. That fixes the boot issue, and it avoids the space issue in bug 947142, but it means some machines (Samsung and reportedly Lenovo) can be bricked. None of these are really great scenarios, but that is where we stand.
(In reply to Josh Boyer from comment #32) > Please test this scratch build when it finishes and let us know if your > machine boots again: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=5445919 I can confirm that the following kernels boot into userspace on the Fedora 18 distribution: kernel-3.9.4-300.4.fc19.x86_64.rpm kernel-debug-3.9.4-300.4.fc19.x86_64.rpm Additional installed packages: kernel-modules-extra-3.9.4-300.4.fc19.x86_64.rpm kernel-headers-3.9.4-300.4.fc19.x86_64.rpm Although I would like to make a small note. I poked around and looked a bit in dmesg for new errors in both kernels and found: [erro@local ~]$ dmesg | grep "HP ENVY" [ 0.000000] DMI: Hewlett-Packard HP ENVY dv6 Notebook PC/181B, BIOS F.24 01/22/2013 [erro@local ~]$ dmesg | grep Warning [ 14.846450] ACPI Warning: 0x0000000000005040-0x000000000000505f SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20130117/utaddress-251) [ 14.847949] ACPI Warning: 0x0000000000000428-0x000000000000042f SystemIO conflicts with Region \PMIO 1 (20130117/utaddress-251) [ 14.848002] ACPI Warning: 0x0000000000000530-0x000000000000053f SystemIO conflicts with Region \GPIO 1 (20130117/utaddress-251) [ 14.848026] ACPI Warning: 0x0000000000000530-0x000000000000053f SystemIO conflicts with Region \_SB_.GPIO 2 (20130117/utaddress-251) [ 14.848049] ACPI Warning: 0x0000000000000530-0x000000000000053f SystemIO conflicts with Region \_SB_.PCI0.PEG0.PEGP.GPIO 3 (20130117/utaddress-251) [ 14.848074] ACPI Warning: 0x0000000000000500-0x000000000000052f SystemIO conflicts with Region \GPIO 1 (20130117/utaddress-251) [ 14.848097] ACPI Warning: 0x0000000000000500-0x000000000000052f SystemIO conflicts with Region \_SB_.GPIO 2 (20130117/utaddress-251) [ 14.848119] ACPI Warning: 0x0000000000000500-0x000000000000052f SystemIO conflicts with Region \_SB_.PCI0.PEG0.PEGP.GPIO 3 (20130117/utaddress-251) [erro@local ~]$ dmesg | grep Error [ 0.579031] ACPI Error: No handler for Region [RAM_] (ffff8804a7e2d900) [EmbeddedControl] (20130117/evregion-161) [ 0.579035] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20130117/exfldio-305) [ 0.579059] ACPI Error: Method parse/execution failed [\_SB_.ACCL._STA] (Node ffff8804a7e63140), AE_NOT_EXIST (20130117/psparse-537) [ 0.579126] ACPI Error: Method execution failed [\_SB_.ACCL._STA] (Node ffff8804a7e63140), AE_NOT_EXIST (20130117/uteval-103) [erro@local ~]$ dmesg | grep Exception [ 1.511317] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20130117/hwxface-568) [ 1.511337] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20130117/hwxface-568) [erro@local ~]$ dmesg | grep Firmware [ 1.654811] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [ 3.373625] [Firmware Bug]: No valid trip found [ 7.688226] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS While the acpi warnings and errors are not new and have existed since I had installed Fedora 18 on this system, the acpi exceptions and the first firmware bug are new to the afforementioned kernels (but I assume that these are also due to HP broken bios implementation, no?).
(In reply to Josh Boyer from comment #34) > OK, so assuming the scratch kernel in comment #32 actually makes people's > machines boot again, we're back to bug 947142. The patches we added for > that (and that went upstream) seem to be causing this issue, so reverting > them fixes this bug but leaves us with the original problem. > > One of the alternatives for the original problem was to not do space checks > at all, but that leaves us with the er... original original problem. Some > machines will be susceptible to being bricked. So we have 3 scenarios at > the moment: > > 1) Current state of affairs. We can install and protect against machine > bricking, but some people can't boot. > > 2) Revert the patches causing people to not be able to boot (the scratch > kernel), but then some subset of machines won't be able to install Fedora. > That is bug 947142. > > 3) Revert the patches and boot with efi_no_storage_paranoia=1 by default. > That fixes the boot issue, and it avoids the space issue in bug 947142, but > it means some machines (Samsung and reportedly Lenovo) can be bricked. > > None of these are really great scenarios, but that is where we stand. I read the mail discussion at http://marc.info/?t=136924016400007&r=1&w=2. This may be a silly suggestion, but why not _temporarily_ split the kernel build to a build with and without the patch. On kernel updates, detect if the machine is a Samsung/Lenovo, and if it is, update with the patched kernel. Otherwise, do (3), until the problem is hopefully resolved in kernel 3.11. Of course, this should be done by the individual distributions and not in the upstream kernel. Can it be done or is it painful to implement this solution?
(In reply to Josh Boyer from comment #34) > 1) Current state of affairs. We can install and protect against machine > bricking, but some people can't boot. Not booting is not an option. See Ingo's comments in the community discussion. > 2) Revert the patches causing people to not be able to boot (the scratch > kernel), but then some subset of machines won't be able to install Fedora. > That is bug 947142. Why is Fedora dependent on writing EFI variables to install? It certainly did not used to be a dependency. Why not just install with a warning message? > 3) Revert the patches and boot with efi_no_storage_paranoia=1 by default. > That fixes the boot issue, and it avoids the space issue in bug 947142, but > it means some machines (Samsung and reportedly Lenovo) can be bricked. Bricking systems is not an option. > None of these are really great scenarios, but that is where we stand. Since #1 and #3 are not options, #2 is the only choice.
@josh. My laptop hasn't been able to boot with the last few kernel versions but the scratch build fixes the problem for me. If you need more details, let me know. Thanks!
> Why is Fedora dependent on writing EFI variables to install? It certainly did not used to be a dependency It's always been a dependency. You need to write an EFI variable to tell the firmware where your bootloader is, otherwise the system won't boot. > Since #1 and #3 are not options, #2 is the only choice. #2 is also not an option. This is unfortunate since it rules out all the options we currently have, so we need to find another option.
Actually I'm unable to boot with 3.9.X kernel, also in Legacy Mode (Bios Emulation). If bug 947142 can be workarouded with legacy mode, I think that the better way is to revert the patches.
(In reply to lu.error from comment #36) > I read the mail discussion at http://marc.info/?t=136924016400007&r=1&w=2. > This may be a silly suggestion, but why not _temporarily_ split the kernel > build to a build with and without the patch. On kernel updates, detect if > the machine is a Samsung/Lenovo, and if it is, update with the patched > kernel. Otherwise, do (3), until the problem is hopefully resolved in kernel > 3.11. Of course, this should be done by the individual distributions and not > in the upstream kernel. Can it be done or is it painful to implement this > solution? That's not really feasible within Fedora infrastructure.
(In reply to Matthew Garrett from comment #39) > > Why is Fedora dependent on writing EFI variables to install? It certainly did not used to be a dependency > > It's always been a dependency. You need to write an EFI variable to tell the > firmware where your bootloader is, otherwise the system won't boot. > > > Since #1 and #3 are not options, #2 is the only choice. > > #2 is also not an option. This is unfortunate since it rules out all the > options we currently have, so we need to find another option. Seems to be that the only option is to revert the patch. It was an invalid patch that broke the kernel for orders of magnitude more machines that it helped. That sounds to me like a bad patch that needs to be pulled ASAP.
(In reply to Ken Tobias from comment #42) > (In reply to Matthew Garrett from comment #39) > > > Why is Fedora dependent on writing EFI variables to install? It certainly did not used to be a dependency > > > > It's always been a dependency. You need to write an EFI variable to tell the > > firmware where your bootloader is, otherwise the system won't boot. > > > > > Since #1 and #3 are not options, #2 is the only choice. > > > > #2 is also not an option. This is unfortunate since it rules out all the > > options we currently have, so we need to find another option. > > Seems to be that the only option is to revert the patch. It was an invalid > patch that broke the kernel for orders of magnitude more machines that it > helped. That sounds to me like a bad patch that needs to be pulled ASAP. That was a bit abrupt. Apologies.
(In reply to Matthew Garrett from comment #39) > > Since #1 and #3 are not options, #2 is the only choice. > > #2 is also not an option. This is unfortunate since it rules out all the > options we currently have, so we need to find another option. Looks like you came up with another option. Boots on SGI UV1 & UV2 systems, with grub2, grub and elilo. Thanks! http://marc.info/?t=137011763400001&r=1&w=2
(In reply to Russ Anderson from comment #44) > (In reply to Matthew Garrett from comment #39) > > > Since #1 and #3 are not options, #2 is the only choice. > > > > #2 is also not an option. This is unfortunate since it rules out all the > > options we currently have, so we need to find another option. > > Looks like you came up with another option. Boots on SGI UV1 & UV2 systems, > with grub2, grub and elilo. Thanks! > > http://marc.info/?t=137011763400001&r=1&w=2 Here is a different scratch-build with that patch applied instead of the reverts. Please test and let us know if this resolves booting for you: http://koji.fedoraproject.org/koji/taskinfo?taskID=5458508
Discussed at 2013-06-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-03/f19final-blocker-review-2.2013-06-03-16.00.log.txt . Accepted as a blocker per https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria#Expected_installed_system_boot_behavior : "A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account." etc (this could be taken under various criteria, really). As per the kernel team, the situation here is basically: we can't release with the number of systems busted with the current code, so if this proposed fix isn't good, we need another one.
(In reply to Josh Boyer from comment #45) > Here is a different scratch-build with that patch applied instead of the > reverts. Please test and let us know if this resolves booting for you: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=5458508 I can confirm that the following kernels boot into the Fedora 18 distribution on the system I work on: kernel-3.9.4-300.8.fc19.x86_64.rpm kernel-debug-3.9.8-300.4.fc19.x86_64.rpm Additional installed packages: kernel-modules-extra-3.9.4-300.8.fc19.x86_64.rpm kernel-headers-3.9.4-300.8.fc19.x86_64.rpm
Thank you for testing. I tested this locally on 3 different EFI machines and while they didn't exhibit any of the problem symptoms the kernel does boot on all of them. I've added this patch and it will be included in the next set of builds.
(In reply to Josh Boyer from comment #45) > > Here is a different scratch-build with that patch applied instead of the > reverts. Please test and let us know if this resolves booting for you: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=5458508 This boots fine for me in EFI mode. It doesn't boot with Secure Boot, but there are no problems at all with EFI. This is the first 3.9.x kernel that hasn't panicked under EFI.
I can confirm that kernel-3.9.4-300 is ok for me, boot without panic. Great work!
kernel-3.9.4-301.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.9.4-301.fc19
Will be updated also package for F18?
(In reply to Steven Rosenberg from comment #49) > (In reply to Josh Boyer from comment #45) > > > > Here is a different scratch-build with that patch applied instead of the > > reverts. Please test and let us know if this resolves booting for you: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=5458508 > > This boots fine for me in EFI mode. It doesn't boot with Secure Boot, but > there are no problems at all with EFI. Secure Boot not working is expected with scratch build kernels. They aren't signed with the Fedora certs. The official build should work fine. (In reply to Paolo Leoni from comment #52) > Will be updated also package for F18? Yes. Bodhi will leave a comment similar to comment #51 when an F18 update is submitted.
Package kernel-3.9.4-301.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.9.4-301.fc19' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-10050/kernel-3.9.4-301.fc19 then log in and leave karma (feedback).
kernel-3.9.4-101.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/FEDORA-2013-9123/kernel-3.9.4-101.fc17
3.9.4-200 (fc18 x86_64) has been a pita for me as well. I can only confirm a hard lockup (every-time) w/ 3.9.4-200. All previous kernels boot cleanly. Specs: Lenovo T520 Intel core i7 vPro
So sorry, I meant to say 3.9.4-400 (fc18 x86_64) has been problematic. 3.9.4-200 (fc18 x86_64) boots fine for me, and (for the time being) is what I'm using day to day.
There is no 3.9.4-400 kernel anywhere that I can see, for f17, f18 or f19. The way the numbering works, 400 would be a Rawhide kernel, but Rawhide is on 3.10. Could you double check what works and what doesn't for you? Thanks.
(In reply to Adam Williamson from comment #58) > There is no 3.9.4-400 kernel anywhere that I can see, for f17, f18 or f19. > The way the numbering works, 400 would be a Rawhide kernel, but Rawhide is > on 3.10. Could you double check what works and what doesn't for you? Thanks. ( @Adam, too true. Thanks for catching that, and sorry for the confusion! I typed it twice in a row, so let's chalk it up to a Peter Griffin moment. I was referring to these two kernels: kernel-3.9.4-200.fc18.x86_64 kernel-3.9.2-200.fc18.x86_64 For me, the problematic kernel is: 3.9.4-200.fc18.x86_64. Very sorry for the dyslexic moment.
I'm on F18 with an HP Pavilion dv7 (Intel HD graphics). 3.9.2 and 3.9.4 crash at boot for me. 3.8.11 works fine. Thanks all for all the work on this. Looking forward to the new kernel with the fix! Paul
Paul, please if you can test this update: http://koji.fedoraproject.org/koji/buildinfo?buildID=424616 and report here if it fix your problem. A feedback would be useful.
I downloaded and installed that kernel (only the kernel, do I need anything else?) Does not boot, but hangs earlier. I get three lines from grub: Booting 'Fedora (3.9.4-302.fc19.i686)' Loading Fedora (3.9.4-302.fc19.i686) Loading initial ramdisk ... Then the screen hangs there. Maybe a dumb question, can I boot fc19 on Fedora 18? Paul
Never mind, and sorry for the churn. I grabbed the 32 bit kernel in my excitement. 64 bit kernel boots just fine! [psprague@ringworld:~]$ uname -a Linux ringworld 3.9.4-302.fc19.x86_64 #1 SMP Tue Jun 4 17:53:56 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
I have same problem, when I boot with kernel-3.9.4-200.fc18.x86_64 but, 3.6.10-4.fc18.x86_64 is fine. hope fix it soon... Kev.
Confirming kernel-3.9.4-302.fc19.x86_64 also boots on my HP ENVY dv7 7240us with UEFI and Secure Boot enabled in F18. Paul
Confirming kernel-3.9.4-301.fc19.x86_64 and kernel-modules-extra-3.9.4-301.fc19.x86_64 boots and runs on my HP ENVY dv7 (i7, HD4000) with UEFI and Secure Boot in F18.
kernel-3.9.4-301.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Is this also available in the f18 repository? Tried yum update in f18 and the kernel version is not in the list, yum still says for f18 kernel-3.9.4-200.f18 is the latest and is still broken (kernel panic) on my toshiba p870 notebook.
It looks pretty clear that this issue is affecting F18 too, so re-opening for F18. Kernel team, it seems indicated at this point to send the fix to F18 too.
This does affect F18, but you can run the F19 kernel in F18 if you want the fix now. That's what I'm doing.
Much users don't know how to manually update kernel from F19 branch. For users affected by this issue, kernel 3.9.2 on F18 is still broken, so it's important to update also in F18.
(In reply to Adam Williamson from comment #69) > It looks pretty clear that this issue is affecting F18 too, so re-opening > for F18. Kernel team, it seems indicated at this point to send the fix to > F18 too. We already included it last week. It'll be in the next f18 update submitted. The 3.9.5-200 build already has the fix.
Package kernel-3.9.5-100.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.9.5-100.fc17' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-9123/kernel-3.9.5-100.fc17 then log in and leave karma (feedback).
kernel-3.9.5-201.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.9.5-201.fc18
3.9.4-300.4.fc19.x86_64 works for me but the 3.9.5-201 in Fedora 18 goes into a shutdown sequence automatically and I can't boot into it. Any ideas?
(In reply to Rahul Sundaram from comment #75) > 3.9.4-300.4.fc19.x86_64 works for me but the 3.9.5-201 in Fedora 18 goes > into a shutdown sequence automatically and I can't boot into it. Any ideas? If it is going into a shutdown sequence, it isn't this bug. This bug is a panic and you don't even boot. Please file a new bug.
Thanks. filed #973475
The F19 update went stable 5 days ago, so dropping the f19 blocker aspects of this, it's now just for f17/f18. Can be closed when those update go stable I guess.
By the way, currently F19 installer uses 3.9.2-301.fc19.x86_64 for the installer kernel (not what gets installed, but the installer kernel itself). I tried netinstall and the kde live, I would imagine gnome live would be the same. I don't know if this gets automatically fixed at some point but for right now if you have a machine affected by this issue these installers will kernel panic.
Er, what do you mean by 'currently'? Final TC2 included the fixed kernel-3.9.4-301.fc19 . Beta, of course, was built long ago and is not going to change.
Ok, sorry, yes I was referring to the beta download on the main page.
Ah, OK. Yeah, there are only three 'official public (pre-)release' milestones per cycle, Alpha, Beta, Final. If you want to get in a faster loop you can join the validation testing of the TC and RC builds, which are the 'test builds' for those three public (pre-)releases.
TC2 installer up and running just fine of course. Thanks for your patience and for pointing me in the right direction!
kernel-3.9.5-201.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.9.8-100.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.