Hi,
I use openbox WM and the SLiM login manager.
I upgraded my F41 -> F42 machines, following the instructions on https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/ to the letter.
However, the machine comes up with a blank screen. It appears to me that the system is trying to start X but is unable to do so. I tried getting a login console (without a login manager display) but that prompt disappears almost immediately.
Previously, I did not have a problem with any of my upgrades so I am not sure what is going on here. But would you have any suggestions on how to address this problem?
Many thanks and best wishes, Ranjan
On Fri May23'25 04:53:58PM, Community Support for Fedora Users wrote:
From: Ranjan Maitra via users users@lists.fedoraproject.org Date: Fri, 23 May 2025 16:53:58 -0500 To: Community Support for Fedora Users users@lists.fedoraproject.org Cc: Ranjan Maitra mlmaitra@gmx.com Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: F41 -> F42 (openbox+slim: X does not get started)
Hi,
I use openbox WM and the SLiM login manager.
I upgraded my F41 -> F42 machines, following the instructions on https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/ to the letter.
However, the machine comes up with a blank screen. It appears to me that the system is trying to start X but is unable to do so. I tried getting a login console (without a login manager display) but that prompt disappears almost immediately.
Previously, I did not have a problem with any of my upgrades so I am not sure what is going on here. But would you have any suggestions on how to address this problem?
Many thanks and best wishes, Ranjan
Hi,
Did anyone have any suggestions on what to do here? I can provide more information but I am not sure what to do.
Thanks, Ranjan
Hi.
On Fri, 30 May 2025 15:24:10 -0500 Ranjan Maitra via users wrote:
I use openbox WM and the SLiM login manager.
I upgraded my F41 -> F42 machines, following the instructions on https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/ to the letter.
However, the machine comes up with a blank screen. It appears to me that the system is trying to start X but is unable to do so. I tried getting a login console (without a login manager display) but that prompt disappears almost immediately.
At the grub menu, add systemd.debug_shell to the kernel parameters. Suppress rhgb may also help.
You will normally get a root shell on tty9.
Then look at the logs from tty9: journalctl -b, /var/log/Xorg.0.log
Hi Francis,
Thanks very much for this!
On Sat May31'25 07:48:07AM, Francis.Montagnac@inria.fr wrote:
From: Francis.Montagnac@inria.fr Date: Sat, 31 May 2025 07:48:07 +0200 To: Community support for Fedora users users@lists.fedoraproject.org CC: Ranjan Maitra mlmaitra@gmx.com Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: F41 -> F42 (openbox+slim: X does not get started)
Hi.
On Fri, 30 May 2025 15:24:10 -0500 Ranjan Maitra via users wrote:
I use openbox WM and the SLiM login manager.
I upgraded my F41 -> F42 machines, following the instructions on https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/ to the letter.
However, the machine comes up with a blank screen. It appears to me that the system is trying to start X but is unable to do so. I tried getting a login console (without a login manager display) but that prompt disappears almost immediately.
At the grub menu, add systemd.debug_shell to the kernel parameters. Suppress rhgb may also help.
You will normally get a root shell on tty9.
Before I do this, do I need to have a root account set up? I currently do not have root on my machines (but have sudo) set up but I can create root if needed.
Then look at the logs from tty9: journalctl -b, /var/log/Xorg.0.log
I am able to get into one of these machines and was able to look at /var/log/Xorg.0.log.
Here it is:
https://paste.centos.org/view/f54fe5e6
I also dumped journalctl -b, but that file is huge (85MB). I can upload it, but what are the lines/parts we are looking for?
These two are from a remote login done without rebooting (and without the suggested added kernel parameter). I am happy to do that of course, or provide more information as needed to help!
Many thanks again, and best wishes, Ranjan
-- francis -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Ranjan Maitra via users wrote:
On Sat May31'25 07:48:07AM, Francis.Montagnac@inria.fr wrote:
Then look at the logs from tty9: journalctl -b, /var/log/Xorg.0.log
I am able to get into one of these machines and was able to look at /var/log/Xorg.0.log.
Here it is:
Searching for errors (EE) in the xorg log shows this on line 437:
[ 39.627] (EE) Failed to open authorization file "/var/run/slim/slim.auth": No such file or directory
I know nothing about slim, but that seems like a problem. The package does include /var/run/slim and has a tmpfiles.d config which should recreate it on boot, but perhaps it is missing. If not, whatever creates slim.auth seems amiss.
FWIW, /var/run should be changed to /run to avoid systemd warnings (if nothing else).
That's really more of problem for the upstream and/or Fedora maintainers, but any interested users could submit a patch to correct this either upstream or to Fedora's package.
Todd,
Thank you for this!
On Sat May31'25 04:18:49PM, Todd Zullinger wrote:
From: Todd Zullinger tmz@pobox.com Date: Sat, 31 May 2025 16:18:49 -0400 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: F41 -> F42 (openbox+slim: X does not get started)
Ranjan Maitra via users wrote:
On Sat May31'25 07:48:07AM, Francis.Montagnac@inria.fr wrote:
Then look at the logs from tty9: journalctl -b, /var/log/Xorg.0.log
I am able to get into one of these machines and was able to look at /var/log/Xorg.0.log.
Here it is:
Searching for errors (EE) in the xorg log shows this on line 437:
[ 39.627] (EE) Failed to open authorization file "/var/run/slim/slim.auth": No such file or directory
I know nothing about slim, but that seems like a problem. The package does include /var/run/slim and has a tmpfiles.d config which should recreate it on boot, but perhaps it is missing. If not, whatever creates slim.auth seems amiss.
Thanks, interesting, but I checked and the same error also shows up on the F41 box (and does not seem to create an X "problem"). And there is no slim.auth (on F41) anywhere. Perhaps things have become stricter and needs to be fixed (from F42 onwards).
The version on slim is slim-1.4.0-10.fc42 on F42 and slim-1.4.0-9.fc41 on F41. I did not think that the last numeral mattered much.
However, I note that slim has a 1.4.1 version upstream. Not sure if it will fix anything though.
https://sourceforge.net/projects/slim-fork/
FWIW, /var/run should be changed to /run to avoid systemd warnings (if nothing else).
I see, the spec file appears to have the following:
* Wed Jun 01 2011 Jan Kaluza jkaluza@redhat.com - 1.3.2-6 - fix #708693 - added tmfiles.d config to create /var/run/slim directory
That's really more of problem for the upstream and/or Fedora maintainers, but any interested users could submit a patch to correct this either upstream or to Fedora's package.
OK, I am embarrassed to say that I think I am the Fedora maintainer (from the retired original package but did not receive email about the updated version). But what is the change that I need to do in the spec file to get the /var/run changed to /run?
I have posted the slim.spec that I have here: https://paste.centos.org/view/c6952de4
(I was actually under the impression that packaging tools took care of such things automatically.)
Many thanks and best wishes, Ranjan
Ranjan Maitra via users wrote:
Todd,
Thank you for this!
On Sat May31'25 04:18:49PM, Todd Zullinger wrote:
I know nothing about slim, but that seems like a problem. The package does include /var/run/slim and has a tmpfiles.d config which should recreate it on boot, but perhaps it is missing. If not, whatever creates slim.auth seems amiss.
Thanks, interesting, but I checked and the same error also shows up on the F41 box (and does not seem to create an X "problem"). And there is no slim.auth (on F41) anywhere. Perhaps things have become stricter and needs to be fixed (from F42 onwards).
Maybe, but if it just reports a spurious error, that makes me think it's something else. It's also why I don't like ignorable errors. :)
The version on slim is slim-1.4.0-10.fc42 on F42 and slim-1.4.0-9.fc41 on F41. I did not think that the last numeral mattered much.
That greatly depends. That form is NAME-VERSION-RELEASE, where VERSION is the upstream version and release is the number of revisions or releases of that package. Anytime changes are made to the packaging, the release in bumped. That might be for nothing more than a rebuild or it could be a large change to the spec file. You have to look at the rpm changelog and/or the packages git history to determine whether it's a trivial change or not.
warnings (if nothing else).
I see, the spec file appears to have the following:
- Wed Jun 01 2011 Jan Kaluza jkaluza@redhat.com - 1.3.2-6
- fix #708693 - added tmfiles.d config to create /var/run/slim directory
That's really more of problem for the upstream and/or Fedora maintainers, but any interested users could submit a patch to correct this either upstream or to Fedora's package.
OK, I am embarrassed to say that I think I am the Fedora maintainer (from the retired original package but did not receive email about the updated version).
Hah! So you are. Hopefully that will help if you find the package requires some fiddling to fix this issue. :)
But what is the change that I need to do in the spec file to get the /var/run changed to /run?
I have posted the slim.spec that I have here: https://paste.centos.org/view/c6952de4
(I was actually under the impression that packaging tools took care of such things automatically.)
Over time, things change and require adaptations in the spec files. /var/run is now a symlink to /run. In the past, it was the opposite. When systemd starts a service and notices /var/run for the pid file, it logs a warning that you should change it.
Whether that is something you feel is important for the package, I don't know. Attached is a patch (entirely untested) showing one way to do it (which includes some whitespace cleanups in the immediately surrounding lines).
I used the %{_runstatedir} macro rather than hard-coded /run. Not everyone bothers with that, particularly when it seems unlikely to change and more so when the macro is so much longer.
Using the macro also means generating the tmpfiles.d config in the spec rather than keeping it separate. That's another matter of taste and style which can be argued either way.
I based it directly from the Fedora slim git repo, which is a number of revisions ahead of the one you pasted. The only changes are the release bumps for rebuilds with Fedora 39-42, so it doesn't affect the patch context.
Todd,
Thanks very much again!
Maybe, but if it just reports a spurious error, that makes me think it's something else. It's also why I don't like ignorable errors. :)
I agree, same with warnings. I do not like disregarding them, and want more warnings.
The version on slim is slim-1.4.0-10.fc42 on F42 and slim-1.4.0-9.fc41 on F41. I did not think that the last numeral mattered much.
That greatly depends. That form is NAME-VERSION-RELEASE, where VERSION is the upstream version and release is the number of revisions or releases of that package. Anytime changes are made to the packaging, the release in bumped. That might be for nothing more than a rebuild or it could be a large change to the spec file. You have to look at the rpm changelog and/or the packages git history to determine whether it's a trivial change or not.
I see, I think that after the last spec file that I pushed, it was mostly updated with every new release of Fedora.
Btw, I noticed that 1.4.1 has the following as changelog:
* Adjusted how/when the pseudo-root window is created and removed, in preparation for handling multiple monitors in SLiM * Adjusted slimlock to use the panel class in the way it was designed to be used. * Current version of SLiM fixed by allocating bimap always. * Find '#' character * That passwd_feedback wrong * Changed the App::mcookiesize const member variable to a #define * Reinstate install of systemd service file - required by Debian * Note an expired passwords bug in the man page * Ticket #3 : Use xinerama to pick a viewport (single monitor) for DM mode too * Fixed an annoying developer warning from cmake. * Updated systemd service file to fix some debian / lintian messages.
* Adjusted how/when the pseudo-root window is created and removed, in preparation for handling multiple monitors in SLiM * Adjusted slimlock to use the panel class in the way it was designed to be used. * Current version of SLiM fixed by allocating bimap always. * Find '#' character * That passwd_feedback wrong * Changed the App::mcookiesize const member variable to a #define * Reinstate install of systemd service file - required by Debian * Note an expired passwords bug in the man page * Ticket #3 : Use xinerama to pick a viewport (single monitor) for DM mode too * Fixed an annoying developer warning from cmake. * Updated systemd service file to fix some debian / lintian messages.
I do not know if the systemd service itself is distribution-specific (perhaps so), but if not, would it fix the problem?
warnings (if nothing else).
I see, the spec file appears to have the following:
- Wed Jun 01 2011 Jan Kaluza jkaluza@redhat.com - 1.3.2-6
- fix #708693 - added tmfiles.d config to create /var/run/slim directory
That's really more of problem for the upstream and/or Fedora maintainers, but any interested users could submit a patch to correct this either upstream or to Fedora's package.
OK, I am embarrassed to say that I think I am the Fedora maintainer (from the retired original package but did not receive email about the updated version).
Hah! So you are. Hopefully that will help if you find the package requires some fiddling to fix this issue. :)
But what is the change that I need to do in the spec file to get the /var/run changed to /run?
I have posted the slim.spec that I have here: https://paste.centos.org/view/c6952de4
(I was actually under the impression that packaging tools took care of such things automatically.)
Over time, things change and require adaptations in the spec files. /var/run is now a symlink to /run. In the past, it was the opposite. When systemd starts a service and notices /var/run for the pid file, it logs a warning that you should change it.
Whether that is something you feel is important for the package, I don't know. Attached is a patch (entirely untested) showing one way to do it (which includes some whitespace cleanups in the immediately surrounding lines).
I used the %{_runstatedir} macro rather than hard-coded /run. Not everyone bothers with that, particularly when it seems unlikely to change and more so when the macro is so much longer.
Using the macro also means generating the tmpfiles.d config in the spec rather than keeping it separate. That's another matter of taste and style which can be argued either way.
I based it directly from the Fedora slim git repo, which is a number of revisions ahead of the one you pasted. The only changes are the release bumps for rebuilds with Fedora 39-42, so it doesn't affect the patch context.
Thanks very much again for this! I will look at it tomorrow and push the update and also incorporate this patch after checking it! But it is a good start for me.
I hope it will also address the X issue.
Best wishes, Ranjan
diff --git c/slim-tmpfiles.conf i/slim-tmpfiles.conf deleted file mode 100644 index 8ccb38b..0000000 --- c/slim-tmpfiles.conf +++ /dev/null @@ -1 +0,0 @@ -d /var/run/slim diff --git c/slim.spec i/slim.spec index d599859..329fb7e 100644 --- c/slim.spec +++ i/slim.spec @@ -15,9 +15,8 @@ Source3: slim-dynwm Source4: slim-fedora.txt # logrotate entry (see bz#573743) Source5: slim.logrotate.d -Source6: slim-tmpfiles.conf -Source7: slim.service -patch0: slim-1.4.0-fedora.patch +Source6: slim.service +patch0: slim-1.4.0-fedora.patch patch1: slim-1.4.0-selinux.patch
## Keyring copied on 2023-02-26 from: xfontsel.gpg @@ -84,16 +83,17 @@ install -p -m755 %{SOURCE3} %{buildroot}%{_bindir}/%{name}-dynwm chmod 0644 %{buildroot}%{_sysconfdir}/%{name}.conf install -d -m755 %{buildroot}%{_sysconfdir}/pam.d install -p -m644 %{SOURCE1} %{buildroot}%{_sysconfdir}/pam.d/%{name} -mkdir -p %{buildroot}%{_localstatedir}/run/%{name} +mkdir -p %{buildroot}%{_runstatedir}/%{name} rm -f %{buildroot}%{_datadir}/%{name}/themes/default/background.jpg ln -s ../../../backgrounds/f%{?fedora}/default/f%{?fedora}-01-day.png %{buildroot}%{_datadir}/%{name}/themes/default/background.png # install logrotate entry install -m0644 -D %{SOURCE5} %{buildroot}/%{_sysconfdir}/logrotate.d/%{name}
-install -p -D %{SOURCE6} %{buildroot}%{_sysconfdir}/tmpfiles.d/%{name}.conf +mkdir -p %{buildroot}%{_sysconfdir}/tmpfiles.d +echo "d %{_runstatedir}/%{name}" >%{buildroot}%{_sysconfdir}/tmpfiles.d/%{name}.conf
mkdir -p %{buildroot}%{_unitdir} -install -m 644 %{SOURCE7} %{buildroot}%{_unitdir}/%{name}.service +install -m 644 %{SOURCE6} %{buildroot}%{_unitdir}/%{name}.service
# Fix lib dir according to bits of system mkdir -p %{buildroot}/%{_libdir}/ @@ -118,7 +118,7 @@ mkdir -p %{buildroot}/%{_libdir}/ %config(noreplace) %verify(not size mtime md5) %{_sysconfdir}/pam.d/%{name} %config(noreplace) %verify(not size mtime md5) %{_sysconfdir}/%{name}.conf %config(noreplace) %verify(not size mtime md5) %{_sysconfdir}/logrotate.d/%{name} -%ghost %dir %{_localstatedir}/run/%{name} +%ghost %dir %{_runstatedir}/%{name} %{_bindir}/%{name}* %{_bindir}/update_slim_wmlist %{_mandir}/man1/%{name}*.1*
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi.
On Sat, 31 May 2025 14:53:50 -0500 Ranjan Maitra via users wrote:
At the grub menu, add systemd.debug_shell to the kernel parameters. Suppress rhgb may also help.
You will normally get a root shell on tty9.
Before I do this, do I need to have a root account set up?
No.
I am able to get into one of these machines
Thus forget systemd.debug_shell: this is simpler. Using SSH I guess.
and was able to look at /var/log/Xorg.0.log.
Here it is:
Besides the EE slim.auth pointed by Todd, this log shows that Xorg terminates successfully after less than 2 seconds, without saying why: weird.
I also dumped journalctl -b, but that file is huge (85MB). I can upload it, but what are the lines/parts we are looking for?
I don't know slim, but being a display manager, it's him that starts Xorg. Look thus for slim traces in the journal, and also in it's logfiles: /var/log/slim.log
On Sun, 01 Jun 2025 07:48:16 +0200 Francis.Montagnac@inria.fr wrote:
I don't know slim, but being a display manager, it's him that starts Xorg. Look thus for slim traces in the journal, and also in it's logfiles: /var/log/slim.log
I installed slim on a test machine. /var/log/slim.log says:
slim: could not load background image for theme 'default'
Due to this broken link (in F42):
/usr/share/slim/themes/default/background.png \ -> ../../../backgrounds/f42/default/f42-01-day.png
An immediate workaround is to modify slim.conf with:
current_theme original
that uses the images in /usr/share/slim/themes/original/
slim starts then properly:
systemctl status slim <snip> Main PID: 57856 (slim) <snip> CGroup: /system.slice/slim.service ├─57856 /usr/bin/slim └─57858 /usr/libexec/Xorg -auth /var/run/slim/slim.auth
Otherwise it fails with
Main PID: 55882 (code=exited, status=1/FAILURE)
systemd[1]: slim.service: Scheduled restart job, restart counter is at 5. systemd[1]: slim.service: Start request repeated too quickly. systemd[1]: slim.service: Failed with result 'exit-code'. systemd[1]: Failed to start slim.service - SLiM Login Manager.
/usr/share/backgrounds/f42/default contains:
f42-01-day.jxl f42-01-night.jxl f42.xml
Linking /usr/share/slim/themes/default/background.jpg to ../../../backgrounds/f42/default/f42-01-day.jxl
doesn't work although slim opens it (seen with strace). I suspect that the slim code should be modified to manage those .jxl (JPEG XL codestream) files.
Another point: /etc/pam.d/slim uses pam_console.so that is not provided (any more ?) on F42.
Hi,
Ranjan Maitra via users wrote:
Btw, I noticed that 1.4.1 has the following as changelog:
* Adjusted how/when the pseudo-root window is created and removed, in preparation for handling multiple monitors in SLiM * Adjusted slimlock to use the panel class in the way it was designed to be used. * Current version of SLiM fixed by allocating bimap always. * Find '#' character * That passwd_feedback wrong * Changed the App::mcookiesize const member variable to a #define * Reinstate install of systemd service file - required by Debian * Note an expired passwords bug in the man page * Ticket #3 : Use xinerama to pick a viewport (single monitor) for DM mode too * Fixed an annoying developer warning from cmake. * Updated systemd service file to fix some debian / lintian messages.I do not know if the systemd service itself is distribution-specific (perhaps so), but if not, would it fix the problem?
I don't know whether systemd even issues the warning for the slim.service as it doesn't mention /var/run there; it's only set in the config.
The changes to use /run rather than /var/run may just be minor future-proofing to avoid problems if the /var/run symlink were removed.
The Fedroa package ships its own slim.service unit file which has a few differences from upstream (which I presume are useful, but really don't know). Any improvements made to the upstream systemd unit file would have to be reviewed and merged into the unit file Fedora ships.
The upstream changes to slim.service between 1.4.0 and 1.4.1 appear to be contained in this commit.
https://sourceforge.net/p/slim-fork/code/60/tree/trunk/slim.service?diff=61f...
--- a/slim.service +++ b/slim.service @@ -1,10 +1,14 @@ [Unit] Description=SLiM Simple Login Manager +Documentation=man:slim(1) After=systemd-user-sessions.service
[Service] ExecStart=/usr/bin/slim -n -s Restart=on-failure
+CapabilityBoundingSet=~CAP_SYS_PTRACE + [Install] Alias=display-manager.service +WantedBy=multi-user.target
Documentation=man:slim(1)' allows `systemctl status slim` to show a link to the man page.
CapabilityBoundingSet=~CAP_SYS_PTRACE removes the services ability to trace arbitrary processes (refer to capabilities(7) for more details). It's not a bad thing to limit what the process can do.
WantedBy=multi-user.target is likely not desireable as it would try to start slim in the multi-user target which might conflict with another desktop manager that is installed. It's probably better to leave that out to ensure that multiple desktop managers can be cleanly installed without fighting with each other. But that's just a cursory view. I am far from an expert on systemd units, particularly with respect to the graphical desktop setup. :)
Francis.Montagnac@inria.fr wrote:
On Sun, 01 Jun 2025 07:48:16 +0200 Francis.Montagnac@inria.fr wrote:
I don't know slim, but being a display manager, it's him that starts Xorg. Look thus for slim traces in the journal, and also in it's logfiles: /var/log/slim.log
I installed slim on a test machine. /var/log/slim.log says:
slim: could not load background image for theme 'default'
Due to this broken link (in F42):
/usr/share/slim/themes/default/background.png \ -> ../../../backgrounds/f42/default/f42-01-day.png
Nice. I believe that was changed per:
https://fedoraproject.org/wiki/Changes/SwitchToJXLforDefaultWallpaper
Another point: /etc/pam.d/slim uses pam_console.so that is not provided (any more ?) on F42.
The pam_console.so was removed from pam in Fedora 39:
https://fedoraproject.org/wiki/Changes/RemovePamConsole https://bugzilla.redhat.com/2166692
The change page even has a link to slim as a dependency:
https://bugzilla.redhat.com/1822229
That was automatically closed as WONTFIX because it was reported in 2020, during the Fedora 33 cycle. :)
Since it's working in Fedora 41, I would take that as sign that dropping that from the slim.pam in the Fedora package won't do any harm and will avoid the warning.
Thank you to both!
OK, dealing with the pam first, here is the problem.
Another point: /etc/pam.d/slim uses pam_console.so that is not provided (any more ?) on F42.
The pam_console.so was removed from pam in Fedora 39:
https://fedoraproject.org/wiki/Changes/RemovePamConsole https://bugzilla.redhat.com/2166692
The change page even has a link to slim as a dependency:
https://bugzilla.redhat.com/1822229
That was automatically closed as WONTFIX because it was reported in 2020, during the Fedora 33 cycle. :)
Since it's working in Fedora 41, I would take that as sign that dropping that from the slim.pam in the Fedora package won't do any harm and will avoid the warning.
So, dropping pam, with -DUSEPAM=no, there seems to be a problem in the compilation:
slim-1.4.0/app.cpp: In member function ‘App::AuthenticateUser(bool)’: slim-1.4.0/app.cpp:616:9: warning: ‘pw’ may be used uninitialized [-Wmaybe-uninitialized] 616 | if (pw == 0) | ^~ slim-1.4.0/app.cpp:599:24: note: ‘pw’ was declared here 599 | struct passwd *pw;
I wonder if there is something off here in the file's header:
#ifdef USE_PAM
#include <string>
int conv(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *appdata_ptr) { *resp = (struct pam_response *) calloc(num_msg, sizeof(struct pam_response)); Panel* panel = *static_cast<Panel**>(appdata_ptr); int result = PAM_SUCCESS; int i;
for (i = 0; i < num_msg; i++) { (*resp)[i].resp = 0; (*resp)[i].resp_retcode = 0; switch (msg[i]->msg_style) { case PAM_PROMPT_ECHO_ON: /* We assume PAM is asking for the username */ panel->EventHandler(Panel::Get_Name); switch (panel->getAction()) { case Panel::Suspend: case Panel::Halt: case Panel::Reboot: (*resp)[i].resp=strdup("root"); break;
case Panel::Console: case Panel::Exit: case Panel::Login: (*resp)[i].resp=strdup(panel->GetName().c_str()); break; default: break; } break;
case PAM_PROMPT_ECHO_OFF: /* We assume PAM is asking for the password */ switch (panel->getAction()) { case Panel::Console: case Panel::Exit: /* We should leave now! */ result = PAM_CONV_ERR; break;
default: panel->EventHandler(Panel::Get_Passwd); (*resp)[i].resp=strdup(panel->GetPasswd().c_str()); break; } break;
case PAM_ERROR_MSG: case PAM_TEXT_INFO: /* We simply write these to the log TODO: Maybe we should show them. In particular, if you have a fingerprint reader, PAM passes instructions in PAM_TEXT_INFO messages */ logStream << APPNAME << ": " << msg[i]->msg << endl; break; } if (result != PAM_SUCCESS) break; }
if (result != PAM_SUCCESS) { for (i = 0; i < num_msg; i++) { if ((*resp)[i].resp == 0) continue; free((*resp)[i].resp); (*resp)[i].resp = 0; } free(*resp); *resp = 0; }
return result; }
#endif
Is there a way out of putting in pam?
I wonder if this is the reason behind the spec file (keeping pam for now, mentioned as far back as in 2007!), but this is completely uninformed speculation on my part.
I am trying to see where in the code, the png is read (and see if that can be replaced by jxl).
Many thanks again, and best wishes, Ranjan
Ranjan Maitra via users wrote:
Thank you to both!
OK, dealing with the pam first, here is the problem.
Another point: /etc/pam.d/slim uses pam_console.so that is not provided (any more ?) on F42.
The pam_console.so was removed from pam in Fedora 39:
https://fedoraproject.org/wiki/Changes/RemovePamConsole https://bugzilla.redhat.com/2166692
The change page even has a link to slim as a dependency:
https://bugzilla.redhat.com/1822229
That was automatically closed as WONTFIX because it was reported in 2020, during the Fedora 33 cycle. :)
Since it's working in Fedora 41, I would take that as sign that dropping that from the slim.pam in the Fedora package won't do any harm and will avoid the warning.
So, dropping pam, with -DUSEPAM=no, there seems to be a problem in the compilation:
I don't think you want to drop pam support. Just remove the pam_console.so line from slim.pam in the Fedora package source. It is only that module which was removed.
In other words:
diff --git i/slim.pam w/slim.pam index e42aba2..f0cd831 100644 --- i/slim.pam +++ w/slim.pam @@ -8,5 +8,4 @@ session optional pam_keyinit.so force revoke session include system-auth session required pam_selinux.so close session required pam_loginuid.so -session optional pam_console.so session required pam_selinux.so open
On Sun Jun01'25 04:04:38PM, Todd Zullinger wrote:
From: Todd Zullinger tmz@pobox.com Date: Sun, 1 Jun 2025 16:04:38 -0400 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: F41 -> F42 (openbox+slim: X does not get started)
Ranjan Maitra via users wrote:
Thank you to both!
OK, dealing with the pam first, here is the problem.
Another point: /etc/pam.d/slim uses pam_console.so that is not provided (any more ?) on F42.
The pam_console.so was removed from pam in Fedora 39:
https://fedoraproject.org/wiki/Changes/RemovePamConsole https://bugzilla.redhat.com/2166692
The change page even has a link to slim as a dependency:
https://bugzilla.redhat.com/1822229
That was automatically closed as WONTFIX because it was reported in 2020, during the Fedora 33 cycle. :)
Since it's working in Fedora 41, I would take that as sign that dropping that from the slim.pam in the Fedora package won't do any harm and will avoid the warning.
So, dropping pam, with -DUSEPAM=no, there seems to be a problem in the compilation:
I don't think you want to drop pam support. Just remove the pam_console.so line from slim.pam in the Fedora package source. It is only that module which was removed.
Ah, just reading your earlier email again (just before it came in) made me do the same.
Now to figure out the part about the .jxl files. I will update as to what I find.
Thanks again!
Best wishes, Ranjan
Thanks again!
On Sun Jun01'25 10:11:16AM, Todd Zullinger wrote:
From: Todd Zullinger tmz@pobox.com Date: Sun, 1 Jun 2025 10:11:16 -0400 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: F41 -> F42 (openbox+slim: X does not get started)
Francis.Montagnac@inria.fr wrote:
On Sun, 01 Jun 2025 07:48:16 +0200 Francis.Montagnac@inria.fr wrote:
I don't know slim, but being a display manager, it's him that starts Xorg. Look thus for slim traces in the journal, and also in it's logfiles: /var/log/slim.log
I installed slim on a test machine. /var/log/slim.log says:
slim: could not load background image for theme 'default'
Due to this broken link (in F42):
/usr/share/slim/themes/default/background.png \ -> ../../../backgrounds/f42/default/f42-01-day.png
Nice. I believe that was changed per:
https://fedoraproject.org/wiki/Changes/SwitchToJXLforDefaultWallpaper
[As a note, upstream is in trouble because the maintainer is quite unwell, judging by the ticket responses on the slimfork site. I hope he recovers well and soon, at least for his sake.]
So, I think that there are two options: one, perhaps a long-term one would be to add code that allows for reading .jxl files. That is doable and a lot of work, but might only be transient as Fedora moves to something else down the road.
So, I was thinking of using magick to convert the file to a png while the rpm was being built. Might not be kosher anyway, but I brought in ImageMagick as a BuildRequire, and replaced:
ln -s ../../../backgrounds/f%{?fedora}/default/f%{?fedora}-01-day.png %{buildroot}%{_datadir}/%{name}/themes/default/background.png
with:
magick ../../../backgrounds/f%{?fedora}/default/f%{?fedora}-01-day.jxl convert %{buildroot}%{_datadir}/%{name}/themes/default/background.png
I don't know why this creates the following error:
magick ../../../backgrounds/f42/default/f42-01-day.jxl /home/localuser/rpmbuild/BUILD/slim-1.4.0-build/BUILDROOT/usr/share/slim/themes/default/background.png
magick: unable to open image '../../../backgrounds/f42/default/f42-01-day.jxl': No such file or directory @ error/blob.c/OpenBlob/3596. error: Bad exit status from /var/tmp/rpm-tmp.62ipD8 (%install)
RPM build errors: Bad exit status from /var/tmp/rpm-tmp.62ipD8 (%install)
I do not quite understand why I get this error, especially because the "ln -s" appears to find this path.
Is there a way to specify the .jxl file in the spec file for magick to convert it without hardcoding it?
Many thanks again and best wishes, Ranjan
Ranjan Maitra via users wrote:
[As a note, upstream is in trouble because the maintainer is quite unwell, judging by the ticket responses on the slimfork site. I hope he recovers well and soon, at least for his sake.]
Yes, I hope they get well soon.
So, I think that there are two options: one, perhaps a long-term one would be to add code that allows for reading .jxl files. That is doable and a lot of work, but might only be transient as Fedora moves to something else down the road.
So, I was thinking of using magick to convert the file to a png while the rpm was being built. Might not be kosher anyway, but I brought in ImageMagick as a BuildRequire, and replaced:
ln -s ../../../backgrounds/f%{?fedora}/default/f%{?fedora}-01-day.png %{buildroot}%{_datadir}/%{name}/themes/default/background.png
with:
magick ../../../backgrounds/f%{?fedora}/default/f%{?fedora}-01-day.jxl convert %{buildroot}%{_datadir}/%{name}/themes/default/background.png
I don't know why this creates the following error:
magick ../../../backgrounds/f42/default/f42-01-day.jxl /home/localuser/rpmbuild/BUILD/slim-1.4.0-build/BUILDROOT/usr/share/slim/themes/default/background.png
magick: unable to open image '../../../backgrounds/f42/default/f42-01-day.jxl': No such file or directory @ error/blob.c/OpenBlob/3596. error: Bad exit status from /var/tmp/rpm-tmp.62ipD8 (%install)
RPM build errors: Bad exit status from /var/tmp/rpm-tmp.62ipD8 (%install)
I do not quite understand why I get this error, especially because the "ln -s" appears to find this path.
'ln -s' works because it doesn't actually need the target to create the link. If you did a build in mock and then looked for the target file in the chroot, it's not there because there's no BuildRequires for f%{?fedora}-backgrounds-base, only a Requires.
That ensures it is there at install time, so the symlink works. You'd need to add a BuildRequires to get f%{?fedora}-backgrounds-base installed in the package buildroot where you can use magick to convert it.
Once you're not making a symlink, I think using the absolute path makes things clearer. Having to keep track of where you are relative to the backgrounds directory is a minor hassle, which has no real benefit when you're converting the file and saving it at another path. In other words:
magick %{_datadir}/backgrounds/f%{?fedora}/default/f%{?fedora}-01-day.jxl \ %{buildroot}%{_datadir}/%{name}/themes/default/background.jpg
You don't need to specify convert in the magick command. Using magick as above will convert the file from jxl to jpg (or png if you change the extension).
It may be worth comparing the size and quality of jpg versus png. It takes about 4 times as long to convert to png as jpg (2.8 vs 0.6 seconds) and is about that many times larger as well (6.4M vs 1.4M).
Neither the time nor size for the png is too much. I just noticed it while doing this in a container to test. The input jxl file is under 1M, FWIW.
Todd,
Thanks very much for this!
On Sun Jun01'25 09:09:55PM, Todd Zullinger wrote:
From: Todd Zullinger tmz@pobox.com Date: Sun, 1 Jun 2025 21:09:55 -0400 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: F41 -> F42 (openbox+slim: X does not get started)
Ranjan Maitra via users wrote:
[As a note, upstream is in trouble because the maintainer is quite unwell, judging by the ticket responses on the slimfork site. I hope he recovers well and soon, at least for his sake.]
Yes, I hope they get well soon.
So, I think that there are two options: one, perhaps a long-term one would be to add code that allows for reading .jxl files. That is doable and a lot of work, but might only be transient as Fedora moves to something else down the road.
So, I was thinking of using magick to convert the file to a png while the rpm was being built. Might not be kosher anyway, but I brought in ImageMagick as a BuildRequire, and replaced:
ln -s ../../../backgrounds/f%{?fedora}/default/f%{?fedora}-01-day.png %{buildroot}%{_datadir}/%{name}/themes/default/background.png
with:
magick ../../../backgrounds/f%{?fedora}/default/f%{?fedora}-01-day.jxl convert %{buildroot}%{_datadir}/%{name}/themes/default/background.png
I don't know why this creates the following error:
magick ../../../backgrounds/f42/default/f42-01-day.jxl /home/localuser/rpmbuild/BUILD/slim-1.4.0-build/BUILDROOT/usr/share/slim/themes/default/background.png
magick: unable to open image '../../../backgrounds/f42/default/f42-01-day.jxl': No such file or directory @ error/blob.c/OpenBlob/3596. error: Bad exit status from /var/tmp/rpm-tmp.62ipD8 (%install)
RPM build errors: Bad exit status from /var/tmp/rpm-tmp.62ipD8 (%install)
I do not quite understand why I get this error, especially because the "ln -s" appears to find this path.
'ln -s' works because it doesn't actually need the target to create the link. If you did a build in mock and then looked for the target file in the chroot, it's not there because there's no BuildRequires for f%{?fedora}-backgrounds-base, only a Requires.
Oh, I see. I put in the BuildRequires now, but also made the changes below. I am not sure I needed to put in the BuildRequires but I did it anyway. Btw, it appears to me that the Requires should no longer be needed, since the image that is the only thing that is needed from the backgrounds package is being created and stored essentially in /usr/share/slim/themes/default/background.png
That ensures it is there at install time, so the symlink works. You'd need to add a BuildRequires to get f%{?fedora}-backgrounds-base installed in the package buildroot where you can use magick to convert it.
Once you're not making a symlink, I think using the absolute path makes things clearer. Having to keep track of where you are relative to the backgrounds directory is a minor hassle, which has no real benefit when you're converting the file and saving it at another path. In other words:
I see, thank you for the explanation.
magick %{_datadir}/backgrounds/f%{?fedora}/default/f%{?fedora}-01-day.jxl \ %{buildroot}%{_datadir}/%{name}/themes/default/background.jpgYou don't need to specify convert in the magick command.
Yeah, right! Old habits (when convert was the command) die hard.
Using magick as above will convert the file from jxl to jpg (or png if you change the extension).
It may be worth comparing the size and quality of jpg versus png. It takes about 4 times as long to convert to png as jpg (2.8 vs 0.6 seconds) and is about that many times larger as well (6.4M vs 1.4M).
Indeed, I decided to stick with jpg. I do not think the quality will make that much of a difference and we can see if anyone else does not like the drop from PNG to JPG.
Neither the time nor size for the png is too much. I just noticed it while doing this in a container to test. The input jxl file is under 1M, FWIW.
Right, and I was wondering earlier the real value of this change to jxl. But it does reduce the size a bit, and I guess smaller is always better.
I submitted the updated RPM to F42 testing. I will see if anyone has comments on it, assuming there exists anyone else who uses slim, and then move to looking into 1.4.1 (perhaps next week after 1.4.0 moves to stable). As it is, it is not clear to me that anyone other than me is waiting with bated breath for SLiM:-)
Thank you again for all your explanations and all your help! I am quite at sea with .spec files, one of the reasons being, of course, that I end up dabbling in them rather infrequently, so it is good to have explanations.
Best wishes, Ranjan
Hi,
Ranjan Maitra via users wrote:
On Sun Jun01'25 09:09:55PM, Todd Zullinger wrote:
'ln -s' works because it doesn't actually need the target to create the link. If you did a build in mock and then looked for the target file in the chroot, it's not there because there's no BuildRequires for f%{?fedora}-backgrounds-base, only a Requires.
Oh, I see. I put in the BuildRequires now, but also made the changes below. I am not sure I needed to put in the BuildRequires but I did it anyway. Btw, it appears to me that the Requires should no longer be needed, since the image that is the only thing that is needed from the backgrounds package is being created and stored essentially in /usr/share/slim/themes/default/background.png
Indeed. that Requires can be dropped if that's the only reason it was needed.
You don't need to specify convert in the magick command.
Yeah, right! Old habits (when convert was the command) die hard.
I get that. I was using convert directly until very recently, when it started to complain and direct me to the magick command. And I still get (mildly) annoyed that the command arguments now require different ordering. In the old versions, this worked:
convert -resize 1200x1200 folder{-3000x3000,}.jpg
It works, but now prints:
WARNING: The convert command is deprecated in IMv7, use "magick" instead of "convert" or "magick convert"
So I figure I'll just replace convert with magick, which fails:
$ magick -resize 1200x1200 folder{-3000x3000,}.jpg magick: no images found for operation `-resize' at CLI arg 1 @ error/operation.c/CLIOption/5481.
I have to write it as:
$ magick folder-3000x3000.jpg -resize 1200x1200 folder.jpg
My old habits have to die, but does it have to be so painfully. :)
I submitted the updated RPM to F42 testing. I will see if anyone has comments on it, assuming there exists anyone else who uses slim, and then move to looking into 1.4.1 (perhaps next week after 1.4.0 moves to stable). As it is, it is not clear to me that anyone other than me is waiting with bated breath for SLiM:-)
It can often be tough to gauge how many folks are using a package, I know. Even when no one files bugs or comments on updates, others are surely using it. Good luck with it!
Thank you again for all your explanations and all your help! I am quite at sea with .spec files, one of the reasons being, of course, that I end up dabbling in them rather infrequently, so it is good to have explanations.
Glad it helped!
Todd,
Thanks very much again!
Oh, I see. I put in the BuildRequires now, but also made the changes below. I am not sure I needed to put in the BuildRequires but I did it anyway. Btw, it appears to me that the Requires should no longer be needed, since the image that is the only thing that is needed from the backgrounds package is being created and stored essentially in /usr/share/slim/themes/default/background.png
Indeed. that Requires can be dropped if that's the only reason it was needed.
Thanks!
You don't need to specify convert in the magick command.
Yeah, right! Old habits (when convert was the command) die hard.
I get that. I was using convert directly until very recently, when it started to complain and direct me to the magick command. And I still get (mildly) annoyed that the command arguments now require different ordering. In the old versions, this worked:
convert -resize 1200x1200 folder{-3000x3000,}.jpgIt works, but now prints:
WARNING: The convert command is deprecated in IMv7, use "magick" instead of "convert" or "magick convert"So I figure I'll just replace convert with magick, which fails:
$ magick -resize 1200x1200 folder{-3000x3000,}.jpg magick: no images found for operation `-resize' at CLI arg 1 @ error/operation.c/CLIOption/5481.I have to write it as:
$ magick folder-3000x3000.jpg -resize 1200x1200 folder.jpgMy old habits have to die, but does it have to be so painfully. :)
Right, I learnt last week that there was a change beyond the seemingly innocuous warning, and that is that the input now is in order of operation. It did not use to be that, and I always reverted to the old command when I needed to use arguments (for at least a year).
Glad it helped!
Thanks again!
However, I still have a /var/run/problem.
cat /var/log/Xorg.0.log seems to say:
[ 33.339] (EE) Failed to open authorization file "/var/run/slim/slim.auth": No such file or directory
I do not understand where this is coming from. I have the following patch that I modified.
And also the spec file, but I can not see why I end up with this failure.
There does not appear to be any warnings while builing the RPM from what I can tell.
Many thanks again and best wishes, Ranjan