From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Feedback on problems with Core Update 168 Testing Date: Fri, 13 May 2022 11:09:37 +0100 Message-ID: <89F1EACA-EE8A-463C-A354-1E98DE96BA9D@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6006216579171424245==" List-Id: --===============6006216579171424245== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 12 May 2022, at 21:10, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 12/05/2022 14:53, Michael Tremer wrote: >> Hello, >>> On 12 May 2022, at 12:25, Adolf Belka wrote: >>>=20 >>> Hi, >>>=20 >>> On 12/05/2022 11:13, Michael Tremer wrote: >>>> Hello, >>>> Thanks for spending so much time on this. We definitely need to improve = 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 ru= nning kernel is changed and the kernel is trying to load any modules that 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 and it t= hen 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, the= y cannot be loaded because the signature check fails. That might also explain= why you are seeing so many ipset errors, because the kernel cannot load that= module any more. However, we use so much ipset now, why isn=E2=80=99t the mo= dule loaded from before the update was started? >>>> The same goes for any network drivers. I assume you are using virtio or = a generic e1000 network adapter which will have been initialised at boot time= . The kernel should never unload the kernel module for that interface and loa= d 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. C= onfirmed 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 absolutely= 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 s= ame error messages occurred each time and I always had no network interfaces. >> Okay. That is indeed quite bad then. >> Since there is no kernel in 168, is there a chance that we broke the updat= e to 167? > I don't know but as far as I have been concerned CU167 has worked well on m= y 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 o= kay and I ended up with all my networks assigned and I had network connection= . 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 reboo= ted the vm three more times and each time the error messages were there and n= o network interfaces. >>>=20 >>> I checked with lsmod and the e1000 driver module was not loaded. Confirme= d 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 >=20 > Module Size Used by > crct10dif_pclmul 16384 1 > crc32_pclmul 16384 0 > ghash_clmulni_intel 16384 0 > serio_raw 20480 0 > ohci_pci 20480 0 > ata_generic 16384 0 > pata_acpi 16384 0 > video 57344 0 It looks like these modules could have come from the initramdisk image. At le= ast that is working well. > On my running CU1678 vm lsmod gives the following >=20 > Module Size Used by > tun 61440 2 > nfnetlink_queue 28672 1 > xt_NFQUEUE 16384 8 > xt_MASQUERADE 20480 1 > cfg80211 1036288 0 > rfkill 32768 1 cfg80211 > 8021q 40960 0 > garp 16384 1 8021q > xt_set 16384 260 > ip_set_hash_net 49152 258 > ip_set 57344 2 xt_set,ip_set_hash_net > xt_hashlimit 20480 2 > xt_multiport 20480 4 > xt_policy 16384 5 > xt_TCPMSS 16384 1 > xt_conntrack 16384 7 > xt_comment 16384 18 > ipt_REJECT 16384 1 > nf_reject_ipv4 16384 1 ipt_REJECT > xt_LOG 20480 26 > xt_limit 16384 25 > xt_mark 16384 27 > xt_connmark 16384 2 > nf_log_syslog 24576 26 > iptable_raw 16384 0 > iptable_mangle 16384 1 > iptable_filter 16384 1 > vfat 24576 1 > fat 90112 1 vfat > sch_cake 36864 4 > intel_powerclamp 20480 0 > psmouse 184320 0 > pcspkr 16384 0 > i2c_piix4 28672 0 > e1000 163840 0 > i2c_core 106496 2 psmouse,i2c_piix4 > crct10dif_pclmul 16384 1 > crc32_pclmul 16384 0 > ata_generic 16384 0 > pata_acpi 16384 0 > ghash_clmulni_intel 16384 0 > serio_raw 20480 0 > ohci_pci 20480 0 > video 57344 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 this= but he couldn=E2=80=99t. I am not sure what we can do here. We urgently need to fix this since we migh= t break people=E2=80=99s installations. But something seems to work different= ly for Adolf than for everybody else. -Michael >=20 > Regards, > Adolf. >>> Tried modprobe e1000 but this came back with the following error >>> modprobe: ERROR: could not insert 'e1000': Key was rejected by service >>>=20 >>> So out of 7 or 8 reboots the vm booted with the network drivers loaded on= ce. >>>=20 >>> Regards >>> Adolf >>>>> On 11 May 2022, at 20:08, Adolf Belka wrote: >>>>>=20 >>>>> Hi All, >>>>>=20 >>>>> On 11/05/2022 20:48, Jon Murphy wrote: >>>>>> I just did an update from CU 167 (stable) to CU 168 (testing) and I go= t the same build info: >>>>>> *IPFire 2.27 (x86_64) - Core Update 167 Development Build: master/c22d= 834c* >>>>>> Shouldn=E2=80=99t this be Core Update 168? >>>>> That was what I thought but I couldn't precisely remember what it was i= n the past with Testing Releases. >>>>>=20 >>>>> I then downloaded the Core 168 iso from the nightlies build of master/l= atest/x86_64 and did an install on the First attempt vm. >>>>>=20 >>>>> I got to the stage of entering the root and admin passwords. Entered wh= at I usually do for the vm's and after pressing OK on the admin password scre= en I got as message box saying "Problem setting IPFire 'admin' user password"= . I pressed the OK button and got another message box saying "Initial setup w= as not entirely complete. You must ensure that Setup is properly finished by = running setup again at the shell.". Pressing the OK button on that message bo= x causes setup to restart but again after entering a valid admin password twi= ce I got the same "Problem setting IPFire 'admin' user password" message box. >>>>>=20 >>>>> I then tried installing CU168 from the same iso onto a clone of my runn= ing CU167 vm. Same result with "Problem setting IPFire 'admin' user password"= message box. >>>>>=20 >>>>> Then I created a completely new vm from scratch and tried installing CU= 168 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 update = apache? >>>> -Michael >>>>>=20 >>>>> Don't know if this is related to the problem with the missing interface= s but if not then it is another problem. >>>>>=20 >>>>> I think I am going to raise a bug on this. >>>>>=20 >>>>> Regards, >>>>> Adolf. >>>>>> Jon >>>>>>> On May 11, 2022, at 9:19 AM, Adolf Belka > wrote: >>>>>>>=20 >>>>>>> Hi All, >>>>>>>=20 >>>>>>> On 11/05/2022 16:00, Adolf Belka wrote: >>>>>>>> Hi Leo, >>>>>>>>=20 >>>>>>>> On 11/05/2022 15:26, Leo Hofmann wrote: >>>>>>>>> Hi Adolf, >>>>>>>>>=20 >>>>>>>>> Pakfire always automatically reinstalls the current release before = updating if you are in the testing branch. See this function in the Pakfire c= ode: >>>>>>>> So that proves that I haven't been looking so closely on my upgrades= in the past because I have never noticed that. >>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dsrc/pakfire= /lib/functions.pl;h=3Dd4e338f23ae8ae97d6f18c6d8890d13463dc5d30;hb=3Drefs/head= s/next#l762 >>>>>>>> Now I see it in the code. Thanks very much. >>>>>>>>>=20 >>>>>>>>> But unfortunately this is all I can contribute, my test system upda= ted to 168 without problems! >>>>>>>> Thanks for your help anyway. It's got rid of one of my questions. >>>>>>>>=20 >>>>>>>> Just need to understand now why 2 out of 3 updates resulted in a com= plete 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. >>>>>>>>=20 >>>>>>> Running setup does not help. None of the interfaces are available to = be assigned to the red, green etc zones. >>>>>>>=20 >>>>>>> I checked the interfaces in the vm setup and they are as previously d= efined and previously working on all earlier CU's of my vm. >>>>>>>=20 >>>>>>> When rebooting I did see a fast scrolling message that seemed to say = something like Invalid Kernel Argument but that is as much as I was able to s= ee/ >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Adolf. >>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Adolf. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Best regards >>>>>>>>> Leo >>>>>>>>>=20 >>>>>>>>> Am 11.05.2022 um 15:11 schrieb Adolf Belka: >>>>>>>>>> Hi All, >>>>>>>>>>=20 >>>>>>>>>> I have tried to update my Core Update 167 vm machine three times n= ow (using a clone) and have had several problems so I thought I would outline= what has happened for further thoughts. >>>>>>>>>>=20 >>>>>>>>>> Normally my updates go without any real problems. This is the firs= t time where this is not the case. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> First try:- >>>>>>>>>>=20 >>>>>>>>>> After running the update, which went quite quickly, the bottom of = the screen had >>>>>>>>>>=20 >>>>>>>>>> Core Update 167 Development Build: master/c22d834c >>>>>>>>>>=20 >>>>>>>>>> I couldn't remember if this is what is expected or not for Testing= releases. >>>>>>>>>>=20 >>>>>>>>>> Rebooted the vm and on booting a large number of error messages sc= rolled across the console screen. My Virtualbox terminal for IPFire has no sc= roll capability so I can only write on things I saw as they flew past or what= was on the screen when it stopped. >>>>>>>>>>=20 >>>>>>>>>> Lots of ipset restore error but went by too fast to get more detai= l. >>>>>>>>>>=20 >>>>>>>>>> Tried to access via the WUI and no access. Tried via SSH and no ac= cess. >>>>>>>>>>=20 >>>>>>>>>> Checked the red0 directory and there were no files present. Tried = restarting red0 and got the following message >>>>>>>>>>=20 >>>>>>>>>> starting >>>>>>>>>> DUID 00:04:70:........ >>>>>>>>>> red0: interface not found >>>>>>>>>>=20 >>>>>>>>>> So I ran ip address show and it came up with only the lo interface= . No red0, green0, blue0 or orange0. >>>>>>>>>>=20 >>>>>>>>>> Looked in bootlog and this was filled with around 4000 lines all t= he same >>>>>>>>>>=20 >>>>>>>>>> Loading of module with unavailable key is rejected >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Second try:- >>>>>>>>>>=20 >>>>>>>>>> This time running the update took over 10 mins. >>>>>>>>>>=20 >>>>>>>>>> Noticed on the pakfire screen that it first ran a Core Update 167 = upgrade then it ran the Core Update 168. My IPFire vm was definitely on Core = Update 167. >>>>>>>>>>=20 >>>>>>>>>> /opt/pakfire/db/core/mine contained 167 beforehand. >>>>>>>>>>=20 >>>>>>>>>> Before doing the reboot I accessed via ssh and saw that in the /va= r/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. >>>>>>>>>>=20 >>>>>>>>>> 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-upgrad= e-168 file in the pakfire directory and the 167 version was back to its date = of Apr 28 >>>>>>>>>>=20 >>>>>>>>>> Repository was set back to Stable. >>>>>>>>>>=20 >>>>>>>>>> Changed again to Testing and it said again that there was an updat= e from 167 to 168. >>>>>>>>>>=20 >>>>>>>>>> Before running the pakfire directory had the following >>>>>>>>>>=20 >>>>>>>>>> -rw-r--r-- 1 root root 1.8K Mar 31 23:26 update-core-upgrade-166.l= og >>>>>>>>>> -rw-r--r-- 1 root root 323K Apr 28 09:47 update-core-upgrade-167.l= og >>>>>>>>>>=20 >>>>>>>>>> After running it had >>>>>>>>>>=20 >>>>>>>>>> -rw-r--r-- 1 root root 1.8K Mar 31 23:26 update-core-upgrade-166.l= og >>>>>>>>>> -rw-r--r-- 1 root root 604K May 11 13:24 update-core-upgrade-167.l= og >>>>>>>>>> -rw-r--r-- 1 root root 175 May 11 13:24 update-core-upgrade-168.log >>>>>>>>>>=20 >>>>>>>>>> back to Core Update 167 Development Build: master/c22d834c at bott= om of screen. >>>>>>>>>>=20 >>>>>>>>>> Rebooted. >>>>>>>>>>=20 >>>>>>>>>> All interfaces present. Pakfire under System Status: says Core-Upd= ate-Level: 168 and the bottom of the screen showed Core Update 167 Developmen= t Build: master/c22d834c >>>>>>>>>>=20 >>>>>>>>>> /opt/pakfire/db/core/mine has 168 in it >>>>>>>>>>=20 >>>>>>>>>> I checked the WIO wio.pl file that had a bug fix and it was as exp= ected for CU168. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Third try:- >>>>>>>>>>=20 >>>>>>>>>> -rw-r--r-- 1 root root 323K Apr 28 09:47 update-core-upgrade-167.l= og >>>>>>>>>>=20 >>>>>>>>>> Selected Testing and ran update from 167 to 168 which occurred ver= y quickly. >>>>>>>>>>=20 >>>>>>>>>> -rw-r--r-- 1 root root 604K May 11 14:00 update-core-upgrade-167.l= og >>>>>>>>>> -rw-r--r-- 1 root root 63K May 11 14:01 update-core-upgrade-168.log >>>>>>>>>>=20 >>>>>>>>>> Here is the log file info for pakfire from messages.1.gz and messa= ges which shows it downloading and upgrading CU167 first then doing CU168 as = far as I can tell. >>>>>>>>>>=20 >>>>>>>>>> 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 27 seco= nds old. - DEBUG: noforce >>>>>>>>>> May 11 13:59:30 ipfire pakfire: CORE UPGR: Upgrading from release = 166 to 168 >>>>>>>>>> May 11 13:59:30 ipfire pakfire: DOWNLOAD STARTED: paks/core-upgrad= e-2.27-167.ipfire >>>>>>>>>> May 11 13:59:30 ipfire pakfire: MIRROR INFO: 2 servers found in li= st >>>>>>>>>> May 11 13:59:30 ipfire pakfire: DOWNLOAD INFO: Host: ipfire.earl-n= et.com (HTTPS) - File: pakfire2/2.27.1-x86_64/p= aks/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-Code: 2= 00 - 200 OK >>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD INFO: File received. Star= t checking signature... >>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD INFO: Signature of core-u= pgrade-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-u= pgrade-168 >>>>>>>>>> May 11 13:59:32 ipfire pakfire: MIRROR INFO: 2 servers found in li= st >>>>>>>>>> May 11 13:59:32 ipfire pakfire: DOWNLOAD INFO: Host: mirror1.ipfir= e.org (HTTPS) - File: pakfire2/2.27.1-x86_64/met= a/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-Code: 2= 00 - 200 OK >>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD INFO: File received. Star= t checking signature... >>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD INFO: Signature of meta-c= ore-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-upgrad= e-2.27-168.ipfire >>>>>>>>>> May 11 13:59:33 ipfire pakfire: MIRROR INFO: 2 servers found in li= st >>>>>>>>>> May 11 13:59:33 ipfire pakfire: DOWNLOAD INFO: Host: ipfire.earl-n= et.com (HTTPS) - File: pakfire2/2.27.1-x86_64/p= aks/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-Code: 2= 00 - 200 OK >>>>>>>>>> May 11 13:59:34 ipfire pakfire: DOWNLOAD INFO: File received. Star= t checking signature... >>>>>>>>>> May 11 13:59:34 ipfire pakfire: DOWNLOAD INFO: Signature of core-u= pgrade-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: De= crypting... >>>>>>>>>> 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-167= - Status: 0 >>>>>>>>>> May 11 13:59:35 ipfire pakfire: PAKFIRE UPGR: core-upgrade-167: Up= grading 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: Fi= nished. >>>>>>>>>> May 11 14:00:31 ipfire pakfire: PAKFIRE UPGR: core-upgrade-168: De= crypting... >>>>>>>>>> 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-168= - Status: 0 >>>>>>>>>> May 11 14:00:32 ipfire pakfire: PAKFIRE UPGR: core-upgrade-168: Up= grading files and running post-upgrading scripts... >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> May 11 14:01:10 ipfire pakfire: CLEANUP: tmp >>>>>>>>>> May 11 14:01:10 ipfire pakfire: PAKFIRE UPGR: core-upgrade-168: Fi= nished. >>>>>>>>>> May 11 14:01:10 ipfire pakfire: CORE INFO: core-list.db is 127 sec= onds old. - DEBUG: noforce >>>>>>>>>> May 11 14:01:10 ipfire pakfire: PAKFIRE RESV: wio: Resolving depen= dencies... >>>>>>>>>> May 11 14:01:10 ipfire pakfire: PAKFIRE UPGR: We are going to inst= all all packages listed above. >>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD STARTED: paks/wio-1.3.2-1= 5.ipfire >>>>>>>>>> May 11 14:01:10 ipfire pakfire: MIRROR INFO: 2 servers found in li= st >>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD INFO: Host: mirror1.ipfir= e.org (HTTPS) - File: pakfire2/2.27.1-x86_64/pak= s/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-Code: 2= 00 - 200 OK >>>>>>>>>> May 11 14:01:10 ipfire pakfire: DOWNLOAD INFO: File received. Star= t 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 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 finished= . Closing. >>>>>>>>>>=20 >>>>>>>>>> Rebooted >>>>>>>>>> Lots of ipset restore error but went by too fast to get more detai= l. >>>>>>>>>> Several repeats of the following two lines on the console screen:- >>>>>>>>>>=20 >>>>>>>>>> iptables v1.8.7 (legacy): can't initialize iptables table `filter'= : Table does not exist (do you need to insmod?) >>>>>>>>>> Perhaps iptables or your kernel needs to be upgraded. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Only lo interface present. All other interfaces red0, green0, blue= 0, orange0 not present. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I have given up at this point. >>>>>>>>>>=20 >>>>>>>>>> I have kept the clones of all three attempts so if you need any ad= ditional info from logs or files just let me know. >>>>>>>>>>=20 >>>>>>>>>> If this is something obviously wrong that I am doing, please let m= e know. If not then I will probably raise a bug on this. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Adolf. --===============6006216579171424245==--