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
Hi all,
@bonnietwin according to the OpenVPN problem can you please try the following for /var/ipfire/langs/en.pl →
$ diff -u /var/ipfire/langs/en.pl_core172_buggy /var/ipfire/langs/en.pl
--- /var/ipfire/langs/en.pl_core172_buggy 2022-12-04 20:06:24.628640598 +0100
+++ /var/ipfire/langs/en.pl 2022-12-04 20:11:56.363993014 +0100
@@ -795,6 +795,7 @@
'details' => 'Details',
'device' => 'Device',
'devices on blue' => 'Devices on BLUE',
+'dh' => 'Diffie-Hellman-Parameter',
'dhcp advopt add' => 'Add a DHCP option',
'dhcp advopt added' => 'DHCP option added',
'dhcp advopt blank value' => 'DHCP Option value cannot be empty.',
@@ -2313,6 +2314,7 @@
'show ca certificate' => 'Show CA certificate',
'show certificate' => 'Show file',
'show crl' => 'Show certificate revocation list',
+'show dh' => 'Show Diffie-Hellman parameters',
'show host certificate' => 'Show host certificate',
'show last x lines' => 'Show last x lines',
'show lines' => 'Show lines',
for english webinterface only!!!
For german webinterface →
--- /var/ipfire/langs/de.pl_core172_buggy 2022-12-04 20:34:44.901874457 +0100
+++ /var/ipfire/langs/de.pl 2022-12-04 20:39:54.810759610 +0100
@@ -760,6 +760,7 @@
'details' => 'Mehr',
'device' => 'Gerät',
'devices on blue' => 'Geräte auf BLAU',
+'dh' => 'Diffie-Hellman-Parameter',
'dhcp advopt add' => 'DHCP Option hinzufügen',
'dhcp advopt added' => 'DHCP Option hinzugefügt',
'dhcp advopt blank value' => 'Wert für DHCP Option darf nicht leer sein',
@@ -2256,6 +2257,7 @@
'show ca certificate' => 'CA Zertifikat anzeigen',
'show certificate' => 'Datei anzeigen',
'show crl' => 'Certificate Revocation List anzeigen',
+'show dh' => 'Diffie-Hellman-Parameter anzeigen',
'show host certificate' => 'Host-Zertifikat anzeigen',
'show last x lines' => 'die letzten x Zeilen anzeigen',
'show otp qrcode' => 'Zeige OTP QRCode',
and for /srv/web/ipfire/cgi-bin/ovpnmain.cgi →
$ diff -u /srv/web/ipfire/cgi-bin/ovpnmain.cgi_core172_buggy /srv/web/ipfire/cgi-bin/ovpnmain.cgi
--- /srv/web/ipfire/cgi-bin/ovpnmain.cgi_core172_buggy 2022-12-04 19:58:07.719077771 +0100
+++ /srv/web/ipfire/cgi-bin/ovpnmain.cgi 2022-12-04 20:32:13.904384551 +0100
@@ -977,7 +977,7 @@
print SERVERCONF "ca ${General::swroot}/ovpn/ca/cacert.pem\n";
print SERVERCONF "cert ${General::swroot}/ovpn/certs/servercert.pem\n";
print SERVERCONF "key ${General::swroot}/ovpn/certs/serverkey.pem\n";
- print SERVERCONF "dh ${General::swroot}/ovpn/ca/$cgiparams{'DH_NAME'}\n";
+ print SERVERCONF "dh $dhparameter\n";
print SERVERCONF "# Cipher\n";
print SERVERCONF "cipher $cgiparams{'DCIPHER'}\n";
@@ -5700,7 +5700,7 @@
print <<END;
<tr>
- <td class='base' $col3>$Lang::tr{'dh parameter'}</td>
+ <td class='base' $col3>$Lang::tr{'dh'}</td>
<td class='base' $col3>$dhsubject</td>
<form method='post' name='frmdhparam'><td width='3%' align='center' $col3>
<input type='hidden' name='ACTION' value='$Lang::tr{'show dh'}' />
you need to execute a
update-lang-cache
after the changes.
Best,
Erik
3 Likes
Hi @ummeegge
Excellent work. Just fed those changes into my vm IPFire and the OpenVPN page is working fine again.
Will you submit that as a patch or do you want me to do that on your behalf?
2 Likes
Thanks for testing and delivering the feedback Adolf , have wrote already @pmueller and have ask for testing and checking this topic but am not sure how much work is around the corner for him so it might be great if you can go for this since i do not have a build environment around.
Best,
Erik
Hi Erik, I thought I remembered that you no longer had a build environment.
No problems, I will submit a patch and mark it as suggested by yourself. Thanks for the help.
1 Like
You´re welcome and thanks again.
Patch with your fix has been submitted.
https://patchwork.ipfire.org/project/ipfire/list/?series=3223
3 Likes