Description of problem:
Fedora will not install on Lenovo W520 with Nvidia Graphics Card 1000M.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Put DVD in DVD Rom
2. Boot to DVD
3. Select Install Fedora
4. Error occurs and install stop:
systemd: Failed to fully start up daemon. No such file or directory.
Fedora Does not install
Fedora should install.
Does it work in non-discrete mode?
Yes, it does install in when selecting integrated graphics mode.
Please attach the complete error message you are seeing. The systemd message alone is likely not the real problem here.
That message is the complete message displayed on the screen. I can't jump to any other VTY's or anything to try and get any other information.
As I mentioned at https://bugzilla.redhat.com/show_bug.cgi?id=752613
This seems to be an issue with the hardware vitualization being enabled. Hopefully this narrows down the problem and someone can fix it cause I've been having this issue since Fedora 15 (haven't tried earlier versions, but Arch Linux works fine).
Same. Still is not working
As a temporary workaround, you can boot with "noapic", which does not affect any functionality (as opposed to disabling hardware virtualization).
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
@Dave: Thanks for the reply. I've tested with and without Nouveau (nVidia proprietary driver's kernel module won't compile). Without Nouveau, I was able to boot the system with the default kernel parameters (i.e. without noapic). With Nouveau, Fedora still crashes at the initrd stage (probably during udev initialization, like in other distros).
@Dave - this worked great for me! I was suffering this exact problem on my Lenova W520 in Discrete Graphics mode. I ended up using the noapic boot parameter as a workaround, but this is no longer needed for me after updating to kernel-3.3.0-4!
@GordonL are you running the closed source nvidia driver? I tried removing noapic from kernel params on 3.3.0-4 and 3.3.0-5 (f17) both running nouveau and machine fails to boot.
@Patrick: I am using Nouveau. I previously tried the Nvidia driver when I was wrestling with this bug, but was never able to get that to work. My /var/log/Xorg.0.log says:
[ 56.489] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so
[ 56.489] (II) Module nouveau: vendor="X.Org Foundation"
[ 56.489] compiled for 188.8.131.522, module version = 0.0.16
[ 56.489] Module class: X.Org Video Driver
[ 56.489] ABI class: X.Org Video Driver, version 11.0
I previously needed the noapic Kernel option for the machine to boot, but after upgrading to kernel 184.108.40.206 I was able to remove noapic and it is still working great!
Here are two more notes which may or may not be useful to someone:
1) I've now upgraded to kernel 3.3.1-3.fc16.x86_64 and the fix is still working. I verified on the grub command line that noapic=1 is NOT specified.
2) I have Intel Virtualization Technology Enabled (this is key because, previously, I could disable this rather than specify noapic=1). However, I have the "Intel VT-d" feature disabled. That feature (VT-d) is not required for me to run VMWare. I'm not sure if enabling it would cause any problems for me (haven't tried).
i'm also running 3.3.1-3.fc17.x86_64 and have the same Virtulization settings and my machine will _not_ boot without 'noapic' in the kernel parameters.
I restored the default settings in the BIOS and then changed the graphics from Optimus to Discrete. This was the only change from default settings.
Version: 8BET53WW (1.33 )
Release Date: 10/21/2011
Firmware Revision: 1.25
Machine will boot if in Optimus mode _without_ 'noapic' but put it in Discrete and it hangs without 'noapic'.
Hi Patrick. My BIOS is a little bit newer:
UEFI BIOS Version: 8BET55WW (1.35)
UEFI BIOS Release Date: 2011-12-06
I'm not sure where to get the firmware version you referenced. I do see this on my BIOS info screen:
Embedded Controller: 8A4T38WW (1.20)
If you turn off Intel Virtualization Technology, does it work for you even without noapic=1? Of course this doesn't help if you need the feature (like I do).
It has always worked for me in integrated graphics mode, but I can't use that as I commonly plug the system into a 30" external monitor using DisplayPort (through a docking station). As far as I know, this can't be done with the integrated graphics system.
It is too bad that the "fix" doesn't seem to be working for everyone. I never saw any particular negative side effects when I was using noapic=1, but I am glad that I no longer seem to need it after the fix.
This seems to be resolved and/or some sort of firmware issue.
If this is still being seen on F16 3.4 kernels or F17 3.5 kernels, please open a new bug.