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.
 
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.