Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spring Boot bootBuildImage fails with Invalid response received when loading image #1392

Closed
Ch4s3r opened this issue May 15, 2024 · 12 comments
Closed
Labels
type:question A user question

Comments

@Ch4s3r
Copy link

Ch4s3r commented May 15, 2024

Cannot build docker image with spring boot's bootBuildImage, when adding the latest java buildpack (13.0.1).

Expected Behavior

A docker image is created.

Current Behavior

./gradlew clean bootBuildImage results in Invalid response received when loading image "pack.local/builder/voglnshknh:latest"

Steps to Reproduce

  1. (Code can also be found at: https://github.com/Ch4s3r/bootbuildimage-arm)
  2. Create new spring project with Gradle and Kotlin using JDK21
  3. Add java buildpack in version 13.0.1
  4. Execute ./gradlew clean bootBuildImage

Motivations

Wanted to try out the fix for activeprocessorcount and the this build is the first one for dual stack support with arm and this could be related.
Device used: M3 aarch64

@Ch4s3r Ch4s3r changed the title Spring Boot bootBuildImage fails on arm Spring Boot bootBuildImage fails with 13.0.1 May 15, 2024
@Ch4s3r Ch4s3r changed the title Spring Boot bootBuildImage fails with 13.0.1 Spring Boot bootBuildImage fails with Invalid response received when loading image May 15, 2024
@Ch4s3r Ch4s3r changed the title Spring Boot bootBuildImage fails with Invalid response received when loading image Spring Boot bootBuildImage fails with Invalid response received when loading image May 15, 2024
@dmikusa
Copy link
Contributor

dmikusa commented May 15, 2024

./gradlew clean bootBuildImage results in Invalid response received when loading image "pack.local/builder/voglnshknh:latest"

I don't think that's related to arm. It seems to be having trouble fetching an image, but it's not clear from this message. Can you include the full build output?

Other things you might want to try to troubleshoot:

  • Clear out the images/cache/etc... from Docker. docker system prune --volumes can be helpful. That should remove any old volumes, which can sometimes cause trouble.
  • Try using pack build and see if you have the same results. They're mostly the same thing, but every once and a while something pops up where the behavior differs.

@dmikusa dmikusa added the type:question A user question label May 15, 2024
@Ch4s3r
Copy link
Author

Ch4s3r commented May 15, 2024

Sure here you go:

❯ ./gradlew clean bootbuildimage
Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details

> Task :bootBuildImage
Building image 'docker.io/library/bootbuildimage-arm:0.0.1-SNAPSHOT'

 > Pulling builder image 'docker.io/paketobuildpacks/builder-jammy-base:latest' ..................................................
 > Pulled builder image 'paketobuildpacks/builder-jammy-base@sha256:7e0f8acd6e77c3219bcf58385c133b385633fcb0b135d56c228d97f37068b4ff'
 > Pulling run image 'docker.io/paketobuildpacks/run-jammy-base:latest' ..................................................
 > Pulled run image 'paketobuildpacks/run-jammy-base@sha256:ea0789090e3dcc6d3670a0e67aef87e3277db613a190f1d49d5828d00e55909a'
 > Pulling buildpack image 'docker.io/paketobuildpacks/java:13.0.1' ..................................................
 > Pulled buildpack image 'paketobuildpacks/java@sha256:2407cac986d8596b560b0fbdeadb3bb41fc8285c0994341b6611f381a52b7d97'

> Task :bootBuildImage FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':bootBuildImage'.
> Invalid response received when loading image "pack.local/builder/voglnshknh:latest"

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

BUILD FAILED in 13s
7 actionable tasks: 6 executed, 1 up-to-date

@Ch4s3r
Copy link
Author

Ch4s3r commented May 15, 2024

Pruning did not help and calling it via pack (0.33.2) did also fail.

pack build test --builder paketobuildpacks/builder-jammy-base --buildpack docker.io/paketobuildpacks/java:13.0.1

with error:

Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)

