Missing XEN Boot option following repair

Yesterday after agreeing to download some updates, I could not find the Virtual Machine Manager for the 3 XEN VMs (vm1-oes[novell oes]; vm2-gw[groupwise]; vm3-gms[groupwise mobility service]) that I have on my server. (In fact, I was no longer sure if I was looking at the host, or if I was looking at one of the VMs. I tried to do a reboot of the server, and at reboot I had the option to select XEN (then the default), but the boot failed to complete (progress bar at about 95%). I left it at that yesterday. Today I have done an automatic repair but the XEN boot option has disappeared, though I believe the various VM folders and files are still present.

The automatic repair option seemed to work (including repair of Ext3 file system); the next stage said that Initrd modules (jbd; mbcache; ext3) were missing from /etc/sysconfig/kernel so I selected repair to add the missing modules to the initial RAM disk. "Calling mkinitrd failed’, and I took a photo of the resulting log file, which is a bit much to type out here.
Then the repair process said ‘Boot loader error detected’ and again I chose the automatic repair option.

In an earlier post with a similar issue, I see that the poster was asked to run some zypper commands, which I have done and am able to copy here:

Directory: /root/Desktop
Sun Apr 8 14:13:23 ACST 2018
noddy:~/Desktop # zypper pd
Refreshing service ‘nu_novell_com’.
Loading repository data…
Reading installed packages…
S | Repository | Internal Name | Name | Version | Arch | Is Base
–±-----------±--------------±------------------------------------±-----------±-------±-------
i | @System | SUSE_SLES | SUSE Linux Enterprise Server 11 SP4 | 11.4-1.109 | x86_64 | Yes
noddy:~/Desktop # zypper lr -d

| Alias | Name | Enabled | Refresh | Priority | Type | URI | Service

–±-------------------------------------------------±-------------------------------------------------±--------±--------±---------±---------±-----------------------------------------------------------------------------------------------------±-------------
1 | PK_TMP_DIR | PK_TMP_DIR | Yes | Yes | 99 | plaindir | dir:///var/tmp/TmpDir.AA9maF |
2 | SUSE-Linux-Enterprise-Server-11-SP4 11.4.4-1.109 | SUSE-Linux-Enterprise-Server-11-SP4 11.4.4-1.109 | Yes | No | 99 | yast2 | cd:///?devices=/dev/sr0 |
3 | nu_novell_com:SLE11-Public-Cloud-Module | SLE11-Public-Cloud-Module | No | Yes | 99 | NONE | https://nu.novell.com/repo/$RCE/SLE11-Public-Cloud-Module/sle-11-x86_64?credentials=NCCcredentials | nu_novell_com
4 | nu_novell_com:SLE11-SP4-Debuginfo-Pool | SLE11-SP4-Debuginfo-Pool | No | Yes | 99 | NONE | https://nu.novell.com/repo/$RCE/SLE11-SP4-Debuginfo-Pool/sle-11-x86_64?credentials=NCCcredentials | nu_novell_com
5 | nu_novell_com:SLE11-SP4-Debuginfo-Updates | SLE11-SP4-Debuginfo-Updates | No | Yes | 99 | NONE | https://nu.novell.com/repo/$RCE/SLE11-SP4-Debuginfo-Updates/sle-11-x86_64?credentials=NCCcredentials | nu_novell_com
6 | nu_novell_com:SLE11-Security-Module | SLE11-Security-Module | No | Yes | 99 | NONE | https://nu.novell.com/repo/$RCE/SLE11-Security-Module/sle-11-x86_64?credentials=NCCcredentials | nu_novell_com
7 | nu_novell_com:SLES11-Extras | SLES11-Extras | No | Yes | 99 | NONE | https://nu.novell.com/repo/$RCE/SLES11-Extras/sle-11-x86_64?credentials=NCCcredentials | nu_novell_com
8 | nu_novell_com:SLES11-SP4-Pool | SLES11-SP4-Pool | Yes | Yes | 99 | rpm-md | https://nu.novell.com/repo/$RCE/SLES11-SP4-Pool/sle-11-x86_64?credentials=NCCcredentials | nu_novell_com
9 | nu_novell_com:SLES11-SP4-Updates | SLES11-SP4-Updates | Yes | Yes | 99 | rpm-md | https://nu.novell.com/repo/$RCE/SLES11-SP4-Updates/sle-11-x86_64?credentials=NCCcredentials | nu_novell_com
n

So, can I resuscitate this server by simply adding the XEN boot option back into the bootloader file? Would love some guidance, please.

Jerome

zexec4 wrote:
[color=blue]

Yesterday after agreeing to download some updates, I could not find
the Virtual Machine Manager for the 3 XEN VMs[/color]

I have a SLES11 SP4 server hosting three Xen VMs. About a month ago I
ran zypper to update my OES2015 SP1 VM and things didn’t go well. The
VM booted but most of the services were unavailable. Something seemed
terribly wrong so I opened an SR.

It took a while to diagnose the problem but what happened was the
update included a new kernel which didn’t get correctly installed
leaving the old kernel only partially installed. Many of the old kernel
modules were “missing”. The solution was to get the old kernel working
then attempt the update once again which got everything back to normal.

My point is this: you can’t repair a system until you have properly
diagnosed the problem. You appear to be encountering one issue after
another and attempting to resolve each issue.

There are a couple of Knowledge Partners that frequent this forum who
may be able to assist in diagnosing the problem but I suspect a more
hands on approach may be needed so perhaps it’s time for you to open an
SR.


Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.

[QUOTE=KBOYLE;51994]zexec4 wrote:
[color=blue]

Yesterday after agreeing to download some updates, I could not find
the Virtual Machine Manager for the 3 XEN VMs[/color]

I have a SLES11 SP4 server hosting three Xen VMs. About a month ago I
ran zypper to update my OES2015 SP1 VM and things didn’t go well. The
VM booted but most of the services were unavailable. Something seemed
terribly wrong so I opened an SR.

It took a while to diagnose the problem but what happened was the
update included a new kernel which didn’t get correctly installed
leaving the old kernel only partially installed. Many of the old kernel
modules were “missing”. The solution was to get the old kernel working
then attempt the update once again which got everything back to normal.

My point is this: you can’t repair a system until you have properly
diagnosed the problem. You appear to be encountering one issue after
another and attempting to resolve each issue.

There are a couple of Knowledge Partners that frequent this forum who
may be able to assist in diagnosing the problem but I suspect a more
hands on approach may be needed so perhaps it’s time for you to open an
SR.


Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.[/QUOTE]

Thank you Kevin: I agree and will open an SR.
Cheers

While I have raised a new SR, I don’t have a very high priority and it seems the support people have been very busy this week. Hoping to help myself a little I’ve tried some things and done lots of researching, and found there is a boot.omsg while tells a little about what went wrong. (Since I can boot into normal SLES after restoring the menu.lst file). So I was wondering if anyone can assist in diagnosing these lines from the boot.omsg where the last lines correspond to the XEN boot failing to complete:

REDIRECT=/dev/tty1 COLUMNS=124
PATH=/bin:/sbin:/usr/bin:/usr/sbin vga=0x317 DO_CONFIRM=
RUNLEVEL=5 resume=/dev/disk/by-id/scsi-3600508e00000000075fcb5123f95e409-part1 PWD=/
SPLASHCFG=/etc/bootsplash/themes/SLES/config/bootsplash-1024x768.cfg PREVLEVEL=N LINES=44
HOME=/ SHLVL=2 AVAHI_COMPAT_NOWARN=1
splash=silent SPLASH=yes ROOTFS_BLKDEV=/dev/disk/by-id/scsi-3600508e00000000075fcb5123f95e409-part2
_=/sbin/startproc DAEMON=/usr/sbin/cupsd ]
done
<notice – Apr 10 22:14:01.359125000>
‘cups start’ exits with status 0

