pak install error in Docker ARM64 architecture running under emulation on AMD64 machine

[dmolitor]

I'm running into a bit of a niche issue. I have a machine running Windows 11 on AMD64 architecture. I am attempting to build Docker images for ARM64 architectures for which Docker uses QEMU for emulation during the build process. However, when trying to install packages via pak during the build process, pak fails with the following error message:

Error in remote(function(...) get("pkg_install_make_plan", asNamespace("pak"))(...), : Subprocess is busy or cannot start

To replicate this on Windows, do the following:

• From the console (e.g. Command Prompt) run an R-based ARM64 image under emulation: docker run -it --rm --platform linux/arm64 posit/r-base:4.5.2-noble
• Next, install pak binary per the usual:

  install.packages("pak", repos = sprintf("https://r-lib.github.io/p/pak/stable/%s/%s/%s", .Platform$pkgType, R.Version()$os, R.Version()$arch))
  

• Then attempt to install any package with pak:

  > pak::pkg_install("renv")
  Error in remote(function(...) get("pkg_install_make_plan", asNamespace("pak"))(...),  :
    Subprocess is busy or cannot start
  

I have a gut feeling that this is related to running R/pak under emulation because I've experienced some weird behavior in the past as a result of emulation. However, I want to confirm whether or not this is the case; any help would be appreciated!

[remlapmot]

Your commands work for me on x86_64 Windows 11 under QEMU emulation installed with as per the docs

docker run --privileged --rm tonistiigi/binfmt --install all

On my machine the QEMU emulation is incredibly slow, the installing pak step took approx 1 minute before I saw the R prompt return - so maybe you were just too fast entering the install renv command. The installing renv step took over 5 minutes.

(And maybe worth saying that going the other way on Apple Silicon Macs - they run linux/amd64 containers at almost native speed - so much faster than QEMU - and of course build linux/arm64 containers at native speed.)

[dmolitor]

Thanks for checking; it's helpful to know that it works on your system as expected! I was originally using the QEMU that is bundled with Docker Desktop; unfortunately, I confirmed that the issue persists for me when installing QEMU manually as well. +1 to the fact that emulation under QEMU is, in general, very slow. Still unsure what is causing the issue, but thanks for the input!

[remlapmot]

One nice way to speed up your builds is that both r-universe and the Public Posit Package Manager now have Linux ARM64 binary R packages.

You can either specify a new pak repo - but as something going wrong for you with that - you can modify the repos option.

• r-universe: https://docs.r-universe.dev/install/binaries.html

linux_binary_repo <- function(universe){
  sprintf('https://%s.r-universe.dev/bin/linux/noble-%s/%s/', 
    universe,
    R.version$arch, 
    substr(getRversion(), 1, 3))
}

# For example: enable cran repository
options(repos = linux_binary_repo(c('cran')))

# Then
install.packages(c(...))

• PPPM: https://packagemanager.posit.co/client/#/repos/cran/setup?r_environment=other

options(repos = c(CRAN = sprintf("https://packagemanager.posit.co/cran/latest/bin/linux/noble-%s/%s", R.version["arch"], substr(getRversion(), 1, 3))))
# Then
install.packages(c(...))

Anyway there is no problem in pak - so I'd say this can be closed.

[dmolitor]

On the contrary, there is something going wrong in pak since e.g. install.packages("renv") works fine yet pak::pkg_install("renv") fails. However, I agree that it seems unlikely that there is an obvious solution (this may be due to some peculiarity of my setup despite it being fairly standard) especially since you've confirmed that you don't encounter this issue. I will close as a weird, one-off error case if nobody else is able to provide any troubleshooting ideas.