Description of problem:
Boot hangs after "loading initramfs"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Update to kernel-3.5.0-2.fc17.i686 on Dell Latitude D610
After printing "loading initramfs", screen clears and nothing else happens
kernel-3.4.6-2.fc17.i686 still works, so it isn't some other upgraded package. My guess is that something changed with KMS for Intel.
I see the same thing on an OptiPlex GX620 and the 64-bit kernel: kernel-3.5.0-2.fc17.x86_64.
When I removed the "quiet" kernel flag, the last line that printed was
fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
(This is actually a cut-n-paste from dmesg output after booting the 3.4.6-2 kernel, but I am pretty sure it was the last line when the boot failed.)
The 3.5.0-2.fc17.x86_64 does successfully boot on my Thinkpad T510.
I had the same bug. Remove quiet parameter and rhgb from kernel command line.
Sounds like a duplicate of bug 843826
My Ferrari 4006 (Fedora 32 bit intalled) failed to boot after I upgraded from Fedora (3.4.6-2.FC17.i686.PAE) to Fedora (3.5.0-2.FC17.i686.PAE) a couple of days ago.
Fedora (3.4.6-2.FC17.i686.PAE) still boots and works as expected.
3.5.0-2 displays a message that says loading initial ram disk after a few seconds the screen goes blank (these steps always occur).
After about 20 seconds I expect to see a prompt to enter encryption password, but the prompt never appears.
After 30-45 seconds the fan goes into high gear. Waited an additional 60-120 seconds. Still no prompt appeared.
Same here with Dell latitude D410: Blank screen after "loading initial ramdisk" and no activity. Ctl-alt-del works to restart and 3.4.6 kernel boots fine.
*** boot and selected Fedora (3.5.0-2.FC17.i686.PAE)
removed "rhgb quiet" from kernel command line
last line that displayed on my screen was (if I wrote it down correctly):
2.455884 fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
*** boot fails so I cannot use dmesg - is there a way to retrieve this data (dmesg) after the next boot?
*** rebooted and selected Fedora (3.4.6-2.FC17.i686.PAE)
removed "rhgb quiet" from the kernel command line
$ dmesg >dmesg.out
[ 2.039704] [drm] fb mappable at 0xC80C0000
[ 2.039713] [drm] vram apper at 0xC8000000
[ 2.039717] [drm] size 7057408
[ 2.039721] [drm] fb depth is 24
[ 2.039724] [drm] pitch is 6720
[ 2.039858] fbcon: radeondrmfb (fb0) is primary device
Let me know if dmesg.out might be useful
Do any of you see this "conflicting fb hw.." message in dmesg for 3.4 boots?
(In reply to comment #8)
> Do any of you see this "conflicting fb hw.." message in dmesg for 3.4 boots?
I don't either. I only see it in 3.5 boots.
Does dmesg text survive a reboot? If so, how do I retrieve it?
I do see the "conflicting fb hw usage ..." message when booting the 3.4.6-2.fc17.x86_64 kernel. Here are the surrounding lines from dmesg when booted from that kernel
[ 6.413595] Freeing unused kernel memory: 1000k freed
[ 6.414164] Write protecting the kernel read-only data: 12288k
[ 6.421381] Freeing unused kernel memory: 2024k freed
[ 6.427605] Freeing unused kernel memory: 1484k freed
[ 6.492616] dracut: dracut-018-78.git20120622.fc17
[ 6.528405] dracut: rd.luks=0: removing cryptoluks activation
[ 6.555614] udevd: starting version 182
[ 6.596244] [drm] Initialized drm 1.1.0 20060810
[ 6.643718] i915 0000:00:02.0: setting latency timer to 64
[ 6.696612] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 6.696619] [drm] Driver supports precise vblank timestamp query.
[ 6.696693] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 6.740968] [drm] initialized overlay support
[ 6.787802] checking generic (e0000000 760000) vs hw (e0000000 10000000)
[ 6.787807] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[ 6.787833] Console: switching to colour dummy device 80x25
[ 6.788828] fbcon: inteldrmfb (fb0) is primary device
[ 6.823504] Console: switching to colour frame buffer device 200x75
[ 6.830251] fb0: inteldrmfb frame buffer device
[ 6.830254] drm: registered panic notifier
[ 6.830263] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[ 6.880834] dracut: Starting plymouth daemon
[ 6.992562] dracut: rd.dm=0: removing DM RAID activation
[ 7.011335] dracut: rd.md=0: removing MD RAID activation
[ 7.141675] Initializing USB Mass Storage driver...
Something happened today and the 3.5.0-2.fc17.x86_64 kernel is booting.
Per the suggestion in bug 843826, I added drm.debug=7 to my kernel args, and the kernel booted. dmesg was too full to get anything interesting from the early boot (the oldest entry was at 490 seconds - I had a 1 TB filesystem that had to be checked on boot), so I tried to boot again without the debug flag and it succeeded.
I have now booted 4 times in the 3.5.0-2.fc17.x86_64 kernel without issue.
I have no idea what changed.
After reading David's msg above I tried similar.
1. booted 3.5 without change to kernel command line (using USB kybd and mouse)
2. loading initial ramdisk ...
3. waited 60-120 seconds without response (well beyond the 15 seconds that I usually get a prompt to enter encrypted disk passphrase).
4. boot failed.
5. booted 3.5 replaced "rhgb quiet" with "drm.debug=7" (using USB kybd and mouse)
6. loading inital ramdisk ...
7. 2.456428 fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
8. boot failed
9. bootd 3.5 with "rhgb quiet" replaced with "drm.debug=7" (all USB, firewire devices, speakers and microphone unplugged)
10. loading initial ramdisk ...
11. 1.181911 fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
12. waited 60-120 seconds without response (well beyond the 15 seconds that I usually get a prompt to enter encrypted disk passphrase).
13. boot failed.
14. successfully booted 3.4
I believe 845631 is a dup of this or at least related; same issue different hardware
Still the same problem with Kernel 3.5.1-1.fc17.i686.
Confirmed here also with D610 - kernel-3.5.1 still doesn't boot.
I tried to give bad karma, but bodhi gets an internal error.
can someone drop a complete dmesg from a working boot with 3.4 as an attachment, and if you can get a 3.5 boot, a full dmesg from it as well.
also lspci -vvnn as root would be nice from an affected system
Created attachment 603899 [details]
lspci output (dell precision m4500)
lspci output (dell precision m4500) sucessful boot on 3.3.4-5.fc17.x86_64
Created attachment 603901 [details]
dmesg output (dell precision m4500)
dmesg output (dell precision m4500) sucessful boot on 3.3.4-5.fc17.x86_64
Martin you are seeing this problem with nouveau as well?
As far as I know I am using nouveau, and I yes I see the problem when booting with the newer kernel.
In case it's important, it has occured to me from reading back over the comments above that my hang maybe a bit later in the boot process than some of the other folks (for me the fedora logo appears but never gets aroudn to disappearing), so it's possible there is more than one bug.
Created attachment 604002 [details]
lspci.out - Dell Latitude D610
Created attachment 604004 [details]
dmesg.out - Dell Latitude D610
Created attachment 604037 [details]
lspci.out - Dell Optiplex 170L (**Working**)
This is lspci from a system that *does* boot with 3.5 kernels, for comparison.
Created attachment 604038 [details]
dmesg.out - Dell Optiplex 170L (**Working**)
This is dmesg from a system that *does* boot, for comparison.
(In reply to comment #23)
> In case it's important, it has occured to me from reading back over the
> comments above that my hang maybe a bit later in the boot process than some
> of the other folks (for me the fedora logo appears but never gets aroudn to
> disappearing), so it's possible there is more than one bug.
This happened to me once in several attempts to boot (and that one time I was then not able to restart using ctl-alt-del; I had to use the power switch).
Created attachment 604055 [details]
dmesg output from FC17 3.4 on Acer Ferrari 4006
Created attachment 604056 [details]
sudo lspci -vvnn output from Acer Ferrari 4006
kernel-3.5.2 still broken. You can test and leave karma at https://admin.fedoraproject.org/updates/kernel-3.5.2-1.fc17
My thinking is the only way we'll track this down is for one or two brave souls to take on an upstream kernel bisection between 3.4 and 3.5
I'm not able to reproduce this here on machines I have, and it seems like some combination of grub2/kernel/hardware is required to trigger it.
One of the kernel guys or myself could probably lead someone through a bisection procedure.
Ok, looking at the lspci outputs, the thing that jumps out at me is that all the failing systems have IDE controllers, and all the working systems have SATA controllers. Any counterexamples to this? Note: the Dell m4500 is SATA, but gets much farther in the boot process and is probably a different bug.
Most interesting is the 170L that I posted in comment#26. That has both an IDE and a SATA controller, and is currently running from the SATA controller. I wonder if it would fail if I stuck in a PATA disk?
The IDE laptop is returning to college in a few days, so I can't help with the bisection unless the IDE disk turns out to be the trigger so that I can test on the 170L.
It seems the D610 actually has a SATA controller, and uses a SATA->PATA bridge to connect PATA drives. (Apparently, the T43 thinkpad did the same thing.) The dmesg output from other failing systems seem to have a similar setup - there is a SATA controller for ata1 - with a PATA drive attached through a bridge.
(Some people actually modify their T43 to remove the SATA-PATA bridge and install a SATA connector.)
Is there a kernel already built partway between 3.4 and 3.5 I could test? Or do they have to be built?
(In reply to comment #35)
> Is there a kernel already built partway between 3.4 and 3.5 I could test?
> Or do they have to be built?
We have a large number of kernels for the 3.5 development window. They were built in rawhide, so they end in f18 but should be mostly compatible. You can find them in koji:
There's a koji-bisect script as well:
Created attachment 915484 [details]
(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
I started a kernel bisection using a kernel.org kernel. I got a failure to boot on the 7th boot on 3.5.0 and had 20 successful boots on 3.4.0. I also got a failure to boot on the 3rd boot on the 1st in-between kernel.
Hi, I'd like to chime in to say I own both a Latitude D410 (that as noted above does not successfully boot a 3.5.x kernel but 3.4.6 boots fine on) as well as an IBM ThinkPad T43 that has the same exact setup with no problems booting the aformentioned 3.5.x kernels. Both have similar Intel Pentium M CPUs and Intel based video.
But I'm writing to explain how I was able to convince my Latitude-D410 to boot the failing kernels.
I played around with the grub settings that loaded the 3.5.x kernels until I found a combination of settings that work.
First you need to hit 'e' when grub is about to boot the kernel, then remove the first two lines that read:
Then modify the 'linux' line and remove 'rhgb quiet' and replace with 'nomodeset'.
Hit Ctrl-x and the system will proceed to boot in a text mode only form. If you employ full drive encryption, take note of a simplistic text prompt for your password, then eventually X will load and all is good again.
Only thing I noticed is that the fonts appear different this way and I also suspect video acceleration is gone, unsure why.
I am including a copy of both dmesg and lspci running the 3.5.2 x86 kernel on my Latitude-D410 with the grub modifications I listed.
Please do not hesitate to ask me for more help in testing this as I'd like to be able to boot my Latitude with the same ease as I boot my ThinkPad.
Created attachment 605436 [details]
dmesg Latitude-D410 running 3.5.2 32bit with modified grub options.
Created attachment 605437 [details]
lspci -v Latitude-D410 running 3.5.2 32bit with modified grub options.
Ok I'm writing again to note that while I can get the system to boot with those modifications to the grub config...I just figured out why the fonts appear different and why there doesn't appear to be any video acceleration.
It doesn't appear to be running an Intel X video driver, but rather the VESA driver. I guess that's better than nothing, but I didn't think VESA was provided with the BIOSes of modern computers. I suppose my Latitude D410 isn't exactly that new any more.
I am including a copy of X.org.0.log to show how X initialized itself with this kernel and those modified grub options.
Created attachment 605447 [details]
X.org.0.log Latitude-D410 running 3.5.2 32bit with modified grub options.
Trying the recipie in comment#39, on the D610 with 3.5.2 32bit, nomodeset allows booting to proceed, but Xorg shows a blank screen. I can switch to a text console, however.
If I leave in the load_video and set gfxpayload=keep lines, then booting proceeds (as evidenced by the disk activity light), but Xorg shows a black screen, and attempting to switch to a text console briefly displays the login menu before blanking the screen again. Ctrl-Alt-Del does initiate a controlled reboot.
The fact that nomodeset allows booting to proceed seems to rule out the IDE connection. This is yet another problem with kernel modeset.
lspci and dmesg already posted previously
(In reply to comment #37)
> Same problem with Dell Latitude D410.
> Last working kernel 3.4.5-2.fc17.i686
Could you please add your dmesg as an attachment and delete that humongous comment?
Followed the steps listed in comment #39. My laptopp booted with FC17 3.5
The response (keyboard and mouse) is *very* sluggish, but the Gnome 3 GUI *is* working. I'll attach output from dmesg and lspci -vvnn
Created attachment 605449 [details]
dmesg output from FC17 3.5 on Acer Ferrari 4006
Gnome 3 GUI is working the mouse and keyboard are *very* sluggish
Created attachment 605450 [details]
sudo lspci -vvnn output from FC17 3.5 on Acer Ferrari 4006
Gnome 3 GUI is working, but the mouse and kybd are *very* sluggish
So does it boot if you remove the grub lines but don't add nomodeset?
using my Acer Ferrari 4006 I attempted to boot Fedora (3.5.0-2.fc17.i686.PAE)
(I realize that's not the newest kernel)
and removed 'rhgb quiet'
Last line to appear on the screen was:
1.051600 radeon 0000:01:00.0: radeon: using MSI.
waited a min or two (60-120 seconds) and pressed the ENTER button (expecting the screen to go blank then display a text msg asking for a password to unlock the hard drive), but nothing happened.
failed to boot when I did not use 'nomodeset'
Has anyone tried this that has the newest kernel installed?
can a few people post their full /boot/grub2/grub.cfg files as well?
want to know if you are getting gfxterm, which I don't see here very often.
(In reply to comment #49)
> So does it boot if you remove the grub lines but don't add nomodeset?
Not for me. I had to have ALL 3 modifications before it would even ask for my full drive encryption password and then proceed to a login screen within X using the VESA driver rather than the usual Intel i915GM driver. I will post my /boot/grub2/grub.cfg here in a few minutes just incase it helps as I do find it strange that my ThinkPad having the same exact software and same CPU video combo don't suffer this. Only thing I can think of is the BIOSes are different and maybe setting up the hardware environment prior to boot in a manner that is non-ideal on the Dell vs. the IBM?
Created attachment 605573 [details]
can I also get /etc/default/grub as well?
can people check if they have
in their /boot/grub2/grub.cfg and see if commenting it out helps things any?
D610 does not boot without nomodeset, even after removing the load_video and set gfxpayload=keep lines. However, while nomodeset allows booting, the Xorg server does not work - displaying a black screen. Removing the grub lines (or, from bug#843826, commenting out terminal_output=gfxterm) enables text mode consoles to work when booting with nomodeset (otherwise, text mode displays blank also). But without nomodeset, there is no disk activity after "loading initramfs".
Created attachment 605691 [details]
grub.cfg Latitude D610
/etc/default/grub on Latitude D610:
GRUB_CMDLINE_LINUX="rd.lvm.lv=vg_laura/f17 rd.md=0 rd.dm=0 SYSFONT=True KEYTABLE=us rd.luks=0 rd.lvm.lv=vg_laura/SWAP LANG=en_US.UTF-8 rhgb quiet"
While other people noted that it randomly boots with 3.5 sometimes, the D610 has never, ever booted with 3.5 for me - except with nomodeset.
If this could be a BIOS issue, perhaps we should post some part of dmidecode?
My Latitude-D410 also will NOT boot without nomodeset. However mine does manage to boot all the way up to a X login which proceeds to my desktop after authenticating. As noted earlier, in my case I just noticed the fonts were different looking and the general sluggishness of the display and quickly figured out it's because the Intel X.org driver that I'm used to loading up was replaced by a generic possibly fallback VESA driver that at least works to get me to my desktop.
If it's a BIOS issue then in that case there isn't much I can do. Dell hasn't released newer BIOS for my Latitude-D410 in quite some time and I know I'm running the latest version already. But even if it were a BIOS issue, begs the question why Linux and the Intel X.org driver have worked fine all this time and now suddenly it doesn't. At the very least a workaround or shim for the buggy BIOS/firmware should be put into place.
I personally lean towards the BIOS being the likely culprit as I am running nearly the exact same config on my ThinkPad T43 that has been booting the 3.5.x series kernels on a similar Pentium M with the same Intel 915GM video just fine without modifying grub.cfg. Obviously the BIOS firmware supplied by IBM is quite different than the BIOS supplied by Dell even for the same or similar hardware.
I will post my /etc/defaults/grub here shortly as well.
Here is my /etc/defaults/grub
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
# GRUB_TERMINAL="serial console"
# GRUB_SERIAL_COMMAND="serial --unit=0 --speed=9600"
The only thing I just realized is that this file is different on my ThinkPad than it is on my Latitude. Unsure if these differences matter however. The only other configuration difference I just noticed as well is that the ThinkPad is using MSDOS patitioning with Logical Volumes and my Latitude is using GPT and standard GPT partitions with no Logical Volumes. I don't suppose that would be causing this however...
(In reply to comment #55)
> can people check if they have
> in their /boot/grub2/grub.cfg and see if commenting it out helps things any?
Please note I just checked and both my ThinkPad and my Latitude have that line. I will test tomorrow if the Latitude will boot with that line removed/commented out. But for now the ThinkPad boots with it just fine.
Here is also the ThinkPad's /etc/defaults/grub
GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm.lv=vg_t43/lv_root KEYTABLE=us SYSFONT=True LANG=en_US.UTF-8 rd.luks.uuid=luks-64275afb-b596-4f28-9ee6-bea5b93df2ca rd.lvm.lv=vg_t43/lv_swap rd.dm=0 rhgb quiet"
As you can see somewhat different than the Latitude, unsure why.
I'm writing to regretfully inform that the latest kernel did NOT work as it claimed in the --changelog output of yum.
Machine still performed exactly the same if you let it boot up as normal (the panel back-light actually turns off on the Latitude-D410).
If you modify the grub parameters, this time, the only change necessary to make it work is the nomodeset. No need to remove the load_video and set gfxpayload=keep lines. However it still appears to be using the VESA X.org driver for me, so this is probably only just a step in the right direction and not anywhere near a final solution.
Oh and I meant to say this is with the latest kernel-3.5.2-3.fc17.i686.PAE released lastnight or early this morning.
Created attachment 607732 [details]
3.5 kernels video braindamage - Acer 5670
This is not the Dell D610, but an Acer 5670 with ATI video.
3.5 kernels cause Xorg to garbage random pixels (enough that it is unusable). The text mode consoles work. Please note that the very same Xorg works perfectly with 3.4.x kernels. #.5.x *really* screws something up.
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03)
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
04:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5789 Gigabit Ethernet PCI Express (rev 21)
0a:09.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
0a:09.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
0a:09.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
Also, the rhgb image has black pixels instead of grey at the top. It switches over to grey in the middle of a pixel row. Again, this happens with 3.5 kernels, but not with 3.4 kernels. But since it actually does boot on this box, maybe some more diagnostics can be done. Remember that on the D610, using nomodeset would allow booting, but Xorg would show a black screen (on 3.5.x kernels).
please don't do that we have do completly different bugs with completely different symptoms, why would you pile that in here?
please open a separate bug for the radeon problem its not the same thing.
The radeon (and Intel and Nvidia) work perfectly with 3.4 kernels. Other responders here where it actually hangs have different systems than D610 (the specific model is not the issue). They all hang at the same spot with the same error message (except reporting different graphics drivers). For all graphics types, it is "fixed" by adding nomodeset (except you get an inferior and slow graphics mode - although gnome-shell still runs). They all work with kernel 3.4.
While you might feel that my last report doesn't belong here because it actually finished booting (albeit with dead graphics), the title change is certainly justified because it is not just a D610 model that you can ignore. This is a wide spread problem (or set of unrelated problems that all happen with the same kernel change at the same point in the boot process). The 3.5 kernels kill 2 out the 4 systems I've tried F17 on (which all work great with 3.4 kernels). Plus the other posters here.
I'm not sure how to report this latest 3.5 problem. It still goes under "kernel" because that is the component that breaks it when booting 3.5. (Same Xorg version with both 3.4 and 3.5 kernels.)
Reported the non-hanging graphics problem in bug#852826.
No change with Kernel 3.5.4-1
Has anyone found a reasonable workaround (other than sticking to the 3.4.6 kernel, which is what I am doing)?
I have tried booting with 'nomodeset' and an etc/X11/xorg.conf designed to load the intel driver, but I havn't been able to make that work. In particular, just modelling it on the old xorg.conf I used before the kernel started doing the modeset does not work.
Same results as Walter, D610, kernel-3.5.4-1.fc17.i686
I would like to see this resolved. Let me know if I can provide and information. Boot hangs halfway through the shading the the plymouth? fedora logo.
Link to the 3.4.6 kernels Walter mentions:
I don't know if this helps, but 3.7.0-0.rc0.git3.1.fc19.x86_64 from rawhide Works For Me. The previous one I tried from rawhide 3.6.0-0.rc6.git0.2.fc18.x86_64 didn't work.
3.5.6-1.fc17 Still does not boot my Dell Latitude D410. I may need to try this rawhide kernel mentioned by Martin and report back my findings as well.
I'm using a Fedora 4006 with AMD Turion64 processor and ATI Mobility Radeon X700 graphics card.
I attempted to boot (twice) using Fedora-18-Nightly-20121011.09-i686-Live-desktop.iso
First attempt was with my laptop without the external monitor. Fedora 18 began to start and eventually the screen went gray with an underscore cursor in the upper-left corner. I waited for a while (about 90 seconds) and the fan sped up then the DVD drive started, but only for a second or two. The screen was still gray with nothing on it except the underscore cursor. The fan was still going full speed. I waited another 2 minutes then powered down.
Second attempt was with my laptop and the external monitor. Everything happened the same way as in the first attempt.
kernel-3.6.1-1.fc17.i686 hangs after loading initial ramdisk. Screen goes dark, then shuts off. Fan runs, no HD activity.
kernel-3.6.2-4.fc17.i686, d610, hangs halfway through shading the logo on the plash screen...
Latitude D410. My favorite traveling laptop. It has a stick-on penguin over the windows sticker. Fedora 17.
3.4 kernel still works, 3.5 and 3.6 do not. I've tried several of the work-arounds presented in the above comments. No good for me.
I have also seen the message "fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver" just before the black screen. One piece of information, sometimes the boot process results in a partially filled in 'teardrop' then hangs, most of the time it is a black screen. Can't find anything to correlate that with.
I just downloaded Fedora 18 alpha live CD xfce. Unfortunately it also will not boot on my D410. Very sad. Black screen after a message about SELinux not being able to find some file or directory.
I guess this means that those of us who are having these problems will not be able to install F18 at all unless this gets fixed in time for the F18 release?
If so, what can any of us do to help get this resolved?
Does anyone have a pointer to documentation that explains how to do an upstream kernel bisection?
The best thing to do is to make time to download the F18 alpha/beta disks, attempt to install, and report that it doesn't work. This should be a beta blocker for F18 (not that it will be).
Do you mean for me to override a good install that is still usable using the 3.4 Kernel with a bad one?
Don't wanna do that, since I know that the live version of 18 Alpha does not boot. Unless you insist...
(In reply to comment #81)
> Do you mean for me to override a good install that is still usable using the
> 3.4 Kernel with a bad one?
> Don't wanna do that, since I know that the live version of 18 Alpha does not
> boot. Unless you insist...
No, just boot from the LiveCD - if it doesn't even do that, then report it. If the LiveCD boots, install to separate LV if you are running LVM and know how to tweak grub. You could also use an older tiny hard drive that you upgraded years ago (or upgrade your current tiny hard drive with a new one) to [attempt to] install F18 to.
I'm new here. How do I officially report the live CD problem, what info should I capture and how to capture it?
I really like my little D410 so I want to give all it info I can.
(In reply to comment #83)
> I'm new here. How do I officially report the live CD problem, what info
> should I capture and how to capture it?
> I really like my little D410 so I want to give all it info I can.
Obviously, you already have a bugzilla account. So click New / Fedora and select the component LiveCD and report that it doesn't boot, along with your model, lspci from a working kernel, etc. I have two "clients" (family and friends) with laptops that don't boot with kernel-3.5 and later. Until the kernel finally gets fixed (if ever), you might want to edit /etc/sysconfig/kernel and change UPDATEDEFAULT=no. This prevents changing the default boot kernel when the latest kernel is updated. You can install the latest 3.4 kernel from F16 on F17.
I don't know if it would help to report the problem upstream. It's pretty bad that 2 out of 6 of the machines I'm responsible for (Dell D610 and Sony something) won't boot with any version of the last 2 major releases of the linux kernel. Unfortunately, none of the machines I use personally have a problem with the new kernels - so I can't do any in depth debugging to help out.
Sorry, Have no idea how to fill in the bug report. It is not exactly self-explanatory
I do have the lspci output and a description of what happens.
Start d410 with fedora 18 live xfce cd (downloaded today) in bootable external cd drive.
CD reads & presents boot menu including "Start Fedora 18" -- accepted
CD reads, screen is black (15-20 seconds)
Screen -> grey with text cursor (underscore) at upper left for 5 seconds
Screen -> black
CD reads as if it is doing something important...
CD stops, Screen still black.
Still black for over 3 minutes.
No more CD activity
pressing CD eject button does nothing
Ctrl C does nothing
Ctrl Alt Del does nothing
Must power down to get out of hang condition.
Don't know how to 'attach' a file, so...
lspci output from Kernel 3.4
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3)
00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03)
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)
02:01.0 CardBus bridge: Texas Instruments PCI6515 Cardbus Controller
02:01.5 Communication controller: Texas Instruments PCI6515 SmartCard Controller
02:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)
Just tried Fedora 18 Beta (Live xfce) on 11/27/2012, Same problem, screen goes blank after CD reads for about 4 seconds. CD stops, no more action.
(In reply to comment #78)
> Latitude D410. My favorite traveling laptop. It has a stick-on penguin
> over the windows sticker. Fedora 17.
> 3.4 kernel still works, 3.5 and 3.6 do not. I've tried several of the
> work-arounds presented in the above comments. No good for me.
> I have also seen the message "fb: conflicting fb hw usage inteldrmfb vs VESA
> VGA - removing generic driver" just before the black screen. One piece of
> information, sometimes the boot process results in a partially filled in
> 'teardrop' then hangs, most of the time it is a black screen. Can't find
> anything to correlate that with.
I can confirm this on my Latitude D410. The machine boots with the Kernel 3.3.4. But after the system-update GRUB will try to boot into Kernel 3.6.7. In most cases I will get the black screen. Sometimes the half-filled Fedora Icon.
Can I provide some more information like Log files?
I just booted successfully with latest kernel 3.6.8-2.fc17.i686
This is the first kernel since 3.4.6-2.fc17.i686 which has booted on my
Dell D410 (best laptop I've owned -- it has survived shoulder-high drop onto a cobbled street in Vietnam and a several milder falls).
kernel 3.6.8-2.fc17.i686 boots my D410 also. YEA!
Thanks to the fixers.
kernel 3.6.8-2.fc17.i686 boots my D410 also.
kernel 3.6.8-2.fc17.i686 boots my Dell D610 also.
Thanks to all who made this happen.
What can we do to ensure the fix (whatever it was) has made it (or will make it) into F18 final, since F18 beta reportedly fails with this same bug?
(I would try myself, but I dont have access to my dell machine until I return from holiday)
(In reply to comment #92)
> What can we do to ensure the fix (whatever it was) has made it (or will make
> it) into F18 final, since F18 beta reportedly fails with this same bug?
We didn't explicitly add any patches for this issue in Fedora. Whatever fixed it was brought in through the 3.6.8 rebase if it is really fixed. The only glaringly related looking commit is:
Author: Igor Murzov <email@example.com>
Date: Sat Oct 13 04:41:25 2012 +0400
ACPI video: Ignore errors after _DOD evaluation.
commit fba4e087361605d1eed63343bb08811f097c83ee upstream.
F18 is already rebased to 3.6.8 and will be moving to 3.6.9 soon, so it will get the same set of commits.
If the others in this bug that haven't spoken up yet could report results, that would be appreciated.
(In reply to comment #93)
> If the others in this bug that haven't spoken up yet could report results,
> that would be appreciated.
My Dell E5520 failed to boot with vmlinuz-3.6.8-2.fc17.x86_64. It will only boot with 3.3.4-5.fc17.x86_64 (or earlier). All subsequent kernels fail to launch (with or without modifications in <a href="show_bug.cgi?id=845388#c39">comment #39</a>.
The system is a fresh install from an LXDE spin.
(In reply to comment #94)
> (In reply to comment #93)
> > If the others in this bug that haven't spoken up yet could report results,
> > that would be appreciated.
> My Dell E5520 failed to boot with vmlinuz-3.6.8-2.fc17.x86_64. It will only
> boot with 3.3.4-5.fc17.x86_64 (or earlier). All subsequent kernels fail to
> launch (with or without modifications in <a
> href="show_bug.cgi?id=845388#c39">comment #39</a>.
Thank you for testing.
Unfortunately, you have different hardware than a dell d410/d610. Also, "failed to boot" isn't quite descriptive enough. I would suggest you open a new bug to track your issues.
(In reply to comment #93)
> (In reply to comment #92)
> > What can we do to ensure the fix (whatever it was) has made it (or will make
> > it) into F18 final, since F18 beta reportedly fails with this same bug?
> We didn't explicitly add any patches for this issue in Fedora. Whatever
> fixed it was brought in through the 3.6.8 rebase if it is really fixed. The
> only glaringly related looking commit is:
> commit 4d60ac3f136e26522dbdbff28624f59165a27cd9
> Author: Igor Murzov <firstname.lastname@example.org>
> Date: Sat Oct 13 04:41:25 2012 +0400
> ACPI video: Ignore errors after _DOD evaluation.
> commit fba4e087361605d1eed63343bb08811f097c83ee upstream.
> F18 is already rebased to 3.6.8 and will be moving to 3.6.9 soon, so it will
> get the same set of commits.
> If the others in this bug that haven't spoken up yet could report results,
> that would be appreciated.
I am replying to also show that I tested the updated 3.6.8-2.fc17.i686.PAE kernel started booting my Dell Latitude-D410 successfully and without the use of the VESA x.org video driver.
I too was curious as the rpm --changelog for the latest kernel makes no mention of any patch specific to this bug (though previous kernels did despite the fact that they did NOT work).
I am commenting simply to note and confirm that the kernel on the second test compose of the kde spin for Fedora 18 (3.6.10-4.fc18) boots, installs, and seems to run fine on my D 610. This seems to be the first to do so for me.
This bug was for the D610 systems and appears to be fixed with the commit referenced above. For those of you with different hardware that isn't booting still, please open a new bug.
I just booted kernel-3.6.10 on my daughters D610, and it works (first since 3.4). So it is indeed fixed. Thanks to the fixers.
P.S. Is there some kind of tool end-users could use to help debug these kinds of kernel problems sooner? Perhaps some way of redirecting console output to some kind of media? I know it is possible to use a serial console and log that on another machine. How about a USB serial "console" that simulates a USB serial device, and logs console output on the device, then can be mounted as a USB storage drive to retrieve the log.