Hello, > On 13 May 2022, at 16:02, Rob Brewer wrote: > > On Thursday 12 May 2022 14:15 Rob Brewer wrote: > >> On Thursday 12 May 2022 13:51 Michael Tremer wrote: >> >>> 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 >>> >> I was upgrading 165-168 so I think Linux 5.15.23-ipfire was from 165. >> I am trying to build a bootable USB drive so I can mount the ssd and look >> at the Pakfire logs. >> >> >> Rob >> > I have been unable to boot from a usb drive so I re-fitted an old mSATA SSD > with an earlier version of IPFIRE and was surprisingly unable to boot from > there also. > > On investigation the bios is reporting: > > SeaBIOS (version rel-1.14.0.1-0-g8610266a) > > yet I manually upgraded it to v4.16.0.2 a few weeks ago after a discussion > with Bernard. > > https://community.ipfire.org/t/entropy-with-new-apu-firmware/7707 > > Could something have downgraded or corrupted the BIOS? No, we never touch this as it is too unpredictable what would happen. > I'll try to re-flash back to v4.16.0.2 if I can and try to boot again. But that is not the same version number that you are comparing there. SeaBIOS is a part of the firmware and comes in a different version. > > > Rob > >>>> On 12 May 2022, at 11:43, Rob Brewer >>>> wrote: >>>> >>>> On Thursday 12 May 2022 10: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’s >>>>> 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 >>>>> 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. >>>>> >>>>> 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’t the module 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 load it again later. I have no idea what could have >>>>> triggered that. >>>>> >>>>> 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? >>>>> >>>> >>>> >>>> >>>> My Pakfire upgrade to 168 on my development APU2 board failed during >>>> upgrade and I lost ethernet communication with the PC. >>>> >>>> The APU2 now fails after the grub prompt with the error: >>>> >>>> *IPFire 2.27 (x86_64) - core166 Development Build: master/8f696f60 >>>> GNU/Linu >>>> >>>> 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. >>>> >>>> so it looks like update-initramfs didn't run after the upgrade. >>>> >>>> I'll try to boot the box from a usbstick and see if I can access the >>>> disk. >>>> >>>> Rob