From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: Feedback on problems with Core Update 168 Testing Date: Wed, 18 May 2022 17:52:10 +0000 Message-ID: <04a0e3ff-60bf-dd5e-8f45-d30c7d8a7a59@ipfire.org> In-Reply-To: <25fdce7a-e37e-dda1-d9f8-09709f3b5c11@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5317504267448638510==" List-Id: --===============5317504267448638510== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Adolf, thank you for all the extensive testing and reporting back. Ah, indeed, the newly introduced Cron job is stil missing due to silly me con= fusing the fcrontab binary and an actual fcrontab. I think the most straight-forward= way to fix this is to just ship the entire crontab file, and force fcrontab to recre= ate the - yes - fcrontab based on its content. @Michael: How does one ship a single file with a Core Update that is not cove= red by any rootfile? Thanks, and best regards, Peter M=C3=BCller > Hi All, >=20 > Virtually everything I have tested in CU168 looks to be working as expected. >=20 > The only problem I have found to-date is the Rules update for Suricata in t= he Intrusion Prevention System. >=20 > The old daily or weekly option is gone and the update should now occur twic= e per day but that entry is not in the fcrontab in CU168 Testing so no update= s are occurring for the rulesets unless you manually force them when the upda= te occurs with no problem. >=20 >=20 > Regards, >=20 > Adolf >=20 >=20 > On 17/05/2022 10:09, Adolf Belka wrote: >> Hi Michael, >> >> On 13/05/2022 22:37, Michael Tremer wrote: >>> Hello, >>> >>> Okay, this is really bad then if we are breaking RAID installations. >>> >>> I tried to debug this, but VirtualBox is not my friend today. >>> >>> I asked some bug reporter to provide me with the logs that I want over he= re: >>> >>> =C2=A0=C2=A0 https://bugzilla.ipfire.org/show_bug.cgi?id=3D12862 >> After applying this fix to my CU167 vm and proving that it stayed consiste= nt I have now done an upgrade to CU168 Testing. This does a CU167 update befo= re doing the CU168 update and I am glad to announce that my previous problems= with losing all my network interfaces etc are gone. >> >> My Core Update 168 Development Build: master/bbd4767f successfully restart= ed with a fully active raid array and I will now restart doing my CU168 Testi= ng evaluation. >> >> Thanks very much for all the help. >> >> Regards, >> Adolf. >>> >>> -Michael >>> >>>> On 13 May 2022, at 18:12, Adolf Belka wrote: >>>> >>>> Hi All, >>>> >>>> I think I may understand what is happening with my vm now. Of course I c= ould also be wrong :-) but I will give it a go. >>>> >>>> I saw bug#12862 where upgrading from CU166 to CU167 had stopped the raid= array running so that IPFire was only on one disk. >>>> >>>> I had missed seeing this in my evaluation of CU167 on my vm which does r= un with a raid array. >>>> >>>> The vm shows the following >>>> >>>> -bash-5.1$ cat /proc/mdstat >>>> Personalities : >>>> md127 : inactive sdb[1](S) >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 52428724 blocks super 1.0 >>>> >>>> unused devices: >>>> >>>> >>>> It looks like IPFire was only running on sda. >>>> >>>> So when I am doing an upgrade to CU168 it is likely that only one disk o= f the raid pair is being updated. >>>> >>>> The CU168 vm that is working has the same as the above setting. >>>> >>>> The CU168 vm that is not working has the following setting >>>> >>>> -bash-5.1$ cat /proc/mdstat >>>> Personalities : >>>> md127 : inactive sda[0](S) >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 52428724 blocks super 1.0 >>>> >>>> unused devices: >>>> >>>> So it looks like it has booted up on the disk that was not updated from = the raid pair. >>>> >>>> >>>> This probably also explains why occasionally I have had a vm that was no= t working suddenly start working properly when I reboot it, but booting again= can put it back into non-working mode. >>>> >>>> It is probably dependent on which of the two disks actually get used to = boot from. >>>> >>>> So the problem looks like it would only affect people who have raid setu= ps and the problem originated in the CU167 upgrade. >>>> >>>> So raid systems need to have their raid arrays fully working before doin= g an upgrade. >>>> >>>> At least the above is my interpretation of what I have found. What does = everyone else think. >>>> >>>> >>>> Regards, >>>> >>>> Adolf. >>>> >>>> >>>> On 13/05/2022 15:59, Adolf Belka wrote: >>>>> Hi Michael, >>>>> >>>>> I have found some differences between the vm's that have upgraded with = no problem and those that have lost most of the modules. >>>>> >>>>> I did another three vm clones and upgrades and the first two all went w= ith no problems. I was starting to think the issue had gone away but on the t= hird one the same problem happened after the reboot. >>>>> >>>>> However I did copy the boot directory info for these two cases and foun= d an interesting effect. >>>>> >>>>> For the problem vm here was the boot directory layout of the CU167 base= machine >>>>> >>>>> drwxr-xr-x=C2=A0 5 root root 4.0K Apr 28 09:47 . >>>>> drwxr-xr-x 21 root root 4.0K Nov 28 15:49 .. >>>>> -rw-r--r--=C2=A0 1 root root 179K Apr 26 13:00 config-5.15.35-ipfire >>>>> drwxr-xr-x=C2=A0 3 root root=C2=A0 16K Jan=C2=A0 1=C2=A0 1970 efi >>>>> drwxr-xr-x=C2=A0 6 root root 4.0K Apr 28 09:47 grub >>>>> -rw-------=C2=A0 1 root root=C2=A0 26M Apr 28 09:47 initramfs-5.15.35-i= pfire.img >>>>> drwx------=C2=A0 2 root root=C2=A0 16K Sep 30=C2=A0 2021 lost+found >>>>> -rw-r--r--=C2=A0 1 root root 4.7M Apr 26 13:00 System.map-5.15.35-ipfire >>>>> -rw-r--r--=C2=A0 1 root root 6.7M Apr 26 13:00 vmlinuz-5.15.35-ipfire >>>>> >>>>> After upgrade and before reboot this had changed to >>>>> >>>>> drwxr-xr-x=C2=A0 5 root root 4.0K May 13 15:40 . >>>>> drwxr-xr-x 21 root root 4.0K Nov 28 15:49 .. >>>>> -rw-r--r--=C2=A0 1 root root 179K May=C2=A0 3 04:02 config-5.15.35-ipfi= re >>>>> drwxr-xr-x=C2=A0 3 root root=C2=A0 16K Jan=C2=A0 1=C2=A0 1970 efi >>>>> drwxr-xr-x=C2=A0 6 root root 4.0K May 13 15:41 grub >>>>> -rw-------=C2=A0 1 root root=C2=A0 26M May 13 15:41 initramfs-5.15.35-i= pfire.img >>>>> drwx------=C2=A0 2 root root=C2=A0 16K Sep 30=C2=A0 2021 lost+found >>>>> -rw-r--r--=C2=A0 1 root root 4.7M May=C2=A0 3 04:02 System.map-5.15.35-= ipfire >>>>> -rw-r--r--=C2=A0 1 root root 6.7M May=C2=A0 3 04:02 vmlinuz-5.15.35-ipf= ire >>>>> >>>>> Dates and times of some of the files/directories have changed as would = be expected. >>>>> >>>>> After Reboot and with the problem the boot directory was now >>>>> >>>>> drwxr-xr-x=C2=A0 5 root root 4.0K Apr 28 09:47 . >>>>> drwxr-xr-x 21 root root 4.0K Nov 28 15:49 .. >>>>> -rw-r--r--=C2=A0 1 root root 179K Apr 26 13:00 config-5.15.35-ipfire >>>>> drwxr-xr-x=C2=A0 3 root root 4.0K Sep 30=C2=A0 2021 efi >>>>> drwxr-xr-x=C2=A0 6 root root 4.0K Apr 28 09:47 grub >>>>> -rw-------=C2=A0 1 root root=C2=A0 26M Apr 28 09:47 initramfs-5.15.35-i= pfire.img >>>>> drwx------=C2=A0 2 root root=C2=A0 16K Sep 30=C2=A0 2021 lost+found >>>>> -rw-r--r--=C2=A0 1 root root 4.7M Apr 26 13:00 System.map-5.15.35-ipfire >>>>> -rw-r--r--=C2=A0 1 root root 6.7M Apr 26 13:00 vmlinuz-5.15.35-ipfire >>>>> >>>>> Which is the same as for the original CU167 machine except that the dat= e/time of the efi directory has changed >>>>> >>>>> For the vm clone that upgraded with no problems the boot directory afte= r reboot was the same as after upgrade. >>>>> >>>>> I don';t understand why or how this has happened but it is certainly a = difference between the vm's having the problem and the ones not. >>>>> >>>>> Regards, >>>>> >>>>> Adolf. >>>>> >>>>> On 13/05/2022 12:09, Michael Tremer wrote: >>>>>> Hello, >>>>>> >>>>>>> On 12 May 2022, at 21:10, Adolf Belka wrot= e: >>>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>> On 12/05/2022 14:53, Michael Tremer wrote: >>>>>>>> Hello, >>>>>>>>> On 12 May 2022, at 12:25, Adolf Belka wr= ote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 12/05/2022 11:13, Michael Tremer wrote: >>>>>>>>>> Hello, >>>>>>>>>> Thanks for spending so much time on this. We definitely need to im= prove the general update experience since we sometimes seem to break people= =E2=80=99s systems and it is not nice to re-install a firewall from scratch. = It will take a while. >>>>>>>>>> So what I can say is that the kernel module issues come from when = the running kernel is changed and the kernel is trying to load any modules th= at now have changed. This fails by design, because we sign our kernel modules= . The key is randomly generated at build time and used to sign all modules an= d it then thrown away. For each build, we are using a different, unique key t= hat is not preserved. >>>>>>>>>> This means that although the kernel modules are of the same versio= n, they cannot be loaded because the signature check fails. That might also e= xplain why you are seeing so many ipset errors, because the kernel cannot loa= d that module any more. However, we use so much ipset now, why isn=E2=80=99t = the module loaded from before the update was started? >>>>>>>>>> The same goes for any network drivers. I assume you are using virt= io or a generic e1000 network adapter which will have been initialised at boo= t time. The kernel should never unload the kernel module for that interface a= nd load it again later. I have no idea what could have triggered that. >>>>>>>>> It is a generic e1000 network adapter that is being used by Virtual= Box. Confirmed that on my working CU167 vm. >>>>>>>>>> No matter what though; after you reboot, the new kernel should be = booted being able to load all modules it wants and the system should run abso= lutely fine. Can you confirm that that is at least the case? >>>>>>>>> No it is not the case. Yesterday when I booted the vm several times= the same error messages occurred each time and I always had no network inter= faces. >>>>>>>> Okay. That is indeed quite bad then. >>>>>>>> Since there is no kernel in 168, is there a chance that we broke the= update to 167? >>>>>>> I don't know but as far as I have been concerned CU167 has worked wel= l on my vm. >>>>>>> Is there something I should look for on my CU167 vm? >>>>>>>>> Just now I tried booting my third attempt vm again and this time it= ran okay and I ended up with all my networks assigned and I had network conn= ection. An IP was assigned by dhcp to the red interface. >>>>>>>> Third time lucky isn=E2=80=99t good enough for me :) >>>>>>> Me neither :-) >>>>>>>>> I then rebooted again and this time the error messages were back. I= rebooted the vm three more times and each time the error messages were there= and no network interfaces. >>>>>>>>> >>>>>>>>> I checked with lsmod and the e1000 driver module was not loaded. Co= nfirmed the e1000 driver directory was not present in /sys/bus/pci/drivers >>>>>>>> Have there been any modules loaded? If one loads, they all should lo= ad. >>>>>>> This is what I get with lsmod >>>>>>> >>>>>>> Module=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Size=C2=A0=C2=A0=C2=A0 Used by >>>>>>> crct10dif_pclmul=C2=A0=C2=A0=C2=A0 16384=C2=A0=C2=A0=C2=A0 1 >>>>>>> crc32_pclmul=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16384=C2=A0=C2= =A0=C2=A0 0 >>>>>>> ghash_clmulni_intel=C2=A0=C2=A0=C2=A0 16384=C2=A0=C2=A0=C2=A0 0 >>>>>>> serio_raw=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 20480=C2=A0=C2=A0= =C2=A0 0 >>>>>>> ohci_pci=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 20480=C2=A0=C2=A0= =C2=A0 0 >>>>>>> ata_generic=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16384=C2=A0=C2= =A0=C2=A0 0 >>>>>>> pata_acpi=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16384=C2=A0=C2=A0= =C2=A0 0 >>>>>>> video=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 57344=C2=A0=C2=A0=C2=A0 0 >>>>>> >>>>>> It looks like these modules could have come from the initramdisk image= . At least that is working well. >>>>>> >>>>>>> On my running CU1678 vm lsmod gives the following >>>>>>> >>>>>>> Module=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Size=C2=A0 Used by >>>>>>> tun=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 61440=C2=A0 2 >>>>>>> nfnetlink_queue=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 28672=C2=A0= 1 >>>>>>> xt_NFQUEUE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 16384=C2=A0 8 >>>>>>> xt_MASQUERADE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2= 0480=C2=A0 1 >>>>>>> cfg80211=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 1036288=C2=A0 0 >>>>>>> rfkill=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 32768=C2=A0 1 cfg80211 >>>>>>> 8021q=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 40960=C2=A0 0 >>>>>>> garp=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16384=C2=A0 1 8021q >>>>>>> xt_set=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16384=C2=A0 260 >>>>>>> ip_set_hash_net=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 49152=C2=A0= 258 >>>>>>> ip_set=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 57344=C2=A0 2 xt_set,ip_set_hash_net >>>>>>> xt_hashlimit=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 20480=C2=A0 2 >>>>>>> xt_multiport=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 20480=C2=A0 4 >>>>>>> xt_policy=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 16384=C2=A0 5 >>>>>>> xt_TCPMSS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 16384=C2=A0 1 >>>>>>> xt_conntrack=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 16384=C2=A0 7 >>>>>>> xt_comment=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 16384=C2=A0 18 >>>>>>> ipt_REJECT=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 16384=C2=A0 1 >>>>>>> nf_reject_ipv4=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16384= =C2=A0 1 ipt_REJECT >>>>>>> xt_LOG=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 20480=C2=A0 26 >>>>>>> xt_limit=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 16384=C2=A0 25 >>>>>>> xt_mark=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16384=C2=A0 27 >>>>>>> xt_connmark=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 16384=C2=A0 2 >>>>>>> nf_log_syslog=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2= 4576=C2=A0 26 >>>>>>> iptable_raw=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 16384=C2=A0 0 >>>>>>> iptable_mangle=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16384= =C2=A0 1 >>>>>>> iptable_filter=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16384= =C2=A0 1 >>>>>>> vfat=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 24576=C2=A0 1 >>>>>>> fat=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 90112=C2=A0 1 vfat >>>>>>> sch_cake=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 36864=C2=A0 4 >>>>>>> intel_powerclamp=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 20480=C2=A0 0 >>>>>>> psmouse=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 184320=C2=A0 0 >>>>>>> pcspkr=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16384=C2=A0 0 >>>>>>> i2c_piix4=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 28672=C2=A0 0 >>>>>>> e1000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 163840=C2=A0 0 >>>>>>> i2c_core=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 106496=C2=A0 2 psmouse,i2c_piix4 >>>>>>> crct10dif_pclmul=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16384=C2=A0 1 >>>>>>> crc32_pclmul=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 16384=C2=A0 0 >>>>>>> ata_generic=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 16384=C2=A0 0 >>>>>>> pata_acpi=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 16384=C2=A0 0 >>>>>>> ghash_clmulni_intel=C2=A0=C2=A0=C2=A0 16384=C2=A0 0 >>>>>>> serio_raw=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 20480=C2=A0 0 >>>>>>> ohci_pci=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 20480=C2=A0 0 >>>>>>> video=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 57344=C2=A0 0 >>>>>> >>>>>> Yes, this looks more like it. >>>>>> >>>>>>> The last 8 entries are the same but a whole load of others are missin= g. >>>>>> >>>>>> Stefan gave me a call this morning telling me that he tried to reprodu= ce this but he couldn=E2=80=99t. >>>>>> >>>>>> I am not sure what we can do here. We urgently need to fix this since = we might break people=E2=80=99s installations. But something seems to work di= fferently for Adolf than for everybody else. >>>>>> >>>>>> -Michael >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Adolf. >>>>>>>>> Tried modprobe e1000 but this came back with the following error >>>>>>>>> modprobe: ERROR: could not insert 'e1000': Key was rejected by serv= ice >>>>>>>>> >>>>>>>>> So out of 7 or 8 reboots the vm booted with the network drivers loa= ded once. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Adolf >>>>>>>>>>> On 11 May 2022, at 20:08, Adolf Belka = wrote: >>>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> On 11/05/2022 20:48, Jon Murphy wrote: >>>>>>>>>>>> I just did an update from CU 167 (stable) to CU 168 (testing) an= d I got the same build info: >>>>>>>>>>>> *IPFire 2.27 (x86_64) - Core Update 167 Development Build: maste= r/c22d834c* >>>>>>>>>>>> Shouldn=E2=80=99t this be Core Update 168? >>>>>>>>>>> That was what I thought but I couldn't precisely remember what it= was in the past with Testing Releases. >>>>>>>>>>> >>>>>>>>>>> I then downloaded the Core 168 iso from the nightlies build of ma= ster/latest/x86_64 and did an install on the First attempt vm. >>>>>>>>>>> >>>>>>>>>>> I got to the stage of entering the root and admin passwords. Ente= red what I usually do for the vm's and after pressing OK on the admin passwor= d screen I got as message box saying "Problem setting IPFire 'admin' user pas= sword". I pressed the OK button and got another message box saying "Initial s= etup was not entirely complete. You must ensure that Setup is properly finish= ed by running setup again at the shell.". Pressing the OK button on that mess= age box causes setup to restart but again after entering a valid admin passwo= rd twice I got the same "Problem setting IPFire 'admin' user password" messag= e box. >>>>>>>>>>> >>>>>>>>>>> I then tried installing CU168 from the same iso onto a clone of m= y running CU167 vm. Same result with "Problem setting IPFire 'admin' user pas= sword" message box. >>>>>>>>>>> >>>>>>>>>>> Then I created a completely new vm from scratch and tried install= ing CU168 Testing iso and again got "Problem setting IPFire 'admin' user pass= word" message box. >>>>>>>>>> That seems to be a bug that should not be there. Did we recently u= pdate apache? >>>>>>>>>> -Michael >>>>>>>>>>> >>>>>>>>>>> Don't know if this is related to the problem with the missing int= erfaces but if not then it is another problem. >>>>>>>>>>> >>>>>>>>>>> I think I am going to raise a bug on this. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Adolf. >>>>>>>>>>>> Jon >>>>>>>>>>>>> On May 11, 2022, at 9:19 AM, Adolf Belka > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/05/2022 16:00, Adolf Belka wrote: >>>>>>>>>>>>>> Hi Leo, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/05/2022 15:26, Leo Hofmann wrote: >>>>>>>>>>>>>>> Hi Adolf, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Pakfire always automatically reinstalls the current release b= efore updating if you are in the testing branch. See this function in the Pak= fire code: >>>>>>>>>>>>>> So that proves that I haven't been looking so closely on my up= grades in the past because I have never noticed that. >>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dsrc/p= akfire/lib/functions.pl;h=3Dd4e338f23ae8ae97d6f18c6d8890d13463dc5d30;hb=3Dref= s/heads/next#l762 >>>>>>>>>>>>>> Now I see it in the code. Thanks very much. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But unfortunately this is all I can contribute, my test syste= m updated to 168 without problems! >>>>>>>>>>>>>> Thanks for your help anyway. It's got rid of one of my questio= ns. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just need to understand now why 2 out of 3 updates resulted in= a complete loss of the interface assignments. >>>>>>>>>>>>>> Will wait to hear other inputs on this problem. >>>>>>>>>>>>>> Maybe will try running setup on the first try I had to confirm= that I can re-assign the interfaces again. >>>>>>>>>>>>>> >>>>>>>>>>>>> Running setup does not help. None of the interfaces are availab= le to be assigned to the red, green etc zones. >>>>>>>>>>>>> >>>>>>>>>>>>> I checked the interfaces in the vm setup and they are as previo= usly defined and previously working on all earlier CU's of my vm. >>>>>>>>>>>>> >>>>>>>>>>>>> When rebooting I did see a fast scrolling message that seemed t= o say something like Invalid Kernel Argument but that is as much as I was abl= e to see/ >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Adolf. >>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>> Leo >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am 11.05.2022 um 15:11 schrieb Adolf Belka: >>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have tried to update my Core Update 167 vm machine three t= imes now (using a clone) and have had several problems so I thought I would o= utline what has happened for further thoughts. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Normally my updates go without any real problems. This is th= e first time where this is not the case. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> First try:- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> After running the update, which went quite quickly, the bott= om of the screen had >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Core Update 167 Development Build: master/c22d834c >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I couldn't remember if this is what is expected or not for T= esting releases. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Rebooted the vm and on booting a large number of error messa= ges scrolled across the console screen. My Virtualbox terminal for IPFire has= no scroll capability so I can only write on things I saw as they flew past o= r what was on the screen when it stopped. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Lots of ipset restore error but went by too fast to get more= detail. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Tried to access via the WUI and no access. Tried via SSH and= no access. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Checked the red0 directory and there were no files present. = Tried restarting red0 and got the following message >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> starting >>>>>>>>>>>>>>>> DUID 00:04:70:........ >>>>>>>>>>>>>>>> red0: interface not found >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So I ran ip address show and it came up with only the lo int= erface. No red0, green0, blue0 or orange0. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Looked in bootlog and this was filled with around 4000 lines= all the same >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Loading of module with unavailable key is rejected >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Second try:- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This time running the update took over 10 mins. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Noticed on the pakfire screen that it first ran a Core Updat= e 167 upgrade then it ran the Core Update 168. My IPFire vm was definitely on= Core Update 167. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /opt/pakfire/db/core/mine contained 167 beforehand. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Before doing the reboot I accessed via ssh and saw that in t= he /var/log/pakfire/ directory the update-core-upgrade-167 file has been upda= ted as well as there being a 168. Both files had the same last modified date/= time. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Rebooted. This time everything came back up okay but the bot= tom of the screen now just said Core Update 167 and there was no update-core-= upgrade-168 file in the pakfire directory and the 167 version was back to its= date of Apr 28 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Repository was set back to Stable. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Changed again to Testing and it said again that there was an= update from 167 to 168. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Before running the pakfire directory had the following >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -rw-r--r-- 1 root root 1.8K Mar 31 23:26 update-core-upgrade= -166.log >>>>>>>>>>>>>>>> -rw-r--r-- 1 root root 323K Apr 28 09:47 update-core-upgrade= -167.log >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> After running it had >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -rw-r--r-- 1 root root 1.8K Mar 31 23:26 update-core-upgrade= -166.log >>>>>>>>>>>>>>>> -rw-r--r-- 1 root root 604K May 11 13:24 update-core-upgrade= -167.log >>>>>>>>>>>>>>>> -rw-r--r-- 1 root root 175 May 11 13:24 update-core-upgrade-= 168.log >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> back to Core Update 167 Development Build: master/c22d834c a= t bottom of screen. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Rebooted. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> All interfaces present. Pakfire under System Status: says Co= re-Update-Level: 168 and the bottom of the screen showed Core Update 167 Deve= lopment Build: master/c22d834c >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /opt/pakfire/db/core/mine has 168 in it >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I checked the WIO wio.pl file that had a bug fix and it was = as expected for CU168. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Third try:- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -rw-r--r-- 1 root root 323K Apr 28 09:47 update-core-upgrade= -167.log >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Selected Testing and ran update from 167 to 168 which occurr= ed very quickly. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -rw-r--r-- 1 root root 604K May 11 14:00 update-core-upgrade= -167.log >>>>>>>>>>>>>>>> -rw-r--r-- 1 root root 63K May 11 14:01 update-core-upgrade-= 168.log >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Here is the log file info for pakfire from messages.1.gz and= messages which shows it downloading and upgrading CU167 first then doing CU1= 68 as far as I can tell. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> May 11 13:59:30 ipfire pakfire: PAKFIRE INFO: IPFire Pakfire= 2.27.1-x86_64 started! >>>>>>>>>>>>>>>> May 11 13:59:30 ipfire pakfire: CORE INFO: core-list.db is 2= 7 seconds old. - DEBUG: noforce >>>>>>>>>>>>>>>> May 11 13:59:30 ipfire pakfire: CORE UPGR: Upgrading from re= lease 166 to 168 >>>>>>>>>>>>>>>> May 11 13:59:30 ipfire pakfire: DOWNLOAD STARTED: paks/core-= upgrade-2.27-167.ipfire >>>>>>>>>>>>>>>> May 11 13:59:30 ipfire pakfire: MIRROR INFO: 2 servers found= in list >>>>>>>>>>>>>>>> May 11 13:59:30 ipfire pakfire: DOWNLOAD INFO: Host: ipfire.= earl-net.com (HTTPS) - File: pakfire2/2.27.1-x8= 6_64/paks/core-upgrade-2.27-167.ipfire >>>>>>>>>>>>>>>> May 11 13:59:30 ipfire pakfire: DOWNLOAD INFO: pakfire2/2.27= .1-x86_64/paks/core-upgrade-2.27-167.ipfire has size of 71914825 bytes >>>>>>>>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD INFO: HTTP-Status-C= ode: 200 - 200 OK >>>>>>>>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD INFO: File received= . Start checking signature... >>>>>>>>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD INFO: Signature of = core-upgrade-2.27-167.ipfire is fine. >>>>>>>>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD FINISHED: pakfire2/= 2.27.1-x86_64/paks/core-upgrade-2.27-167.ipfire >>>>>>>>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD STARTED: meta/meta-= core-upgrade-168 >>>>>>>>>>>>>>>> May 11 13:59:32 ipfire pakfire: MIRROR INFO: 2 servers found= in list >>>>>>>>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD INFO: Host: mirror1= .ipfire.org (HTTPS) - File: pakfire2/2.27.1-x86_= 64/meta/meta-core-upgrade-168 >>>>>>>>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD INFO: pakfire2/2.27= .1-x86_64/meta/meta-core-upgrade-168 has size of 1804 bytes >>>>>>>>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD INFO: HTTP-Status-C= ode: 200 - 200 OK >>>>>>>>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD INFO: File received= . Start checking signature... >>>>>>>>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD INFO: Signature of = meta-core-upgrade-168 is fine. >>>>>>>>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD FINISHED: pakfire2/= 2.27.1-x86_64/meta/meta-core-upgrade-168 >>>>>>>>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD STARTED: paks/core-= upgrade-2.27-168.ipfire >>>>>>>>>>>>>>>> May 11 13:59:33 ipfire pakfire: MIRROR INFO: 2 servers found= in list >>>>>>>>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD INFO: Host: ipfire.= earl-net.com (HTTPS) - File: pakfire2/2.27.1-x8= 6_64/paks/core-upgrade-2.27-168.ipfire >>>>>>>>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD INFO: pakfire2/2.27= .1-x86_64/paks/core-upgrade-2.27-168.ipfire has size of 34355484 bytes >>>>>>>>>>>>>>>> May 11 13:59:34 ipfire pakfire: DOWNLOAD INFO: HTTP-Status-C= ode: 200 - 200 OK >>>>>>>>>>>>>>>> May 11 13:59:34 ipfire pakfire: DOWNLOAD INFO: File received= . Start checking signature... >>>>>>>>>>>>>>>> May 11 13:59:34 ipfire pakfire: DOWNLOAD INFO: Signature of = core-upgrade-2.27-168.ipfire is fine. >>>>>>>>>>>>>>>> May 11 13:59:34 ipfire pakfire: DOWNLOAD FINISHED: pakfire2/= 2.27.1-x86_64/paks/core-upgrade-2.27-168.ipfire >>>>>>>>>>>>>>>> May 11 13:59:34 ipfire pakfire: PAKFIRE UPGR: core-upgrade-1= 67: Decrypting... >>>>>>>>>>>>>>>> May 11 13:59:34 ipfire pakfire: CLEANUP: tmp >>>>>>>>>>>>>>>> May 11 13:59:34 ipfire pakfire: DECRYPT STARTED: core-upgrad= e-167 >>>>>>>>>>>>>>>> May 11 13:59:35 ipfire pakfire: DECRYPT FINISHED: core-upgra= de-167 - Status: 0 >>>>>>>>>>>>>>>> May 11 13:59:35 ipfire pakfire: PAKFIRE UPGR: core-upgrade-1= 67: Upgrading files and running post-upgrading scripts... >>>>>>>>>>>>>>>> May 11 14:00:31 ipfire pakfire: CLEANUP: tmp >>>>>>>>>>>>>>>> May 11 14:00:31 ipfire pakfire: PAKFIRE UPGR: core-upgrade-1= 67: Finished. >>>>>>>>>>>>>>>> May 11 14:00:31 ipfire pakfire: PAKFIRE UPGR: core-upgrade-1= 68: Decrypting... >>>>>>>>>>>>>>>> May 11 14:00:31 ipfire pakfire: CLEANUP: tmp >>>>>>>>>>>>>>>> May 11 14:00:31 ipfire pakfire: DECRYPT STARTED: core-upgrad= e-168 >>>>>>>>>>>>>>>> May 11 14:00:32 ipfire pakfire: DECRYPT FINISHED: core-upgra= de-168 - Status: 0 >>>>>>>>>>>>>>>> May 11 14:00:32 ipfire pakfire: PAKFIRE UPGR: core-upgrade-1= 68: Upgrading files and running post-upgrading scripts... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: CLEANUP: tmp >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: PAKFIRE UPGR: core-upgrade-1= 68: Finished. >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: CORE INFO: core-list.db is 1= 27 seconds old. - DEBUG: noforce >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: PAKFIRE RESV: wio: Resolving= dependencies... >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: PAKFIRE UPGR: We are going t= o install all packages listed above. >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD STARTED: paks/wio-1= .3.2-15.ipfire >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: MIRROR INFO: 2 servers found= in list >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD INFO: Host: mirror1= .ipfire.org (HTTPS) - File: pakfire2/2.27.1-x86_= 64/paks/wio-1.3.2-15.ipfire >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD INFO: pakfire2/2.27= .1-x86_64/paks/wio-1.3.2-15.ipfire has size of 47216 bytes >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD INFO: HTTP-Status-C= ode: 200 - 200 OK >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD INFO: File received= . Start checking signature... >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD INFO: Signature of = wio-1.3.2-15.ipfire is fine. >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD FINISHED: pakfire2/= 2.27.1-x86_64/paks/wio-1.3.2-15.ipfire >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: PAKFIRE UPGR: wio: Decryptin= g... >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: CLEANUP: tmp >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: DECRYPT STARTED: wio >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: DECRYPT FINISHED: wio - Stat= us: 0 >>>>>>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: PAKFIRE UPGR: wio: Upgrading= files and running post-upgrading scripts... >>>>>>>>>>>>>>>> May 11 14:01:11 ipfire pakfire: CLEANUP: tmp >>>>>>>>>>>>>>>> May 11 14:01:11 ipfire pakfire: PAKFIRE UPGR: wio: Finished. >>>>>>>>>>>>>>>> May 11 14:01:11 ipfire pakfire: PAKFIRE INFO: Pakfire has fi= nished. Closing. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Rebooted >>>>>>>>>>>>>>>> Lots of ipset restore error but went by too fast to get more= detail. >>>>>>>>>>>>>>>> Several repeats of the following two lines on the console sc= reen:- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> iptables v1.8.7 (legacy): can't initialize iptables table `f= ilter' : Table does not exist (do you need to insmod?) >>>>>>>>>>>>>>>> Perhaps iptables or your kernel needs to be upgraded. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Only lo interface present. All other interfaces red0, green0= , blue0, orange0 not present. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have given up at this point. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have kept the clones of all three attempts so if you need = any additional info from logs or files just let me know. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If this is something obviously wrong that I am doing, please= let me know. If not then I will probably raise a bug on this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Adolf. >>>>>> >>> --===============5317504267448638510==--