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: Thu, 12 May 2022 13:51:26 +0100 Message-ID: <81C8B831-ABD1-4B50-9006-44373F5D330E@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2470154315214352322==" List-Id: --===============2470154315214352322== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Rob, You seem to already have lost the kernel there which is not part of 168. Can you extract any log files from /var/log/pakfire? -Michael > On 12 May 2022, at 11:43, Rob Brewer wrote: >=20 > On Thursday 12 May 2022 10:13 Michael Tremer wrote: >=20 >> Hello, >>=20 >> 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 will >> take a while. >>=20 >> 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 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 then thrown away. For each build, we are using a different, >> unique key that is not preserved. >>=20 >> This means that although the kernel modules are of the same version, they >> 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 module loaded from before the update was started? >>=20 >> 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 load it again later. I have no idea what could have triggered that. >>=20 >> 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? >>=20 >=20 >=20 >=20 > My Pakfire upgrade to 168 on my development APU2 board failed during upgrad= e=20 > and I lost ethernet communication with the PC. >=20 > The APU2 now fails after the grub prompt with the error:=20 >=20 > *IPFire 2.27 (x86_64) - core166 Development Build: master/8f696f60 GNU/Linu >=20 > Loading Linux 5.15.23-ipfire ... > error: file `/vmlinuz-5.15.23-ipfire' not found. > Loading initial ramdisk ... > error: you need to load the kernel first. >=20 > so it looks like update-initramfs didn't run after the upgrade. >=20 > I'll try to boot the box from a usbstick and see if I can access the disk. >=20 > Rob --===============2470154315214352322==--