Hello group, hopefully a quick one:
I am trying to install the suite of standard slurm packages (slurm, munge, slurmdbd, slurm-wlm-basic-plugins) on a compute node. Ubuntu 22.04.05 LTS just upgraded.
*However, these packages now bring down x11 (libx11-6 and all of that other garbage in Ubuntu land). *
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.
Thanks! Jess
On 6/25/25 11:39 am, Jesse Hayward via slurm-users wrote:
Does slurm actually depend on x11 now?
My guess would be that is coming from the sview package, which is an X11 program. Why that would be getting pulled in is what I think you'd want to look for.
https://slurm.schedmd.com/sview.html
https://launchpad.net/ubuntu/jammy/+package/sview
But if I'm reading that right the version in Ubuntu 22.04 is ancient (21.08.5).
All the best, Chris
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.
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.
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.
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.
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.
-
Christopher Samuel -
Jesse Hayward -
Kevin Buckley