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.
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 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.
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 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
Hello,
On 17 Mar 2021, at 12:40, Adolf Belka adolf.belka@ipfire.org wrote:
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.
Arne applied this which should be good enough until the system reboots and creates the new pipe in the right place:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5d747ddb70e74c9f5503...
-Michael
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
Hello,
On 17 Mar 2021, at 09:35, Adolf Belka adolf.belka@ipfire.org 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.
No worries. I would only blame myself for forgetting to find a solution for this.
Arne simply created a symlink which temporarily makes things work again until the next reboot. After that, things are fine.
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]
This is another one that I fucked up myself :)
I do not know why though, because I tested an earlier version of the update on my machine and it worked fine.
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 suppose Arne tested it and committed it.
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
This was part of glibc deprecating libcrypt. Therefore I added a fork which is actively maintained.
Thanks for looking into these problems.
-Michael
Regards,
Adolf
-- Sent from my laptop
-
Adolf Belka -
Michael Tremer