On May 13, 2022, at 10:02 AM, Rob Brewer <ipfire-devel@grantura.co.uk> 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?

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 <ipfire-devel@grantura.co.uk>
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