Bug 208380

The Grub boot menu is not updated by Xen but is rather handled by the openSUSE 10.2 installation program.

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

This may be the same as Bug #213838.

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

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

Ok, I think I've tracked down the problem:

If one selects the Xen pattern during installation or even after it (in a running system), all needed xen packages but "kernel-xen" get installed. Thus, if no xen kernel gets installed, there is no possibility an entry in "/boot/grub/menu.lst" can get created.

If one installs the (missing) package "kernel-xen" after an incomplete xen pattern installation, the entry in "menu.lst" will be created.

Since this is apparently a pattern problem, I'll reasign this bug.

Ok, fixed for beta2.

I am posting a comment because I think that the wrong fix was probably applied here.
One or the other (not both) of kernel-xen or kernel-xenpae needs to be installed with xen based on how much memory the machine has, and it appears that with the fix from comment 7 that kernel-xen is used in every case.  Thus, kernel-xenpae will never be installed, if I am correct, and 32 bit hardware will be limited to a small amount of RAM which is bad for implementing a number of VM's (increasing to critical).

My experiance was that when I did a Xen pattern install during initial installation, the xen kernel WAS installed (somewhat contrary to comment #6, see bug 215736). On a machine that had 4G Memory kernel-xenpae was installed and on one with only 1G RAM kernel-xen was installed so I think the code is already in there to install the correct xen kernel, we just need to have the GRUB boot menu entry added properly.

To clarify, adding kernel-xen to the xen pattern will NOT ultimately solve the original problem mentioned here.  Comment 6 refers to post installing xen for which all those details in the comment are accurate but the real problem for this entry is in the initial install(as mentioned in bug 215736).
For further reference please see bugs 143367, 163138, and 161559 which all indicate that something in perl-bootloader needs altered in 10.2 for this to work.  These are some of the bugs related to similar issues that occured in 10.1 and SLES10. These bugs also indicate that perhaps Andreas Gruenbacher knows a lot about how this works and may be a good resource.
As a side note, (this probably belongs in another bug...) the kernel-xen and kernel-xenpae entries in the grub menu look rather ugly compared to how they have looked in past releases.
regards,
Lynn

Then let's reopen this...

Ok, this seems to be a regression to SLE10.
But now there are two different bugs, that should be tracked differently:

- For 32bit there seems to be a separate mechanism to select either xen or xenpae kernel additionally to the xen pattern, whereas this seems to be missing o x86_64
Please open a separate bug for this.

- the xen entry is missing if the xen-kernel is selected during installation.
  We verified this now and will track this within this bug.

To comment #8:

I have to admit that - dependent on the underlying architecture, thus 32bit or 64bit, and installed RAM - different xen kernels should be used. That is, as Lynn already said, kernel-xen or kernel-xenpae.

Nevertheless no xen kernel gets installed (on a x86_64 system) - even during a fresh installation, except for selecting the missing xen kernel manually.

(In reply to comment #11)
> To comment #8:
> 
> Nevertheless no xen kernel gets installed (on a x86_64 system) - even during a
> fresh installation, except for selecting the missing xen kernel manually.
>
Hi Alexander, 
I was not able to duplicate your results.  During a fresh install on bare x86_64 hardware (i.e. not a VM) I selected mostly defaults and added the Xem pattern. At this point the kernel-xen did not appear to be selected for install(maybe this is what you were referring to?). After completing the install, though, there was a kernel-xen package installed on my system.  I did this with a Beta 1 DVD.  I think some process detects that the Xen pattern was selected and then selects the appropriate kernel-xen to install based on arch and memory.
Lynn

Right, maybe I've misinterpreted that ;) - I've just installed openSUSE 10.2 Beta1 Plus and kernel-xen(pae) appears in the xen pattern and gets installed, too.

Nevertheless, the xen entry in menu.lst is missing.

Ok, in beta2plus an entry is created but is wrong:
modules(<device>)/boot/initrd-xen 
is missing

I just installed beta2plus on two different machines (i386 & x86_64) and in both cases the /boot/grub/menu.lst file did not contain an entry for Xen (even though all the xen packages were installed properly).  Am I missing something?

Can you please add the y2logs?

Created attachment 105550 [details]
y2log files

The attached tar contains all the log files in '/var/log/YaST2' from my x86-64 machine.  I hope the log files you are looking for are in that directory.

Created attachment 105551 [details]
yast2 log files

The attached file contains all the log files in '/var/log/YaST2' from my i386 machine (installed with openSUSE 10.2 Beta 2 plus).

Just to confirm, I also found that on openSUSEbeta2plus there is no grub enty *and* no initrd-xen when selecting Xen during install process.  After the install if I reinstall kernel-xen then the initrd-xen and the grub entry are there.

can someone try this patch please, IF the missing initrd is indeed the problem?
the global variable i to loop through all kernels is overwritten by the new code added by me:

--- /sbin/mkinitrd      2006-11-14 00:11:37.000000000 +0100
+++ /root/mkinitrd.olh  2006-11-16 14:05:10.000000000 +0100
@@ -1209,6 +1209,7 @@ mkinitrd_kernel() {
     local need_dmraid
     local -a features
     local fs_modules drv_modules uld_modules xen_modules
+    local i
 
     tmp_mnt=$work_dir/mnt
     tmp_mnt_small=${tmp_mnt}_small

I can test this until Monday (20/11). Anyone else that can test this sooner?

s/I can/I can't/

Factory install 2006NOV18 the initrd-xen is linked to a non-existant "initrd-2.6.18.2-12-xen" the standard initrd is linked to "initrd-2.6.18.2-12-default". Have the initrd names perhaps been functionally consolidated into this "default" and maybe the code is lagging the change?
As a work-around can this initrd-2.6.18.2-12-default be substituted?

factory is outdated, dont bother with it. Did you try the patch above?

submitted a quick fix which avoids usage of cached_proposal.
this one has been tested in a beta2plusplus environment already.

this means we fixed the blocking condition, xen section gets proposed

Installation of openSUSE 10.2 Beta2 x86_64
I've made a NEW installation now with Beta2 (over the previous alpha5)
  /dev/sda6 Ext3 /
  /dev/sda7 Ext4 /home
(beside, there is an XP installation and openSUSE 10.1 on /dev/sda8) 

Selected the GNOME desktop installation, then selected additional XEN pattern.
XEN was still not added to the 10.2 new boot menu.
 

This is fixed for me (on i386) with RC1.

Can we mark this as fixed now?

I tested on 2 different systems - works. closing

I can confirm this is fixed in RC1 on i386 and x86_64