Bug 2212779

kernel-debug-6.3.7-200.fc38.x86_64  affected as well

Hi Andrew,

(In reply to Andrew from comment #0)
> Affected kernel: kernel-debug-6.3.6-200.fc38.x86_64
> 6.3.5 as well, possibly all 6.3.x
> Kernel 6.2.16-300.fc38.x86_64+debug boots fine.
> All built by `dracut --uefi ... new.efi`
> Does not boot printing only this message about possible memory corruption.
> No other logs, no any boot progress after this.
> 
> My laptop supports only UEFI boot so can't check legacy BIOS boot.

Please, could you provide the full dracut command line (and all the extra steps that you are taking)?

> Reproducible: Always

Created attachment 1972174 [details]
dracut command and its output

(In reply to Augusto Caringi from comment #2)

> Please, could you provide the full dracut command line (and all the extra
> steps that you are taking)?

Sure. Log with complete command attached. It generates .efi file placed at EFI partition, so that are all steps involved.
efibootmgr is already configured to boot it.
kernel-debug-6.2.16-300.fc38.x86_64 boots fine with that.
kernel-debug-6.3.8-200.fc38.x86_64 does not. All 6.3.x is affected, I think.
Just in case, might also be related somehow (happens on my another PC, not using UEFI combined executable there): bug# 2216874

EFI info:

    # dmidecode
    # dmidecode 3.4
    Getting SMBIOS data from sysfs.
    SMBIOS 3.3.0 present.
    Table at 0xCD01D000.

    Handle 0x0000, DMI type 0, 26 bytes
    BIOS Information
            Vendor: American Megatrends International, LLC.
            Version: N.1.06GRU06
            Release Date: 05/25/2022
            Address: 0xF0000
            Runtime Size: 64 kB
            ROM Size: 16 MB
            Characteristics:
                    PCI is supported
                    BIOS is upgradeable
                    BIOS shadowing is allowed
                    Boot from CD is supported
                    Selectable boot is supported
                    BIOS ROM is socketed
                    EDD is supported
                    Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
                    Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
                    5.25"/360 kB floppy services are supported (int 13h)
                    5.25"/1.2 MB floppy services are supported (int 13h)
                    3.5"/720 kB floppy services are supported (int 13h)
                    3.5"/2.88 MB floppy services are supported (int 13h)
                    Print screen service is supported (int 5h)
                    8042 keyboard services are supported (int 9h)
                    Serial services are supported (int 14h)
                    Printer services are supported (int 17h)
                    CGA/mono video services are supported (int 10h)
                    ACPI is supported
                    USB legacy is supported
                    BIOS boot specification is supported
                    Targeted content distribution is supported
                    UEFI is supported
            BIOS Revision: 5.19
            Firmware Revision: 1.14

Out of curiosity... Do you really need to generate this uefi executable by hand?

I'm asking because when a kernel is installed via dnf/rpm usually a grub2 entry is automatically created.

Are you able to boot this kernel using grub2-efi?

BTW, I was able to reproduce your problem inside a VM...

(In reply to Augusto Caringi from comment #4)

Good question. I left it in this state after configuring LUKS encryption on root partition. It was a simpler flow for me to build a single binary and boot it from UEFI, omitting grub at all and maybe saving a second or two at every boot.
It might be implemented as a standard option in future, as far as I understand: https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
I can try grub-efi if you think it might give some info about this problem.

Thanks for for the info about VM. So, it should not be specific to my machine.
Main question for me is possibility of real memory corruption on non-debug builds of 6.3. Taking into account references KASAN error as well.

(In reply to Andrew from comment #5)
> (In reply to Augusto Caringi from comment #4)
> 
> Good question. I left it in this state after configuring LUKS encryption on
> root partition. It was a simpler flow for me to build a single binary and
> boot it from UEFI, omitting grub at all and maybe saving a second or two at
> every boot.
> It might be implemented as a standard option in future, as far as I
> understand:
> https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
> I can try grub-efi if you think it might give some info about this problem.

Not info, but probably it will work. At least here, I was able to boot the debug kernel using grub-efi.

> Thanks for for the info about VM. So, it should not be specific to my
> machine.

Yes... But note that this "Overlapping PE sections detected." error message is not from the linux kernel... It's from the uefi loader.

There is a possibility of this problem being in dracut messing up the sections during the PE executable creation.

> Main question for me is possibility of real memory corruption on non-debug
> builds of 6.3. Taking into account references KASAN error as well.

Tried grub-efi and I'm able to boot 6.3.8-200.fc38.x86_64+debug with no errors seen for now.
So seems like dracut issue. It's still a question for me why it produces so different results for kernel 6.2 and 6.3
Should we reassign this ticket?

6.4.3 is affected as well.
Just in case: got another KASAN warning: bug# 2223090