Trouble running core 183 on an APU4d4 board

Hardware
1

After the update from core 182 to 183 several services stopped working.

  • OpenVPN client does not connect anymore
  • IGMPproxy stopped working (console is flooded with “mroute: pending queue full, dropping entries”
  • Web service stopping after a few hours
  • Routing between green and blue not possible
  • Pakfire hangs
  • reboot cmd (command-line and web button) hangs, system does not reboot
  • Edid/add devices on “Blue Access” not possible
  • Only internet access (green and blue) is possible

Okay, something went wrong wth the update. So I wiped the disk, reinstalled the 183 iso image from a flash drive and made a fresh installation.
After installing the needed add-ons I restored the backup files, made on core 182.
(main backup, igmpproxy, guardian, wio).
After that the IPfire got unsable again, same as after the online update.

So to be sure, I downloaded again a fresh 183 iso image and did the whole procedure again. Same thing.

To solve the problem I downloaded core 182, installed it and restored the same backup files. Everything fine!!! IPfire and all services are up and running.
Now I’m trapped to stay on 182 for a longer time.

I don’t know exactly how to trace down the problem, perhaps something is wrong in the kernel, but it has to be related to the APU4 board, otherwise a lot of complains would have came in.

It’s definitely not the hardware, cause 182 is running smoothly.
Does anyone else observed this problem?

2

I have an APU4 board and that has worked fine with CU183.

3

Sorry, mine is a APU4(d4) as well. I corrected the topic name.

It is really strange…

4

That is very strange.

You have also had the problem with both doing a Core Update from 182 to 183 and doing a fresh install of Core Update 183 and that is even more strange.

If the problem happens consistently for you when upgrading from Core Update 182 to 183 then only thing I can suggest is to look through the Core Update log to see if there are any messages of something going wrong during the Core Update phase or if that completes successfully, in which case the issue is occurring after that.

Your experience with the fresh install suggests the problem is not with the install itself as you mention the issues occurred after the restore of the addons.

You could look in the logs to see if there are any messages from the restore stage.

You could also try doing a fresh CU183 install and then do the addon restores one at a time and check if everything is okay before restoring the next.

That way you could identify which addon restore is causing the problem, if that is actually the case.

My systems (physical and virtual) all have the wio addon but none have the guardian or igmpproxy addons.

However neither of those have had any updates for quite a while so certainly no issues would be expected from the update from 182 to 183 for those addons.

No real other suggestions to make unfortunately.

1 Like
5

I had a similar issue.
After upgrading to 183 my terminal got flooded with network messages. IPFIRE wasn’t reachable via Browser nor SSH. I wasn’t able to login and reboot wasn’t working too.
My solution:

  • Unplugged all network cables
  • Hard reset
  • Waited until login appeared (took some time because of several timeouts)
  • Plugged in GREEN cable
  • Waited until access via web-browser worked again
  • uninstalled IGMPPROXY with pakfire
  • plugged in RED cable
  • reboot immediately
  • Everything worked again (ignored IGMPPROXY error messages)
6

Hi @fax_number

Welcome to the IPFire community.

As you did not need to reinstall to get it working then you could look in the upgrade logs to see what messages there are.

The file would be
/var/log/pakfire/update-core-upgrade-183.log

1 Like
7

The log doesn’t show any unusal messages or errors. No clue why IGMPPROXY is causing errors

8

So that suggests the core update is not the cause of the issue.

What is in the /var/log/messages file if you grep for igmpproxy?

9

The only unusal messages are from kernel:

Mar  6 18:03:29 ipcop kernel: CPU: 1 PID: 4245 Comm: igmpproxy Not tainted 6.6.15-ipfire #1
Mar  6 18:03:29 ipcop kernel: CPU: 1 PID: 4245 Comm: igmpproxy Tainted: G      D            6.6.15-ipfire #1
Mar  6 18:04:29 ipcop kernel: task:igmpproxy       state:D stack:0     pid:4245  ppid:1      flags:0x00004002
Mar  6 18:07:29 ipcop kernel: task:igmpproxy       state:D stack:0     pid:4245  ppid:1      flags:0x00004002
Mar  6 18:10:29 ipcop kernel: task:igmpproxy       state:D stack:0     pid:4245  ppid:1      flags:0x00004002
Mar  6 18:13:29 ipcop kernel: task:igmpproxy       state:D stack:0     pid:4245  ppid:1      flags:0x00004002
Mar  6 18:16:29 ipcop kernel: task:igmpproxy       state:D stack:0     pid:4245  ppid:1      flags:0x00004002
Mar  6 18:19:29 ipcop kernel: task:igmpproxy       state:D stack:0     pid:4245  ppid:1      flags:0x00004002

They appeared first after upgrading to 183 and then after each reboot

BTW: “ipcop” is the name of my PC (old habits :wink: )

10

The flags for the tainted status mean that

  • G - all modules loaded were GPL compatible (so that is good - means no proprietary modules)
  • D - the kernel died recently, ie there was an OOPS or BUG

So it didn’t quite go into a kernel panic but there was some problem between the kernel and igmpproxy causing the kernel to die.

As igmpproxy has not been updated for a year and a half, the likelihood is that some change in the kernel is causing a mismatch with igmpproxy.
In CU183 the kernel was updated from 6.1.61 to 6.6.15. It could also be that the kernel update has fixed some issue that now means that igmpproxy needs to also be updated.

Hopefully the problem will be fixed by an updated igmpproxy or kernel update.

It might be good if this issue could be reported into the igmpproxy issues page
https://github.com/pali/igmpproxy/issues?q=is%3Aissue+
to see if anyone else is having a similar problem with igmpproxy and the 6.6 kernel base.

1 Like
11

@bonnietwin, that’s a really good analysis and I think this could really be the cause of that problem, not the hardware.

Perhaps there is some feedback from other users which use the igmpproxy.
Is the igmpproxy project still actively maintained?

Unfortunately it’s a must install for me to watch German Telekom TV.

12

It depends on how you define actively.

The last commit to the igmpproxy github repo was made in Jan 2023.

The last closed issue was in October 2022.

The date of the most recently opened issue is May 2023.

So there is some activity but not a huge amount.

You will probably need to re-install CU182 and stay with that for the moment.

Currently the kernel version in CU184 and what will become CU185 has not been updated compared to CU183 so nothing to test out there.

13

I continue this topic here, instead of opening a new one “igmpproxy not working”.

As known so far, igmpproxy does not work on core 183 and up anymore and causes a kernel crash which results in an unusable system.

First suggestion was a relation to the kernel update from 6.0 to 6.6.
This is reported here on the igmpproxy github repo
But as described above by Thomas, igmpproxy 0.4 (without modification) seems to be working again in the latest dev core 186.

Out of curiosity, is there a relevant change/fix concerning the kernel in core 186?

14

CU185 has linux kernel 6.6.15.

The kernel version in what will be CU186 is currently 6.6.28 as of April 17th with around 6 updates since CU185.

1 Like
15

This isn’t good at all. igmpproxy looks pretty unmaintained looking at the last commits and bug reports. Are there any alternatives to it?

16

check the system log file to see the error or warning related information which can provide the root cause of the error.