On 2/25/11 8:40 AM, Mark Hatle wrote:
> On 2/24/11 10:41 PM, Jeff Johnson wrote:
>>
>> On Feb 24, 2011, at 11:14 PM, Mark Hatle wrote:
>>
>>> I'm trying to validate prelinked binaries and I'm getting a somewhat
>>> strange result:
>>>
>>> ........ /bin
>>> S.?..... /bin/bash
>>> ........ /bin/bashbug
Ok, I've done more digging. If I run this within gdb, I'm suddenly seeing an
error message appear on the screen:
prelink: Couldn't write file to standard output: Broken pipe
S.?..... <filename>
However, if I use gdb and step through the fork/exec in rpmdb/legacy.c at around
like 128.. I don't get the error message -- and it comes back with a "." for a
valid md5um. (If I run this without GDB, I get the '?' and no error message
from prelink.)
So it looks like we have some type of pipe issue.
Any suggestions?
>>> The macro setting being used is:
>>>
>>> %__prelink_undo_cmd /usr/sbin/prelink prelink -y library
>>>
>>> I'm not sure what the '?' indicates, but I suspect it's some type of a
>>> failure
>>> to get the information from the prelinker.
>>>
>>
>> Hmmm ... I'm pretty sure prelink affects only libraries, not executables.
>> It has been years ...
>
> Prelink affects any ELF executable. But it doesn't do much good on
> executables
> unless the libraries are already prelinked... All the prelinker does is
> predefine the ELF relocations so that ld.so doesn't need to compute them at
> load
> time. (ld.so does however still have a check the relocations are valid, if
> they're not then it falls back to the old way of computing them all at load
> time.)
>
>>> I have a strong suspicion the problem is actually on the prelink side --
>>> but I'm
>>> not sure how to debug what RPM is doing that is ending up with the '?'.
>>>
>>
>>> So first question -- what does the '?' indicate? Second, is there any
>>> debugging
>>> available that can help me understand what type of output the prelinker may
>>> be
>>> sending back to RPM so I can diagnose what may be wrong there?
>>>
>>
>> ? == indeterminate like 700 root.root read by non-root.
>
> I'm wondering if the pipe closed early (i.e. prelink didn't actually return
> any
> data..)
>
>> rpm is just trying to verify a digest on plaintext.
>>
>> Usually its just the content as plaintext.
>>
>> But prelink alters the content, so the digest has to be run off a pipe
>> to prelink undo.
>>
>> prelink has builtin sha1/md5 options: try those.
>
> I have run those, and I'm getting the results that I believe are correct.
> This
> is why I'm not sure whats going wrong -- but I still suspect it's on the
> prelink
> side of thins.
>
>> And you can use /usr/bin/{md5sum.sha1sum,sha256sum} with prelink undo
>> to duplicate exactly what rpm should be doing.
>>
>> Extract the digest and compare with the manual results.
>>
>> I hope you're not putting prelinked content in a *.rpm. That has
>> a really obscure failure mode because rpmbuild assumes unprelinked
>> plaintext which prelink undo tries to restore. If the content
>> was already prelinked, then the digest will never match.
>
> Nope, the prelinker is run after the filesystem is constructed...
>
> --Mark
>
>> But that doesn't sound like your problem, and its libraries, not executables,
>> affected by prelink I'm almost certain (run readelf -a to tell whether
>> prelinked
>> or not. compare with the check implemented).
>>
>> hth
>>
>> 73 de Jeff
>
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
