-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi,
Am Mo den 24. Nov 2014 um 14:03 schrieb Mattia Rizzolo: > On Thu, Oct 16, 2014 at 12:35 PM, Klaus Ethgen <[email protected]> wrote: > > The new eatmydata put the .so file to another location so while > > upgrading the system, there will be many of the following error messages > > when apt is run with eatmydata: > > I feel you are doing something really wrong in using apt with eatmydata. I > hope you will not blame someone different to yourself if some bad things > occur to your system. Well, I would like to do it without eatmydata. Unfortunately is apt (or dpkg) does a to aggressive sync orgy. In my setup (not to slow disks but no SSD) a a bit bigger upgrade takes far over 30 minutes where it take only 1 or 2 minutes with eatmydata. The risk that something goes wrong in 30 minutes is much higher than in 1 minute. I also like more the kernel to know about what should be written to disk. I read somewhere about an idea to have a command line switch to apt and/or dpkg to not sync that aggressive while an upgrade. That would be a real good idea. Finally, what do you think, eatmydata was originally the reason for? It was exactly the complete crazy sync orgies in apt. (That is what I heard about.) > > ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from > > LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. > > > > The upgrade process should put a link in the old location and remove it > > only if LD_PRELOAD is populated with the new location. > > Well, this would mean change the content of LD_PRELOAD of a running process > (apt and children), not something wise to do. Actually the content of > LD_PRELOAD is changed once you restart apt, not before. > I could drop a symlink, but when I'm going to remove it? I can't think of > anything sane to do here. Well, doesn't matter if the content changes as the process will have the old (now deleted) file still opened. The problem are new spawned processes who cannot find the libraries in LD_PRELOAD. A symlink is great here. It is even easy to check if that path is still in LD_PRELOAD. If not, that can be deleted safely. > Either way, I'd be for just ignore the warning and go ahead. I'll think it > better, but currently I'm overload. That might be ok for me too. It is only scarring first seeing that error. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBCgAGBQJUcz07AAoJEKZ8CrGAGfasxzUL/RDz9nbYaxRHbkevblfzZprG OXQdRNFPqmpZ/dFbxGbOTY2y3NyVNZqo0buLf+oQa57uvb/gd+bjXHEsQY5b3zXb E8/9BZvPvg1P9Sm7ruy/hityugSZtIdJ8fnQsgQJPlqX/PX3O+1RTM1PIjcVFVM9 13163fmVeOKS4F5SZVkjffsa6rmRSkz0Ag1mTWIKnp1MKNvUlW+n7ov0NzRH5/RK OTguTH/Jfsd8lyHIVTWwE165iVBXylP/1rdh91uvDVJ7R0FCcRuvwSZGm/NktGpc BXd2qBBzcSLzxOhP3HEf8XPykGTCVfhssnOghuokFlSJVEzv1fjDvf0k7AR5Lu27 j0w25oNko9aNkml6C+mCdWXriagm+QPIjFEMyTqv0fAcV8LMSgM/9LMDrw7IF6SR KHEzNlLkCV5U8J6GkFRVQsFP3STKbTLOjCMgf96liNW2q0E1vcEgsNq5Zlqfjm5l LMI83o4IoTa3RT6bLh6jWsEqcYF8k/dnihLzBfTBSQ== =5B7l -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
