Description of problem: Went through an install where virtualisation (XEN) was selected. The system created the installation, but when the system rebooted to complete, the XEN kernel locked up. (Refer to 233843 (fc6) and updates (fc7) bugzilla entries. Because there is no regular kernel, and because at this stage there is no rescue DVD, a full reinstall was necessary, only this time, excluding the virtualisation option. After yum -y update, the virtualisation kernel (XEN) was installed. At least I had a boot time fall back to the non-xen kernel. Version-Release number of selected component (if applicable): How reproducible: Fc6, every update following October 2006. And including FC7. Steps to Reproduce: 1. 2. 3. Actual results: System will not boot with XEN kernel due to problems with it. Expected results: Annaconda should always install the non-xen kernel as well as the XEN kernel. (or do the XEN install after the reboot to add first user). Additional info: Not really annaconda's fault
You will *never* be running both kernels, though. Installing both leads to nothing more than a waste of disk space, bandwidth, etc as long as it doesn't work. If the kernel is broken, it should be fixed. Not papered over with hacks like installing a "backup" kernel.
Jeremy Perhaps you did not understand my note. In a clean fresh install, I chose virtualisation, because I wanted to run XEN. The XEN kernel got installed, as it should, together with my other selected downloads. When I rebooted, XEN locked up, and there was no way to boot with another kernel. So, I had to scrub the install and redo it skipping virtualisation. That of course took up a lot of my time, and network time. The non XEN kernel worked. Then I added virtualisation (still the XEN kernel did not work), but at least I had a fallback system. Oh yes, my hard drive is a 250gig, of which I made the boot partition large enough to support 6 kernel copies. Fix the XEN problem and I will be happy.