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=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 : >>> >>> 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