From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Feedback on problems with Core Update 168 Testing Date: Fri, 13 May 2022 19:12:09 +0200 Message-ID: In-Reply-To: <2ec9e93a-643b-3538-8aec-f761c978f3ab@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8307195541557398422==" List-Id: --===============8307195541557398422== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, I think I may understand what is happening with my vm now. Of course I could = also be wrong :-) but I will give it a go. I saw bug#12862 where upgrading from CU166 to CU167 had stopped the raid arra= y running so that IPFire was only on one disk. I had missed seeing this in my evaluation of CU167 on my vm which does run wi= th 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 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 of 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 52428724 blocks super 1.0 unused devices: So it looks like it has booted up on the disk that was not updated from the r= aid pair. This probably also explains why occasionally I have had a vm that was not wor= king 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 setups an= d the problem originated in the CU167 upgrade. So raid systems need to have their raid arrays fully working before doing an = upgrade. At least the above is my interpretation of what I have found. What does every= one 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 p= roblem and those that have lost most of the modules. > > I did another three vm clones and upgrades and the first two all went with = no problems. I was starting to think the issue had gone away but on the third= one the same problem happened after the reboot. > > However I did copy the boot directory info for these two cases and found an= interesting effect. > > For the problem vm here was the boot directory layout of the CU167 base mac= hine > > 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-ipfir= e.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-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 May 13 15:41 grub > -rw-------=C2=A0 1 root root=C2=A0 26M May 13 15:41 initramfs-5.15.35-ipfir= e.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-ipfi= re > -rw-r--r--=C2=A0 1 root root 6.7M May=C2=A0 3 04:02 vmlinuz-5.15.35-ipfire > > Dates and times of some of the files/directories have changed as would be e= xpected. > > 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-ipfir= e.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 date/ti= me of the efi directory has changed > > For the vm clone that upgraded with no problems the boot directory after re= boot was the same as after upgrade. > > I don';t understand why or how this has happened but it is certainly a diff= erence 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 wrote: >>> >>> Hi Michael, >>> >>> On 12/05/2022 14:53, Michael Tremer wrote: >>>> Hello, >>>>> On 12 May 2022, at 12:25, Adolf Belka wrote: >>>>> >>>>> Hi, >>>>> >>>>> On 12/05/2022 11:13, Michael Tremer wrote: >>>>>> Hello, >>>>>> Thanks for spending so much time on this. We definitely need to improv= e 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 wil= l 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 that n= ow have changed. This fails by design, because we sign our kernel modules. Th= e key is randomly generated at build time and used to sign all modules and it= then thrown away. For each build, we are using a different, unique key that = is not preserved. >>>>>> This means that although the kernel modules are of the same version, t= hey cannot be loaded because the signature check fails. That might also expla= in why you are seeing so many ipset errors, because the kernel cannot load th= at 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 virtio o= r a generic e1000 network adapter which will have been initialised at boot ti= me. The kernel should never unload the kernel module for that interface and l= oad it again later. I have no idea what could have triggered that. >>>>> It is a generic e1000 network adapter that is being used by VirtualBox.= Confirmed that on my working CU167 vm. >>>>>> No matter what though; after you reboot, the new kernel should be boot= ed being able to load all modules it wants and the system should run absolute= ly 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 interface= s. >>>> Okay. That is indeed quite bad then. >>>> Since there is no kernel in 168, is there a chance that we broke the upd= ate to 167? >>> I don't know but as far as I have been concerned CU167 has worked well 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 connecti= on. 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 reb= ooted 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. Confir= med the e1000 driver directory was not present in /sys/bus/pci/drivers >>>> Have there been any modules loaded? If one loads, they all should load. >>> 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 5= 7344=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 20480= =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 24576= =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 missing. >> >> Stefan gave me a call this morning telling me that he tried to reproduce t= his but he couldn=E2=80=99t. >> >> I am not sure what we can do here. We urgently need to fix this since we m= ight break people=E2=80=99s installations. But something seems to work differ= ently 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 service >>>>> >>>>> So out of 7 or 8 reboots the vm booted with the network drivers loaded = once. >>>>> >>>>> Regards >>>>> Adolf >>>>>>> On 11 May 2022, at 20:08, Adolf Belka wrot= e: >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> On 11/05/2022 20:48, Jon Murphy wrote: >>>>>>>> I just did an update from CU 167 (stable) to CU 168 (testing) and I = got the same build info: >>>>>>>> *IPFire 2.27 (x86_64) - Core Update 167 Development Build: master/c2= 2d834c* >>>>>>>> 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 master= /latest/x86_64 and did an install on the First attempt vm. >>>>>>> >>>>>>> I got to the stage of entering the root and admin passwords. Entered = what I usually do for the vm's and after pressing OK on the admin password sc= reen I got as message box saying "Problem setting IPFire 'admin' user passwor= d". I pressed the OK button and got another message box saying "Initial setup= was not entirely complete. You must ensure that Setup is properly finished b= y running setup again at the shell.". Pressing the OK button on that message = box causes setup to restart but again after entering a valid admin password t= wice I got the same "Problem setting IPFire 'admin' user password" message bo= x. >>>>>>> >>>>>>> I then tried installing CU168 from the same iso onto a clone of my ru= nning CU167 vm. Same result with "Problem setting IPFire 'admin' user passwor= d" message box. >>>>>>> >>>>>>> Then I created a completely new vm from scratch and tried installing = CU168 Testing iso and again got "Problem setting IPFire 'admin' user password= " message box. >>>>>> That seems to be a bug that should not be there. Did we recently updat= e apache? >>>>>> -Michael >>>>>>> >>>>>>> Don't know if this is related to the problem with the missing interfa= ces 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 befor= e updating if you are in the testing branch. See this function in the Pakfire= code: >>>>>>>>>> So that proves that I haven't been looking so closely on my upgrad= es in the past because I have never noticed that. >>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dsrc/pakfi= re/lib/functions.pl;h=3Dd4e338f23ae8ae97d6f18c6d8890d13463dc5d30;hb=3Drefs/he= ads/next#l762 >>>>>>>>>> Now I see it in the code. Thanks very much. >>>>>>>>>>> >>>>>>>>>>> But unfortunately this is all I can contribute, my test system up= dated to 168 without problems! >>>>>>>>>> Thanks for your help anyway. It's got rid of one of my questions. >>>>>>>>>> >>>>>>>>>> Just need to understand now why 2 out of 3 updates resulted in a c= omplete 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 tha= t I can re-assign the interfaces again. >>>>>>>>>> >>>>>>>>> Running setup does not help. None of the interfaces are available t= o be assigned to the red, green etc zones. >>>>>>>>> >>>>>>>>> I checked the interfaces in the vm setup and they are as previously= defined and previously working on all earlier CU's of my vm. >>>>>>>>> >>>>>>>>> When rebooting I did see a fast scrolling message that seemed to sa= y something like Invalid Kernel Argument but that is as much as I was able 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 times= now (using a clone) and have had several problems so I thought I would outli= ne what has happened for further thoughts. >>>>>>>>>>>> >>>>>>>>>>>> Normally my updates go without any real problems. This is the fi= rst time where this is not the case. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> First try:- >>>>>>>>>>>> >>>>>>>>>>>> After running the update, which went quite quickly, the bottom o= f the screen had >>>>>>>>>>>> >>>>>>>>>>>> Core Update 167 Development Build: master/c22d834c >>>>>>>>>>>> >>>>>>>>>>>> I couldn't remember if this is what is expected or not for Testi= ng releases. >>>>>>>>>>>> >>>>>>>>>>>> Rebooted the vm and on booting a large number of error messages = 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 or wh= at was on the screen when it stopped. >>>>>>>>>>>> >>>>>>>>>>>> Lots of ipset restore error but went by too fast to get more det= ail. >>>>>>>>>>>> >>>>>>>>>>>> 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. Trie= d 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 interfa= ce. 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 Update 16= 7 upgrade then it ran the Core Update 168. My IPFire vm was definitely on Cor= e Update 167. >>>>>>>>>>>> >>>>>>>>>>>> /opt/pakfire/db/core/mine contained 167 beforehand. >>>>>>>>>>>> >>>>>>>>>>>> Before doing the reboot I accessed via ssh and saw that in the /= var/log/pakfire/ directory the update-core-upgrade-167 file has been updated = 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 bottom = of the screen now just said Core Update 167 and there was no update-core-upgr= ade-168 file in the pakfire directory and the 167 version was back to its dat= e of Apr 28 >>>>>>>>>>>> >>>>>>>>>>>> Repository was set back to Stable. >>>>>>>>>>>> >>>>>>>>>>>> Changed again to Testing and it said again that there was an upd= ate 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 at bo= ttom of screen. >>>>>>>>>>>> >>>>>>>>>>>> Rebooted. >>>>>>>>>>>> >>>>>>>>>>>> All interfaces present. Pakfire under System Status: says Core-U= pdate-Level: 168 and the bottom of the screen showed Core Update 167 Developm= ent 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 e= xpected 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 occurred v= ery 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 mes= sages which shows it downloading and upgrading CU167 first then doing CU168 a= s far as I can tell. >>>>>>>>>>>> >>>>>>>>>>>> May 11 13:59:30 ipfire pakfire: PAKFIRE INFO: IPFire Pakfire 2.2= 7.1-x86_64 started! >>>>>>>>>>>> May 11 13:59:30 ipfire pakfire: CORE INFO: core-list.db is 27 se= conds old. - DEBUG: noforce >>>>>>>>>>>> May 11 13:59:30 ipfire pakfire: CORE UPGR: Upgrading from releas= e 166 to 168 >>>>>>>>>>>> May 11 13:59:30 ipfire pakfire: DOWNLOAD STARTED: paks/core-upgr= ade-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-x86_64= /paks/core-upgrade-2.27-167.ipfire >>>>>>>>>>>> May 11 13:59:30 ipfire pakfire: DOWNLOAD INFO: pakfire2/2.27.1-x= 86_64/paks/core-upgrade-2.27-167.ipfire has size of 71914825 bytes >>>>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD INFO: HTTP-Status-Code:= 200 - 200 OK >>>>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD INFO: File received. St= art 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.ipf= ire.org (HTTPS) - File: pakfire2/2.27.1-x86_64/m= eta/meta-core-upgrade-168 >>>>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD INFO: pakfire2/2.27.1-x= 86_64/meta/meta-core-upgrade-168 has size of 1804 bytes >>>>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD INFO: HTTP-Status-Code:= 200 - 200 OK >>>>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD INFO: File received. St= art 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-upgr= ade-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-x86_64= /paks/core-upgrade-2.27-168.ipfire >>>>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD INFO: pakfire2/2.27.1-x= 86_64/paks/core-upgrade-2.27-168.ipfire has size of 34355484 bytes >>>>>>>>>>>> May 11 13:59:34 ipfire pakfire: DOWNLOAD INFO: HTTP-Status-Code:= 200 - 200 OK >>>>>>>>>>>> May 11 13:59:34 ipfire pakfire: DOWNLOAD INFO: File received. St= art 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-167: = Decrypting... >>>>>>>>>>>> May 11 13:59:34 ipfire pakfire: CLEANUP: tmp >>>>>>>>>>>> May 11 13:59:34 ipfire pakfire: DECRYPT STARTED: core-upgrade-167 >>>>>>>>>>>> May 11 13:59:35 ipfire pakfire: DECRYPT FINISHED: core-upgrade-1= 67 - Status: 0 >>>>>>>>>>>> May 11 13:59:35 ipfire pakfire: PAKFIRE UPGR: core-upgrade-167: = 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-167: = Finished. >>>>>>>>>>>> May 11 14:00:31 ipfire pakfire: PAKFIRE UPGR: core-upgrade-168: = Decrypting... >>>>>>>>>>>> May 11 14:00:31 ipfire pakfire: CLEANUP: tmp >>>>>>>>>>>> May 11 14:00:31 ipfire pakfire: DECRYPT STARTED: core-upgrade-168 >>>>>>>>>>>> May 11 14:00:32 ipfire pakfire: DECRYPT FINISHED: core-upgrade-1= 68 - Status: 0 >>>>>>>>>>>> May 11 14:00:32 ipfire pakfire: PAKFIRE UPGR: core-upgrade-168: = 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-168: = Finished. >>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: CORE INFO: core-list.db is 127 s= econds old. - DEBUG: noforce >>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: PAKFIRE RESV: wio: Resolving dep= endencies... >>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: PAKFIRE UPGR: We are going to in= stall 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.ipf= ire.org (HTTPS) - File: pakfire2/2.27.1-x86_64/p= aks/wio-1.3.2-15.ipfire >>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD INFO: pakfire2/2.27.1-x= 86_64/paks/wio-1.3.2-15.ipfire has size of 47216 bytes >>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD INFO: HTTP-Status-Code:= 200 - 200 OK >>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD INFO: File received. St= art 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: Decrypting... >>>>>>>>>>>> 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 - Status: 0 >>>>>>>>>>>> May 11 14:01:10 ipfire pakfire: PAKFIRE UPGR: wio: Upgrading fil= es 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 finish= ed. Closing. >>>>>>>>>>>> >>>>>>>>>>>> Rebooted >>>>>>>>>>>> Lots of ipset restore error but went by too fast to get more det= ail. >>>>>>>>>>>> Several repeats of the following two lines on the console screen= :- >>>>>>>>>>>> >>>>>>>>>>>> iptables v1.8.7 (legacy): can't initialize iptables table `filte= r' : 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, bl= ue0, 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. >> --===============8307195541557398422==--