F41 -> F42 (openbox+slim: X does not get started)

[Ranjan Maitra]

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

[Ranjan Maitra]

On Fri May23'25 04:53:58PM, Community Support for Fedora Users wrote:
> From: Ranjan Maitra via users 
> Date: Fri, 23 May 2025 16:53:58 -0500
> To: Community Support for Fedora Users 
> Cc: Ranjan Maitra 
> Reply-To: Community support for Fedora users 
> 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

[Ranjan Maitra]

Hi Francis,

Thanks very much for this!

On Sat May31'25 07:48:07AM, [e-mail] wrote:
> From: [e-mail]
> Date: Sat, 31 May 2025 07:48:07 +0200
> To: Community support for Fedora users 
> CC: Ranjan Maitra 
> Reply-To: Community support for Fedora users 
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Todd Zullinger]

Ranjan Maitra via users wrote:
> On Sat May31'25 07:48:07AM, [e-mail] 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:
>
> https://paste.centos.org/view/f54fe5e6

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.

[Ranjan Maitra]

Todd,

Thank you for this!

On Sat May31'25 04:18:49PM, Todd Zullinger wrote:
> From: Todd Zullinger 
> Date: Sat, 31 May 2025 16:18:49 -0400
> To: [e-mail]
> Reply-To: Community support for Fedora users 
> Subject: Re: F41 -> F42 (openbox+slim: X does not get started)
>
> Ranjan Maitra via users wrote:
> > On Sat May31'25 07:48:07AM, [e-mail] 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:
> >
> > https://paste.centos.org/view/f54fe5e6
>
> 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  - 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

[Todd Zullinger]

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

[Ranjan Maitra]

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  - 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> 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:
> https://paste.centos.org/view/f54fe5e6

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 [e-mail] 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.

[Todd Zullinger]

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

[Todd Zullinger]

[e-mail] wrote:
> On Sun, 01 Jun 2025 07:48:16 +0200 [e-mail] 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.

[Ranjan Maitra]

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

[Todd Zullinger]

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

[Ranjan Maitra]

On Sun Jun01'25 04:04:38PM, Todd Zullinger wrote:
> From: Todd Zullinger 
> Date: Sun, 1 Jun 2025 16:04:38 -0400
> To: [e-mail]
> Reply-To: Community support for Fedora users 
> 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

[Ranjan Maitra]

Thanks again!

On Sun Jun01'25 10:11:16AM, Todd Zullinger wrote:
> From: Todd Zullinger 
> Date: Sun, 1 Jun 2025 10:11:16 -0400
> To: [e-mail]
> Reply-To: Community support for Fedora users 
> Subject: Re: F41 -> F42 (openbox+slim: X does not get started)
>
> [e-mail] wrote:
> > On Sun, 01 Jun 2025 07:48:16 +0200 [e-mail] 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

[Todd Zullinger]

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.

[Ranjan Maitra]

Todd,

Thanks very much for this!

On Sun Jun01'25 09:09:55PM, Todd Zullinger wrote:
> From: Todd Zullinger 
> Date: Sun, 1 Jun 2025 21:09:55 -0400
> To: [e-mail]
> Reply-To: Community support for Fedora users 
> 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.jpg
>
> You 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

[Todd Zullinger]

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!

[Ranjan Maitra]

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,}.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. :)

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