Hi Rob,
I don’t thing the "SeaBIOS (version rel-1.14.0.1-0-g8610266a)" equals an old BIOS. I see the same SeaBIOS line except I am on "BIOS version v4.15.0.1 "
I cannot reboot now to double check (people working from home). So this is from an old log file.
03-11 20:32:39.779: |*IPFire 2.27 (x86_64) - core163 GNU/Linux, with Linux 5.15.6-ipfire PC Engines apu4 03-11 20:32:39.779: coreboot build 20212311 | 03-11 20:32:39.779: BIOS version v4.15.0.1 | 03-11 20:32:39.779: 4080 MB ECC DRAM | 03-11 20:32:39.779: | | 03-11 20:33:00.772: SeaBIOS (version rel-1.14.0.1-0-g8610266a)
03-11 20:33:03.781: Press F10 key now for boot menu
Jon
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