Core Update 185

1

Curious if anyone has updated to 185… howdee go?

1 Like
2

Updated without problems.
System is running without issues.

3 Likes
3

Thanks Bernhard,

Just finished doing mine… smooth, no issues.

Suricata running OK with ThreatFox Indicators enabled apart from several messages in the Intrusion Detection log that I will followup - at quick glance suggests nothing major.

Kudos to the IPF Team for another job well done (I quite like the new red)

2 Likes
4

I have updated a IPFire and once the update was finished (for a while I think, since the WUI was left hanging), when I tried to access the Console again, I couldn’t.

I logged in via SSH and restarted Apache and since then, everything seems to be going perfectly.

Saludos.

1 Like
5

After the update the WUI should be accessible, just with my system.
Are you shure the update had finished? pakfire logs to /var/log/messages, where you can check this.

BTW: the console is the the KVM or serial interface, not the WUI. :wink:

7

for some reason the update did not take kindly to the zabbix pakfire addon and locked up the gui.

We rebooted, and ran pakfire via the CLI with no further issues.

Regards

BB

8

… or SSH right?

9

Me too.
System runs fine since 0900 this morning.

10

Hi all, I also had a minor WebGUI issue when I upgraded, the WebGUI froze on the “pakfire working” window, then when I refreshed, it said “ipfire refused to connect”, so I just left it for about 20 minutes, then I pushed the reset button on the box and once it was up and running, I gave it ANOTHER reboot from the status menu, just to be sure. No hassles since.

2 Likes
11

This is more than a rare problem. It happened on my main IPF, so after some 10 minutes frozen at the “pakfire working” window, I was able to switch tabs to System and execute a clean reboot.

It did not happen on my reserve IPF, which completed “pakfire working” and displayed a message “your system requires a reboot”. Quite different hardware from my main IPF.

1 Like
12

I don’t think so. The console is the direct access to the device. For SSH you need a functioning network.

13

Ah, ok. I should have understood that.

Console: hardware or physical access, as you stated.

Sorry for the OT bit… I had more coffee today.

14

Stuck at:

image
image1404×833 123 KB

the timer 30 seconds s either not working properly or also stuck.

Left it for almost 10 minutes, then will get it by the throat via IPMI and do a hard reboot. I have still have conn, but we shall see what happens after reboot.

Edit: and up again.

15

I had the same issues updating from 182->183 and from 183->185. In both cases, the “Pakfire is working” page never advanced, and when I hit refresh, my browser returned a Page Not Found. I had no access to the IPF WebUI. The first time, I was doing this remotely, so I had to drive to work on a Sunday to troubleshoot. I was able to log into IPFire from the command line, then issue a reboot command, which brought it back up. I had to do this a 2nd time going from 183->185. Fortunately, I was already onsite, so it wasn’t a big deal. But it makes me wonder about the next core update. I should plan on doing it onsite and not remotely just in case I cannot travel.

Forgot to mention, on other hardware, no issues at all. Update completed normally in the web UI and I was able to reboot from the Web UI. Hardware that worked normally was fanless Celeron J3160 appliance. Hardware that disconnected from the Web UI before the update completed was a desktop i5-4590 system.

16

When you have this Problem, then most of the time the Apache-Server is stuck.

Try this in the console:

/etc/init.d/apache restart

After that you should go back to your WebUI.

1 Like
17

Good to know. But still, I don’t remember this ever happening after an update until now. And it happened two times in a row; from 182->183 and again from 183->185. And there were several other reports of this behavior updating to 185 in this thread. Makes me wonder if there is an underlying issue.

18

It has happened on different Core Updates but for different reasons. This has already been covered in other posts.

The first issue was from CU180 to CU181.
After some investigation it seems that the runtime linker cache wasn’t up to date at the time Apache was being restarted, and therefore it simply failed to restart.
Based on that investigation a change was made in the apache initscript as per the commit.

apache2: Properly re-execute Apache on restart

Previously, we sent Apache a signal to relaunch itself which caused
Apache to kill all child processes, and re-execute them.

However, when updating glibc, any newly compiled modules could not be
loaded as Apache was running with the previous version of glibc until
the next reboot.

This change will now properly stop Apache and restart it which solves
this problem.

This changed from using the apache restart command to running the apache stop command followed by the apache start command.

In CU184 to 185 a similar problem occurred of apache ending up not running.

Further investigation of the apache stop command shows that it does not wait for all stop stages to have been completed before moving on to the next command in the initscript. So the apache start command was run but the apache stop command had not finished removing all the pid info and so the apache start command thought that if the pid is existing then apache is running so no need to start it up.

Unfortunately not all creators of initscripts ensure that a specific step has ben completed before moving on to the next one, which turns out to be the case with apache.

A new commit fix has now been made in CU186 (next branch)

initscripts: Correctly wait for Apache2 to terminate

This is achieved by telling killproc which PIDs to wait for.

The underlying theme is the apache initscript.

  • The apache restart command worked okay in the past but not when the glibc library was changed.

  • Running apache stop followed by apache start turns out not to wait till apache has fully stopped before trying to start apache.

3 Likes
19

Updated, WebUI was not responding, Did a reboot, looks like it’s working.

1 Like
20

So far I update 2 devices. Both I had to manually restart apache.

One had issues where it couldn’t find certain custom service objects (the were removed a while ago as a service, but apparently not from the group)

The other is giving me this error after upgrade.

[root@dragon ~]# /etc/init.d/firewall restart
Setting up firewall
modprobe: FATAL: Module nf_log_ipv4 not found in directory /lib/modules/6.1.61-ipfire                                                                  [  OK  ]
[root@dragon ~]#

I decided not to continue updating my other production systems.

21

I am presuming you upgraded from CU182 or earlier to CU185.

This indicates that something must have been stopped part way through the update.

This is saying that it was trying to look in the 6.1.61-ipfire directory but that should no longer be present or looked for as CU183 changed the kernel to 6.6.15

Can you check if you have a directory present that is labelled

/lib/modules/6.6.15-ipfire/

Can you also confirm if
lib/modules/6.1.6-ipfire/
exists or not and if it exists what files/directories does it have in it.

Can you give more details about what custom service objects you are referring to here?

1 Like