Re: Feedback on problems with Core Update 168 Testing

[Rob Brewer <ipfire-devel@grantura.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]

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(a)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