Bug 13590 - Freeradius not starting: libssl version mismatch
Summary: Freeradius not starting: libssl version mismatch
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: x86_64 Unspecified
: Will only affect a few users Crash
Assignee: Michael Tremer
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-15 16:26 UTC by datamorgana
Modified: 2025-08-10 13:16 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description datamorgana 2024-02-15 16:26:02 UTC
After an update of IPFire to core183, Freeradius refuses to start.
No logs are written.

Manual debugging shows a version mismatch of libssl and freeradius:

# /usr/sbin/radiusd -X -d /etc/raddb
libssl version mismatch.  built: 30100020 linked: 30200010

Thanks for reading.
Comment 1 Michael Tremer 2024-02-15 16:28:48 UTC
Can you try to back up your configuration, uninstall the package and install it again, please?
Comment 2 Adolf Belka 2024-02-15 16:39:14 UTC
@Michael

If freeradius is linked to openssl then presumably freeradius has to have its PAK_VER bumped and be shipped with the core update.


If my understanding is correct then I can do a patch submission to bump and ship freeradius for CU184.
Comment 3 Michael Tremer 2024-02-15 16:42:24 UTC
Yes, this would be the fix. A reinstall would confirm that.

I forgot to mention that it would be a good idea to empty the package cache in /var/cache/pakfire before install.
Comment 4 datamorgana 2024-02-15 16:52:04 UTC
What do I have to do to reinstall only the patched freeradius package?
Can I leave IPFire as it is and do only a reinstall of freeradius?
Will the freeradius configuration be affected/deleted?
Comment 5 Michael Tremer 2024-02-15 16:56:13 UTC
(In reply to datamorgana from comment #4)
> Will the freeradius configuration be affected/deleted?

It should be automatically be backed up, but just to be sure, have a backup.

> What do I have to do to reinstall only the patched freeradius package?
> Can I leave IPFire as it is and do only a reinstall of freeradius?

Yes, you only need to reinstall the freeradius package.
Comment 6 datamorgana 2024-02-15 18:28:04 UTC
Thanks!

And how will I receive notice of the newly updated freeradius package?
Will it be listed in Packfire's "Available Updates" after a click on "Refresh List" while still having not uninstalled the package, or do I need to uninstall the package first and "Refresh List" or just wait?
Comment 7 datamorgana 2024-02-15 18:29:29 UTC
(In reply to Michael Tremer from comment #3)
> Yes, this would be the fix. A reinstall would confirm that.
> 
> I forgot to mention that it would be a good idea to empty the package cache
> in /var/cache/pakfire before install.

# ls -la freeradius*
-rw-r--r-- 1 root root 2403485 Nov 18  2020 freeradius-3.0.21-12.ipfire
-rw-r--r-- 1 root root 2403944 Mar 28  2021 freeradius-3.0.21-13.ipfire
-rw-r--r-- 1 root root 1925542 Oct 25  2021 freeradius-3.0.23-14.ipfire
-rw-r--r-- 1 root root 1946169 Nov  4  2022 freeradius-3.0.23-15.ipfire
-rw-r--r-- 1 root root 1945708 Mar  7  2023 freeradius-3.0.23-16.ipfire
-rw-r--r-- 1 root root 1969214 Jun 17  2023 freeradius-3.0.26-17.ipfire
-rw-r--r-- 1 root root 1975527 Jul 19  2023 freeradius-3.0.26-18.ipfire
-rw-r--r-- 1 root root 1999033 Oct 13 16:49 freeradius-3.2.3-19.ipfire

All of them, or just freeradius-3.0.21-12.ipfire?
Comment 8 datamorgana 2024-02-15 18:33:31 UTC
(In reply to datamorgana from comment #7)
> (In reply to Michael Tremer from comment #3)

> All of them, or just freeradius-3.0.21-12.ipfire?

Sorry, I meant the latest, freeradius-3.2.3-19.ipfire but it would probably safe to just delete all.
Comment 9 Michael Tremer 2024-02-15 18:53:48 UTC
All is fine. The older ones won't be used anyways.
Comment 11 Michael Tremer 2024-02-16 12:36:07 UTC
Merged into master.
Comment 12 datamorgana 2024-02-29 17:23:00 UTC
I did a successful re-install of the addon freeradius-3.2.3-19.
Tests with the patched freeradius were also successful.
Thanks a lot!

I will set the issue to CLOSED / FIXED.
Comment 13 datamorgana 2025-07-03 06:57:57 UTC
After update to "IPFire 2.29 (x86_64) - Core-Update 195" on 2025-07-03,
Freeradius won't start.

Here is the debug log, captured with:

# /usr/sbin/radiusd -X 2>&1 | tee /var/log/radius/debug.1.log
libssl version mismatch.  built: 30400000 linked: 30500000

Reopening bug #13590 from 2024-02-15 16:26:02 UTC

Thanks
Comment 14 datamorgana 2025-07-03 06:58:47 UTC
Reopened.
Comment 15 Michael Tremer 2025-07-03 07:36:07 UTC
(In reply to datamorgana from comment #14)
> Reopened.

Thank you. This will be fixed in c196.
Comment 16 Adolf Belka 2025-07-06 14:02:00 UTC
The bumped radius is available via CU196 Testing.
Comment 17 Adolf Belka 2025-07-06 14:40:33 UTC
This can only be tested by a user that already had freeradius installed in CU194 prior to the latest bump.

In any of my testing with CU195 or CU196 installing freeradius gives a working system as the install uses the bumped version with the correct openssl version.

Testing confirmation will need to be carried out by the original bug reporter.
Comment 18 datamorgana 2025-07-06 20:10:18 UTC
So this time it doesn't suffice to delete the cached /var/cache/pakfire/freeradius-3.2.6-23.ipfire, does it? Unfortunately I do not have a testing environment for IPFire, so if you could be so kind and direct me to the bumped version of freeradius-3.2.6-23.ipfire so that I can install, test and confirm it. Thanks.
Comment 19 Adolf Belka 2025-07-07 11:16:07 UTC
(In reply to datamorgana from comment #18)
> So this time it doesn't suffice to delete the cached
> /var/cache/pakfire/freeradius-3.2.6-23.ipfire, does it? Unfortunately I do
> not have a testing environment for IPFire, so if you could be so kind and
> direct me to the bumped version of freeradius-3.2.6-23.ipfire so that I can
> install, test and confirm it. Thanks.

You can delete the cached version and re-install and it will fix your problem but I am not sure if it tests the change we have made or not.

The simplest way would be to change the system to the Testing version and see if that fixed it but if that is something that you can't do then I think we will have to leave it as it is.

The change is simple enough that I am certain it will fix this problem.