Description of problem:
Trying to install F13alpha or F12 fails completely early on. I PXE boot the machine (no CDROM drive). Everything is pulled in nicely, /sbin/loader is started. After that, I think, a short message about discovering hardware is shown.
I'm not so sure about this because immediately the screen is blanked. This is where the system then seems to hang. Nothing at all happens. I left it for more than 30 mins on one occasion.
Version-Release number of selected component (if applicable):
F13alpha netinstall ISO
F12 full DVD ISO
Steps to Reproduce:
1.PXE boot x201
blank screen after loader is started
One difference: in F12 the backlight of the TFT is on. In F13aloha it is off. In case this rings a bell.
> Trying to install F13alpha or F12 fails completely early on. I PXE boot the
> machine (no CDROM drive). Everything is pulled in nicely, /sbin/loader is
> started. After that, I think, a short message about discovering hardware is
There are a couple messages that could be the last thing you're seeing here. Fairly early on, there are these two:
hardware.c: fprintf(stderr, "detecting hardware...\n");
hardware.c: fprintf(stderr, "waiting for hardware to initialize...\n");
Then later once the graphical part of anaconda starts, there's this guy:
w = self.anaconda.intf.waitWindow(_("Finding Devices"),
_("Finding storage devices"))
Do you happen to know which you're seeing, or perhaps you can reproduce this and attach the exact message.
> I'm not so sure about this because immediately the screen is blanked. This is
> where the system then seems to hang. Nothing at all happens. I left it for
> more than 30 mins on one occasion.
Yeah there's a lot of possible causes for this, unfortunately, and none of them are going to be fun to track down.
(In reply to comment #2)
> hardware.c: fprintf(stderr, "detecting hardware...\n");
> hardware.c: fprintf(stderr, "waiting for hardware to initialize...\n");
Both of these messages appear and then the screen is blanked. Immediately after the second message.
In case it matters, this is an i7 CPU, 4GB RAM, SSD.
This is most likely an Xorg / kms bug. Can you try to start anaconda with nomodeset on the kernel cmdline ?
If that gets you in to loader it is a kms bug. If it then crashes when trying to enter stage2, we also have a plain ums bug. In either case we will need to know
what kind of graphics card this machine is using, so we can re-assign it to the proper component.
As for RHEL-6 impact, you may want to file a separate bug against RHEL-6 for this.
Using nomodeset I actually can see the installer. I still cannot provide the lspci information because I don't get much further.
After the question re v4/v6 network the installer insists on using the wlan interface. Even after I use the rfkill switch. The machine booted via the ethernet port.
I cannot say what the exact model number for the ethernet chip is. It's definitely some e1000 variant. Is there any other reason but an unknown ethernet port for the installer to not use it?
The wlan use doesn't go anywhere either. NetworkManager is started but always fails. On The log console I see
NOTICE NetworkManager: ifcfg-rh: error: Missing SSID
The network doesn't have a hidden SSID.
Is there a way to completely disable the wlan from the kernel command line? Any other suggestions?
I've moved the bug back to anaconda. Once I know the graphic chipset details I'll open a bug for the X server.
Any comments? What testing can I do? Any alternate boot images which provide more debugging etc?
I'm experiencing the same problems on a Lenovo X201i laptop with both F12 and F13 Alpha installers.
So far I have tracked it down to an issue with kernel mode setting - if it's enabled, the screen just goes blank and the laptop never goes anywhere. If you disable KMS, installation will proceed.
From my understanding, the GPU on these laptops is Intel HD Graphics (also called GMA HD) which is integrated with the core i5 CPU.
According to http://www.thinkwiki.org/wiki/Intel_HD_Graphics, kernel 2.6.33 and Intel Xorg driver 2.10 or newer is recommended, which is not met by F12 but is by F13 Alpha.
* Standard F12 kernel and xorg intel drivers will cause a complete system crash.
* Standard F13 kernel and xorg intel drivers will no longer cause a complete system crash, however the screen goes completely blank and the laptop is only reachable via the network.
Probably best to file a KMS/Xorg bug on this rather than an Anaconda bug?
(In reply to comment #9)
> * Standard F13 kernel and xorg intel drivers will no longer cause a complete
> system crash, however the screen goes completely blank and the laptop is only
> reachable via the network.
You got the network to work? This doesn't work for me. What install media did you use?
(In reply to comment #10)
> You got the network to work? This doesn't work for me. What install media did
> you use?
Yup, network worked fine for me with the ethernet e1000 driver.
However the wifi is more interesting - The X201i series ship with a couple different possible wifi cards, depending on the exact model and options at the time of order.
I ordered mine with the "ThinkPad b/g/n Wi-Fi wireless LAN Mini-PCIe" but there is also a "Intel WiFi Link 1000" option on some of the models.
The card I got turned out to be a rtl8192se which isn't supported in Fedora 12, so it would never obstruct the installer (the card does have linux drivers tho, see http://tinyurl.com/yc4zurr for more info about setting it up).
I'm guessing that the card in your laptop may be a different chipset which Fedora is recognising but for whatever reason is failing to work correctly with, whereas for me, Fedora wasn't even aware of the wifi.
I did my install using the boot image on a USB drive and then installing via HTTP.
Ajax analyzed the video problem. More recent kernels or backports for the Intel driver will fix it. I see the video stuff working with a RHEL6 boot media which has the backport.
But my machine's ethernet chips seems not to be recognized by the installer. I have a live image on a USB stick and it will happily use the chip. But the installer complaints that it cannot find the driver and refuses to continue the installation (media comes over NFS).
What info do the anaconda guys need to track this down?
Confirmed for myself as well, after building the RHEL 6 beta kernel 2.6.32-19 on Fedora 13 beta the problem with video was resolved.
However the problem still remains with the Fedora 13 Beta kernel, tested with 2.6.33-2-57
> Ajax analyzed the video problem. More recent kernels or backports for the
> Intel driver will fix it. I see the video stuff working with a RHEL6 boot
> media which has the backport.
Then we should probably retitle this bug so it's obvious what issue it is now tracking.
> But my machine's ethernet chips seems not to be recognized by the installer. I
> have a live image on a USB stick and it will happily use the chip. But the
> installer complaints that it cannot find the driver and refuses to continue the
> installation (media comes over NFS).
> What info do the anaconda guys need to track this down?
The contents of tty3, 4, and 5 would be helpful. Screenshots are acceptable. I feel like this is likely to be a driver bug, though, as anaconda has very little to do with module loading anymore. We basically just trust that the module knows which hardware it supports.
(In reply to comment #14)
> The contents of tty3, 4, and 5 would be helpful. Screenshots are acceptable.
> I feel like this is likely to be a driver bug, though, as anaconda has very
> little to do with module loading anymore. We basically just trust that the
> module knows which hardware it supports.
This is with the F13beta over PXE. With nomodeset so that I see anything.
The installer fails when it cannot use the wlan device. Although of course an ethernet cable is plugged in so that PXE works.
tty3 shows info re floppy and CDROM (neither exists) and then the network status. The most important line
INFO loader: only have one network device: wlan0
This is wrong, there is an ethernet port.
On tty4 all the non-wlan messages are scrolled off. The wlan is encrypted so I don't expect that to work (should it)? The firmware module is present (iwlwifi-6000).
tty5 is empty.
I assume the important thing here is the message of the ethernet module (should be a normal 1G Intel card). How can I see that? I now the card is supported. When using the lifecd I can use the ethernet connection.
If you hit ^Z when you get to this error dialog, do you get dropped to a shell? If so, you are in an extremely limited environment where you should have enough stuff to copy /tmp/syslog and /tmp/anaconda.log to a USB key or similar. Note that you have busybox to provide a lot of the missing utilities.
(In reply to comment #16)
> If you hit ^Z when you get to this error dialog, do you get dropped to a shell?
> If so, you are in an extremely limited environment where you should have
> enough stuff to copy /tmp/syslog and /tmp/anaconda.log to a USB key or similar.
> Note that you have busybox to provide a lot of the missing utilities.
I did that. I then saw that the e1000e module is loaded. But the interface isn't configured. In fact, it doesn't even appear in the ifconfig output. After removing the module and adding it back NetworkManger correctly configured it. I.e., dhclient ran and the interface got the correct IP address.
Unfortunately fg doesn't work after ^Z so I cannot continue.
What do you want me to look at next?
exit will return you to anaconda.
I'd like you to attach /tmp/syslog and /tmp/anaconda.log to this bug report if you can.
(In reply to comment #18)
> exit will return you to anaconda.
> I'd like you to attach /tmp/syslog and /tmp/anaconda.log to this bug report if
> you can.
BTW: which busybox? I get dropped into bash with almost no utilities installed. I had to copy cp and ls etc on the USB stick. Anyway, I'll attach the two files.
Created attachment 409283 [details]
syslog after failed wlan lookup
The e1000e modules hasn't been removed and re-added.
Created attachment 409284 [details]
same situation as for syslog file.
05:17:02,523 INFO kernel:e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
05:17:02,523 INFO kernel:e1000e: Copyright (c) 1999 - 2009 Intel Corporation.
05:17:02,523 INFO kernel:e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
05:17:02,524 DEBUG kernel:e1000e 0000:00:19.0: setting latency timer to 64
05:17:02,524 DEBUG kernel: alloc irq_desc for 28 on node -1
05:17:02,524 DEBUG kernel: alloc kstat_irqs on node -1
05:17:02,524 DEBUG kernel:e1000e 0000:00:19.0: irq 28 for MSI/MSI-X
05:17:02,525 INFO kernel:e1000e 0000:00:19.0: PCI INT A disabled
05:17:02,525 WARN kernel:e1000e: probe of 0000:00:19.0 failed with error -2
I have the same issue during install on DELL optiplex760,my hardware is:
Nothing fixed in F13 GA.
The e1000e driver still doesn't work after startup, only after removing and re-inserting it.
The kernel mode driver for the Intel chip still doesn't do the right thing, the screen is blank. I thought ajax mentioned the support would be backported.
I.e., no progress whatsoever since F13-alpha.
Created attachment 425792 [details]
hacked up patch which makes the display work on Thinkpad x201
The video display problem isn't something with the fedora kernel, it doesn't work in the upstream kernel either (nor the f14 kernels). It does work with the RHEL 6 Beta kernel, is anyone trying to push the rhel kernel patches upstream?
I have attached a very hacked up patch that makes my x201 work with the laptop screen. Hopefully someone who knows this stuff better can determine what the actual patch should be and get this properly fixed.
Now if only the display port on the dock would work properly :(
(In reply to comment #25)
> Created an attachment (id=425792) [details]
> hacked up patch which makes the display work on Thinkpad x201
Indeed, I can confirm that. Checked with 22.214.171.124-133. Thanks a lot.
I can confirm the problems with arrandale graphics on Thinkpad x201. More context can be found at https://bugs.launchpad.net/fedora/+source/linux/+bug/554569
Is the 126.96.36.199-11.fc13 kernel from koji any better?
(In reply to comment #28)
> Is the 188.8.131.52-11.fc13 kernel from koji any better?
No, the screen is still turned off.
http://lists.freedesktop.org/archives/intel-gfx/2010-July/007328.html is the patch that is likely needed...
(In reply to comment #30)
> http://lists.freedesktop.org/archives/intel-gfx/2010-July/007328.html is the
> patch that is likely needed...
Indeed, Adam's patch works. I might try tomorrow connecting an external monitor. With the patch from comment #25 this doesn't work. The screen turns off when trying to mirror the screen.
I don't see this patch in the drm-next git tree.
When using an external projector on a machine using Adam's patch it works in principle. Except when I try to mirror the screens. The laptop has a resolution of 1280x800, the mini projector I use has 640x480. Upon connecting the projector I see the extended desktop and can move windows there. But once I select to mirror the screen the laptop screen turns off and the signal to the projector is also turned off.
Is this also a frequency selection issue? It's certainly not in the same category as this bug (at least the machine boots) but might be related. I'll open a new bug if I get told to do so.
Patch went in 184.108.40.206-18.fc13
Open another bug for the external display issue and reference this bug in case they're related.
bug: [Ironlake LVDS] Dell E6410 boots to black screen , https://bugs.freedesktop.org/show_bug.cgi?id=28746 and bug :[Arrandale] No output (black) on eDP https://bugs.freedesktop.org/show_bug.cgi?id=28070 seems to be a similar bug ,
which has been closed after this patch:
which was applied on 220.127.116.11-137.fc13.x86_64
(In reply to comment #35)
> Patch went in 18.104.22.168-18.fc13
Confirmed. Work with 22.214.171.124-20.fc13.x86_64.
There was one other issue which prevented installation (the e1000e driver doesn't work, has to be re-inserted). I haven't tested this recently.
As far as I am concerned the bug can be closed.
> Open another bug for the external display issue and reference this bug in case
> they're related.
The IBM team confirmed on multiple ThinkPad x201 systems that the new 126.96.36.199-20.fc13 kernel does indeed resolve the video problem. Excellent - many thanks to everyone for their help.
I agree that the bug can be closed.
kernel-188.8.131.52-147.2.4.fc13 has been submitted as an update for Fedora 13.
kernel-184.108.40.206-147.2.4.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-220.127.116.11-147.2.4.fc13
kernel-18.104.22.168-147.2.4.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.