I have a few machines that all run a coreos version that has not been updated for a while - they are on 34 still - but I do not seem to manage to work around the following problem.
When I upgrade, I get the error
error: Executing %transfiletriggerin for glibc-common: Package 'glibc-common' has (currently) unsupported <lua> script in '%transfiletriggerin'
I found online that there is a fixed version of rpm-ostree that will circumvent this problem, but I do not know how to get it on my system.
Any suggestions of a way how to proceed without reinstalling the machines?
This sort of problem is why it is strongly recommended to do routine upgrades so things stay current and one does not have major version conflicts.
Can you upgrade one level at a time as is recommended as the normal upgrade procedure?
This involves upgrading to the latest for the currently running version, then upgrade to the next release version.
If that does not work then it may be necessary to do a full reinstall.
We have an issue in our issue tracker for this but IIUC it only ever affected our rawhide stream (which is a development stream that no one should be running) and not our production streams.
I’m not sure how you got your system into this position. Can you share the output of rpm-ostree status?
Also I’m interested: is it your intention to stay on old Fedora releases or to stay up to date and this is blocking the system from coming up to date?
Yes. For Fedora CoreOS we recommend people leave automatic upgrades enabled.
This isn’t necessary. In Fedora CoreOS we have an upgrade graph, which will instruct the system on the next safe upgrade path to take. From 34 the system will hop through a few “barriers” but it will eventually end up on the latest version.
I did not realize the role of the dependency graph - only had to remove the manually added openjdk and the system moved forward.
Now only need to find out how to configure the zincati locking manager for cluster wide updates. (The machines for a hadoop cluster that should not just randomly upgrade any node any time.)
I have shared the status from a different node in the cluster, as, the good news: this one is now updated! I only need to do something about cgroups still.
[core@X ~]$ sudo rpm-ostree status --verbose
State: busy
AutomaticUpdatesDriver: Zincati (zincati.service)
DriverState: active; found update on remote: 34.20210611.3.0
Transaction: deploy --lock-finalization revision=0bdf0aee2585cafb224be19eec3b77501cb2044f028cf43a78f4de7ebd7c1a47 --disallow-downgrade
Initiator: caller :1.49
Deployments:
* ostree://fedora:fedora/x86_64/coreos/stable
Version: 34.20210427.3.0 (2021-05-18T08:56:57Z)
BaseCommit: b4b2199ec09b9e4200024b52062b119035a06b3ffc27b4268c5b8c3aa6fcde17
`- fedora-coreos-pool (2021-05-18T08:33:01Z)
Commit: a0b24d540c4ecf57bb090ac663d676b6eb4450ee47091a6f7d8620f128260f78
|- fedora-cisco-openh264 (2021-02-23T00:49:00Z)
|- updates (2021-05-28T00:52:10Z)
`- fedora (2021-04-23T10:47:57Z)
Staged: no
StateRoot: fedora-coreos
GPGSignature: 1 signature
Signature made Tue May 18 11:00:13 2021 using RSA key ID 1161AE6945719A39
Good signature from "Fedora <fedora-34-primary@fedoraproject.org>"
LayeredPackages: java-1.8.0-openjdk-devel
ostree://fedora:fedora/x86_64/coreos/stable
Version: 34.20210427.3.0 (2021-05-18T08:56:57Z)
Commit: b4b2199ec09b9e4200024b52062b119035a06b3ffc27b4268c5b8c3aa6fcde17
`- fedora-coreos-pool (2021-05-18T08:33:01Z)
StateRoot: fedora-coreos
GPGSignature: 1 signature
Signature made Tue May 18 11:00:13 2021 using RSA key ID 1161AE6945719A39
Good signature from "Fedora <fedora-34-primary@fedoraproject.org>"
I think the problem with updating was eventually caused by the openjdk that I layered on top of the normal install - after removing it, and enabling zincati, it moved to the right version.
The node is part of an Hadoop cluster that I did not dare to be auto-updated. Then I found I had insufficient time to maintain it properly… until this week, when I was kind-a shocked to find we are this much behind already.
(I need to sort out the lock-managed upgrade procedure.)
So the problem has indeed been the rpm-ostree install of the OpenJDK version at the time conflicting somehow with the lua version that rpm-ostree expected:
Jul 25 20:20:51 rbdata10 zincati[4815]: [INFO ] target release '34.20210611.3.0' selected, proceeding to stage it
Jul 25 20:21:24 rbdata10 zincati[4815]: [ERROR] failed to stage deployment: rpm-ostree deploy failed:
Jul 25 20:21:24 rbdata10 zincati[4815]: error: Could not depsolve transaction; 1 problem detected:
Jul 25 20:21:24 rbdata10 zincati[4815]: Problem: conflicting requests
Jul 25 20:21:24 rbdata10 zincati[4815]: - package java-1.8.0-openjdk-devel-1:1.8.0.332.b09-1.fc34.x86_64 requires java-1.8.0-openjdk(x86-64) = 1:1.8.0.332.b09-1.fc34, but>
Jul 25 20:21:24 rbdata10 zincati[4815]: - package java-1.8.0-openjdk-devel-1:1.8.0.282.b08-4.fc34.x86_64 requires java-1.8.0-openjdk(x86-64) = 1:1.8.0.282.b08-4.fc34, but>
Jul 25 20:21:24 rbdata10 zincati[4815]: - package java-1.8.0-openjdk-1:1.8.0.332.b09-1.fc34.x86_64 requires java-1.8.0-openjdk-headless(x86-64) = 1:1.8.0.332.b09-1.fc34, >
Jul 25 20:21:24 rbdata10 zincati[4815]: - package java-1.8.0-openjdk-1:1.8.0.282.b08-4.fc34.x86_64 requires java-1.8.0-openjdk-headless(x86-64) = 1:1.8.0.282.b08-4.fc34, >
Jul 25 20:21:24 rbdata10 zincati[4815]: - package java-1.8.0-openjdk-headless-1:1.8.0.332.b09-1.fc34.x86_64 requires copy-jdk-configs >= 4.0, but none of the providers ca>
Jul 25 20:21:24 rbdata10 zincati[4815]: - package java-1.8.0-openjdk-headless-1:1.8.0.282.b08-4.fc34.x86_64 requires copy-jdk-configs >= 3.3, but none of the providers ca>
Jul 25 20:21:24 rbdata10 zincati[4815]: - package copy-jdk-configs-4.0-1.fc34.noarch requires /usr/bin/lua, but none of the providers can be installed
Jul 25 20:21:24 rbdata10 zincati[4815]: - package copy-jdk-configs-3.7-8.fc34.noarch requires /usr/bin/lua, but none of the providers can be installed
Jul 25 20:21:24 rbdata10 zincati[4815]: - package lua-5.4.4-1.fc34.x86_64 requires lua-libs = 5.4.4-1.fc34, but none of the providers can be installed
Jul 25 20:21:24 rbdata10 zincati[4815]: - package lua-5.4.2-2.fc34.x86_64 requires lua-libs = 5.4.2-2.fc34, but none of the providers can be installed
Jul 25 20:21:24 rbdata10 zincati[4815]: - package lua-5.4.4-1.fc34.i686 requires libm.so.6, but none of the providers can be installed
Jul 25 20:21:24 rbdata10 zincati[4815]: - package lua-5.4.4-1.fc34.i686 requires libm.so.6(GLIBC_2.0), but none of the providers can be installed
Jul 25 20:21:24 rbdata10 zincati[4815]: - package lua-5.4.4-1.fc34.i686 requires libm.so.6(GLIBC_2.29), but none of the providers can be installed
Jul 25 20:21:24 rbdata10 zincati[4815]: - package lua-5.4.4-1.fc34.i686 requires libc.so.6(GLIBC_2.11), but none of the providers can be installed
Jul 25 20:21:24 rbdata10 zincati[4815]: - package lua-5.4.2-2.fc34.i686 requires libm.so.6, but none of the providers can be installed
Jul 25 20:21:24 rbdata10 zincati[4815]: - package lua-5.4.2-2.fc34.i686 requires libm.so.6(GLIBC_2.0), but none of the providers can be installed
Jul 25 20:21:24 rbdata10 zincati[4815]: - package lua-5.4.2-2.fc34.i686 requires libm.so.6(GLIBC_2.29), but none of the providers can be installed
Jul 25 20:21:24 rbdata10 zincati[4815]: - package lua-5.4.2-2.fc34.i686 requires libc.so.6(GLIBC_2.11), but none of the providers can be installed
Jul 25 20:21:24 rbdata10 zincati[4815]: - lua-libs-5.4.4-1.fc34.i686 has inferior architecture
Jul 25 20:21:24 rbdata10 zincati[4815]: - lua-libs-5.4.2-2.fc34.i686 has inferior architecture
Jul 25 20:21:24 rbdata10 zincati[4815]: - glibc-2.33-21.fc34.i686 has inferior architecture
Jul 25 20:21:24 rbdata10 zincati[4815]: - glibc-2.33-5.fc34.i686 has inferior architecture
Jul 25 20:21:24 rbdata10 zincati[4815]: - cannot install both lua-libs-5.4.4-1.fc34.x86_64 and lua-libs-5.4.3-1.fc34.x86_64
Jul 25 20:21:24 rbdata10 zincati[4815]: - cannot install both lua-libs-5.4.2-2.fc34.x86_64 and lua-libs-5.4.3-1.fc34.x86_64
Jul 25 20:21:24 rbdata10 zincati[4815]: - cannot install both glibc-2.33-21.fc34.x86_64 and glibc-2.33-15.fc34.x86_64
Jul 25 20:21:24 rbdata10 zincati[4815]: - cannot install both glibc-2.33-5.fc34.x86_64 and glibc-2.33-15.fc34.x86_64