View Full Version : boot.compliance fails on SLES 11 SP2 boot

02-May-2012, 15:38
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:

# 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.

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?

02-May-2012, 17:06
ashbyj wrote:

> So, why
> does this service even get installed when I upgrade to SP2 on a
> physical server?

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...

08-May-2012, 14:15
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.

10-May-2012, 08:55
chkconfig boot.compliance off
and forget it :-)
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.

10-May-2012, 13:19
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.