After upgrading from Core 198/199 to Core 200, the lldpd service remains visible in the WebGUI status page but is permanently stuck in the "STOPPED" state. Investigations show that while the package has been removed from the Pakfire repositories, existing installations are not being cleaned up, and the binary becomes dysfunctional due to kernel/library mismatches. Steps to Reproduce: Start with an IPFire installation (Core 198 or 199) where lldpd was previously installed. Verify lldpd is running (/etc/init.d/lldpd status returns RUNNING). Perform an upgrade to Core 200 via Pakfire. After reboot (Kernel 6.18), observe the WebGUI: Link Layer Discovery Protocol is listed but marked as STOPPED. Attempting to start the service manually fails to create a PID file in /var/run/lldpd.pid. Observed Behavior: pakfire info lldpd returns: PAKFIRE WARN: Pak 'lldpd' not found. The binary /usr/sbin/lldpd remains on the system but fails to fork/daemonize correctly under the 6.18 kernel. Removing the init script (mv /etc/init.d/lldpd /root) and restarting the web server does not remove the entry from the WebGUI Status page, indicating a hardcoded or stale configuration entry in the services monitoring logic. Environment: Hardware: x86_64 Pre-upgrade: Core 199 (Kernel 6.12.58) Post-upgrade: Core 200 (Kernel 6.18.7) Installation source: Restored from a Core 199-based ISO backup. Suggested Fix: Ensure that if a package is deprecated and removed from Pakfire, the upgrade script explicitly handles the removal of the binary, the init script, and the entry in the services monitoring database to prevent "ghost services" in the WebGUI.
(In reply to Arno Jonker from comment #0) > After upgrading from Core 198/199 to Core 200, the lldpd service remains > visible in the WebGUI status page but is permanently stuck in the "STOPPED" > state. Investigations show that while the package has been removed from the > Pakfire repositories, existing installations are not being cleaned up, and > the binary becomes dysfunctional due to kernel/library mismatches. > LLPD has not been removed from the pakfire repositories. LLPD is not an addon it is a core program and has been seen it was introduced in CU199, so it could not have been present on a CU198 system. I created a CU198 fresh install. Confirmed that llpd was not present on the system, either as a binary nor the WUI page. I updated with the stable branch from CU198 to CU199. The LLPD WUI page is now available. I enabled it and pressed the save button. It now moved from Stopped to Started. Also on the Services page it moved from Stopped to Started. I also checked the initscript status and it also said it was running. I then changed to the Testing branch and updated to CU200 Testing and rebooted. After the reboot LLPD was not running and this was because it had been disabled on the WUI page. I enabled it and it was now running.
To clarify the issue. It occurs when updating from CU199 to CU200 Testing. An enabled LLPD after the update and reboot is no longer enabled. This change of LLPD going from enabled to disabled should not occur during the update. That is a bug. The previous setting should stay in place.
For IPFire2.x bugs the component should always be --- as described in the documentation.
After enabling LLPD again in CU200 Testing, I then rebooted the system again and after this the LLPD was still running, so the issue is not related directly to the initscript as that works correctly if LLPD is set as enabled. The issue must be related to something in the update.sh script.
I have modified the title of this bug to better reflect the bug found.
Corrected LLPD to LLDP in title.
After further investigation the cause has been identified. LLDP was introduced in CU199 for the first time, so the install in CU199 just puts an empty settings file into /var/ipfire/lldp/ When updating to a Testing release pakfire first does an update of the previous CU before running the actual CU update. This is to ensure that on systems that have been used for testing that the latest version of the previous CU was fully installed. For CU200 Testing this means that first CU199 update is run, which installs LLDP as from a fresh install. This replaces any existing settings file with an empty file. When CU200 goes to final release then the update will just do CU200 and this problem will not occur as the existing settings file will be kept. I will keep this bug open until CU200 has had its full release and the above has been confirmed at which point I will close it. In the meantime the issue can be resolved by just enabling LLDP and entering the description or by doing a restore of a CU199 backup.
Hello, do we have a more permanent solution for this? I agree that the LLDP settings are easy enough to restore, but this might happen again in the future with other settings which might be more difficult.
(In reply to Michael Tremer from comment #8) > Hello, > > do we have a more permanent solution for this? I agree that the LLDP > settings are easy enough to restore, but this might happen again in the > future with other settings which might be more difficult. I understand what you are saying. Any new function in a CU could then be overwritten in the CU Testing version after it. The only options I can easily think off are * Stop doing the CU of the previous version when doing a Testing update * Have an option to disable the previous CU version update when required.