Fedora 33 kernel does not boot

[gbraad]

When building the kernel from Fedora 33 (or using the Fedora kernel will cause a startup failure. Not sure why, but since the Fedora kernel is built using GCC 10, I suspect this to be the problem:

$ gcc --version
gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.1379]
Your Distribution version: Fedora 33
Whether the issue is on WSL 2 and/or WSL 1: WSL2

Steps to reproduce

$ sudo dnf install flex bison openssl-devel libelf-utils
$ git clone https://github.com/Microsoft/WSL2-Linux-Kernel
$ cd WSL2-Linux-Kernel
$ cp Microsoft/config-wsl .config
$ vi arch/x86/boot/compressed/kaslr_64.c    # as you will be hitting a failure, remove `__force_order`
$ make -j 10
$ cp arch/x86/boot/bzImage fedkernel

using the resulting kernel will not boot.

ld: arch/x86/boot/compressed/pgtable_64.o:(.bss+0x0): multiple definition of `__force_order'; arch/x86/boot/compressed/kaslr_64.o:(.bss+0x0): first defined here

arch/x86/boot/compressed/kaslr_64.c

-/* Used by pgtable.h asm code to force instruction serialization. */
-unsigned long __force_order;

https://lore.kernel.org/lkml/[email protected]/

WSL logs:

Expected behavior

Starting environment

PS> wsl
$ 

Actual behavior

PS> wsl --shutdown
PS> wsl
The operation timed out because a response was not received from the virtual machine or container.

[gbraad]

I have tested the same setup from a docker container with Ubuntu 20.04

$ podman run -it --name wslkernel-build ubuntu:20.04 bash
# apt update
# apt install build-essential flex bison libssl-dev libelf-dev bc git
# ... pull
# ... cp config
# ... make -j 10
# cp arch/x86/boot/bzImage ubukernel
# gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

PS> cat C:\Users\gbraad\.wslconfig
[wsl2]
processors=4
kernel=c:\\wslkernel\\ubukernel
kernelCommandline="systemd.unified_cgroup_hierarchy=1"
PS> wsl
 ~ $ uname -na
Linux WinT14 4.19.84-microsoft-standard+ #1 SMP Fri Mar 5 12:12:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

---

Tested this on Ubuntu 20.10 and this also fails for the same reason:

root@7987425ca418:/WSL2-Linux-Kernel# vi arch/x86/boot/compressed/kaslr_64.c
root@7987425ca418:/WSL2-Linux-Kernel# make -j10
  DESCEND  objtool
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  Building modules, stage 2.
  MODPOST 0 modules
  CC      arch/x86/boot/compressed/kaslr_64.o
  LD      arch/x86/boot/compressed/vmlinux
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
  ZOFFSET arch/x86/boot/zoffset.h
  OBJCOPY arch/x86/boot/vmlinux.bin
  AS      arch/x86/boot/header.o
  LD      arch/x86/boot/setup.elf
  OBJCOPY arch/x86/boot/setup.bin
  BUILD   arch/x86/boot/bzImage
Setup is 15932 bytes (padded to 16384 bytes).
System is 8521 kB
CRC 9ab18dab
Kernel: arch/x86/boot/bzImage is ready  (#1)
root@7987425ca418:/WSL2-Linux-Kernel# scp  arch/x86/boot/bzImage [email protected]:ubu2010kernel
root@7987425ca418:/WSL2-Linux-Kernel# gcc --version
gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0

PS> wsl --shutdown
PS> wsl
The operation timed out because a response was not received from the virtual machine or container.

[0xbadfca11]

Don't use master branch. That is outdated. Use linux-msft-wsl-5.4.y branch instead.

[gbraad]

Modify 'master' to refer to the branches perhaps?

---

was wondering why I got an old 4.9 kernel, while the current 'latest' release update was already running 5.4.

[gbraad]

$ uname -na
Linux WinT14 5.4.91-gbraad-WSL2+ #4 SMP Sat Mar 6 12:09:56 CST 2021 x86_64 x86_64 x86_64 GNU/Linux

That seems to work. So then I am wondering what 'specifics' need to be there to allow booting... as the 'Fedora'-kernel won't boot:

$ ls -al /boot
-rwxr-xr-x  1 root root 10539760 Feb 11 02:01 vmlinuz-5.10.15-200.fc33.x86_64
-rwxr-xr-x  1 root root 10538704 Feb 18 05:35 vmlinuz-5.10.17-200.fc33.x86_64
-rwxr-xr-x  1 root root 10538096 Feb 27 00:36 vmlinuz-5.10.19-200.fc33.x86_64

have been tried. Is there a way to see the 'console' ?

[0xbadfca11]

Below features required and must not be module.
The initrd is occupied by WSL and cannot be used in the boot process.
The Fedora 33 kernel has these features enabled, but as a module.

CONFIG_HYPERV
CONFIG_VSOCKETS
CONFIG_HYPERV_VSOCKETS
CONFIG_PCI_HYPERV
CONFIG_HYPERV_STORAGE
CONFIG_SCSI_FC_ATTRS
CONFIG_HYPERV_NET
CONFIG_NET_9P
CONFIG_NET_9P_VIRTIO
CONFIG_9P_FS
CONFIG_BINFMT_MISC

It is recommended to add debugConsole=true to wslconfig when creating a custom kernel. (May not work unless you have a new Windows 10 build)

[gbraad]

I am on Insiders. Will see what can be done to solve this.

[gbraad]

@0xbadfca11 when I use WSL2 and enabled unified_hierarchy it ends up in a hybrid mode. This is one of the reasons I am looking into this. Any clue why that might be?

[0xbadfca11]

I'm not sure about unified_hierarchy .