Sorry, one last time: Now the same issue is occuring with the package slurmd.
What is going on here?
On Thu, Jul 10, 2025 at 5:09 PM Jesse Hayward jhayward@vassar.edu wrote:
Update: Definitely an apt problem, not a slurm one, apologies. Still ancient issues from an old gnome-control-center install a prior admin did years ago. Sheesh. Did many apt rebuilds and it never complained. Dpkg rebuild + reboot solved the issue. Held packaged.
Glad we're moving to Rocky for our next rig.
Thanks all for your help
Best, Jesse
On Thu, Jul 10, 2025 at 5:04 PM Jesse Hayward jhayward@vassar.edu wrote:
Hi all,
Unfortunately still struggling. I am not installing x11 on my compute nodes. Especially not anything Ubuntu has to offer. See attached screenshot.
[image: 966c96eb-79c4-4f12-ba23-bf099bb9b1c6.png] Best, Jesse
On Tue, Jul 1, 2025 at 4:55 PM Jesse Hayward jhayward@vassar.edu wrote:
Thanks, all!
Your advice was all helpful on different levels; especially Kevin's.
Christopher, your advice was also helpful, we definitely want to stick to a more minimal setup. Rest assured, we *just* upgraded everything to 22.04. This issue was because of a pre-upgrade purge of the slurm suite due to a botched apt autoremove. Probably some sprinkling of human error there on my part, as well. I'm also building an OHPC-Master server which will host PXE for those same nodes, so in either a pinch or upgrade-approval workflow, we can just change the boot order on the nodes to pick up the chrooted image.
Jess, please feel free to reach out to me directly via Email or give me a call. I would like to hear a bit more.
Cheers all, Jesse
On Thu, Jun 26, 2025 at 6:42 AM Kevin Buckley < kevin.buckley.pawsey.org.au@gmail.com> wrote:
On 2025/06/25 23:39, Jesse Hayward via slurm-users wrote:
Does slurm actually depend on x11 now? Or do I need to take a look at
my
apt config and see what's going on over there, instead.
TL;DR: it doesn't have to - but you might need to buid your own DEB-files
Looking at the SPEC file in the head of the GitHub repo sources, sees this documented:
# build options .rpmmacros options change to default action # ==================== ==================== ======================== ... # --without x11 %_without_x11 1 disable internal X11 support ...
and there's a corresponding
%bcond_without x11
statement.
That would suggest that "the builder" can turn it off when running the configure
To echo Chris's thoughts as well, I'm sure I have asked SchedMD about sview in the past (think I was in a different country too), but I can't now recall what their justification, for needing to pull in the GUI stuff there, was.
FWIW,
If I do an rpm -qR against the RPMs we have on our login nodes then I can see some "obvious" GUI-bits
libgdk-x11-2.0.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libgtk-x11-2.0.so.0()(64bit) libpango-1.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libpangoft2-1.0.so.0()(64bit)
but, sadly, they are all requirements for the "main"
slurm
package, which deployes sview, and not, as one might hope
slurm-contribs
where you might hope to find them, or even completely off-side in some (currently non-existing)
slurm-contribs-gui
package.
