Sorry for missing the list :-(. ————————-
Hi Adolf,
thanks for having an eye on the community and reporting things back. Arne has already fixed that (see https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5d747ddb70e74c9f5503618c... and other comments in the current master).
Sorry for answering this so late. There was communication on this over different places (community, chat, here, ...) and so things get lost somehow. I do not know if this could be improved, but at least I want to say sorry that you were not aware that the problem was already fixed.
Greetings Jonatan
Am 17.03.2021 um 13:40 schrieb Adolf Belka adolf.belka@ipfire.org:
Hi All,
On 17/03/2021 11:51, Adolf Belka wrote: Hi Everyone,
On 17/03/2021 10:35, Adolf Belka wrote: Dear all,
There is feedback on the forum about IPFire not rebooting after update and needing a soft reset. After that it boots again. I also found the same effect on my VM testbed system for testing.
https://community.ipfire.org/t/feedback-core-update-155-testing/4896
That symptom triggered my memory (a bit late) and I found the discussion about my sysvinit patch.
https://lists.ipfire.org/pipermail/development/2021-February/009403.html
So the fix never got created and it did not revert from the update.
Sorry for this mess. I will do a new patch to hopefully solve that problem for adding to Core Update 155, or you can revert sysvinit and I will make the update for the following Core Update.
Thinking about this while out walking the dog, I realised if the decision is to leave the updated package in Core Update 155 then I need to just create a patch for whatever fix is required to make it work properly on first boot. If the decision is to revert then I will need to create a patch for the full update again. I will work on creating a patch to just fix what is now in CU155 unless I hear differently from anyone.
Regards,
Adolf.
Back in early 2018 the sysvinit team decided to move the initctl pipe from /dev to /run.
The commit message for this was "FreeBSD apparently does not like named pipes in /dev, so we move it to /run for better cross-platform compatibility."
I installed CU155 from scratch and I had no problem at all. The pipe was in /run and nothing in /dev.
It is when an upgrade is carried out and the system starts with the pipe in /dev, then the upgrade is not changing this. It is only changed after a forced reboot by doing a soft reset.
It seems that we need some lines to remove the pipe from /dev and create it in /run at an appropriate stage of the upgrade. Is the lfs file the correct place to have these commands after the install commands or should they be in the file used to carry out the Core Update. The lfs file doesn't seem the correct place for this as it is only needed once for the upgrade from CU154 to CU155. After that the pipe will always stay in /run.
I would appreciate advice on the best approach. If it should be in the upgrade script, where is that located? If it should be in the lfs do I just put the mknod command after the install command.
Regards,
Adolf.
I also found the same problem with ssh not working after the update as mentioned in the forum post.
Rebooting gave the following error message in the log.
/usr/sbin/sshd: /lib/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /usr/sbin/sshd) [FAIL]
People on the forum had deleted the /lib/libcrypt.so.1 link, which was made to /lib/libcrypt-2.32.so and remade it to /usr/lib/libcrypt.so.1 and they have reported that ssh then works. I have not tried that fix yet.
I checked the OpenSSH update patch I created and I didn't find anything related to libcrypt or a change of libcrypt location from /lib to /usr/lib
Regards,
Adolf
Hi Jonatan & All,
Thanks for the feedback. Glad it is all solved. I would rather do some investigation that ends up not being needed than not doing something that then should have been done.
I will clone a new CU154 VM and test the update again tomorrow.
Regards,
Adolf.
On 17/03/2021 16:22, Jonatan Schlag wrote:
Sorry for missing the list :-(. ————————-
Hi Adolf,
thanks for having an eye on the community and reporting things back. Arne has already fixed that (see https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5d747ddb70e74c9f5503618c... https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5d747ddb70e74c9f5503618cc8aaa79b8f728cb3 and other comments in the current master).
Sorry for answering this so late. There was communication on this over different places (community, chat, here, ...) and so things get lost somehow. I do not know if this could be improved, but at least I want to say sorry that you were not aware that the problem was already fixed.
Greetings Jonatan
Am 17.03.2021 um 13:40 schrieb Adolf Belka adolf.belka@ipfire.org:
Hi All,
On 17/03/2021 11:51, Adolf Belka wrote:
Hi Everyone,
On 17/03/2021 10:35, Adolf Belka wrote:
Dear all,
There is feedback on the forum about IPFire not rebooting after update and needing a soft reset. After that it boots again. I also found the same effect on my VM testbed system for testing.
https://community.ipfire.org/t/feedback-core-update-155-testing/4896
That symptom triggered my memory (a bit late) and I found the discussion about my sysvinit patch.
https://lists.ipfire.org/pipermail/development/2021-February/009403.html
So the fix never got created and it did not revert from the update.
Sorry for this mess. I will do a new patch to hopefully solve that problem for adding to Core Update 155, or you can revert sysvinit and I will make the update for the following Core Update.
Thinking about this while out walking the dog, I realised if the decision is to leave the updated package in Core Update 155 then I need to just create a patch for whatever fix is required to make it work properly on first boot. If the decision is to revert then I will need to create a patch for the full update again. I will work on creating a patch to just fix what is now in CU155 unless I hear differently from anyone.
Regards,
Adolf.
Back in early 2018 the sysvinit team decided to move the initctl pipe from /dev to /run.
The commit message for this was "FreeBSD apparently does not like named pipes in /dev, so we move it to /run for better cross-platform compatibility."
I installed CU155 from scratch and I had no problem at all. The pipe was in /run and nothing in /dev.
It is when an upgrade is carried out and the system starts with the pipe in /dev, then the upgrade is not changing this. It is only changed after a forced reboot by doing a soft reset.
It seems that we need some lines to remove the pipe from /dev and create it in /run at an appropriate stage of the upgrade. Is the lfs file the correct place to have these commands after the install commands or should they be in the file used to carry out the Core Update. The lfs file doesn't seem the correct place for this as it is only needed once for the upgrade from CU154 to CU155. After that the pipe will always stay in /run.
I would appreciate advice on the best approach. If it should be in the upgrade script, where is that located? If it should be in the lfs do I just put the mknod command after the install command.
Regards,
Adolf.
I also found the same problem with ssh not working after the update as mentioned in the forum post.
Rebooting gave the following error message in the log.
/usr/sbin/sshd: /lib/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /usr/sbin/sshd) [FAIL]
People on the forum had deleted the /lib/libcrypt.so.1 link, which was made to /lib/libcrypt-2.32.so and remade it to /usr/lib/libcrypt.so.1 and they have reported that ssh then works. I have not tried that fix yet.
I checked the OpenSSH update patch I created and I didn't find anything related to libcrypt or a change of libcrypt location from /lib to /usr/lib
Regards,
Adolf
*thumbs up*
On 17 Mar 2021, at 17:11, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Jonatan & All,
Thanks for the feedback. Glad it is all solved. I would rather do some investigation that ends up not being needed than not doing something that then should have been done.
I will clone a new CU154 VM and test the update again tomorrow.
Regards,
Adolf.
On 17/03/2021 16:22, Jonatan Schlag wrote:
Sorry for missing the list :-(. ————————-
Hi Adolf,
thanks for having an eye on the community and reporting things back. Arne has already fixed that (see https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5d747ddb70e74c9f5503618c... https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5d747ddb70e74c9f5503618cc8aaa79b8f728cb3 and other comments in the current master).
Sorry for answering this so late. There was communication on this over different places (community, chat, here, ...) and so things get lost somehow. I do not know if this could be improved, but at least I want to say sorry that you were not aware that the problem was already fixed.
Greetings Jonatan
Am 17.03.2021 um 13:40 schrieb Adolf Belka adolf.belka@ipfire.org:
Hi All,
On 17/03/2021 11:51, Adolf Belka wrote:
Hi Everyone,
On 17/03/2021 10:35, Adolf Belka wrote:
Dear all,
There is feedback on the forum about IPFire not rebooting after update and needing a soft reset. After that it boots again. I also found the same effect on my VM testbed system for testing.
https://community.ipfire.org/t/feedback-core-update-155-testing/4896
That symptom triggered my memory (a bit late) and I found the discussion about my sysvinit patch.
https://lists.ipfire.org/pipermail/development/2021-February/009403.html
So the fix never got created and it did not revert from the update.
Sorry for this mess. I will do a new patch to hopefully solve that problem for adding to Core Update 155, or you can revert sysvinit and I will make the update for the following Core Update.
Thinking about this while out walking the dog, I realised if the decision is to leave the updated package in Core Update 155 then I need to just create a patch for whatever fix is required to make it work properly on first boot. If the decision is to revert then I will need to create a patch for the full update again. I will work on creating a patch to just fix what is now in CU155 unless I hear differently from anyone.
Regards,
Adolf.
Back in early 2018 the sysvinit team decided to move the initctl pipe from /dev to /run.
The commit message for this was "FreeBSD apparently does not like named pipes in /dev, so we move it to /run for better cross-platform compatibility."
I installed CU155 from scratch and I had no problem at all. The pipe was in /run and nothing in /dev.
It is when an upgrade is carried out and the system starts with the pipe in /dev, then the upgrade is not changing this. It is only changed after a forced reboot by doing a soft reset.
It seems that we need some lines to remove the pipe from /dev and create it in /run at an appropriate stage of the upgrade. Is the lfs file the correct place to have these commands after the install commands or should they be in the file used to carry out the Core Update. The lfs file doesn't seem the correct place for this as it is only needed once for the upgrade from CU154 to CU155. After that the pipe will always stay in /run.
I would appreciate advice on the best approach. If it should be in the upgrade script, where is that located? If it should be in the lfs do I just put the mknod command after the install command.
Regards,
Adolf.
I also found the same problem with ssh not working after the update as mentioned in the forum post.
Rebooting gave the following error message in the log.
/usr/sbin/sshd: /lib/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /usr/sbin/sshd) [FAIL]
People on the forum had deleted the /lib/libcrypt.so.1 link, which was made to /lib/libcrypt-2.32.so and remade it to /usr/lib/libcrypt.so.1 and they have reported that ssh then works. I have not tried that fix yet.
I checked the OpenSSH update patch I created and I didn't find anything related to libcrypt or a change of libcrypt location from /lib to /usr/lib
Regards,
Adolf
-- Sent from my laptop
Hi All,
Reran the CU155 upgrade on my testbed VM. The fixes from Arne worked perfectly. No problems rebooting after the upgrade and was able to ssh in to the system.
I had every service turned on except IPSec VPN. After the upgrade, everything was running as before. Same after the reboot.
wio and bacula addons are working as expected after the upgrade.
I selected all graphs with hourly resolution and all was working as I would expect it to.
All ALG options gone on FW options WUI page.
Everything worked as expected, with no problems so far. I expect it to stay like that now.
I will try it over the next few days and confirm that everything stays stable.
Regards,
Adolf.
On 18/03/2021 12:31, Michael Tremer wrote:
*thumbs up*
On 17 Mar 2021, at 17:11, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Jonatan & All,
Thanks for the feedback. Glad it is all solved. I would rather do some investigation that ends up not being needed than not doing something that then should have been done.
I will clone a new CU154 VM and test the update again tomorrow.
Regards,
Adolf.
On 17/03/2021 16:22, Jonatan Schlag wrote:
Sorry for missing the list :-(. ————————-
Hi Adolf,
thanks for having an eye on the community and reporting things back. Arne has already fixed that (see https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5d747ddb70e74c9f5503618c... https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5d747ddb70e74c9f5503618cc8aaa79b8f728cb3 and other comments in the current master).
Sorry for answering this so late. There was communication on this over different places (community, chat, here, ...) and so things get lost somehow. I do not know if this could be improved, but at least I want to say sorry that you were not aware that the problem was already fixed.
Greetings Jonatan
Am 17.03.2021 um 13:40 schrieb Adolf Belka adolf.belka@ipfire.org:
Hi All,
On 17/03/2021 11:51, Adolf Belka wrote:
Hi Everyone,
On 17/03/2021 10:35, Adolf Belka wrote: > Dear all, > > There is feedback on the forum about IPFire not rebooting after update and needing a soft reset. After that it boots again. I also found the same effect on my VM testbed system for testing. > > https://community.ipfire.org/t/feedback-core-update-155-testing/4896 > > That symptom triggered my memory (a bit late) and I found the discussion about my sysvinit patch. > > https://lists.ipfire.org/pipermail/development/2021-February/009403.html > > So the fix never got created and it did not revert from the update. > > Sorry for this mess. I will do a new patch to hopefully solve that problem for adding to Core Update 155, or you can revert sysvinit and I will make the update for the following Core Update. > Thinking about this while out walking the dog, I realised if the decision is to leave the updated package in Core Update 155 then I need to just create a patch for whatever fix is required to make it work properly on first boot. If the decision is to revert then I will need to create a patch for the full update again. I will work on creating a patch to just fix what is now in CU155 unless I hear differently from anyone.
Regards,
Adolf.
Back in early 2018 the sysvinit team decided to move the initctl pipe from /dev to /run.
The commit message for this was "FreeBSD apparently does not like named pipes in /dev, so we move it to /run for better cross-platform compatibility."
I installed CU155 from scratch and I had no problem at all. The pipe was in /run and nothing in /dev.
It is when an upgrade is carried out and the system starts with the pipe in /dev, then the upgrade is not changing this. It is only changed after a forced reboot by doing a soft reset.
It seems that we need some lines to remove the pipe from /dev and create it in /run at an appropriate stage of the upgrade. Is the lfs file the correct place to have these commands after the install commands or should they be in the file used to carry out the Core Update. The lfs file doesn't seem the correct place for this as it is only needed once for the upgrade from CU154 to CU155. After that the pipe will always stay in /run.
I would appreciate advice on the best approach. If it should be in the upgrade script, where is that located? If it should be in the lfs do I just put the mknod command after the install command.
Regards,
Adolf.
> > I also found the same problem with ssh not working after the update as mentioned in the forum post. > > Rebooting gave the following error message in the log. > > /usr/sbin/sshd: /lib/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /usr/sbin/sshd) [FAIL] > > > People on the forum had deleted the /lib/libcrypt.so.1 link, which was made to /lib/libcrypt-2.32.so and remade it to /usr/lib/libcrypt.so.1 and they have reported that ssh then works. I have not tried that fix yet. > > I checked the OpenSSH update patch I created and I didn't find anything related to libcrypt or a change of libcrypt location from /lib to /usr/lib > > > Regards, > > Adolf >
-- Sent from my laptop
-
Adolf Belka -
Jonatan Schlag -
Michael Tremer