From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Feedback on Core Update 155 Testing Date: Wed, 17 Mar 2021 13:40:49 +0100 Message-ID: <1d2ca961-efce-70c0-cd94-e45c5ee38210@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9217282416831726669==" List-Id: --===============9217282416831726669== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 effec= t 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 a= bout 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 th= e update for the following Core Update. >> > Thinking about this while out walking the dog, I realised if the decision i= s 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 CU15= 5 unless I hear differently from anyone. > > Regards, > > Adolf. > Back in early 2018 the sysvinit team decided to move the initctl pipe from /d= ev 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 i= n /run at an appropriate stage of the upgrade. Is the lfs file the correct pl= ace to have these commands after the install commands or should they be in th= e file used to carry out the Core Update. The lfs file doesn't seem the corre= ct place for this as it is only needed once for the upgrade from CU154 to CU1= 55. After that the pipe will always stay in /run. I would appreciate advice on the best approach. If it should be in the upgrad= e 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 men= tioned 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 (requir= ed by /usr/sbin/sshd) [FAIL] >> >> >> People on the forum had deleted the /lib/libcrypt.so.1 link, which was mad= e to /lib/libcrypt-2.32.so and remade it to /usr/lib/libcrypt.so.1 and they h= ave 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 re= lated to libcrypt or a change of libcrypt location from /lib to /usr/lib >> >> >> Regards, >> >> Adolf >> --===============9217282416831726669==--