1

I upgraded from Debian 10 to 11 one week ago.

The recurring error is:

symbol lookup error: /lib/systemd/libsystemd-shared-247.so: undefined symbol: seccomp_api_get

It caused a kernel panic when booting the system.

I had to switch to systemv as the init system.

Now, when I try to restore systemd, I have the following error:

root@nas:~# apt install systemd
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
systemd is already the newest version (247.3-6).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Setting up systemd (247.3-6) ...
systemd-machine-id-setup: symbol lookup error: /lib/systemd/libsystemd-shared-247.so: undefined symbol: seccomp_api_get
dpkg: error processing package systemd (--configure):
 installed systemd package post-installation script subprocess returned error exit status 127
Errors were encountered while processing:
 systemd
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

My versions:

root@nas:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:    11
Codename:   bullseye
root@nas:~# uname -a
Linux nas 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux

1 Answer 1

4

I found a solution here:

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). […]

The new libseccomp2 package shipped new binaries to /usr/lib/x86_64-linux-gnu but the runtime loader loaded the old version in /lib/x86_64-linux-gnu. […]

The problem disappears if either I remove the old libs from /lib/x86_64-linux-gnu

So I deleted these files:

rm /lib/x86_64-linux-gnu/libseccomp.so.2*

And I was able to switch back to Systemd.

How to check it

You can use dpkg --search and it will tell if a file or directory is orphaned:

dpkg --search /lib/x86_64-linux-gnu/libseccomp.so.2
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libseccomp.so.2

You can find files without corresponding packages with cruft-ng: How to find files that are not owned by any package?


Update

There is a symlink between /lib/x86_64-linux-gnu/ and /usr/lib/x86_64-linux-gnu/, so search in both directories before deciding to remove something.

I ran dpkg --search /usr/lib/terminfo/ and it returned a warning, so I removed the directory and it midly broke the CLI, because it is in fact a dependency of ncurses-base.

Searching in /usr/lib/ and /lib/ gives the package that own this directory.

dpkg --search /usr/lib/terminfo/ /lib/terminfo/
dpkg-query: no path found matching pattern /usr/lib/terminfo/
ncurses-base: /lib/terminfo

So we must not rely on one search from dpkg --search to decide if it's safe to remove data.

1
  • 1
    Thank you. I was upgrading an old netgear readynas box and sudo rm /lib/*/libseccomp.so.2* did the trick for me.
    – hexmode
    Jan 11, 2022 at 22:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .