Skip to content

Unable to rebuild on certain architectures #1103

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

Open
ocaisa opened this issue May 28, 2025 · 6 comments
Open

Unable to rebuild on certain architectures #1103

ocaisa opened this issue May 28, 2025 · 6 comments

Comments

@ocaisa
Copy link
Member

ocaisa commented May 28, 2025

For A64FX and Grace we have accounts on real systems which we use for building. However, those systems do not support fakeroot so we currently have no way to rebuild packages (affecting #1101 and #1102)

@bedroge
Copy link
Collaborator

bedroge commented May 28, 2025

One possible solution could be to bind mount /cvmfs from the host, and bind mount an empty host directory on top of it to replace an existing installation. That seems to work:

$ apptainer shell -B /cvmfs/software.eessi.io -B $PWD/emptydir:/cvmfs/software.eessi.io/versions/2023.06/software/linux/aarch64/a64fx/software/buildenv/default-foss-2023a docker://ghcr.io/eessi/build-node:debian11
INFO:    Using cached SIF image
Apptainer> ls /cvmfs/software.eessi.io/versions/2023.06/software/linux/aarch64/a64fx/software/buildenv/default-foss-2023a
Apptainer> touch /cvmfs/software.eessi.io/versions/2023.06/software/linux/aarch64/a64fx/software/buildenv/default-foss-2023a/newfile
Apptainer> 

You can't bind mount it as a new directory, then you get read-only file system errors, but for rebuilds that's not an issue, as we always want to replace an existing directory.

The only issue is that we do need to have /cvmfs on the host in this case, bind mounting on top of a /cvmfs that was fuse-mounted by the container does not seem to work. I guess all/most of our build cluster do have /cvmfs on the host, so it may not be an issue right now, but we always assumed that we may be building on nodes that don't have this.

@bedroge
Copy link
Collaborator

bedroge commented May 28, 2025

But I guess we could definitely add it as a second (and even the preferred) rebuild method, i.e. check if /cvmfs is available on the host and then use this approach. If it's not available, we could fall back to fakeroot (if support for that is available).

@boegel
Copy link
Contributor

boegel commented May 29, 2025

Do we know why fakeroot is not supported on Deucalion & JURECA? Is that deliberate?

Anyway, the approach where we leverage /cvmfs from the host if it's available seems reasonable to me.

@ocaisa
Copy link
Member Author

ocaisa commented May 29, 2025

It sounds like it is feasible, we build with an overlay and rebuild with a bind mount. Is there any bot where CVMFS is not available natively (Grace maybe)?

It should also make tarballs smaller as I believe right now we are also tarring up the CVMFS cache.

@boegel
Copy link
Contributor

boegel commented Jun 12, 2025

Just noting that the reason we're relying on fakeroot is to dance around the problems in #556

I'm slowly getting annoyed enough to try and come up with a solution for this once and for all, and I'm still hoping there's a way without having to rely on an EESSI mount provided by the host (since that comes with downsides as well).

@boegel
Copy link
Contributor

boegel commented Jun 12, 2025

Latest version of bubblewrap (bwrap) has introduced support for creating writable overlays, that looks promising...

Step 0:

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

No branches or pull requests

3 participants