Just tried it and it works from my location. So something seems to filter rsync on your side. Can you reach other rsync servers? Adrian

Right now, there is no timeline. We talked about it in the TSC meeting and I tried to build the first packages, but at that time the build system was not ready. A few of us will be at ISC 2022 so mayb

Indeed, but if you click 'Go to download repository' it will take you to http://obs.openhpc.community:82/OpenHPC:/2.5:/Factory/EL_8/x86_64/ It is running on port 82, so not sure it is reachable for ev

There is a version with the fix at: https://obs.openhpc.community/package/show/OpenHPC:2.5:Factory/slurm It is for the upcoming 2.5 release. Adrian

Please open a ticket at https://github.com/openhpc/ohpc/issues The 2.x branch does not seem to have a comps file at all and the 1.2 comps file also does not contain the XML header you mentioned is mis

You can either look here for all packages OpenHPC provides: https://obs.openhpc.community/project/show/OpenHPC:2.0:Factory or here: https://github.com/openhpc/ohpc/tree/2.x/components or here: http://

Many years ago, during CentOS 6 I used debootstrap to create Ubuntu VMs on a CentOS system. It seems debootstrap is still available in EPEL: https://src.fedoraproject.org/rpms/debootstrap That should

Looking at the buildlogs of 2.1 I see that pmix support is no longer compiled in. I guess this is because of the following patch: https://github.com/openhpc/ohpc/commit/c04c33f48d2a75e7fe07697ce277a98

Hello Vinícius, Jeremy already mentioned the ticket this has been discussed last week, but I am curious why you say CentOS Stream is positioned as the default? Is this documented somewhere? Because it

OpenHPC publishes container images at: https://quay.io/organization/ohpc Which are based on: https://github.com/openhpc/ohpc/tree/2.x/containers Maybe that helps you. Adrian

I would say it is possible, but probably not as easy as you hope. From what you describe, it sounds like everything is running in your container. mpirun and the process mpirun starts. The difference w

I have had the same problem. I think the reason is that slurm does not go through logind when the nodes are assigned. I worked around this with a prolog and epilog script: $ cat files/slurm.prolog #!/

This sounds a lot like the recent mpich bug in which certain node names are not correctly recognized. This is fixed with 1.3.9 (and 1.3.8.1): https://github.com/openhpc/ohpc/blob/obs/OpenHPC_1.3.9_Fac

#slurm

Yes, that is definitely necessary.

What is the value of ControlMachine= in your slurm.conf? For the OSS EU workshop I was setting it to the value of what 'hostname' returned. Adrian

Maybe because that is the fastest your nvme0n1 device can read the data? How much memory do you have? What happens if you run it a second time? Running it a second time should have the file in the fil

#infiniband #openhpc

2.3.1 will be included in the next release (1.3.8): https://github.com/openhpc/ohpc/issues/977 Adrian

Can you write to the NFS? Can you show the output of 'mount'? Adrian

It seems all those failures are happening the first time the failing package touches /opt/ohpc. There is an incomplete cpio error message, so cpio has trouble unpacking the RPM content on that file sy

Could you provide more details about the errors you are seeing. Do you have errors installing ohpc-release-1.3-1.el7.x86_64.rpm or does that work? Can you give a full output of the error you get tryin