linux-kernel - Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8aff5c17-d414-2412-7269-c9d15f574037@gmx.com>
Date:   Mon, 22 Aug 2022 15:49:51 +0800
From:   Qu Wenruo <quwenruo.btrfs@....com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     stable <stable@...r.kernel.org>,
        "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-x86_64@...r.kernel.org
Subject: Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64
 UEFI runtime)

On 2022/8/22 15:33, Greg KH wrote:
> On Mon, Aug 22, 2022 at 03:24:53PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2022/8/22 14:25, Greg KH wrote:
>>> On Mon, Aug 22, 2022 at 09:15:59AM +0800, Qu Wenruo wrote:
>>>> Hi,
>>>>
>>>> When backporting some btrfs specific patches to all LTS kernels, I found
>>>> v4.14.290 kernel unable to boot as a KVM guest with edk2-ovmf
>>>> (edk2-ovmf: 202205, qemu 7.0.0, libvirt 1:8.6.0).
>>>>
>>>> While all other LTS/stable branches (4.19.x, 5.4.x, 5.10.x, 5.15.x,
>>>> 5.18.x, 5.19.x) can boot without a hipccup.
>>>>
>>>> I tried the following configs, but none of them can even provide an
>>>> early output:
>>>>
>>>> - CONFIG_X86_VERBOSE_BOOTUP
>>>> - CONFIG_EARLY_PRINTK
>>>> - CONFIG_EARLY_PRINTK_EFI
>>>>
>>>> Is this a known bug or something new?
>>>
>>> Has this ever worked properly on this very old kernel tree?  If so, can
>>> you use 'git bisect' to find the offending commit?
>>
>> Unfortunately the initial v4.14 from upstream can not even be compiled.
>
> Really?  Try using an older version of gcc and you should be fine.  It
> did build properly back in 2017 when it was released :)

Yeah, I'm pretty sure my toolchain is too new for v4.14.0. But my distro
only provides the latest and mostly upstream packages.

It may be a even worse disaster to find a way to rollback to older
toolchains using my distro...

Also my hardware may not be well suited for older kernels either.
(Zen 3 CPU used here)

In fact, I even find it hard just to locate a v4.14.x tag that can compile.
After some bisection between v4.14.x tags, only v4.14.268 and newer tags
can even be compiled using latest toolchain.
(But still tons of warning, and tons of objdump warnings against
insn_get_length()).

I'm not sure what's the normal practice for backports to such old branch.

Do you stable guys keep dedicated VMs loaded with older distro just for
these old branches?
If so, any recommendation on those kinda retro distro?

Thanks,
Qu

>
> thanks,
>
> greg k-h