I upgraded (or so I thought) an x86_64 to core 172 Testing.
- WUI not found
- console displays message “libreadline.so.8 cannot open shared object file: no such file or directory”
Unable to log in either way
2 Likes
Hi,
thank you for testing and reporting back.
Indeed, this is a rather severe error that slipped through. This commit fixes it; an updated version of Core Update 172 (testing) should be ready in about three hours.
Thanks, and best regards,
Peter Müller
6 Likes
Hi @pmueller
Tested the updated version but now it is crashing with missing libhistory.so.8
Hi,
indeed - my fault, again. 
Fixed by this commit; again, build should be done in a few hours or so, and anyone installing Core Update 172 (testing) afterwards will automagically receive the fixed version of it.
The root cause of these is a bit unobtrusive: Both libhistory.so.8.1 and libreadline.so.8.1 are deleted relatively early during the update, thanks to readline being updated to 8.2, which causes the library filenames to change - the symlinks (libhistory.so.8 and libreadline.so.8 remain present, but will have to be updated later in order to point to the right file again). However, the removal takes place before any new files shipped with Core Update 172 (testing) are unpacked - and this unpacking happens by invoking a subshell.
And at this point, we try to invoke a new shell, which would need an intact readline and all related libraries - but they are not present at this time. Therefore, extraction of new files fails - unfortunately, because in these, there would be libhistory.so.8.2 and libreadline.so.8.2, and once unpacked, everything would be peachy and vanilla again.
Silly me removed the removal line of libreadline.so.8.1 earlier, but forgot about libhistory.so.8.1, leading to a very similar outcome. At least on this front, Core Update 172 (testing) should be finally doing better if installed in a couple of hours. 
Apologies for all the hassle, and many thanks for reporting back,
Peter Müller
6 Likes
Tested out the new Testing version. The update occurred this time but after doing the reboot I no longer have any network interfaces except for lo.
Before I had red0, green0, blue0 and orange0.
/var/ipfire/ethernet/scanned_nics shows
`/var/ipfire/ethernet/settings shows
Running setup showed that green + red + orange + blue was correctly selected but saying OK or cancel then came up with the following error page
but the drivers and card assignments shows the nics are assigned to the interfaces which was the previous setup but they no longer seem to be able to be found.
Exiting from setup caused Network restarting but it was very quick and nothing changed with regard to the interfaces. Still only lo.
I did another reboot and saw the message
/usr/sbin/httpd: error while loading shared libraries: libexpat.so.1: cannot open shared object file: no such file or directory FAIL
Doing a further reboot changed nothing with regard to the network interfaces again. So the update caused something major withy regard to the interfaces no longer being seen.
All the above is on my vm testbed system (VirtualBox).
Let me know what file contents or checks you want me to run or report on.
As I can’t scroll the console screen on my virtual system all the messages with fails etc went by too quickly. So I recorded the booting process with VirtualBox and then took screenshots of various stages. The later stages might be occurring because of the first error found but I thought it was better to provide all of the messages I found, or at least examples of those that have multiple repeats like the iptables related ones. Hope these help.
EDIT:
Also noted that apache daemon is not starting which probably explains the failure of the WUI access.
1 Like
I performed the 172 testing update and never recovered from reboot. Had to rebuild to last stable.
A fresh install of the test xz.img, release dc9f7554, to real hardware proceeds to completion. It has 4 NIC, which are found and configured.
But the reboot locks up at “Searching for Sensors”. Install was to an ancient AMD e350 mainboard, but it does have sensors
Hi,
the errors @bonnietwin and others are still experiencing stem from yet another mistake, since xz is invoked during the update for extracting files. Similar to the subshell problem mentioned earlier, we cannot delete any dependencies of any component that is required for the extraction routine. However, the update.sh did that by removing liblzma.so.5.2.5, again causing file extraction to fail.
This commit fixes it, and will land in master in due course - again, a fixed version of Core Update 172 will then be available in a couple of hours.
This is also why @rodneyp and anybody else who did a fresh installation of Core Update 172 never experienced any of these errors, since all these images are very much intact.
Thanks, and best regards,
Peter Müller (hopes that this was the last of such bugs in Core Update 172 )
6 Likes
Mistakes can happen. I know, i have made my fair share of them.
The way I look at it is that in Testing is the place to find them, which we are doing 
so I think that is good news.
7 Likes
I upgraded (a different x86_64 hardware installation) from core 171 stable to core 172 testing from master/eb9e29f9.
So far, so good:
- WUI working
- console login working
- dhcp & DNS working
OTOH, fresh install of above build to e350 hardware gets beyond “searching for sensors” but then loses console, no WUI & apparently no network
Hi @all,
i tested an upgrade from 171 to 172 got a lot of errors.
I use a kvm vitalized instance.
First the module are not loaded and i’m not able to use “depmod -A”.
After copy liblzma.so from a other instance depmod works and the modules are loaded.
After booting i have my network up, but at booting a lot of errors because libs are not found:
- libxml2.so.2
- libexpat.so.1
- rddtool.so
Thanks Frank
I upgraded to: master/eb9e29f9 and no errors about missing libs.
Hi @pmueller
I can also confirm that
Core-Update 172 Development Build: master/eb9e29f9
Upgrades and reboots without any problems.
I will check through the menu items tomorrow to check that everything is working but I have already noted a problem with the OpenVPN menu. When I select it I get a page showing the DH parameters. Pressing Back on that page just shows the same page. Nothing I have tried so far gets the normal OpenVPN WUI page to be shown.
This is what is shown:-
Pressing Back shows the same page as does selecting the OpenVPN WUI menu page.
2 Likes
re fresh install of master/eb9e29f9.
Although my e350 mainboard gives no problems with openSUSE Leap, clonezilla, gparted etc, etc, etc, I conclude that it is not compatible with IPFire.
Dug out an older Sempron 64 mainboard and master/eb9e29f9 installed with that. Generally working, excepting DHCP. DHCP loads, during boot, but is ineffective. Staticly addressed workstations appear to have full network function.
Good sunday!.
I have updated to the " Actualización del núcleo 172 Development Build: master/eb9e29f9" and it has worked correctly for me.
My profile: fireinfo.ipfire.org - Profile 9d73b2b007ea75a8c15d748d8ac07e6effd8ec8f
Thanks for your effort!!!
BR
Hi @rodneyp
Is the dhcp server showing as running on the Status - Services menu page?
On my vm testbed dhcp is working fine. All my vm systems get their ip’s from IPFire, either as fixed ip’s or from a dynamic pool and all got the expected ip address without any problems.
I can confirm that on “master/eb9e29f9” the openvpn config menu seams to be broken.
2 Likes
The problem with openvpn is only with the config menu page. The Openvpn road warrior connections work as normal.
Hi @bonnietwin
re the fresh install:
After changing the USB NIC for green0 and rebooting, dhcp server is showing as starting on the startup screen and as running in the Status - Services menu page. A laptop, that uses dhcp, now connects.
I’ll test out the upgraded installation, which has more features set up, in coming days