From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Feedback on Core Update 155 Testing Date: Thu, 18 Mar 2021 11:31:28 +0000 Message-ID: <98DD7874-9731-4C2A-978C-FE12B8C4CAA4@ipfire.org> In-Reply-To: <26e1f069-118a-9d6f-0915-2a03bfa9325f@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9108636945213429393==" List-Id: --===============9108636945213429393== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable *thumbs up* > On 17 Mar 2021, at 17:11, Adolf Belka wrote: >=20 > Hi Jonatan & All, >=20 > Thanks for the feedback. Glad it is all solved. I would rather do some inve= stigation that ends up not being needed than not doing something that then sh= ould have been done. >=20 > I will clone a new CU154 VM and test the update again tomorrow. >=20 > Regards, >=20 > Adolf. >=20 > On 17/03/2021 16:22, Jonatan Schlag wrote: >> Sorry for missing the list :-(. >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94- >>=20 >> Hi Adolf, >>=20 >> thanks for having an eye on the community and reporting things back. >> Arne has already fixed that (see https://git.ipfire.org/?p=3Dipfire-2.x.gi= t;a=3Dcommit;h=3D5d747ddb70e74c9f5503618cc8aaa79b8f728cb3 and other comments in the current master). >>=20 >> Sorry for answering this so late. There was communication on this over dif= ferent 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. >>=20 >> Greetings Jonatan >>=20 >>>> Am 17.03.2021 um 13:40 schrieb Adolf Belka : >>>>=20 >>>> =EF=BB=BFHi All, >>>>=20 >>>> On 17/03/2021 11:51, Adolf Belka wrote: >>>>> Hi Everyone, >>>>>=20 >>>>> On 17/03/2021 10:35, Adolf Belka wrote: >>>>>> Dear all, >>>>>>=20 >>>>>> 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 e= ffect on my VM testbed system for testing. >>>>>>=20 >>>>>> https://community.ipfire.org/t/feedback-core-update-155-testing/4896 >>>>>>=20 >>>>>> That symptom triggered my memory (a bit late) and I found the discussi= on about my sysvinit patch. >>>>>>=20 >>>>>> https://lists.ipfire.org/pipermail/development/2021-February/009403.ht= ml >>>>>>=20 >>>>>> So the fix never got created and it did not revert from the update. >>>>>>=20 >>>>>> Sorry for this mess. I will do a new patch to hopefully solve that pro= blem for adding to Core Update 155, or you can revert sysvinit and I will mak= e the update for the following Core Update. >>>>>>=20 >>>>> Thinking about this while out walking the dog, I realised if the decisi= on is to leave the updated package in Core Update 155 then I need to just cre= ate a patch for whatever fix is required to make it work properly on first bo= ot. If the decision is to revert then I will need to create a patch for the f= ull update again. I will work on creating a patch to just fix what is now in = CU155 unless I hear differently from anyone. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Adolf. >>>>>=20 >>>> Back in early 2018 the sysvinit team decided to move the initctl pipe fr= om /dev to /run. >>>>=20 >>>> 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." >>>>=20 >>>>=20 >>>> I installed CU155 from scratch and I had no problem at all. The pipe was= in /run and nothing in /dev. >>>>=20 >>>> 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 f= orced reboot by doing a soft reset. >>>>=20 >>>> 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 corre= ct 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 t= o CU155. After that the pipe will always stay in /run. >>>>=20 >>>>=20 >>>> I would appreciate advice on the best approach. If it should be in the u= pgrade script, where is that located? If it should be in the lfs do I just pu= t the mknod command after the install command. >>>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>>>>=20 >>>>>> I also found the same problem with ssh not working after the update as= mentioned in the forum post. >>>>>>=20 >>>>>> Rebooting gave the following error message in the log. >>>>>>=20 >>>>>> /usr/sbin/sshd: /lib/libcrypt.so.1: version `XCRYPT_2.0' not found (re= quired by /usr/sbin/sshd) [FAIL] >>>>>>=20 >>>>>>=20 >>>>>> 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 th= ey have reported that ssh then works. I have not tried that fix yet. >>>>>>=20 >>>>>> I checked the OpenSSH update patch I created and I didn't find anythin= g related to libcrypt or a change of libcrypt location from /lib to /usr/lib >>>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf >>>>>>=20 > --=20 > Sent from my laptop --===============9108636945213429393==--