Error: ipv4: FIB tables does not exist

I noticed this error on booting (Core 161, 64-bit):
“Error: ipv4: FIB tables does not exist.”

Searching for it didn’t yield too many results. Nothing useful for me.
Anyone knows what this means?

This looks to be due to updates in both iproute2 and the kernel that now show a message when a table is not present when it is checked for whereas in the past if the table was not there then no message was provided.

An update was done in iproute2 around3 years ago that enabled strict checking and newer kernels have been changed to better inform the user of what happens to a request when strict checking is enabled.

So the table has always not existed at boot stage but in the past no message was given. Now a message is given.

So nothing to worry about from my understanding.

I found the information in the following mail thread from the iproute2 mailing list.

https://www.mail-archive.com/netdev@vger.kernel.org/msg291638.html

A bit more searching and I have found that a fix to stop showing that message has been applied to iproute2-5.14.0 which was implemented into Core Update 161.
Running an ip route show command as per the mail thread still gives the same error message so the iproute2 fix does not look to have worked.

I will look a bit further but there is nothing to worry about the message itself.

2 Likes

The patch applied to iproute2 was designed to prevent showing the message when a dump of the tables was being done and any of the tables are empty.

In CU162 running ip route save > dump no longer gives the message and that was what the iproute2 people were trying to stop.

If you run ip route show table default then you still get the error message.

I will see if I can figure out what ip command is being run at that stage of the booting.

2 Likes

Thanks for the info!

Hello,
One of the machines that runs core 162 does ALWAYS generate there logs when Squid is started
The other machine does not generate these:

Starting Squid Proxy Server…
2021/12/30 15:20:19| WARNING: BCP 177 violation. Detected non-functiona[ OK ]oopback.
Error: ipv4: FIB table does not exist.
Flush terminated
RTNETLINK answers: No such file or directory

Any way to generate that FIB table in the machine that complains about it?
Thank you,
H&M

It is a table that is not needed in IPFire so no point in creating it.

The fix from the kernel people was to not show the message when a dump of all the tables is done and any of them are missing. Basically the dump just saves all tables that exist.

However if you show all the default tables then you still get the message that some of them are empty, even if that is the desired situation.

I looked through the source code but was not able to identify what, in the booting process, is triggering this to be shown.
It might even be that it can’t be fixed in IPFire but requires a fix in the kernel.

My view is to just leave it as it is. Alternatively someone with more code knowledge than me will have to raise it as a bug, spend their time tracking it down and then figure out how to fix it or go and try and persuade the kernel people to fix it.

The RTNETLINK answers: No such file or directory message is also something that will always be there. @arne_f has indicated that

This is normal after connecting. This is a cleanup code that run’s more than one time but we cannot remove it because this breaks the wireless client.

1 Like