[JENKINS-76296] Upgrading to jenkins-2.537-1.noarch on OpenSUSE breaks configuration

[jenkins-infra-bot]

I Just upgraded Jenkins to version 2.537 through zypper on OpenSUSE Leap 15.6. This changed my configuration files, prompting me to re-configure the system. I restored the saved configuration files, but having this happen in an undocumented manner does not look right.

 

Abrufen: jenkins-2.537-1.noarch (jenkins)                   (1/1),  91,6 MiB    
Abrufen: jenkins-2.537-1.noarch.rpm ..........................................................................................................................................<74%>=================================================[- (30,7 MAbrufen: jenkins-2.537-1.noarch.rpm .....................................................................................................................................................................................[fertig (22,0 MiB/s)]
Überprüfung auf Dateikonflikte läuft: ................................................................................................................................................................................................[fertig]
warning: /etc/zypp/repos.d/jenkins.repo saved as /etc/zypp/repos.d/jenkins.repo.rpmsave
warning: /etc/sysconfig/jenkins saved as /etc/sysconfig/jenkins.rpmsave
(1/1) Installieren: jenkins-2.537-1.noarch ...........................................................................................................................................................................................[fertig]

New repo file:

[jenkins]
name=Jenkins
enabled=1
autorefresh=0
baseurl=https://pkg.jenkins.io/opensuse
type=rpm-md
keeppackages=0

Old repo file:

[jenkins]
enabled=1
autorefresh=1
baseurl=https://pkg.jenkins.io/opensuse/
type=rpm-md

This means the automatic refreshing has been disabled.

Moving the sysconfig file would change the data directory as well, leading to the aforementioned issue which prompted me for a new installation.

 

 

---

Originally reported by stefan6419846, imported from: Upgrading to jenkins-2.537-1.noarch on OpenSUSE breaks configuration

• status: Open
• priority: Minor
• component(s): core
• resolution: Unresolved
• votes: 0
• watchers: 3
• imported: 2025-11-24

Raw content of original issue

I Just upgraded Jenkins to version 2.537 through zypper on OpenSUSE Leap 15.6. This changed my configuration files, prompting me to re-configure the system. I restored the saved configuration files, but having this happen in an undocumented manner does not look right.

 

Abrufen: jenkins-2.537-1.noarch (jenkins)                   (1/1),  91,6 MiB    
Abrufen: jenkins-2.537-1.noarch.rpm ..........................................................................................................................................<74%>=================================================[- (30,7 MAbrufen: jenkins-2.537-1.noarch.rpm .....................................................................................................................................................................................[fertig (22,0 MiB/s)]
Überprüfung auf Dateikonflikte läuft: ................................................................................................................................................................................................[fertig]
warning: /etc/zypp/repos.d/jenkins.repo saved as /etc/zypp/repos.d/jenkins.repo.rpmsave
warning: /etc/sysconfig/jenkins saved as /etc/sysconfig/jenkins.rpmsave
(1/1) Installieren: jenkins-2.537-1.noarch ...........................................................................................................................................................................................[fertig]


New repo file:

[jenkins]
name=Jenkins
enabled=1
autorefresh=0
baseurl=https://pkg.jenkins.io/opensuse
type=rpm-md
keeppackages=0

Old repo file:

[jenkins]
enabled=1
autorefresh=1
baseurl=https://pkg.jenkins.io/opensuse/
type=rpm-md

This means the automatic refreshing has been disabled.
Moving the sysconfig file would change the data directory as well, leading to the aforementioned issue which prompted me for a new installation.
 
 

environment

Jenkins 2.537
OpenSUSE Leap 15.6

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  Thanks for reporting the issue.  The 2.537 weekly release is trying to improve the RPM support in the Jenkins project by using a single modernized RPM file for both Red Hat based distributions and openSUSE based distributions.  However, it appears that Fedora Linux (dnf) does not support autorefresh=1 (Fedora discussion) and yet you are indicating that is a crucial part of the openSUSE repo definition.  Can you provide further pointers to autorefresh for openSUSE?
  
  I am surprised that it made any change to /etc/sysconfig, since Jenkins switched from SysV init to systemd in the Linux packages several years ago.  Refer to the "Managing systemd services" documentation.  Have you made any local changes that cause the Jenkins unit to read from /etc/sysconfig?
  

Thanks for reporting the issue. The 2.537 weekly release is trying to improve the RPM support in the Jenkins project by using a single modernized RPM file for both Red Hat based distributions and openSUSE based distributions. However, it appears that Fedora Linux (dnf) does not support autorefresh=1 (Fedora discussion) and yet you are indicating that is a crucial part of the openSUSE repo definition. Can you provide further pointers to autorefresh for openSUSE?

I am surprised that it made any change to /etc/sysconfig, since Jenkins switched from SysV init to systemd in the Linux packages several years ago. Refer to the "Managing systemd services" documentation. Have you made any local changes that cause the Jenkins unit to read from /etc/sysconfig?

[jenkins-infra-bot]

stefan6419846:

• Original comment link
• Raw content of original comment:

  Regarding autorefresh: It is no explicit crucial part, but beneficial as this basically detects automatically when a repository becomes out of date and should be refreshed. The goal is to basically run 
  
  zypper up
  
   without having to call 
  
  zypper ref
  
   beforehand. OpenSUSE user documentation on this is available at https://en.opensuse.org/SDB:Zypper_usage#Refreshing_repositories
  Regarding SysV init versus systemd: The base of this Jenkins installation is rather old and it worked until now. Looking into my configuration files, we load the old configuration inside the override.conf to populate the systemd environment:
  
  [Unit]
  ConditionDirectoryNotEmpty=/home/jenkins
  [Service]
  
  EnvironmentFile=-/etc/sysconfig/jenkins
  [Service]
  
  TimeoutStartSec=600
  
  
  
  Although possibly undocumented, setting the environment variables this way has never been an issue before (as long as the sysconfig file is present), including at least JENKINS_HOME, JENKINS_PORT and JENKINS_JAVA_OPTIONS as far as I can tell from the processes directly.
  

Regarding autorefresh: It is no explicit crucial part, but beneficial as this basically detects automatically when a repository becomes out of date and should be refreshed. The goal is to basically run 

zypper up

 without having to call 

zypper ref

 beforehand. OpenSUSE user documentation on this is available at https://en.opensuse.org/SDB:Zypper_usage#Refreshing_repositories

Regarding SysV init versus systemd: The base of this Jenkins installation is rather old and it worked until now. Looking into my configuration files, we load the old configuration inside the override.conf to populate the systemd environment:

[Unit]
ConditionDirectoryNotEmpty=/home/jenkins

[Service]
EnvironmentFile=-/etc/sysconfig/jenkins

[Service]
TimeoutStartSec=600

Although possibly undocumented, setting the environment variables this way has never been an issue before (as long as the sysconfig file is present), including at least JENKINS_HOME, JENKINS_PORT and JENKINS_JAVA_OPTIONS as far as I can tell from the processes directly.

[jenkins-infra-bot]

dduportal:

• Original comment link
• Raw content of original comment:

  Thanks for raising this issue stefan6419846! We are working on updating the changelog and eventually fix the SUSE packaging. As explained by markewaite it is a set of consequences of unifying the RPM generation for both openSUSE and RedHat which brought some "changes" already made months ago on RedHat but not on openSUSE package.
  
  
  	
  First thing first: not documented yet (work in progress). If you need to rollback to 5.236 or lower, you "only" have to update the repository URL to use https://pkg.jenkins.io/opensuse-legacy. It's a copy of the former https://pkg.jenkins.io/opensuse with all former weekly versions of Jenkins up to 2.536 (but not newer).
  	
  Second: we acknowledge the missing "autorefresh". We'll investigate this regression to fix it for the 2.539 weekly release next week. Thanks for the detailed report!
  	
  Third: the systemd/sysv:
  	
  
  		
  systemd support on OpenSuse (and all Linux installers for Jenkins) happened in 2022. Here is the blog post entry with many tricks to help you on the migration: https://www.jenkins.io/blog/2022/03/25/systemd-migration/#package-configuration
  		
  Merging Redhat and openSUSE package generation brought to openSUSE the change "removal of former SysV script" from Redhat from Jenkins Core 2.417 to the openSUSE installer. I guess it was forgotten since August 2023. Ref. https://www.jenkins.io/changelog-old/#v2.417:
  
  Remove System V initialization scripts from RPM based installers. The System V initialization scripts were replaced in March 2022 with systemd initialization. RPM users with a custom log directory no longer have a logrotate(8) configuration out-of-the-box.
  	
  	
  
  
  

Thanks for raising this issue stefan6419846! We are working on updating the changelog and eventually fix the SUSE packaging. As explained by markewaite it is a set of consequences of unifying the RPM generation for both openSUSE and RedHat which brought some "changes" already made months ago on RedHat but not on openSUSE package.

• First thing first: not documented yet (work in progress). If you need to rollback to 5.236 or lower, you "only" have to update the repository URL to use https://pkg.jenkins.io/opensuse-legacy. It's a copy of the former https://pkg.jenkins.io/opensuse with all former weekly versions of Jenkins up to 2.536 (but not newer).
• Second: we acknowledge the missing "autorefresh". We'll investigate this regression to fix it for the 2.539 weekly release next week. Thanks for the detailed report!
• Third: the systemd/sysv:
  • systemd support on OpenSuse (and all Linux installers for Jenkins) happened in 2022. Here is the blog post entry with many tricks to help you on the migration: https://www.jenkins.io/blog/2022/03/25/systemd-migration/#package-configuration
  • Merging Redhat and openSUSE package generation brought to openSUSE the change "removal of former SysV script" from Redhat from Jenkins Core 2.417 to the openSUSE installer. I guess it was forgotten since August 2023. Ref. https://www.jenkins.io/changelog-old/#v2.417:

    Remove System V initialization scripts from RPM based installers. The System V initialization scripts were replaced in March 2022 with systemd initialization. RPM users with a custom log directory no longer have a logrotate(8) configuration out-of-the-box.

[jenkins-infra-bot]

dduportal:

• Original comment link
• Raw content of original comment:

  
  Second: we acknowledge the missing "autorefresh". We'll investigate this regression to fix it for the 2.539 weekly release next week. Thanks for the detailed report!
  
  I believe the root cause is the removal of this file: https://github.com/jenkinsci/packaging/pull/430/files#diff-5a74a5e43ac334c0d5dbf0a7f74387a82ffec7f20bb65322a964e6420aad2fa9 without transplanting the `autorefresh` parameter on the unified RPM. Gotta check this one ASAP
  

Second: we acknowledge the missing "autorefresh". We'll investigate this regression to fix it for the 2.539 weekly release next week. Thanks for the detailed report!

I believe the root cause is the removal of this file: https://github.com/jenkinsci/packaging/pull/430/files#diff-5a74a5e43ac334c0d5dbf0a7f74387a82ffec7f20bb65322a964e6420aad2fa9 without transplanting the `autorefresh` parameter on the unified RPM. Gotta check this one ASAP

[jenkins-infra-bot]

dduportal:

• Original comment link
• Raw content of original comment:

  And opened fix(weekly 2.537 changelog) add missing item around RPM packaging jenkins-infra/jenkins.io#8551 to add an entry in the changelog. I'm really sorry for the annoyance here.
  
  Please note, due to these "surprises", the packaging unification has been postponed for LTS release from the 2.528.3 planned for 10th December 2025, to the January `2.xxx.1` LTS release (xxx because baseline not selected yet).
  

And opened jenkins-infra/jenkins.io#8551 to add an entry in the changelog. I'm really sorry for the annoyance here.

Please note, due to these "surprises", the packaging unification has been postponed for LTS release from the 2.528.3 planned for 10th December 2025, to the January `2.xxx.1` LTS release (xxx because baseline not selected yet).

[jenkins-infra-bot]

stefan6419846:

• Original comment link
• Raw content of original comment:

  Thanks for the explanation. This has been a very unfortunate chain of events here, as after fixing the configuration, I ran into the SSH bug which was fixed in 2.538 in the meantime, reverting to the old package did not work due to possibly not serving the old release anymore on this repo.
  
  I have identified the root cause for my setup: When migrating our Jenkins installation to use configuration management, we used an old override.conf (relying on the old SysV configuration) and deployed it before initially installing the Jenkins package itself. Thus, the migration would never trigger.
  
  If someone happens to stumble upon the same issue: Stop the service, rename /etc/systemd/system/jenkins.service.d/override.conf, then run bash /usr/share/jenkins/migrate /etc/sysconfig/jenkins and the override.conf should use the correct values (for "broken" setups: replace /etc/sysconfig/jenkins with /etc/sysconfig/jenkins.rpmsave accordingly).
  
  I will leave this issue open for you to further investigate the autorefresh part.
  

Thanks for the explanation. This has been a very unfortunate chain of events here, as after fixing the configuration, I ran into the SSH bug which was fixed in 2.538 in the meantime, reverting to the old package did not work due to possibly not serving the old release anymore on this repo.

I have identified the root cause for my setup: When migrating our Jenkins installation to use configuration management, we used an old override.conf (relying on the old SysV configuration) and deployed it before initially installing the Jenkins package itself. Thus, the migration would never trigger.

If someone happens to stumble upon the same issue: Stop the service, rename /etc/systemd/system/jenkins.service.d/override.conf, then run bash /usr/share/jenkins/migrate /etc/sysconfig/jenkins and the override.conf should use the correct values (for "broken" setups: replace /etc/sysconfig/jenkins with /etc/sysconfig/jenkins.rpmsave accordingly).

I will leave this issue open for you to further investigate the autorefresh part.

[jenkins-infra-bot]

dduportal:

• Original comment link
• Raw content of original comment:

  Thanks Stefan! 
  
  WDYT about the updated changelog: https://www.jenkins.io/changelog/#v2.537 ? Would have it helped you if defined earlier (asking for other contributors)
  

Thanks Stefan!

WDYT about the updated changelog: https://www.jenkins.io/changelog/#v2.537 ? Would have it helped you if defined earlier (asking for other contributors)

[jenkins-infra-bot]

stefan6419846:

• Original comment link
• Raw content of original comment:

  For me the updated changelog looks good and provides the necessary context on why these configuration files were moved/changed. Special setups like mine would still require some investigation, but most users should remain unaffected.
  

For me the updated changelog looks good and provides the necessary context on why these configuration files were moved/changed. Special setups like mine would still require some investigation, but most users should remain unaffected.