On 11/18/2015 09:51 AM, Eero Volotinen wrote:> strace -f -e open software_binary might help, but I have noticed that
> Centos is not really 100% binary compatible in some cases.
CentOS Linux is not 100% bit for bit compatible with RHEL in ANY cases :)
CentOS and RHEL are built from mostly the same source code (we remove RH
trademarks and take out RHN update pieces).
But RHEL source code is rebuilt on RHEL in the Red Hat isolated build
system .. and CentOS Linux is built CentOS in our isolated build system.
Red Hat does not always release everything in their build system (they
might do 2 or 3 versions before they release something). We only have
things they released (and we built) in our build system.
That means almost every single compiled binary file is 'not exactly' the
same (on a bit for bit basis) when compared between CentOS Linux and RHEL.
Thanks,
Johnny Hughes
>
>
>
> --
> Eero
>
> 2015-11-18 17:42 GMT+02:00 Matt Garman <matthew.garman at gmail.com>:
>
>> I always tell vendors I'm using RHEL, even though we're using
CentOS.
>> If you say CentOS, some vendors immediately throw up their hands and
>> say "unsupported" and then won't even give you the time
of day.
>>
>> A couple tricks for fooling tools into thinking they are on an actual
>> RHEL system:
>> 1. Modify /etc/redhat-release to say RedHat Enterprise Linux or
>> whatever the actual RHEL systems have
>> 2. Similarly modify /etc/issue
>>
>> Another tip that has proven successful: run the vendor tool under
>> strace. Sometimes you can get an idea of what it's trying to do
and
>> why it's failing. This is exactly what we did to determine why a
>> vendor tool wouldn't work on CentOS. We had modified
>> /etc/redhat-release (as in (1) above), but forgot about /etc/issue.
>> Strace showed the program existing immediately after an open() call to
>> /etc/issue.
>>
>> Good luck!
>>
>>
>>
>>
>> On Wed, Nov 18, 2015 at 9:24 AM, Michael Hennebry
>> <hennebry at web.cs.ndsu.nodak.edu> wrote:
>>> On Wed, 18 Nov 2015, Birta Levente wrote:
>>>
>>>> I have a supermicro server, motherboard is with C612 chipset
and beside
>>>> that with LSI3108 raid controller integrated.
>>>> Two Intel SSD DC S3710 200GB.
>>>> OS: Centos 7.1 up to date.
>>>>
>>>> My problem is that the Intel SSD Data Center Tool (ISDCT) does
not
>>>> recognize the SSD drives when they connected to the standard
S-ATA
>> ports on
>>>> the motherboard, but through the LSI raid controller is
working.
>>>>
>>>> Does somebody know what could be the problem?
>>>>
>>>> I talked to the Intel support and they said the problem is that
Centos
>> is
>>>> not supported OS ... only RHEL 7.
>>>> But if not supported should not work on the LSI controlled
neither.
>>>
>>>
>>> Perhaps the tool looks for the string RHEL.
>>> My recollection is that when IBM PC's were fairly new,
>>> IBM used that trick with some of its software.
>>> To work around that, some open source developers used the string
"not
>> IBM".
>>> I think this was pre-internet, so google might not work.
>>>
>>> If it's worth the effort, you might make another
"CentOS" distribution,
>>> but call it "not RHEL".
>>>
>>> --
>>> Michael hennebry at web.cs.ndsu.NoDak.edu
>>> "Sorry but your password must contain an uppercase letter, a
number,
>>> a haiku, a gang sign, a heiroglyph, and the blood of a
virgin."
>>> --
>> someeecards
>>> _______________________________________________
>>> CentOS mailing list
>>> CentOS at centos.org
>>> https://lists.centos.org/mailman/listinfo/centos
>> _______________________________________________
>> CentOS mailing list
>> CentOS at centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20151118/0dc836b4/attachment-0001.sig>