boot.compliance fails on SLES 11 SP2 boot

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?

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…

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.

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.

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.