<notice – Apr 10 22:14:01.362214000>
libvirtd start

Starting libvirtd
<notice – Apr 10 22:14:01.901542000>
startproc: execve (/usr/sbin/libvirtd) [
/usr/sbin/libvirtd
–daemon
–config
/etc/libvirt/libvirtd.conf
–listen
], [
CONSOLE=/dev/console
SELINUX_INIT=YES
ROOTFS_FSTYPE=ext3
SHELL=/bin/sh
TERM=linux
ROOTFS_FSCK=0
LC_ALL=POSIX
INIT_VERSION=sysvinit-2.86
REDIRECT=/dev/tty1
COLUMNS=124
PATH=/bin:/sbin:/usr/bin:/usr/sbin
vga=0x317
DO_CONFIRM=
RUNLEVEL=5
resume=/dev/disk/by-id/scsi-3600508e00000000075fcb5123f95e409-part1
PWD=/
SPLASHCFG=/etc/bootsplash/themes/SLES/config/bootsplash-1024x768.cfg
PREVLEVEL=N
LINES=44
HOME=/
SHLVL=2
splash=silent
SPLASH=yes
ROOTFS_BLKDEV=/dev/disk/by-id/scsi-3600508e00000000075fcb5123f95e409-part2
_=/sbin/startproc
DAEMON=/usr/sbin/libvirtd
]
done
<notice – Apr 10 22:14:02.426652000>
‘libvirtd start’ exits with status 0

<notice – Apr 10 22:14:02.430002000>
nscd start

Starting Name Service Cache Daemon
<notice – Apr 10 22:14:02.562694000>
startproc: execve (/usr/sbin/nscd) [
/usr/sbin/nscd
], [
CONSOLE=/dev/console
SELINUX_INIT=YES
ROOTFS_FSTYPE=ext3
SHELL=/bin/sh
TERM=linux
ROOTFS_FSCK=0
LC_ALL=POSIX
INIT_VERSION=sysvinit-2.86
REDIRECT=/dev/tty1
COLUMNS=124
PATH=/bin:/sbin:/usr/bin:/usr/sbin
vga=0x317
DO_CONFIRM=
RUNLEVEL=5
resume=/dev/disk/by-id/scsi-3600508e00000000075fcb5123f95e409-part1
PWD=/
SPLASHCFG=/etc/bootsplash/themes/SLES/config/bootsplash-1024x768.cfg
PREVLEVEL=N
LINES=44
HOME=/
SHLVL=2
splash=silent
SPLASH=yes
ROOTFS_BLKDEV=/dev/disk/by-id/scsi-3600508e00000000075fcb5123f95e409-part2
_=/sbin/startproc
DAEMON=/usr/sbin/nscd
]
done
<notice – Apr 10 22:14:02.847597000>
‘nscd start’ exits with status 0

<notice – Apr 10 22:14:02.866671000>
xendomains start

Restoring Xen domains: vm1-oes
An error occurred while restoring domain vm1-oes:
Error: Domain ‘vm1-oes’ already exists with ID ‘1’
!

There’s obviously an issue restoring the operation of domain vm1-oes because it can see it already exists.

How do I solve this? [I’m getting ready to blow it all away and install SLES12SP2…]
Jerome