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: Thu, 18 Mar 2021 19:31:36 +0100 Message-ID: In-Reply-To: <98DD7874-9731-4C2A-978C-FE12B8C4CAA4@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8975475013514764071==" List-Id: --===============8975475013514764071== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, Reran the CU155 upgrade on my testbed VM. The fixes from Arne worked perfectl= y. No problems rebooting after the upgrade and was able to ssh in to the syst= em. I had every service turned on except IPSec VPN. After the upgrade, everything= was running as before. Same after the reboot. wio and bacula addons are working as expected after the upgrade. I selected all graphs with hourly resolution and all was working as I would e= xpect it to. All ALG options gone on FW options WUI page. Everything worked as expected, with no problems so far. I expect it to stay l= ike that now. I will try it over the next few days and confirm that everything stays stable. Regards, Adolf. On 18/03/2021 12:31, Michael Tremer wrote: > *thumbs up* >=20 >> On 17 Mar 2021, at 17:11, Adolf Belka wrote: >> >> Hi Jonatan & All, >> >> Thanks for the feedback. Glad it is all solved. I would rather do some inv= estigation that ends up not being needed than not doing something that then s= hould 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 :-(. >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94- >>> >>> 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=3Dipfire-2.x.g= it;a=3Dcommit;h=3D5d747ddb70e74c9f5503618cc8aaa79b8f728cb3 and other comments in the current master). >>> >>> Sorry for answering this so late. There was communication on this over di= fferent 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 : >>>>> >>>>> =EF=BB=BFHi 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 updat= e 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 discuss= ion about my sysvinit patch. >>>>>>> >>>>>>> https://lists.ipfire.org/pipermail/development/2021-February/009403.h= tml >>>>>>> >>>>>>> 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 pr= oblem for adding to Core Update 155, or you can revert sysvinit and I will ma= ke the update for the following Core Update. >>>>>>> >>>>>> Thinking about this while out walking the dog, I realised if the decis= ion is to leave the updated package in Core Update 155 then I need to just cr= eate a patch for whatever fix is required to make it work properly on first b= oot. 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 f= rom /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 wa= s in /run and nothing in /dev. >>>>> >>>>> It is when an upgrade is carried out and the system starts with the pip= e 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 creat= e it in /run at an appropriate stage of the upgrade. Is the lfs file the corr= ect 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 p= ut the mknod command after the install command. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Adolf. >>>>> >>>>>>> >>>>>>> I also found the same problem with ssh not working after the update a= s 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 (r= equired by /usr/sbin/sshd) [FAIL] >>>>>>> >>>>>>> >>>>>>> People on the forum had deleted the /lib/libcrypt.so.1 link, which wa= s made to /lib/libcrypt-2.32.so and remade it to /usr/lib/libcrypt.so.1 and t= hey 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 anythi= ng related to libcrypt or a change of libcrypt location from /lib to /usr/lib >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Adolf >>>>>>> >> --=20 >> Sent from my laptop >=20 --===============8975475013514764071==--