Am 15.11.19 um 11:30 schrieb Sorin Manolache:
> As a side, I think having systemd depend on libraries deployed in /usr
> is a bad idea. More generally, using tools (e.g. /usr/bin/find) in the
> pre-mount phase of the boot process that either are deployed in /usr or
> depend on libs in /usr is, in
On 14/11/2019 21.31, Michael Biebl wrote:
Am 14.11.19 um 20:26 schrieb Sorin Manolache:
I copy the new binaries from
/usr/lib/x86_64-linux-gnu to /lib/x86_64-linux-gnu.
Please don't do that. The only reasonable solution is to remove any
stale libraries you have copied/installed manually.
I
On Thu, Nov 14, 2019 at 11:48:14PM +0100, Michael Biebl wrote:
> Is this a system that has been restored from a backup?
It never was.
> Maybe some usr-merge related oddity.
> Michael
This system was originally installed as jessie long time ago and according
to versions of orphaned libraries it
Am 14.11.19 um 20:26 schrieb Sorin Manolache:
> I had the same problem. The cause were some old libs in
> /lib/x86_64-linux-gnu, especially a libseccomp. They are not
> package-managed (i.e. they don't belong to any package). I have copied
> them manually from /usr/lib/x86_64-linux-gnu to
Am 14.11.19 um 23:27 schrieb Jan Sindelar:
> Actually I have found a bunch of libraries not owned by any package
> (according to dpkg) in this directory and I am pretty sure I never manually
> copied them. Clearly this bug is not related to systemd, but I am not sure
> where should I report it.
On Thu, Nov 14, 2019 at 10:52:50PM +0100, Michael Biebl wrote:
> Hi,
> I suppose
> dpkg -S /lib/x86_64-linux-gnu/libseccomp.so.2
> yields nothing.
Hello,
preciselly right, there was stalled version of libseccomp.so.2 in
/lib/x86_64-linux-gnu and
Hello,
On Thu, Nov 14, 2019 at 05:19:32PM +0100, Michael Biebl wrote:
> Am 14.11.19 um 17:16 schrieb Michael Biebl:
> > For the failing binary, please run
> > ldd /path/to/binary
> > and attach the output to this bug report.
> I see from your systemd-delta.txt output:
> systemd-delta: symbol
Am 14.11.19 um 20:26 schrieb Sorin Manolache:
I copy the new binaries from
> /usr/lib/x86_64-linux-gnu to /lib/x86_64-linux-gnu.
Please don't do that. The only reasonable solution is to remove any
stale libraries you have copied/installed manually.
You might have to run ldconfig afterwards.
--
On Thu, 14 Nov 2019 17:19:32 +0100 Michael Biebl wrote:
Am 14.11.19 um 17:16 schrieb Michael Biebl:
> For the failing binary, please run
> ldd /path/to/binary
>
> and attach the output to this bug report.
I see from your systemd-delta.txt output:
systemd-delta: symbol lookup error:
Control: severity -1 normal
Am 14.11.19 um 13:22 schrieb Jan Sindelar:
> Package: systemd
> Version: 243-5
> Severity: critical
> Justification: breaks the whole system
>
> Dear Maintainer,
>
>* What led up to the situation?
> Installing latest systemd package using apt full-upgrade in
Am 14.11.19 um 17:16 schrieb Michael Biebl:
> For the failing binary, please run
> ldd /path/to/binary
>
> and attach the output to this bug report.
I see from your systemd-delta.txt output:
systemd-delta: symbol lookup error:
/lib/systemd/libsystemd-shared-243.so: undefined symbol:
Control: tags -1 + moreinfo
Am 14.11.19 um 13:22 schrieb Jan Sindelar:
> Package: systemd
> Version: 243-5
> Severity: critical
> Justification: breaks the whole system
>
> Dear Maintainer,
>
>* What led up to the situation?
> Installing latest systemd package using apt full-upgrade in
Package: systemd
Version: 243-5
Severity: critical
Justification: breaks the whole system
Dear Maintainer,
* What led up to the situation?
Installing latest systemd package using apt full-upgrade in testing
* What exactly did you do (or not do) that was effective (or
ineffective)?
13 matches
Mail list logo
