build: bump ubuntu in dockerfile

[julienrbrt]

Description

I was getting the following using a too old version of ubuntu

/usr/local/bin/ev-reth: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /usr/local/bin/ev-reth)
/usr/local/bin/ev-reth: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.36' not found (required by /usr/local/bin/ev-reth)

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Performance improvement
• Refactoring

Related Issues

Fixes #(issue)

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Testing

Additional Notes

[gemini-code-assist]

Summary of Changes

Hello @julienrbrt, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical build issue related to outdated GLIBC versions by upgrading the base Ubuntu image in the Dockerfile. The change ensures that the ev-reth application can find the necessary GLIBC libraries, preventing runtime errors and improving the stability of the build environment.

Highlights

• Dockerfile Update: The base Ubuntu image for the runtime stage in the Dockerfile has been upgraded from ubuntu:22.04 to ubuntu:24.04.
• Dependency Resolution: This update resolves GLIBC version not found errors (GLIBC_2.38 and GLIBC_2.36) that were occurring with the older Ubuntu version, ensuring compatibility for ev-reth.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[claude]

Claude finished @julienrbrt's task —— View job

---

Code Review for Ubuntu Dockerfile Bump

Reviewing this pull request that bumps Ubuntu from 22.04 to 24.04 to fix GLIBC compatibility issues.

Todo List:

• Read and analyze the Dockerfile changes
• Evaluate code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Review security implications
• Consider test coverage needs
• Provide comprehensive review feedback

---

Review Summary

Overall Assessment: ✅ APPROVED - This is a well-motivated and properly implemented change that solves a real compatibility issue.

What Changed

• Line 54: Updated base runtime image from ubuntu:22.04 to ubuntu:24.04
• This addresses GLIBC version compatibility issues (GLIBC_2.38 and GLIBC_2.36 not found)

Code Quality & Best Practices ✅

Strengths:

• Targeted fix: The change addresses the root cause (outdated GLIBC) rather than working around it
• Minimal scope: Only changes what's necessary - just the runtime base image
• Consistency: Dockerfile.cross already uses ubuntu:24.04 (line 4), so this brings consistency across Dockerfiles
• Proper multi-stage build: The change correctly targets only the runtime stage, not the build stage

Security Considerations ✅

Positive aspects:

• Security updates: Ubuntu 24.04 LTS includes more recent security patches than 22.04
• Maintained support: 24.04 LTS is supported until 2029 vs 22.04 until 2027
• No new vulnerabilities introduced: Standard Ubuntu image with same package installation pattern

Recommendations:

• Consider pinning to a specific tag like ubuntu:24.04.1 instead of ubuntu:24.04 for more deterministic builds
• The current approach using the floating tag is acceptable for most use cases but may cause slight variations over time

Performance Considerations ⚠️

Potential impacts:

• Image size: Ubuntu 24.04 base image might be slightly larger than 22.04
• Build time: Could affect layer caching if base image changes significantly
• Runtime performance: Should be neutral or positive due to newer system libraries

Recommendation: Monitor build times and image sizes after this change.

Potential Issues & Bugs ✅

None identified - This is a straightforward base image update with:

• No breaking changes to the application layer
• Same package installation commands remain compatible
• Dockerfile syntax and structure unchanged

Test Coverage Considerations ⚠️

Current state:

• No Dockerfile-specific tests visible in the repository
• Integration tests should catch any runtime issues

Recommendations:

1. Build verification: Ensure CI/CD builds and runs the updated image successfully
2. Runtime testing: Verify the application starts and functions correctly with the new base
3. Consider adding: Basic smoke tests that verify the binary works in the new environment

Additional Observations

Consistency check:

• ✅ Dockerfile.cross already uses ubuntu:24.04
• ✅ scripts/reth-backup/Dockerfile inherits from the main image, so it benefits from this fix
• ✅ Cross-compilation Dockerfiles use different base images (ghcr.io/cross-rs/cross) - no changes needed

Minor Suggestions

1. Consider version pinning (optional):

   FROM ubuntu:24.04.1 AS runtime  # More deterministic

2. Update documentation if needed - check if any docs reference the Ubuntu version

Conclusion

This is a well-executed infrastructure fix that:

• ✅ Solves the immediate GLIBC compatibility problem
• ✅ Uses the most appropriate solution (base image update)
• ✅ Maintains security and best practices
• ✅ Has minimal risk of introducing issues

Recommendation: Merge after successful CI verification

---

[gemini-code-assist]

Code Review

The pull request successfully updates the base Ubuntu image in the "Dockerfile" from "22.04" to "24.04". This change is crucial for resolving GLIBC version compatibility issues, as indicated in the description, ensuring the application can run with the necessary dependencies. My feedback focuses on enhancing the reproducibility of the Docker image build.

[gemini-code-assist]

While updating to ubuntu:24.04 resolves the GLIBC dependency issue, for enhanced build reproducibility and stability, it's a good practice to pin the base image to a more specific version or a digest. Using ubuntu:24.04 will always pull the latest patch release of 24.04, which could introduce subtle, unintended changes over time. Consider using a specific point release (e.g., ubuntu:24.04.1 if available and desired) or a full image digest to ensure that builds are consistently using the exact same base image.