Bug 181618

The same could be said of needing the UP kernel if we install the SMP kernel.

Realistically, offering a "fallback" doesn't really help things much and it just
needs to work.  If it doesn't, I want to hear that it's not so that we can make
sure to fix things.

SMP/UP is different because that gets a lot of testing regardless.
We're in completely unchartered territory with the hypervisor kernel.

I think we're making a big mistake here that could cost us valuable testers.
If test3 is broken for some user, they'll have to reinstall without xen before
they can do anything, as opposed to just grabbing updates.

If this were test1, I'd throw caution to the wind, but this is our last chance
to 'get it right' before we ship.

*** Bug 181750 has been marked as a duplicate of this bug. ***

*** Bug 182988 has been marked as a duplicate of this bug. ***

Agreed with davej; right now "it doesn't boot out of the box on $foo
hardware/config" is the most common Xen bug we deal with.  It's going to be a
big turn-off if this results in a lot of installs that don't offer a fallback to
a working kernel.

Arguably, we're having that problem a lot with the non-Xen kernel right now too :-/

Having the fallback really doesn't help a lot as we
a) Don't show the grub menu by default
b) Don't make it easy to change your default (and future defaults as that gets
hard-coded)
c) End up just downloading what doesn't work for you endlessly.

I'm strongly convinced we either need to
1) be confident enough about it working that we can install it and not worry or
2) not have it be a visible option.
The "install a different kernel in case it's broken" option is just silly.

*** Bug 183321 has been marked as a duplicate of this bug. ***

I too thought just having the Xen hypervisor installed was a bit odd. If even
from a "flexibility" point of view rather then a "fallback" one.

Other distros (such as SUSE), when you install XEN have both options in the GRUB
menu.

This makes sense as you may want Xen available for when you want it, but not
have it be the only option.

On the "might be a bug" front, I couldn't get software suspend to work when
booted to the Xen hypervisor, but it did work OK when booted to the normal Linux
kernel. (this was an un-updated FC5t3 box)

(In reply to comment #0)
> right now, only offering to run under the hypervisor isn't a good idea, as it's
> very fragile on x86-64 (I've not tried 32bit).
> 
> We need a fallback option to a regular bare-metal kernel in grub, or users are
> going to be left with unusable installs that they can't update.

Indeed.  I just encountered that myself.  Installed 3 times, and chose to
install xen, thinking "yeah, I'd like to check xen in FC5 out sometime
when I have some spare time", and _assuming_ that it would install the normal
kernel also.

After install, I got the xen kernel only and thought I must have screwed up.
The xen kernel wouldn't boot, so I reinstalled, and got the same problem.
I could not find anywhere in the installer where I could opt into installing
the regular kernel.  I rebooted in rescue mode and couldn't get a shell from
the installer.  Gave up and booted FC4, downloaded the missing kernel,
mounted the FC5 root, chrooted to it, and tried to install the kernel and
got a SEGV and some other errors.

Gave up, reinstalled again and did not choose xen this time.  The install
finally succeeded.

(In reply to comment #1)
> The same could be said of needing the UP kernel if we install the SMP kernel.

Sure, so we install both the SMP and UP kernel then too.  Good idea.

> Realistically, offering a "fallback" doesn't really help things much and it just
> needs to work.  If it doesn't, I want to hear that it's not so that we can make
> sure to fix things.

Damn right it helps things, unless we expect users who maybe want to try out
xen, to stand on their heads and reinstall the OS 5 times, get sick of wasting
their time, declare Fedora unuseable, and switch to Debian/Gentoo/Mandrake/
whatever.

Can we please install a useable system, and provide fallbacks in case that
might not be completely a stable reliable thing right now?

At a bare minimum, at least have a method in the installer of allowing the
end user to say "Yeah, I want a normal kernel with the xen kernel."

I wasted almost an entire day screwing around with this.  If FC5 ships the
same way, then we're really regressing "ease of use" bigtime.



(In reply to comment #8)
> I too thought just having the Xen hypervisor installed was a bit odd. If even
> from a "flexibility" point of view rather then a "fallback" one.

Yeah, no kidding.  It's just a common sense thing IMHO. It's not like the
disk space extra kernels consume really matter nowadays.

> Other distros (such as SUSE), when you install XEN have both options in the
> GRUB menu.

Hmm, perhaps I should give OpenSUSE a whirl in my quest for a useable OS. ;o)

 
> This makes sense as you may want Xen available for when you want it, but not
> have it be the only option.

Exactly.  Xen is new technology, and many people are not too familiar with
it, but may want to experiment with it.  Forcing people to choose Xen only
or non-Xen during install is really artificially limiting things very
ridiculously.  It's not that the normal kernel(s) should be installed too
as a fallback if xen doesn't work per se. it's more that people do not
necessarily want to make a strict decision between xen or non-xen.

This is very very disappointing to me to get the feeling that we're about
to release FC5, and we're going to screw over users like this.  There's going
to be a lot of bad reviews of FC5 due to this.

<SIGH>

We're taking Xen out as a user-visible option for FC5 based on the fact that
it's not ready.

That's a reasonable solution too I guess.  Presumeably Xen will still be
available to experiment with manually in FC5, or is the kernel no longer
present?  I tried to install the xen kernel via yum and couldn't find it.

Was kindof hoping I could help narrow things down for the "doesn't boot"
issue.

If not, I'll wait until rawhide's rolling again and pick up xen from there
I suppose.

Going to do an x86_64 install over the next few days as well and see how
I fare with that.

TIA

BTW, today SUSE delayed 10.1 by a month (I think). Xen was mentioned as a big
reason.

from the opensuse-announce mailing list.

"We have looked at the current status of our beta versions of SUSE
Linux 10.1 and determined that we would like to spent more time to
strengthen the quality of SUSE Linux 10.1 especially in the area of
virtualization (Xen hypervisor) and package management features.  We
also like to address all blockers.  We have therefore revised the
schedule for SUSE Linux 10.1 and like to give an outlook beyond 10.1
as well."

Presumably SLES10 is slipping from a May 6th release as well.