Description of problem: I have dell vostro 3500. I did a system update and when I choose the one of the bottom kernels the system doesn't start. I can't even change virtual terminal pressing alt+f4. kernel-3.12.5-200.fc19.i686 or kernel-3.12.6-200.fc19.i686. I see onlu the logo "F". on kernel kernel-3.11.10-200.fc19.i686 system starts without any problems. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Can you remove the 'rhgb' and 'quiet' kernel parameters from the grub config stanza for that kernel and see if you get some kind of backtrace or further data for debug?
Thank you for advice. I've removed the "rhgb" and "quite" on kernel parameters then I start the system using kernel kernel-3.12.6-200.fc19.i686. I saw something like this: 20 times information "ALSA sound/pci/hda/hda_eld.c:338 HDMI: invalid ELD buf size -1" and then systemd[1]: Failed to register to bus: Did not recive a reply: Posible couses include : the remote aplication not .. policy blocked the reply, the reply timeout expired or network connection was broken Failed to start Avahi mDMS/DMS-SD Stack Failed to start RealtimeKit Scheduling Pilicy Service Failed to start Login Service Could you tell me how can I save all logs while kernel is booting? I have to write all information by myself.
Today was nex update to kernel version kernel-3.12.7-200.fc19.i686 and now i worse because I have kernel panic. I attach two photos with my screen because I don't know how to save log when kernel is booting.
Created attachment 850028 [details] photo1
Created attachment 850029 [details] photo2
Today I've install Fedora 20 then upgrade to kernel version 3.12.7-300 an I have the same problem. I attach next photo. Please repair this bug.
Created attachment 850598 [details] photo-fedora20
Can you blacklist snd_hda_code_hdmi and see if that allows the machine to boot? Also, can you add pause_on_oops=60 so that the kernel oops output doesn't scroll off the screen in the case of a kernel panic? Lastly, can you provide the output of dmesg from a fresh boot with 3.11.10?
Created attachment 851189 [details] dmesg-log-kernel-3.11.10-200
Could you tell me how to blacklist snd_hda_code_hdmi? I'v done like this - add rdblacklist=snd_hda_code_hdmi to /boot/grub2/grub.cfg for example "linux /vmlinuz-3.12.7-200.fc19.i686 root=UUID=597fefa8-3013-4656-b3f0-bed049dda46b ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole.font=latarcyrheb-sun16 vconsole.keymap=pl2 rdblacklist=snd_hda_code_hdmi LANG=en_GB.utf8" but dont't work and kernel is not booting. It is good solution? I'v attached dmesg log.
Sorry, I made a small typo in the driver name. What you have is close, but to blacklist it, you should specify: rd.driver.blacklist=snd_hda_codec_hdmi
If that still doesn't work, try adding: nomodeset and see if that allows things to boot, albeit with slow, unaccelerated graphics.
Only with rd.driver.blacklist=snd_hda_codec_hdmi kernel is not booting. With rd.driver.blacklist=snd_hda_codec_hdmi and nomodeset is booting and gnome starts correctly but as you'v said graphics is unaccelerated and resolition is too small so I can't work. Will you fix this bug on next kernel version?
No, we can't fix it in the next version since we don't really know what the problem is. The nomodeset gives us an indication that it's something to do with the nouveau driver, so we'll reassign there. The driver authors should know what to do next and be able to ask for information on how to debug further.
Can you try "nouveau.modeset=0" rather than "nomodeset"? The i915 driver is also present here, and nouveau appears to not have any connected outputs etc, so I'd expect i915 would be the primary adaptor.
Kernel is still not booting with "nouveau.modeset=0".
Thanks for that, reassigning to Intel driver maintainer.
I have some updates for this bug and I think it is important. Today I've tried to use kernel-3.12.6.200 with "nouveau.modeset=0" and kernel booted correctly. So then I've removed kernel-3.12.7.200 from my system, then again updated system and installed kernel-3.12.8.200. Now when I'm using kernel-3.12.8.200 with "nouveau.modeset=0" it's booting correctly.
And what about without?
kernel-3.11.10-200.fc19.i686 booting correctly without "nouveau.modeset=0" kernel-3.12.6-200.fc19.i686 is not booting without "nouveau.modeset=0" kernel-3.12.8-200.fc19.i686 is not booting without "nouveau.modeset=0"
Heh, well, the older kernel had other issues that apparently got fixed. And now nouveau is broken in 3.12 :( Can I get kernel logs from the non-working case with 3.12 please?
No problem. Could you tell me what logs you need? And what kind of situation? kernel-3.12.8-200.fc19.i686 with nouveau.modeset=0 kernel-3.12.8-200.fc19.i686 without nouveau.modeset=0
You want logs when kernel is not booting correctly? Could you tell me how can I save them to file because I don't know how. Like I said above.
What happens with this bug?
everything is ok - fedora 20 kernel 3.14.2-200.fc20.x86_64 fixed the problem close bug please
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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.