Then what is happening is probably that the chroot doesn't contain
libeatmydata.so; installing libeatmydata1 (or eatmydata itself if that's
easier for you, even if there is no need for the /use/bin/eatmydata that is
shipped by it) *inside* the chroot should take care of the error, and make
eatmydata do its work.
If you can confirm that's the issue please close this bug (or just confirm
and I'll close it).
Thank you!
On Fri, 24 Aug 2018, 10:27 a.m. Шлыков Василий, <vasi...@shlykov.info>
wrote:
> Hi, Mattia!
>
> Yes, you are right. I checked again eatmydata and found that error
> message due to chroot use.
>
> On 8/24/18 1:31 AM, Mattia Rizzolo wrote:
> > Control: tag -1 unreproducible moreinfo
> >
> > On Wed, Aug 22, 2018 at 03:39:14PM +0300, Vasiliy Shlykov wrote:
> >> script eatmydata provided by the package has a serious bug.
> > Please, consider that this package has been in that state for nearly 2
> > years; with so many users somebody else would have noticed such a
> > serious bug.
> >
> >> The symptom: running command with eatmydata script produces message:
> >> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be
> preloaded (cannot open shared object file): ignored.
> > Can't reproduce here.
> >
> > mattia@warren ~ % eatmydata true
> > mattia@warren ~ %
> >
> >
> >> Obviously, this happens due to using wrong path and name of the library:
> >>
> LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+"$LD_LIBRARY_PATH:"}/usr/lib/libeatmydata
> >> LD_PRELOAD=${LD_PRELOAD:+"$LD_PRELOAD "}libeatmydata.so
> >>
> >> Dir /usr/lib/libeatmydata doesn't exists and file libeatmydata.so
> doesn't exists too.
> > That's false.
> > For starters, libeatmydata.so sure does exist, in
> > /usr/lib/x86_64-linux-gnu/libeatmydata.so shipped by the package
> > libeatmydata1, which is depended by eatmydata.
> > Secondly, /usr/lib/libeatmydata used to exist, and is there to support
> > loading the library from such legacy location (think abount having this
> > script wrapping around a chroot call, etc).
> http://bugs.debian.org/765810
> > Also the manpage contains this information.
> > And anyway, adding random directories to LD_LIBRARY_PATH wouldn't
> > automatically trigger such "bug".
> >
> >
> > So, I think you should check your environment and the program you are
> > then calling (as something programs mangle LD_LIBRARY_PATH and
> > LD_PRELOAD themselves).
> > If you can't figure what's going on, please consider sharing more
> > details about your situation.
> >
>
