Re: Feedback on problems with Core Update 168 Testing

[Michael Tremer <michael.tremer@ipfire.org>]

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

Hello,

> On 13 May 2022, at 16:02, Rob Brewer <ipfire-devel(a)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?

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 <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