Dfx 0.8.2 is promoted!

Please see: dfx 0.8.2 release notes


  • Breaking change: The controller parameter for dfx canister create is now passed as --controller <controller>, rather than as an optional positional parameter.
  • Upgrade your cycles wallet with dfx wallet upgrade or dfx wallet --network ic upgrade to install support for multiple controllers.
  • If you’re using dfx start rather than dfx start --background, you may want to call dfx ping --wait-healthy to give the replica time to complete its initialization sequence.


  • Updated replica
    • Supports public spec 0.18.0
    • Supports multiple controllers
    • Supports 64-bit memory
  • Updated Motoko to 0.6.10

Thanks! Is heartbeat included?


Heartbeat in Motoko would be… big.


$ dfx start --clean
Starting webserver for /_/
binding to:
thread 'replica-actor' panicked at 'Could not start replica.: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/dfx/src/actors/replica.rs:270:41

can someone please confirm 0.8.2 works on their machine?

Heartbeat in replica (i.e. the IC) is of course separate from Heartbeat in Motoko. The latter is not implemented yet; you can track Support the heartbeat · Issue #2728 · dfinity/motoko · GitHub to see progress here.


I had this issue when upgrading from 0.7.2 to 0.8.0. Try doing a reboot first, but I had to remove the cache, using dfx cache to get its location, and then remove the old version of dfx which dfx. Then I did a clean install and a reboot :thinking:

1 Like

Thanks for the help. I did what you said, if I understood it correctly.
Still no use.

Does it work for you? I mean, 0.8.2

Does Windows Hello now work with the local replica?

It sounds like you’ve already tried the equivalent, but if not, I’d suggest starting with dfx cache delete.

I did. I also tried to uninstall.sh completely, reboot, install from scratch - same thing.

It looks like there is a problem with the linux replica binary.

So guess for now downgrading is the best solution?

1 Like

I think I’m getting the same issues as others:

Starting webserver for /_/
binding to:
thread 'replica-actor' panicked at 'Could not start replica.: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/dfx/src/actors/replica.rs:270:41
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Hmmm will ping team. seems quite a few reports from the community.

1 Like

Just curious, how this could have passed through a CI/CD process if it fails like this?


The replica and ic-starter binaries that ship with dfx 0.8.2 on linux are broken. We know the reason and are working through a fix for it. We will release dfx 0.8.3 after this fix is available.


Thank you for clarity, @ericswanson

It seems very odd that code is being promoted and released and fails out of the box at such a basic level. A basic automated test suite may be of help here. Do they exist and were they run? Is it fair to say the CI/CD/DEVOPS/ITSM Release process must mature?

Also, do you have processes to track things like expiration date of SSL certificates?


You wrote that “A basic automated test suite may be of help here.” Totally agree.

We, of course, do have an automated test suite. I can see how it would appear as if we lack even the most basic of rudimentary CI/CD systems, and it’s not a good look. I do appreciate the respectful way you offered coaching and guidance without implying that we are a bunch of jokers :stuck_out_tongue_winking_eye:. Thank you. I think that is a very reasonable suggestion for you to make and question to ask.

Now it is worth explaining the state of the world and what did go wrong in this case:

You can see part of the test suite here: sdk/e2e at master · dfinity/sdk · GitHub. We run these tests on both Linux and Darwin.

It’s an uncomfortable fact of life that all test suites have blind spots. This one is no exception. The test suite didn’t catch this defect, so we’ll learn from this and improve. I have work in progress to check for this specific condition: test: check binaries (wip) by ericswanson-dfinity · Pull Request #1868 · dfinity/sdk · GitHub

While I can’t speak to the TLS certificate issue (a different team manages that), I can explain what happened here with dfx start.

As part of open-sourcing the sdk repo, we needed to remove some dependencies on repositories that aren’t yet open-sourced. One of those dependencies is the replica binary and its launcher, ic-starter. Rather than have the sdk’s build system in turn build replica and ic-starter from a private repo, it now downloads prebuilt binaries from download.dfinity.systems.

We use nix for CI and for builds. Nix provides an environment for reproducible builds. It’s quite sophisticated, and also complicated. One of those complications is that in the absence of certain post-processing, dynamically-linked binaries produced by nix will contain links to /nix/store/. For example:

$ ldd replica
    linux-vdso.so.1 (0x00007ffed39ea000)
    libpthread.so.0 => /nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib/libpthread.so.0 (0x00007f3810b84000)
    libgcc_s.so.1 => /nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib/libgcc_s.so.1 (0x00007f3810b6a000)
    librt.so.1 => /nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib/librt.so.1 (0x00007f3810b60000)
    libm.so.6 => /nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib/libm.so.6 (0x00007f3810a1f000)
    libdl.so.2 => /nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib/libdl.so.2 (0x00007f3810a1a000)
    libc.so.6 => /nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib/libc.so.6 (0x00007f3810859000)
    /nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib/ld-linux-x86-64.so.2 => /nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib64/ld-linux-x86-64.so.2 (0x00007f3815b43000)

The previously approach of building replica and ic-starter within sdk used a build target that patched the /nix/store links, but the new process that builds the binaries for download.dfinity.systems did not. (It does now.) So all the automated test suites passed (because they run in nix), and our local testing of the release binaries worked (because we have nix installed).

TLDR: This is a leftover consequence of open-sourcing the SDK. This did not happen before, but we failed to update some things while open-sourcing the SDK. That is now being addressed.


Thanks for the detailed explanation eric, of course we understand this is a complex system and these kind of issues can normally happen, may I suggest to add one more step for the release to be an external manual testing?
Because the internal environment and CI/CD may not 100% reflect the real world we could make a prerelease for the community to test and then we can promote it, we will be more than happy to do it.
I remember we have the same process I think with agent-js