boot.compliance fails on SLES 11 SP2 boot

SUSE Linux Enterprise Server SLES Install-Boot
1

On every SLES 11 SP2 server, the “boot.compliance” service fails on boot. Many times we get a “Press any key to proceed with booting” message.

I see that /etc/init.d/boot.compliance is new in SP2. This script calls /usr/bin/isCompliant, but when run from the shell I get:

Can't locate SUSE/Corral.pm in @INC (@INC contains: /usr/local/perl-5.12.3/lib/site_perl/5.12.3/x86_64-linux /usr/local/perl-5.12.3/lib/site_perl/5.12.3 /usr/local/perl-5.12.3/lib/5.12.3/x86_64-linux /usr/local/perl-5.12.3/lib/5.12.3 .) at /usr/bin/isCompliant line 21. BEGIN failed--compilation aborted at /usr/bin/isCompliant line 21.

As you can see, this is because we have a custom perl build that does not have this perl module installed, so thus isCompliant fails on boot. I could install this perl module, but I’m trying to understand what the heck this boot.compliance is there for anyway. There is zero documentation about it, from what I find on Google.

Per /etc/init.d/boot.compliance:

[CODE]# This script checks if the installation was done in a VMware vSphere

environment. If not, a message will be displayed during each boot process

warning the user he’s in an unsupported state.[/CODE]

Some of our servers are VMs and some are physical servers. So, why does this service even get installed when I upgrade to SP2 on a physical server?

2

ashbyj wrote:
[color=blue]

So, why
does this service even get installed when I upgrade to SP2 on a
physical server?[/color]

Just a thought…

Are you using VMware’s version of SLES?

–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are using the web interface,
show your appreciation and click on the star below…

3

Hi Kevin,

No I’m not using any VMware-specific version of SLES. I’m using an iso I downloaded from the SuSE website. I thought at first that it was part of VMware tools, but /etc/init.d/boot.compliance shows up on bare metal installs as well.

4

chkconfig boot.compliance off
and forget it :slight_smile:
However I don’t like tampering with system packages - if I’d use a different perl (I wouldn’t) I’d put it into a separate installation dir and not replace the original.

5

Yep thats what I ended up doing, turning it off completely. We’ve never had an issue with moving the original /usr/bin/perl and then symlinking it to our custom version, but I think you make a good point.