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? I'll try to re-flash back to v4.16.0.2 if I can and try to boot again. 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