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