fix: Docker build on macOS #32

beck-8 · 2026-01-16T13:39:22Z

… tools in image Mounting empty host directories to these paths hides the installed tools, causing 'cargo/forge not found' errors.

pdptool is compiled for the container environment and cannot execute on the host due to platform/library incompatibilities. Run it via docker exec and use mounted fast-storage for test files.

pdptool runs inside the container and must connect to localhost:4702 (container internal port), not the dynamically allocated host port.

beck-8 · 2026-01-16T17:43:59Z

 INFO src/docker/logs.rs:109: ✓ Removed 24 dead foc* containers
 INFO src/commands/start/mod.rs:487: [3/3] Writing post-start status snapshot...
 INFO src/docker/logs.rs:119: Writing post-start status to: /Users/beck/.foc-devnet/run/26jan17-0123_WoblyFig/post_start_status.log
 INFO src/docker/logs.rs:132: ✓ Post-start status logged
 INFO src/commands/start/mod.rs:490: ═══════════════════════════════════════════════════════════
 INFO src/commands/start/mod.rs:491: Post-start teardown completed successfully
 INFO src/commands/start/mod.rs:492: ═══════════════════════════════════════════════════════════
 INFO src/commands/start/mod.rs:464: Cluster started successfully!

# beck @ beckMacBook-Pro in ~/workspace/foc-localnet on git:fix/docker-gid-conflict x [1:34:12]

beck-8 · 2026-01-16T17:46:39Z

pdptool was also placed in the container because cross-platform issues aren't limited to macOS. The same problem might occur when using it on Ubuntu versions below 24.04.

wjmelements · 2026-01-16T20:17:53Z

I have tried cargo run -- init on this branch and it worked.

wjmelements · 2026-01-16T21:13:27Z

I have tried cargo run -- init on this branch and it worked.

The other steps worked too

redpanda-f · 2026-01-17T09:56:45Z

docker/builder/Dockerfile

 WORKDIR /workspace

 # Define volumes for external access
-VOLUME ["/home/foc-user/.cargo", "/home/foc-user/.rustup", "/home/foc-user/go", "/var/tmp/filecoin-proof-parameters"]


Why was this removed? This is good for caching.

This only works when there is data present. The first time you run the mount, it will clear these directories, causing the toolchain to be lost. I added the critical mappings in a subsequent commit.

That is true, but it cleans up only the first time. The caches are for when the curio or lotus codebase is actively being changed and rebuilt frequently. In those instances, re-init is not needed, and these caches would be useful.

The cargo bin directory was overwritten, so this binary will never exist unless it is manually downloaded on the host machine.

There are two commits here: one temporarily disables everything, and the second maps according to what's actually usable. The -v parameter plays a crucial role. Therefore, I've removed it here because I think it's meaningless.

However, I must admit that some Rust binaries are not cached. The rest, such as go pkg and rust registry, are cached.

redpanda-f · 2026-01-17T10:07:32Z

src/commands/build/docker.rs

        "run".to_string(),
-        "-u".to_string(),
-        "foc-user".to_string(),
+        "--rm".to_string(),


Unsure if the intent really is:

"do not use foc-user for building"

"remove" the container, lose logs

I don't disagree with them, but would like to understand safety argument for removing -u foc-user.

The --rm option is used because if cargo run --build lotus fails, subsequent runs will save the changes, requiring manual cleanup. Error logs will be output upon exit, so there's no need to worry.

The -u foc-user was removed because you added -u gid:uid repeatedly later, so this redundant part was removed.

redpanda-f · 2026-01-17T10:09:08Z

src/commands/start/curio/verification.rs

-        .parse()?;
+    // When running pdptool inside the container, use the container's internal port (4702)
+    // not the host-mapped port
+    let service_url = "http://localhost:4702";


Let's not hardcode stuff. What's wrong with host-mapped port here?

This is because pdptool was moved inside the container, so a fixed internal port was used.

The reason for moving pdptool internally is that the original logic allowed programs compiled inside the container to be used externally, which was not as expected and could cause problems in most environments.

redpanda-f · 2026-01-17T10:12:06Z

src/commands/start/curio/verification.rs

