Major Description
Dynamic CDS dumps seem to include some property in its base-archive CRC calculation which seems to break when installing the same JDK in multiple containers. In other words, creating a CDS dump in one image and using the result in another fails with this:
An error has occurred while processing the shared archive file. Dynamic archive cannot be used: static archive header checksum verification failed. Error occurred during initialization of VM Unable to use shared archive.
In my case, it's the JDK from the ubi8/openjdk-17 image and the ubi8/openjdk-17-runtime image. They have both the very same RPM package, thus JDK, installed: java-17-openjdk-headless-17.0.7.0.7-1.el8_7.x86_64
Steps to reproduce:
$ cat Dockerfile.maven FROM fedora:37 RUN dnf install -y maven java-17-openjdk-devel && dnf clean all RUN mkdir /stuff RUN useradd someuser RUN chown -R someuser /stuff USER someuser COPY HelloWorld.java /stuff RUN cd /stuff && javac HelloWorld.java RUN cd /stuff && java -XX:ArchiveClassesAtExit=app-cds.jsa HelloWorld WORKDIR /stuff ENTRYPOINT [ "mvn" ] $ podman build -t fedora-maven-pkg:1.0 -f Dockerfile.maven $ podman run --rm -ti fedora-maven-pkg:1.0 --version Apache Maven 3.8.5 (Red Hat 3.8.5-3) Maven home: /usr/share/maven Java version: 17.0.6, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-1.fc37.x86_64 Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux", version: "6.2.12-200.fc37.x86_64", arch: "amd64", family: "unix" $ cat Dockerfile.java FROM fedora:37 RUN dnf install -y java-17-openjdk-headless && dnf clean all ENTRYPOINT [ "java" ] $ podman build -t fedora-java-pkg:1.0 -f Dockerfile.java $ podman run --rm -ti fedora-java-pkg:1.0 --version openjdk 17.0.6 2023-01-17 OpenJDK Runtime Environment (Red_Hat-17.0.6.0.10-1.fc37) (build 17.0.6+10) OpenJDK 64-Bit Server VM (Red_Hat-17.0.6.0.10-1.fc37) (build 17.0.6+10, mixed mode, sharing) $ cat Dockerfile.multistage FROM fedora-maven-pkg:1.0 as maven RUN echo "In maven stage" \ && ls -l /stuff/ FROM fedora-java-pkg:1.0 as final RUN mkdir /stuff RUN useradd someuser RUN chown -R someuser /stuff COPY --from=maven /stuff/app-cds.jsa /stuff COPY --from=maven /stuff/HelloWorld.class /stuff WORKDIR /stuff RUN echo "In final stage" \ && ls -l /stuff/ ENTRYPOINT [ "java", "-Xshare:on", "-XX:SharedArchiveFile=app-cds.jsa", "HelloWorld" ] $ podman build -t app-cds-runtime:1.0 -f Dockerfile.multistage $ podman run --rm -ti app-cds-runtime:1.0 An error has occurred while processing the shared archive file. Dynamic archive cannot be used: static archive header checksum verification failed. Error occurred during initialization of VM Unable to use shared archive.
Additional info:
Note that the problem goes away if a) a static CDS dump is being done instead (in that case the base archive is not needed and, thus, doesn't fail. b) if I change the Dockerfile.maven so that it inherits from fedora-java-pkg:1.0, therefore not performing a new install of java-17-openjdk-headless package. This yields me to believe it's some timestamp issue involved when java-17-openjdk-headless is installed in two separate containers.
I wasn't able to reproduce this without RPMs involved, so I'm filing this bug here for now. Maybe this is a packaging bug, maybe an upstream issue.
Like i said previously, I've originally observed this issue when trying to do a proof of concept of an AppCDS quarkus workflow as follows, which should work but unfortunately doesn't due to this bug.
- Build a Quarkus application - including a dynamic CDS dump - using the UBI 8 openjdk-17 image: registry.access.redhat.com/ubi8/openjdk-17 (s2i workflow)
- Use the resulting binaries to transplant them to a runtime image (no maven needed in the runtime image; all that good stuff) based on registry.access.redhat.com/ubi8/openjdk-17-runtime
- Run the app using the container image produced in step 2
