Open jmarrero opened 1 year ago
Any quick and fast way to resolve this or remove the example for now?
No luck with an upgrade using: https://bodhi.fedoraproject.org/updates/FEDORA-2022-a82842a059 either:
Last login: Thu Dec 15 20:40:26 on ttyS0
Fedora CoreOS 37.20221106.3.0
systemctl: error while loading shared libraries: libsystemd-shared-251.7-611.fc37.so: cannot open shared object file: No such file or directory
[core@tutorial ~]$ sudo reboot
reboot: error while loading shared libraries: libsystemd-shared-251.7-611.fc37.so: cannot open shared object file: No such file or directory
[core@tutorial ~]$
What seems to be happening is that for some reason the /usr/bin/systemctl
is left at the old version. Doing rpm --reinstall https://kojipkgs.fedoraproject.org//packages/systemd/251.6/609.fc37/x86_64/systemd-251.6-609.fc37.x86_64.rpm
fixes it here.
# rpm -V systemd|grep -Fv '.......T.' | grep -v missing
....L.... /usr/lib/systemd/system/default.target
# rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2022-bb55f82158
...
(apparent success)
...
# sha256sum /usr/bin/systemctl
acac0aa21c430381bf7e4bcb48f1e85d8d1cd0530b6ee682e1d47cee725aefd4 /usr/bin/systemctl
# rpm -V systemd|grep -Fv '.......T.' | grep -v missing
..5....T. /usr/bin/systemctl
#
So it's just somehow only that binary...
Oh man, of course...the problem is our cliwrap logic again...we're swapping it back to the old binary. To handle this, I think we may need to detect the case where /usr/bin/systemctl
got swapped back, and then just delete the old version.
thanks for the workaround here is in a PR: https://github.com/coreos/layering-examples/pull/50 Lets leave this issue open while we get a proper fix in rpm-ostree to remove the workaround then.
I updated the example because it was no longer building but to build I needed to remove /var/libs
/var/libs content I imagine was important?