Tried switching to JDK17 but that also did not fix it, as pack cli choose to use JDK17 even though the project used JDK21.
With bootBuildImage it took the correct JDK.

Log output of pack build
❯ pack build test --builder paketobuildpacks/builder-jammy-base --buildpack docker.io/paketobuildpacks/java:13.0.1
latest: Pulling from paketobuildpacks/builder-jammy-base
Digest: sha256:7e0f8acd6e77c3219bcf58385c133b385633fcb0b135d56c228d97f37068b4ff
Status: Image is up to date for paketobuildpacks/builder-jammy-base:latest
latest: Pulling from paketobuildpacks/run-jammy-base
Digest: sha256:ea0789090e3dcc6d3670a0e67aef87e3277db613a190f1d49d5828d00e55909a
Status: Image is up to date for paketobuildpacks/run-jammy-base:latest
13.0.1: Pulling from paketobuildpacks/java
Digest: sha256:2407cac986d8596b560b0fbdeadb3bb41fc8285c0994341b6611f381a52b7d97
Status: Downloaded newer image for paketobuildpacks/java:13.0.1
===> ANALYZING
Image with name "test" not found
===> DETECTING
10 of 26 buildpacks participating
paketo-buildpacks/ca-certificates   3.7.0
paketo-buildpacks/bellsoft-liberica 10.7.1
paketo-buildpacks/syft              1.46.0
paketo-buildpacks/gradle            7.10.0
paketo-buildpacks/executable-jar    6.9.0
paketo-buildpacks/apache-tomcat     7.16.1
paketo-buildpacks/apache-tomee      1.9.0
paketo-buildpacks/liberty           4.1.0
paketo-buildpacks/dist-zip          5.7.0
paketo-buildpacks/spring-boot       5.29.1
===> RESTORING
===> BUILDING

Paketo Buildpack for CA Certificates 3.7.0
  https://github.com/paketo-buildpacks/ca-certificates
  Launch Helper: Contributing to layer
    Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper

Paketo Buildpack for BellSoft Liberica 10.7.1
  https://github.com/paketo-buildpacks/bellsoft-liberica
  Build Configuration:
    $BP_JVM_JLINK_ARGS           --no-man-pages --no-header-files --strip-debug --compress=1  configure custom link arguments (--output must be omitted)
    $BP_JVM_JLINK_ENABLED        false                                                        enables running jlink tool to generate custom JRE
    $BP_JVM_TYPE                 JRE                                                          the JVM type - JDK or JRE
    $BP_JVM_VERSION              17                                                           the Java version
  Launch Configuration:
    $BPL_DEBUG_ENABLED           false                                                        enables Java remote debugging support
    $BPL_DEBUG_PORT              8000                                                         configure the remote debugging port
    $BPL_DEBUG_SUSPEND           false                                                        configure whether to suspend execution until a debugger has attached
    $BPL_HEAP_DUMP_PATH                                                                       write heap dumps on error to this path
    $BPL_JAVA_NMT_ENABLED        true                                                         enables Java Native Memory Tracking (NMT)
    $BPL_JAVA_NMT_LEVEL          summary                                                      configure level of NMT, summary or detail
    $BPL_JFR_ARGS                                                                             configure custom Java Flight Recording (JFR) arguments
    $BPL_JFR_ENABLED             false                                                        enables Java Flight Recording (JFR)
    $BPL_JMX_ENABLED             false                                                        enables Java Management Extensions (JMX)
    $BPL_JMX_PORT                5000                                                         configure the JMX port
    $BPL_JVM_HEAD_ROOM           0                                                            the headroom in memory calculation
    $BPL_JVM_LOADED_CLASS_COUNT  35% of classes                                               the number of loaded classes in memory calculation
    $BPL_JVM_THREAD_COUNT        250                                                          the number of threads in memory calculation
    $JAVA_TOOL_OPTIONS                                                                        the JVM launch flags
    Using buildpack default Java version 17
  BellSoft Liberica JDK 17.0.11: Contributing to layer
    Downloading from https://github.com/bell-sw/Liberica/releases/download/17.0.11+10/bellsoft-jdk17.0.11+10-linux-amd64.tar.gz
    Verifying checksum
    Expanding to /layers/paketo-buildpacks_bellsoft-liberica/jdk
    Adding 137 container CA certificates to JVM truststore
    Writing env.build/JAVA_HOME.override
    Writing env.build/JDK_HOME.override
  BellSoft Liberica JRE 17.0.11: Contributing to layer
    Downloading from https://github.com/bell-sw/Liberica/releases/download/17.0.11+10/bellsoft-jre17.0.11+10-linux-amd64.tar.gz
    Verifying checksum
    Expanding to /layers/paketo-buildpacks_bellsoft-liberica/jre
    Adding 137 container CA certificates to JVM truststore
    Writing env.launch/BPI_APPLICATION_PATH.default
    Writing env.launch/BPI_JVM_CACERTS.default
    Writing env.launch/BPI_JVM_CLASS_COUNT.default
    Writing env.launch/BPI_JVM_SECURITY_PROVIDERS.default
    Writing env.launch/JAVA_HOME.default
    Writing env.launch/JAVA_TOOL_OPTIONS.append
    Writing env.launch/JAVA_TOOL_OPTIONS.delim
    Writing env.launch/MALLOC_ARENA_MAX.default
  Launch Helper: Contributing to layer
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/java-opts
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/jvm-heap
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/link-local-dns
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/memory-calculator
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/security-providers-configurer
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/jmx
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/jfr
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/openssl-certificate-loader
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/security-providers-classpath-9
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/debug-9
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/nmt
  Java Security Properties: Contributing to layer
    Writing env.launch/JAVA_SECURITY_PROPERTIES.default
    Writing env.launch/JAVA_TOOL_OPTIONS.append
    Writing env.launch/JAVA_TOOL_OPTIONS.delim