+    let run_id = context.run_id();
+    let container_name = format!("foc-{}-curio-{}", run_id, sp_index);

    let args = [
+        "exec",
+        &container_name,
+        "/usr/local/bin/lotus-bins/pdptool",


not sure testing from within curio container constitutes "healthy" properly, especially given public. Would rather have foc-builder run pdptool for stricter testing.

You are right, I will put pdptool in foc-builder and keep testing service_url externally.

redpanda-f · 2026-01-17T10:13:07Z

src/config.rs

+    /// Returns the appropriate YugabyteDB tarball URL for the current platform:
+    /// - el8-aarch64 for ARM64 systems (Apple Silicon, AWS Graviton, etc.)
+    /// - linux-x86_64 for x86_64 systems
+    fn get_default_yugabyte_url() -> String {


This addition is a "feature update". The S3 fallback has to be changed accordingly in the code as well. Please check that.

I don't understand what you mean by S3 fallback here? But I do see a place I forgot to update.

foc-devnet/scripts/cache-artifacts.sh

Line 27 in 629f8e8

# Cache Yugabyte tarball

redpanda-f

Main changes I’d request before merge:

Fix Yugabyte arch detection (runtime vs compile-time). Also, fix the S3 fallback for downloads
Re-evaluate removal of -u foc-user.
Avoid hardcoded ports and paths. Hoist them into constants if really needed.

- Change from compile-time cfg!() to runtime std::env::consts::ARCH - Update cache-artifacts.sh to detect ARM64/x86_64 at runtime

fix: Docker build GID conflict on macOS

7e6aa23

FilOzzy added this to FOC Jan 16, 2026

github-project-automation bot moved this to 📌 Triage in FOC Jan 16, 2026

beck-8 marked this pull request as draft January 16, 2026 13:54

beck-8 added 2 commits January 16, 2026 22:10

feat: Auto-detect architecture for YugabyteDB download (ARM64/x86_64)

9550771

fix: Auto-remove build containers after completion

33d4da1

rjan90 linked an issue Jan 16, 2026 that may be closed by this pull request

cargo run -- init fails in groupadd with GID already exists #30

Open

rjan90 moved this from 📌 Triage to ⌨️ In Progress in FOC Jan 16, 2026

beck-8 added 5 commits January 16, 2026 23:25

fix: Remove all volume mounts (cargo/rustup/foundry/go) that override…

e375bed

… tools in image Mounting empty host directories to these paths hides the installed tools, causing 'cargo/forge not found' errors.

fix: Auto-detect architecture for Go download (ARM64/x86_64)

ffa436b

feat: Mount cargo/go dependency caches to speed up rebuilds

c77afa9

fix: Run pdptool inside container instead of on host

aa09a29

pdptool is compiled for the container environment and cannot execute on the host due to platform/library incompatibilities. Run it via docker exec and use mounted fast-storage for test files.

fix: Use container internal port for pdptool

c3780aa

pdptool runs inside the container and must connect to localhost:4702 (container internal port), not the dynamically allocated host port.

BigLep assigned beck-8 Jan 16, 2026

beck-8 changed the title ~~fix: Docker build GID conflict on macOS~~ fix: Docker build on macOS Jan 16, 2026

beck-8 marked this pull request as ready for review January 16, 2026 17:46

rjan90 requested a review from redpanda-f January 17, 2026 08:00

rjan90 moved this from ⌨️ In Progress to 🔎 Awaiting review in FOC Jan 17, 2026

redpanda-f reviewed Jan 17, 2026

View reviewed changes

redpanda-f requested changes Jan 17, 2026

View reviewed changes

github-project-automation bot moved this from 🔎 Awaiting review to ⌨️ In Progress in FOC Jan 17, 2026

fix: Use runtime arch detection for YugabyteDB URL

68ae908

- Change from compile-time cfg!() to runtime std::env::consts::ARCH - Update cache-artifacts.sh to detect ARM64/x86_64 at runtime

refactor: Run pdptool in foc-builder for stricter testing

573c261

fix: Docker build on macOS #32

Are you sure you want to change the base?

fix: Docker build on macOS #32

Uh oh!

Conversation

beck-8 commented Jan 16, 2026

Uh oh!

beck-8 commented Jan 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

beck-8 commented Jan 16, 2026

Uh oh!

wjmelements commented Jan 16, 2026

Uh oh!

wjmelements commented Jan 16, 2026

Uh oh!

redpanda-f Jan 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

redpanda-f left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

beck-8 commented Jan 16, 2026 •

edited

Loading

redpanda-f Jan 17, 2026 •

edited

Loading