What is happening with my HAE install?

SUSE Linux Enterprise Server SLES Configure-Administer
1

I have been testing HAE for the past several days. I had a two node cluster
working but was having some issues getting pacemaker to kickoff the drbd
subsystem. After thumbing around on the internet it seemed that all of these
HA apps are under extensive code changes so I went ahead and got an eval
license so I could update my install to the latest code. That’s where
everything has gone quickly down the proverbial crapper.

After updating I now cannot launch DRBD YaST without it trying to reinstall
DRBD…which fails…and I have a chronic set of updates available with
dependency issues.

PackageKit Error dep-resolution-failed: nothing provides
kernel(default:fs_block_dev) = 6e299327513ae2ea needed by ocfs2-kmp-
default-1.4_2.6.32.19_0.2-4.11.5.i586 nothing provides
kernel(default:fs_block_dev) = 6e299327513ae2ea needed by drbd-kmp-
default-8.3.8.1_2.6.32.19_0.2-0.2.5.i586 nothing provides
kernel(default:net_core_dev) = 3ecbc45c7e9b0c3c needed by cluster-network-
kmp-default-1.4_2.6.32.13_0.5-2.3.9.i586 nothing provides
kernel(default:net_core_dev) = 3ecbc45c7e9b0c3c needed by cluster-network-
kmp-default-1.4_2.6.32.13_0.5-2.3.9.i586

Further I have a second set entries in GRUB which I did not have prior,
one with kernel-default and the other with kernel-PAE.

Any ideas on how to sort this?

Thanks.

2

[QUOTE=GofBorg]I have been testing HAE for the past several days. I had
a two node cluster working but was having some issues getting pacemaker
to kickoff the drbd subsystem. After thumbing around on the internet it
seemed that all of these HA apps are under extensive code changes so I
went ahead and got an eval license so I could update my install to the
latest code. That’s where everything has gone quickly down the
proverbial crapper.

After updating I now cannot launch DRBD YaST without it trying to
reinstall DRBD…which fails…and I have a chronic set of updates
available with dependency issues.

PackageKit Error dep-resolution-failed: nothing provides
kernel(default:fs_block_dev) = 6e299327513ae2ea needed by ocfs2-kmp-
default-1.4_2.6.32.19_0.2-4.11.5.i586 nothing provides
kernel(default:fs_block_dev) = 6e299327513ae2ea needed by drbd-kmp-
default-8.3.8.1_2.6.32.19_0.2-0.2.5.i586 nothing provides
kernel(default:net_core_dev) = 3ecbc45c7e9b0c3c needed by
cluster-network- kmp-default-1.4_2.6.32.13_0.5-2.3.9.i586 nothing
provides kernel(default:net_core_dev) = 3ecbc45c7e9b0c3c needed by
cluster-network- kmp-default-1.4_2.6.32.13_0.5-2.3.9.i586

Further I have a second set entries in GRUB which I did not have prior,
one with kernel-default and the other with kernel-PAE.

Any ideas on how to sort this?

Thanks.
[/QUOTE]
Hi
Which kernel are you running (uname -a), might have switched to pae,
hence the conflict? Else the modules installed don’t match your running
kernel.

If you have updated, my SLES 11 SP1 install is on 2.6.32.49-0.3 so you
would need to get the matching kmp’s for your kernel.

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.13-0.19-default
up 17:50, 2 users, load average: 0.06, 0.03, 0.05
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU

3

Which kernel are you running (uname -a), might have switched to pae,[color=blue]
hence the conflict?[/color]

I was running at the time of the update,

Linux 2.6.32.12-0.7-default #1 SMP 2010-05-20 11:14:20 +0200 i686 i686 i386
GNU/Linux

I have two boot entries on node 2 (excluding the failsafe modes), default
and the other is pae.

Interestingly, node 1 did not get the multi kernel choice added to the
boot list but defaulted to pae, although node1 is in no better shape than
node 2 with regards to this newfound dependency problem.

It does not matter if I boot node 2 using either kernel, the update
dependency problems persist.

Less than impressed at the moment.

4

[QUOTE=GofBorg]> Which kernel are you running (uname -a), might have
switched to pae,[color=blue]

hence the conflict?[/color]

I was running at the time of the update,

Linux 2.6.32.12-0.7-default #1 SMP 2010-05-20 11:14:20 +0200 i686 i686
i386 GNU/Linux

I have two boot entries on node 2 (excluding the failsafe modes),
default and the other is pae.

Interestingly, node 1 did not get the multi kernel choice added to the
boot list but defaulted to pae, although node1 is in no better shape
than node 2 with regards to this newfound dependency problem.

It does not matter if I boot node 2 using either kernel, the update
dependency problems persist.

Less than impressed at the moment.

[/QUOTE]
Hi
So what kernel is running at the moment?

You have ocfs2-kmp-default and drbd-kmp-default for a 2.6.32.19_0.2
kernel and cluster-network-kmp-default for a 2.6.32.13_0.5 kernel

All are default, if you look in /lib/modules/ what kernels are listed?

All of those kmp’s are external modules so I’m assuming pulled in from
a repository, can you post the output from;

zypper lr

You might also want to have a look at /boot/grub/menu.lst to see what’s
being called as well.

Check the versions installed, and the repositories they are from via;

zypper if ocfs2-kmp-default

If your running pae, then boot to default, then try updating the modules;

zypper up ocfs2-kmp-default drbd-kmp-default cluster-network-kmp-default

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.13-0.19-default
up 1 day 17:57, 2 users, load average: 0.01, 0.03, 0.05
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU

5

Well, I gave up on that mess and reverted to a previous VM snapshot.

This is what I did that invoked the whole mess.

  1. I had installed SLES11 SP1 and did not configure online update.
  2. I downloaded and installed the add-on product SLES 11 HAE.
  3. I configured a cluster, set up a few apps and ran into some issues when
    working with DRBD and I thought that perhaps an update might sort them out
    so I signed up for an eval license for SLES11 and HAE.
  4. I let SLES and HAE configure their online update repositories.
  5. I updated.
  6. I ended up with various kernels being installed other than the original
    ‘default’ that I had when this all began.
  7. I ended up with dependency errors based on the kernel games.

All I did was follow the path set forth by the series of events above. I
did not play any games with repositories ror the installation.

I would try it again except I would anticipate the same result seeing that I
had problems out of both VM’s that I tested it on.

I am virtualizing my tests on VMware Workstation 8.0.1.