I just upgraded to build 190 on my backup firewall and FRR now fails to start with the following errors:
[root@firewall-02 ~]# frr start
Loading capability module if not yet done.
egrep: warning: egrep is obsolescent; using grep -E
/usr/sbin/zebra: symbol lookup error: /usr/lib/…/lib64/libfrr.so.0: undefined symbol: ly_temp_log_options
I verified that libfrr.so.0 exists. I’m not sure how to resolve.
Hallo @jeffrussell
Welcome to the IPFire community.
frr has not been updated since Core Update 188 and libyang which frr requires to be available was last updated in Core Update 184.
What version of IPFire were you running when you upgraded to Core Update 190.
Tested it out on my vm testbed system running with CFU191 Testing and I got the same sort of message.
I will also try and test it out with CU189.
I was running build 181 previously. Thank you for looking into this.
Okay, looking at this the probability is that when frr was updated in CU188, libyang was not shipped with the update script.
I just had a look in the shipped list for CU188 and libyang was not shipped with it so that might be making a problem for the linked library.
Having looked at libyang, there have been a large number of updates so I will need to do a new update patch for that anyway but that will only get into CU192.
Your best bet would be to take a backup and save it off of IPFire. Then do a fresh install of CU190, reboot, and then do a restore from the backup followed by a reboot.
The library linkage will be correct in the fresh install as that ships all core packages.
I will have to figure out how to remember to ship libyang (a core package) when frr (addon package) is updated.
Unfortunately you’re the first user of frr to flag up this issue.
Thank you for the very quick assessment! I appreciate the help. Fortunately, this is a failover instance, so it isn’t impacting production. Yet. 
I will follow your suggestion and report back if any issues arise.
I have just done a fresh install of CU190 on a vm system and then tested frr out. There is no longer the message about the library undefined symbol, so that confirms that the problem was the lack of shipping libyang when frr was updated in September last year.
Is this fix still targeted for CU192? I didn’t see anything for this in the release notes. I’d rather not have to build my production primary from scratch. Thank you for the help!
Hi @jeffrussell
Looking through the commits I am afraid I cannot find any patch that I submitted for libyang to be shipped.
My apologies, it obviously dropped of my radar.
@arne_f can you please help by shipping libyang in CU192.
frr depends on it and back in CU188 when frr was updated, libyang also needed to be shipped but I was not aware of that at that time.
With a fresh install everything works fine but not with any core updates so far.
libyang has now been shipped in CU192 Testing.
I have commited the change but the build is not finished yet.
Good point Arne. I was too fast with my feedback 
Thank you, gentlemen!!
I tested it out with CU192 Testing.
First I tried it with my earlier version of CU192 Testing before the shipping of libyang by @arne_f
That gave the expected undefined symbol ly_temp_log_options which is provided by libyang.
I then moved my vm testing system back to CU191 and re-did the update to CU192 Testing. This then updated my vm system with the most up to date build from the Testing repo ( Core-Update 192 Development Build: master/09dd8d70 ).
I then started frr and it ran without that error message and I was able to get mgmtd, zebra, bgpd, ospfd & staticd all started.
The status of frr on the Service WUI page was also then shown as running.
This confirms that CU192 Testing has the fix in place.