Paketo Buildpack for Syft 1.46.0
  https://github.com/paketo-buildpacks/syft
    Downloading from https://github.com/anchore/syft/releases/download/v0.105.1/syft_0.105.1_linux_amd64.tar.gz
    Verifying checksum
    Writing env.build/SYFT_CHECK_FOR_APP_UPDATE.default

Paketo Buildpack for Gradle 7.10.0
  https://github.com/paketo-buildpacks/gradle
  Build Configuration:
    $BP_EXCLUDE_FILES                                                                       colon separated list of glob patterns, matched source files are removed
    $BP_GRADLE_ADDITIONAL_BUILD_ARGUMENTS                                                   the additionnal arguments (appended to BP_GRADLE_BUILD_ARGUMENTS) to pass to Gradle
    $BP_GRADLE_BUILD_ARGUMENTS             --no-daemon -Dorg.gradle.welcome=never assemble  the arguments to pass to Gradle
    $BP_GRADLE_BUILD_FILE                                                                   the location of the main build config file, relative to the application root
    $BP_GRADLE_BUILT_ARTIFACT              build/libs/*.[jw]ar                              the built application artifact explicitly.  Supersedes $BP_GRADLE_BUILT_MODULE
    $BP_GRADLE_BUILT_MODULE                                                                 the module to find application artifact in
    $BP_GRADLE_INIT_SCRIPT_PATH                                                             the path to a Gradle init script file
    $BP_INCLUDE_FILES                                                                       colon separated list of glob patterns, matched source files are included
    $BP_JAVA_INSTALL_NODE                  false                                            whether to install Yarn/Node binaries based on the presence of a package.json or yarn.lock file
    $BP_NODE_PROJECT_PATH                                                                   configure a project subdirectory to look for `package.json` and `yarn.lock` files
    Creating cache directory /home/cnb/.gradle
  Compiled Application: Contributing to layer
    Executing gradlew --no-daemon -Dorg.gradle.welcome=never assemble
      Downloading https://services.gradle.org/distributions/gradle-8.7-bin.zip
      ............10%.............20%.............30%.............40%............50%.............60%.............70%.............80%.............90%............100%
      To honour the JVM settings for this build a single-use Daemon process will be forked. For more on this, please refer to https://docs.gradle.org/8.7/userguide/gradle_daemon.html#sec:disabling_the_daemon in the Gradle documentation.
      Daemon will be stopped at the end of the build 
      The message received from the daemon indicates that the daemon has disappeared.
      Build request sent: Build{id=a5cb88ab-ee0f-43a0-9112-d014d92c3792, currentDir=/workspace}
      Attempting to read last messages from the daemon log...
      Daemon pid: 294
        log file: /layers/paketo-buildpacks_gradle/cache/daemon/8.7/daemon-294.out.log
      ----- Last  20 lines from daemon log file - daemon-294.out.log -----
      2024-05-15T17:11:14.730+0000 [DEBUG] [org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler] Starting executing command: Build{id=a5cb88ab-ee0f-43a0-9112-d014d92c3792, currentDir=/workspace} with connection: socket connection from /127.0.0.1:34891 to /127.0.0.1:44690.
      2024-05-15T17:11:14.732+0000 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] Command execution: started DaemonCommandExecution[command = Build{id=a5cb88ab-ee0f-43a0-9112-d014d92c3792, currentDir=/workspace}, connection = DefaultDaemonConnection: socket connection from /127.0.0.1:34891 to /127.0.0.1:44690] after 0.0 minutes of idle
      2024-05-15T17:11:14.733+0000 [INFO] [org.gradle.launcher.daemon.server.DaemonRegistryUpdater] Marking the daemon as busy, address: [6b46128f-c1f9-4ea1-9042-5c2f0194e8e1 port:34891, addresses:[localhost/127.0.0.1]]
      2024-05-15T17:11:14.734+0000 [DEBUG] [org.gradle.launcher.daemon.registry.PersistentDaemonRegistry] Marking busy by address: [6b46128f-c1f9-4ea1-9042-5c2f0194e8e1 port:34891, addresses:[localhost/127.0.0.1]]
      2024-05-15T17:11:14.734+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire exclusive lock on daemon addresses registry.
      2024-05-15T17:11:14.734+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
      2024-05-15T17:11:14.736+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
      2024-05-15T17:11:14.738+0000 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] resetting idle timer
      2024-05-15T17:11:14.738+0000 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] daemon is running. Sleeping until state changes.
      2024-05-15T17:11:14.739+0000 [INFO] [org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy] Daemon is about to start building Build{id=a5cb88ab-ee0f-43a0-9112-d014d92c3792, currentDir=/workspace}. Dispatching build started information...
      2024-05-15T17:11:14.739+0000 [DEBUG] [org.gradle.launcher.daemon.server.SynchronizedDispatchConnection] thread 23: dispatching org.gradle.launcher.daemon.protocol.BuildStarted@30de71b0
      2024-05-15T17:11:14.740+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment] Configuring env variables: [PATH, JAVA_HOME, LIBRARY_PATH, HOSTNAME, CNB_STACK_ID, LD_LIBRARY_PATH, JDK_HOME, PWD, CPATH, CNB_BUILDPACK_DIR, HOME, SYFT_CHECK_FOR_APP_UPDATE]
      2024-05-15T17:11:14.743+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.LogToClient] About to start relaying all logs to the client via the connection.
      2024-05-15T17:11:14.743+0000 [INFO] [org.gradle.launcher.daemon.server.exec.LogToClient] The client will now receive all logging from the daemon (pid: 294). The daemon log file: /layers/paketo-buildpacks_gradle/cache/daemon/8.7/daemon-294.out.log
      2024-05-15T17:11:14.745+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon] Requesting daemon stop after processing Build{id=a5cb88ab-ee0f-43a0-9112-d014d92c3792, currentDir=/workspace}
      2024-05-15T17:11:14.745+0000 [LIFECYCLE] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] Daemon will be stopped at the end of the build 
      2024-05-15T17:11:14.745+0000 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] Stop as soon as idle requested. The daemon is busy: true
      2024-05-15T17:11:14.745+0000 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] daemon stop has been requested. Sleeping until state changes.
      2024-05-15T17:11:14.746+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] The daemon has started executing the build.
      2024-05-15T17:11:14.748+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] Executing build with daemon context: DefaultDaemonContext[uid=94706033-6796-433b-be96-0c2b9ca19557,javaHome=/layers/paketo-buildpacks_bellsoft-liberica/jdk,daemonRegistryDir=/layers/paketo-buildpacks_gradle/cache/daemon,pid=294,idleTimeout=120000,priority=NORMAL,applyInstrumentationAgent=true,daemonOpts=--add-opens=java.base/java.util=ALL-UNNAMED,--add-opens=java.base/java.lang=ALL-UNNAMED,--add-opens=java.base/java.lang.invoke=ALL-UNNAMED,--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens=java.base/java.nio.charset=ALL-UNNAMED,--add-opens=java.base/java.net=ALL-UNNAMED,--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED,-XX:MaxMetaspaceSize=384m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=US-ASCII,-Duser.country=US,-Duser.language=en,-Duser.variant]
      ----- End of the daemon log -----
      
      JVM crash log found: file:///workspace/hs_err_pid294.log
      
      FAILURE: Build failed with an exception.
      
      * What went wrong:
      Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
      
      * Try:
      > Run with --stacktrace option to get the stack trace.
      > Run with --info or --debug option to get more log output.
      > Run with --scan to get full insights.
      > Get more help at https://help.gradle.org.
unable to invoke layer creator
unable to contribute application layer
error running build
exit status 1
ERROR: failed to build: exit status 1
ERROR: failed to build: executing lifecycle: failed with status code: 51

@anthonydahanne
Copy link
Member

Hello @Ch4s3r !

I've run
pack build test --builder paketobuildpacks/builder-jammy-base --buildpack docker.io/paketobuildpacks/java:13.0.1

on your project (using a Mac M1 and Docker Desktop) and it worked

Successfully built image test

Then I've run
./gradlew clean bootbuildimage

and it failed, slightly differently than you though:

 > Pulling buildpack image 'docker.io/paketobuildpacks/java:13.0.1' ..................................................
 > Pulled buildpack image ''

> Task :bootBuildImage FAILED

FAILURE: Build failed with an exception.

I'll try and see if it's related to Spring Boot plugins (probably) with @scottfrederick

Question for you:
Why didn't you use a dual stack builder, such as paketobuildpacks/builder-jammy-buildpackless-tiny ? That way you'd have much faster build on your silicon mac (and keep the same builder for x86 on CI for example)

pack build test --builder paketobuildpacks/builder-jammy-buildpackless-tiny --buildpack docker.io/paketobuildpacks/java:13.0.1

see: spring-projects/spring-boot#40762 (comment)

@anthonydahanne
Copy link
Member

PS: I changed your build.gradle.kts with:

tasks.withType<BootBuildImage> {
        builder.set("paketobuildpacks/builder-jammy-buildpackless-tiny")
	buildpacks.add("paketobuildpacks/java:13.0.1")
}

and I still got the

 > Pulling buildpack image 'docker.io/paketobuildpacks/java:13.0.1' ..................................................
 > Pulled buildpack image ''

but then it continued fine

 > Executing lifecycle version v0.19.6
[...]
Successfully built image 'docker.io/library/bootbuildimage-arm:0.0.1-SNAPSHOT'

@dmikusa
Copy link
Contributor

dmikusa commented May 15, 2024

If you can, I 👍 @anthonydahanne's suggestion of using the buildpackless-tiny builder. It's going to work better/faster on your nice Mac hardware.

That said, you should be able to build with the base builder, if you need something from it that's not included in tiny. The difference is that your MBP is going to be building under emulation/rosetta (depending on how you have Docker setup). In your pack build output, you can see it doing this because it's downloading AMD64 binaries, which the buildpack would only do on an AMD64 base.

That seems to be working, but then the JVM crashes which is very weird. Unfortunately, we can't get at the crash dump the JVM is generating. It's in the build container and that goes away. That seems to be a different error than what you're seeing when you build with the Spring Boot Tools though. In that case, the buildpacks are not even running.

The issue with Spring Boot Tools maybe related to spring-projects/spring-boot#40697, but it's not totally clear. That issue has a hang, whereas you're getting a definitive failure. If you add the --debug flag to Gradle, you'll get a LOT of output, but you can see it communicating with Docker & maybe catch some insights into what happens before it fails.

As a side note, what is your Docker install and what version are you using? Docker Desktop on Mac has had some major version updates recently and this has broken some things with the Spring integration.

@scottfrederick
Copy link

./gradlew clean bootBuildImage results in Invalid response received when loading image "pack.local/builder/voglnshknh:latest"

I can re-create this also, using the provided sample and by modifying Spring Boot's integration tests to use a similar configuration. I'll see what I can figure out on the Spring Boot side.

@scottfrederick
Copy link

I'm pretty sure this has to do with the count of layers in the builder image and the specified buildpack image. We've seen issues like this before. The Paketo builder has 100+ layers, and paketobuildpacks/java:13.0.1 has 28 layers. Spring Boot builds a temporary ephemeral image archive from the builder image, adds the layers from any custom buildpack images to it along with some layers for env vars and other settings. The total count of layers is over the 127 limit for Docker images. Unfortunately, when Spring Boot calls the Docker API to load the image archive, the API responds with HTTP 200 and an empty response, leading to the Invalid response received when loading image message (Boot knows that something went wrong, but the Docker API doesn't give us details).

The workaround is what Anthony and Daniel mentioned above - start with a buildpack-less builder. This works for me:

tasks.withType<BootBuildImage> {
    builder.set("paketobuildpacks/builder-jammy-buildpackless-tiny")
    buildpacks.set(listOf("paketobuildpacks/java:13.0.1"))
}

pack must be smarter about managing layers when custom buildpacks are used along with a base builder. I'll research that and see if there's something we can do in Spring Boot.

@Ch4s3r
Copy link
Author

Ch4s3r commented May 17, 2024

@anthonydahanne

Question for you:
Why didn't you use a dual stack builder, such as paketobuildpacks/builder-jammy-buildpackless-tiny ? That way you'd have much faster build on your silicon mac (and keep the same builder for x86 on CI for example)

I was just using the base setup that is set per default when running bootBuildImage and did not consider changing before, my intent was just pinning the versions of the default run and build image.

@dmikusa

As a side note, what is your Docker install and what version are you using? Docker Desktop on Mac has had some major version updates recently and this has broken some things with the Spring integration.

I was aware of some issues that popped up already as there was a change with layer naming.
My version currently is 4.29.0 (145265).

Is there any estimate when java will get updated in the default builder paketobuildpacks/builder-jammy-base, as it's currently set to 12.1.0?
Because then we would get the dual stack build per default everywhere :)

When setting paketobuildpacks/builder-jammy-tiny as the base without the new java version, I also get an error when starting my spring boot app.

rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2

But with the new java version it works nicely, maybe we can change then for java apps to the tiny builder?

@scottfrederick

The workaround is what Anthony and Daniel mentioned above - start with a buildpack-less builder.

This also works for me, when using bootBuildImage.
Just did not know that there is such a builder :)

@dmikusa
Copy link
Contributor

dmikusa commented May 17, 2024

rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2

Can you give the full build output when this happens? This is usually something that happens when images/binaries get mixed up. I'd like to look into it and make sure we don't have a problem with the multi-arch image. Thanks!

@Ch4s3r
Copy link
Author

Ch4s3r commented May 17, 2024

Can't reproduce it anymore, tried also older versions of paketobuildpacks/builder-jammy-tiny with no luck.
Always builds now :)

@Ch4s3r
Copy link
Author

Ch4s3r commented May 17, 2024

Works as expected now. Thanks for looking into it to everyone who contributed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:question A user question
Projects
None yet
Development

No branches or pull requests

4 participants