IPFire 2.27 Core Update 173, will it come out stable for arm32?

A dear developer friend of mine, gave me a 32-bit raspberry that I still cherish.
Just not to throw it away, I thought of installing the latest stable version of IPFire arm 32 on it.
The RED on the Raspberry 32, I want to connect it to the BLUE network of my IPFire x64 firewall, which I will continue to update.
On the GREEN of the RasbBerry, I want to enable the captive portal and use it for testing.
I plan (with a lot of patience), to “clone the mirror server of the arm32 ADDONs” on a local server of mine, so that I will always have the packets available even when they cannot be found in the future.
I am confident and excited to succeed in this experiment, but I would like to wait for the latest stable version of arm32.

If you confirm the 172 arm32 core is the latest, I will start working on it right away.

I thank you in advance.

Hi, I think the links below will be helpful:



CU172 is the latest current release for 32 bit arm but as shown in the blog link from @tphz it has been deprecated and CU173 will be the last release for 32 bit arm.

64 bit X86 and 64 bit arm will be the only architectures supported from CU174 onwards.


Yes. I actually know that arm32 is not safe and unsuitable.
I have followed the update posts over time.
I will certainly not use such a server as stable.

The RaspBerry 32 I already have. For playing games it might work. :wink:

I will wait for the stable core 173! :+1:

I read a few posts by @ms on Wiki,
All those interesting things about arm processors I didn’t know.

1 Like

Just out of curiosity, do you know when the CU173(stable) cores will come out?

I would expect somewhere in the next couple of weeks but that is just my estimate.

1 Like

I did the experiment described in this topic.
I did a clean installation (no imported configuration) of IPFire arm32 on my RaspBerry 32.
Often the machine freezes permanently and I have to turn it off and on again.
Has anyone experienced the same problem?
Maybe it is arm’s fault, as I read from @ms documentation?



With an exception stack the likelihood is that there is a bug in the kernel.

Basically the kernel developers have not been doing any 32 bit testing on kernel changes for some time.

Whatever the problem is it won’t get fixed now as this is the last 32 bit ARM version.

If you still want to experiment then you will need to try out CU172. The kernel version was changed last time in CU171 and maybe that doesn’t have the issues you are seeing with CU173

1 Like

Thank you very much @bonnietwin ,
I installed CU172, re-imported the backup (from the other version) and so far it is running great!!! :grin:
I do believe you are right. I, too, suspected a Kernel BUG.
I am sorry I did not test the CU173 arm32 testing :pensive:.
I could have done so and reported the BUG in time. :man_shrugging:
I will continue to work with CU172. In case of other anomalies I will update this topic for interested users. :wink:
Thank you all for the great work you do!!!

New machine:

Nothing. It seemed to go at first :pensive: :pensive: :pensive:.
I did a series of “blanket” reboot tests and the problem recurred even with CU172 arm 32.
I’m going to try going down one more version, and then again, I want to figure out what the last working version is.
Just out of my curiosity and for interested users like me.
I will report the results when I am more sure.

I explain the tests I did for arm32:

CU172, CU171, CU170, CU169, CU168 = same problem.
CU159, CU160 = Too much waiting time to configure IPFire via https.

Conclusion: I am not sure if it is a BUG of IPFire. Maybe my hardware is not suitable. Useless to do more testing.

I am curious - what Raspberry Pi model are you using?

From the profile it looks like this one:

I am not sure IPFire will operate with so little RAM.

1 Like


You guessed it!!!
Is that my RaspBerry!!!
The ram I think is 512 (I hope). Insufficient, I am also convinced of that. Definitely not the right hardware to run IPFire. I wanted to try it anyway. Patience. :man_shrugging: