F36 - New kernels not found in bootloader

Ask Fedora
, , ,
1

I’m running the F36 beta, but I can’t seem to boot its (5.17.3) kernel or any of the 5.17.x line.
They don’t appear as options in bootloaders (I’ve tried both GRUB and rEFInd), and they don’t have /boot/vmlinuz-, /boot/initramfs-, or /boot/config- files.

I’ve tried dnf reinstall kernel-core, but the files still don’t get created.
It does seem to create (according to strace) files in /boot/efi/<machine id>/5.17.3...., though.

df -H reports:

/dev/sdc2     1.1G    133M    821M    14%    /boot
/dev/sdc1    210M    185M    26M    88%    /boot/efi

Also, rpm -qa | grep dracut:

dracut-056-1.fc36.x86_64
dracut-network-056-1.fc36.x86_64
dracut-squash-056-1.fc36.x86_64
dracut-live-056-1.fc36.x86_64
dracut-config-rescue-056-1.fc36.x86_64

Here’s tree /boot/efi/<machine id>:
7e8adf25bcf17ef90f292f8ef7af36e062c25a58.png
Please note that when I took the screenshot I had already removed the 5.17.3 kernel for testing purposes, but the same issue occurs with the 5.17.4 custom kernel.

When reinstalling kernel-core, I get:

dkms: running auto installation service for kernel 5.17.4-301.fsync.fc36.x86_64
 Done. 
kdump: kernel 5.17.4-301.fsync.fc36.x86_64 doesn't exist

The reinstall command is successful, however. (Same thing happens with 5.17.3)

A couple theories I had:

  • 0-rescue takes roughly 110MB of space, while the 5.17.x directory is 46MB. Perhaps dracut is running out of space and silently failing? I have tried removing the folder, though it seems that it gets automatically created as part of the reinstall process.
  • I had to fix a SELinux-related problem to upgrade some packages, so perhaps it could be related. I find this unlikely though, as this still happens after setenforce 0.
2

Try the reinstall as dnf reinstall kernel*5.17* so it reinstalls all the various kernel packages. You may also try dnf reinstall grub*

Then if you desire you can also run dracut --force to ensure all the pieces in /boot are properly rebuilt (although that is run with the kernel install and should not be needed).

3

Thanks for the reply!

Since I posted this topic, I have tried several possible solutions.

I did try reinstalling other kernel-related packages, including kernel*-5.17* and kernel*-5.16* (the latter failed because there’s no 5.16.19 for fc36). dracut was also able to generate an initramfs, but there were no vmlinuz or config files.
I did not try reinstalling grub, though.

What I ended up doing was switching from rEFInd + GRUB to systemd-boot. That booted 5.17.4 as normal. I also gave the EFI partition more space.

4

Hello,

I currently have the same issue (on 2 computers, exactly the same issue).
I got a full disk on “/boo/efi” (thank you for that else I would have been end up without any kernel on my list ) so that I drill down a little bit.

1st of all, Can someone point me on resource on how to cleanly move my EFI partition (I got some space left on my disk but at the end not near my efi partition … )

On the kernel missing, I also got the “kdimp kernel doesn’t exist” message :slight_smile:

Exécution du scriptlet: kernel-core-5.17.5-300.fc36.x86_64 8/8
kdump: kernel 5.17.5-300.fc36.x86_64 doesn’t exist
Exécution du scriptlet: kernel-modules-5.17.5-300.fc36.x86_64

So i’m guessing an issue on the post script… But how can I fix that ?

Additional note:

When a kernel is installed, the posttrans script launch:

/bin/kernel-install add 5.17.5-300.fc36.x86_64 /lib/modules/5.17.5-300.fc36.x86_64/vmlinuz

I set a debug on this, and I got the error at this level:

  • /usr/lib/kernel/install.d/92-crashkernel.install add 5.17.5-300.fc36.x86_64 /boot/efi/xxxxxxxxxxxxxxxx/5.17.5-300.fc36.x86_64 /lib/modules/5.17.5-300.fc36.x86_64/vmlinuz
    kdump: kernel 5.17.5-300.fc36.x86_64 doesn’t exist
  • x=0
  • [[ 0 == 77 ]]

No time left for me to debug today …

5

Can you post the output of sudo fdisk -l, lsblk, and df so we can see the disk arrangement and space available.

In general you may be able to use gparted and either relocate the partition /boot/efi to the available free space, or move (or shrink) the partition adjacent to it slightly to allow room to expand /boot/efi.

I am wondering why you have /boot/efi filling up. I use a 250 MB partition for /boot/efi and a 1GB partition for /boot and neither have ever come close to filling up as you can see with this snippet from ‘df’

/dev/sda2                        981197     189805    736096  21% /boot
/dev/sda1                        255724      14260    241464   6% /boot/efi

Only 14 MB used in /boot/efi and <200 MB used in /boot.

On my laptop which dual boots with windows I have this. Still no major size in either partition.

/dev/nvme0n1p5                    795964   271240    467076  37% /boot
/dev/nvme0n1p1                    262144    40160    221984  16% /boot/efi

40 MB in /boot/efi and 270 MB in /boot.

Your message may be a result of no space so the install of the newer kernel failed.

7

I got 2 PCs which I upgraded to fedora36

The fist one has a /boot/efi of 512Mb, there was no disk full on it, but still there is missing kernel
The second one has a /boot/efi of 200Mb

On both, /boot/efi is big because I got file like that:

$ ll /boot/efi/368e02543398477bb01d02927d94e4fa/5.17.5-300.fc36.x86_64
total 60M
-rwx------. 1 root root 49M 3 mai 21:36 initrd
-rwx------. 1 root root 12M 3 mai 21:36 linux

so 60Mb per kernel (NOTE : only the fc36 kernel are here, the fc35 (the only one I can boot ) is not there
Additional note : on my 200Mb computer, It goes disk full because of the 0-rescue kernel which did have a initrd of 160Mb in the /boot/efi/xxxxxx/0-rescue directory.
I temporarly removed dracut-recue to prevent this file generation

Additional debug:

I followed the 92-crashkernel.install script.

The issue is on the kdumpctl script on the “_find_kernel_path_by_release()”, it use a

_grubby_kernel_str=$(grubby --info ALL | grep “^kernel=.*$_release”)

but grubby is unable to find the newer kernel

#> grubby --info ALL

index=0
kernel=“/boot/vmlinuz-5.17.1-200.fc35.x86_64”
args=“ro rhgb quiet systemd.unified_cgroup_hierarchy”
root=“UUID=83597a76-4a55-4681-9de0-9df2e09899d8”
initrd=“/boot/initramfs-5.17.1-200.fc35.x86_64.img”
title=“Fedora Linux (5.17.1-200.fc35.x86_64) 35 (Workstation Edition)”
id=“368e02543398477bb01d02927d94e4fa-5.17.1-200.fc35.x86_64”
index=1
kernel=“/boot/vmlinuz-0-rescue-368e02543398477bb01d02927d94e4fa”
args=“ro rhgb quiet systemd.unified_cgroup_hierarchy”
root=“UUID=83597a76-4a55-4681-9de0-9df2e09899d8”
initrd=“/boot/initramfs-0-rescue-368e02543398477bb01d02927d94e4fa.img”
title=“Fedora (0-rescue-368e02543398477bb01d02927d94e4fa) 30 (Workstation Edition)”
id=“368e02543398477bb01d02927d94e4fa-0-rescue”

No trace of any fc36 kernel

Note: I tried to remove the 92-crashkernel script and reinstall the kernel, there was no error, but no kernel either.

On additional note, in the /boot directory I did not have file like previous kernel. For instance, the kernel-core-5.17.5-300.fc36.x86_64.rpm is told to provides a /boot/initramfs file, but on my computer, it did not.

ll /boot

total 143M
drwxr-xr-x. 3 root root 4,0K 15 mars 2018 16a25ba363244c0e9f6e1ec47539e715
-rw-r–r–. 1 root root 239K 1 avril 22:50 config-5.17.1-200.fc35.x86_64
drwx------. 7 root root 16K 1 janv. 1970 efi
-rw-r–r–. 1 root root 148K 27 janv. 12:54 elf-memtest86±5.31
drwxr-xr-x. 2 root root 4,0K 23 avril 17:46 extlinux
drwx------. 4 root root 4,0K 25 mars 21:40 grub2
-rw-------. 1 root root 70M 17 mars 2018 initramfs-0-rescue-368e02543398477bb01d02927d94e4fa.img
-rw-------. 1 root root 48M 5 avril 08:24 initramfs-5.17.1-200.fc35.x86_64.img
drwxr-xr-x. 3 root root 4,0K 8 avril 2018 loader
-rw-r–r–. 1 root root 147K 27 janv. 12:54 memtest86±5.31
lrwxrwxrwx. 1 root root 46 5 avril 08:24 symvers-5.17.1-200.fc35.x86_64.gz → /lib/modules/5.17.1-200.fc35.x86_64/symvers.gz
-rw-------. 1 root root 6,0M 1 avril 22:50 System.map-5.17.1-200.fc35.x86_64
-rwxr-xr-x. 1 root root 8,0M 17 mars 2018 vmlinuz-0-rescue-368e02543398477bb01d02927d94e4fa
-rwxr-xr-x. 1 root root 12M 1 avril 22:50 vmlinuz-5.17.1-200.fc35.x86_64

On a working box (fresh fc36), how is this supposed to work ? where is the vmlinuz located, where /which initrd is it in use ? Is grub2 still in use ?

I don’t understand how could this work as the “/bin/kernel-install” will launch script from /usr/lib/kernel/install.d which contains in my boxes:

ll /usr/lib/kernel/install.d
total 48K
-rwxr-xr-x. 1 root root 2,0K 7 févr. 22:47 10-devicetree.install
-rwxr-xr-x. 1 root root 1,9K 18 mars 13:59 20-grubby.install
-rwxr-xr-x. 1 root root 7,6K 25 mars 21:40 20-grub.install
-rwxr-xr-x. 1 root root 1,6K 18 janv. 12:35 50-depmod.install
-rwxr-xr-x. 1 root root 1,9K 30 mars 10:53 50-dracut.install
-rwxr-xr-x. 1 root root 791 14 févr. 05:51 60-kdump.install
-rwxr-xr-x. 1 root root 4,3K 18 janv. 12:35 90-loaderentry.install
-rwxr-xr-x. 1 root root 203 14 févr. 05:51 92-crashkernel.install
-rwxr-xr-x. 1 root root 675 7 févr. 22:47 95-kernel-hooks.install
-rwxr-xr-x. 1 root root 1,9K 25 mars 21:40 99-grub-mkconfig.install

  • device tree will do nothing
  • grubby.install will do nothing ( /sbin/new-kernel-pkg is not installed on fc36 so the script precondition is not met and this just exit 0) and even if I install the grubby-deprecated package, some error occurs (no template found) and nothing is really done. (no new grub entry)
  • grub.install will do nothing as this script exit 0 if the /boot/efi/xxxx/kernel-version directory exist, This directory is created by kernel-install before calling this script so this script is useless
  • depmod just do depmod if needed so not here
  • dracut : generate the initrd file into /boot/efi/xxxx/kernel-version directory
  • kdump : will do nothing on install
  • loaderentry copy the kernel into /boot/efi/xxxx/kernel-version directory
  • crashkernelhook => will crash as the kernel is not defined in grub
  • postinstall hook => check post install hook, but I have none so do nothing
  • grub-mkconfig => as there is no new entries in /boot/loader/entries will do nothing
8

This looks suspiciously like you may have had /boot/efi mounted at /boot when that kernel update was made. Is it possible that you have (or had) a bind mount of /boot/efi onto /boot when that kernel was installed?

IME that directory should not exist and the kernel that appears with vmlinuz in that location is in the wrong location for booting.

All the kernel files should be in /boot as this shows

[root@laptop jvian]# ls /boot
config-5.17.4-200.fc35.x86_64                            lost+found
config-5.17.4-300.fc36.x86_64                            memtest86+-5.31
config-5.17.5-300.fc36.x86_64                            symvers-5.17.4-200.fc35.x86_64.gz
efi                                                      symvers-5.17.4-300.fc36.x86_64.gz
elf-memtest86+-5.31                                      symvers-5.17.5-300.fc36.x86_64.gz
extlinux                                                 System.map-5.17.4-200.fc35.x86_64
grub2                                                    System.map-5.17.4-300.fc36.x86_64
initramfs-0-rescue-4721ae52e35645e2b20bd190dd29ced1.img  System.map-5.17.5-300.fc36.x86_64
initramfs-5.17.4-200.fc35.x86_64.img                     vmlinuz-0-rescue-4721ae52e35645e2b20bd190dd29ced1
initramfs-5.17.4-300.fc36.x86_64.img                     vmlinuz-5.17.4-200.fc35.x86_64
initramfs-5.17.5-300.fc36.x86_64.img                     vmlinuz-5.17.4-300.fc36.x86_64
loader                                                   vmlinuz-5.17.5-300.fc36.x86_64

While I don’t know the precise mechanics of the process for installing a new kernel it seems strange that it would use /boot/efi which the installer (with a new bare bones install) only creates as about 250MB or so, to temporarily create those files.
I guess if it uses that directory as temp storage during a kernel install and fills it up while doing so, then fails before completion, it could leave that behind.

The proper location for vmlinuz, initramfs, etc. is:

[root@laptop jvian]# ls /boot
config-5.17.4-200.fc35.x86_64                            lost+found
config-5.17.4-300.fc36.x86_64                            memtest86+-5.31
config-5.17.5-300.fc36.x86_64                            symvers-5.17.4-200.fc35.x86_64.gz
efi                                                      symvers-5.17.4-300.fc36.x86_64.gz
elf-memtest86+-5.31                                      symvers-5.17.5-300.fc36.x86_64.gz
extlinux                                                 System.map-5.17.4-200.fc35.x86_64
grub2                                                    System.map-5.17.4-300.fc36.x86_64
initramfs-0-rescue-4721ae52e35645e2b20bd190dd29ced1.img  System.map-5.17.5-300.fc36.x86_64
initramfs-5.17.4-200.fc35.x86_64.img                     vmlinuz-0-rescue-4721ae52e35645e2b20bd190dd29ced1
initramfs-5.17.4-300.fc36.x86_64.img                     vmlinuz-5.17.4-200.fc35.x86_64
initramfs-5.17.5-300.fc36.x86_64.img                     vmlinuz-5.17.4-300.fc36.x86_64
loader                                                   vmlinuz-5.17.5-300.fc36.x86_64

While under /boot/efi you should only see something like this:

[root@eagle jvian]# ls -l /boot/efi
total 12
drwx------. 4 root root 4096 Jan 19 19:44 EFI
-rwx------. 1 root root   34 Jan 20 12:42 mach_kernel
drwx------. 3 root root 4096 Jan 20 12:42 System
[root@eagle jvian]# ls -l /boot/efi/EFI
total 8
drwx------. 2 root root 4096 Apr 21 21:14 BOOT
drwx------. 2 root root 4096 Apr 21 21:24 fedora
[root@eagle jvian]# ls -l /boot/efi/System/
total 4
drwx------. 3 root root 4096 Jan 20 12:42 Library

Having looked at some of the scripts you listed in /usr/lib/kernel/install.d I find nothing that hard codes the path to do the install in /boot/efi, and unless you have manually run them I see nothing to indicate your system should do an install different than that done for a long time on everyone else’s systems.

I suggest you remove the listed directory and contents, /boot/efi/368e02543398477bb01d02927d94e4fa/5.17.5-300.fc36.x86_64 then run sudo dnf reinstall kernel*5.17.5* --enablerepo=updates-testing and see if it installs properly.

9

as a side note, I shrink a partition and added more space for /boot/efi ( well, need to backup file, delete partition, recreate partition, set flag modify /etc/fstab for the new UUID and restore file ) thing is I got some extra space.

I wasnt sure if there was a change in the boot on fc36. As I did use a fc36 usb live to shrink my partition, I did check how it was build and it is still grub with the same setup as previous so location should be /boot/… for the kernel file.

The kernel-install script has

[ -z "$BOOT_ROOT" ] && for suff in "$MACHINE_ID" "loader/entries"; do
    for pref in "/efi" "/boot" "/boot/efi" ; do
        if [ -d "$pref/$suff" ]; then
            BOOT_ROOT="$pref"
            break 2
        fi
    done
done

[ -z "$BOOT_ROOT" ] && for pref in "/efi" "/boot/efi"; do
    if mountpoint -q "$pref"; then
        BOOT_ROOT="$pref"
        break
    fi
done
[ -z "$BOOT_ROOT" ] && BOOT_ROOT="/boot"

So BOOT_ROOT is defined by checking some directory in order: (xxxx = machine id)
/efi/xxxxx
/boot/xxxxx
/boot/efi/xxxxxx
/efi/loader/entries
/boot/loader/entries
/boot/efi/loader/entries

In my case, /boot/efi/xxxxxx exist so BOOT_ROOT is /boot/efi hence the setup in this location.

As I used a licecd, I check how it was build. there was no /boot/efi/xxxxx.
So I mv this directory and “dnf reinstall kernel-core”
It is now a success.

Long story short : If you’re using grub, if there is a /boot/efi/{machine_id} directory it should be removed

Now there is still a question : Why my 2 computers got the exact same issue ?
The only explanation I got (But I will not drill down that) is I use ext4 “/” partition, and as the main efi partition (/boot/efi) is already on its own, I did not set a “/boot” partition (I got 1 OS “/”, 1 “/home” and some toolings / workfiles partitions )
So perhaps there is somewhere in a fc35 → fc36 migration file something to detect what is the boot partition, with a check like for dir in "/boot" "boot/efi" ; if mountpoint -q $dir ; then boot_dir=$dir break fi in this case, /boot/efi would be picked up and the machine_id directory created.

@computersavvy Thank you !

@roccodotdev Can you tell us if you have the same setup ? ( no /boot partition, and if so, can you rename the /boot/efi/{machine_id} directory and reinstall the kernel-core )

1 Like
10

On the live USB this statement may be true that /boot does not exist. I have not looked to find out.
On the actual installed OS it ALWAYS exists, so that search sequence will not find /efi, but will find /boot and use it as the install path for the kernel.

The fact that you are using ext4 for / makes it unnecessary for the installer to create a separate partition /boot. That is only done by default when the user installs the system using LVM or btrfs as the / partition since the system needs /boot to be ext4 so grub can access and load the kernel properly.

It would appear you have something in the way your system was installed that caused the installer to use /boot/efi instead of /boot as the install point for that kernel.

I don’t know the details when you say So I mv this directory and “dnf reinstall kernel-core” It is now a success.
What exactly did you do? Could you share the commands and steps followed? Were you in the chroot when you did that or were you still in the live USB environment? What directory did you “mv” and what did you “mv” it to?

11

I did have a 1G /boot partition (I still do), and a /boot/efi (~200MB) partition.
I’ve resized the /boot/efi partition to 1G and re-mounted it to /efi.

That said, I have switched to systemd-boot so the issue doesn’t affect me anymore.

12

On my computer (not with the livecd, the standard boot) I simply removed the “/boot/efi/xxxxxxxx” directory with “xxxxxx” the machine id. (I just moved this out of the way first to test)
Now, kernel-install do not detect this directory and the boot_root is back to /boot.

13

This is definitely non-standard and in my opinion risky to your system. Fedora does not have a /efi directory or mount point by default.

14

Got exactly same situation. I have separate /boot (1G) and /boot/efi (200M) partitions. After upgrading to F36beta I have no 5.17 kernel which is installed properly. It tries to put its files into /boot/efi and ends up with no free space issue.
Is there an official workaround for this problem yet?

15

I highlighted what seems to be your problem.

You did not give us any info about the actual system so we cannot make detailed suggestions. No free space indicates that your partition is full and the upgrade of the kernel likely cannot complete properly.

Please post the output of df -h and lsblk so we can see the partitions and usage.

16

lsblk:

zram0                         252:0    0     8G  0 disk [SWAP]
nvme0n1                       259:0    0 465,8G  0 disk 
├─nvme0n1p1                   259:1    0   200M  0 part /boot/efi
├─nvme0n1p2                   259:2    0     3G  0 part /mnt
├─nvme0n1p3                   259:3    0     1G  0 part /boot
└─nvme0n1p4                   259:4    0 461,5G  0 part 
  ├─fedora-root               253:0    0    50G  0 lvm  /
  ├─fedora-swap               253:1    0   7,8G  0 lvm  [SWAP]
  ├─fedora-home               253:2    0 344,8G  0 lvm  /home
  ├─fedora-docker--pool_tmeta 253:3    0   476M  0 lvm  
  │ └─fedora-docker--pool     253:5    0  22,6G  0 lvm  
  └─fedora-docker--pool_tdata 253:4    0  22,6G  0 lvm  
    └─fedora-docker--pool     253:5    0  22,6G  0 lvm

df -h:

Filesystem               Size  Used Avail Use% Mounted on
devtmpfs                 4.0M     0  4.0M   0% /dev
tmpfs                     16G  237M   16G   2% /dev/shm
tmpfs                    6.3G  2.4M  6.3G   1% /run
tmpfs                    4.0M     0  4.0M   0% /sys/fs/cgroup
/dev/mapper/fedora-root   50G   36G   11G  77% /
tmpfs                     16G   75M   16G   1% /tmp
/dev/nvme0n1p3           976M  243M  666M  27% /boot
/dev/mapper/fedora-home  340G  300G   25G  93% /home
/dev/nvme0n1p1           200M  182M   19M  91% /boot/efi
tmpfs                    3.2G  136K  3.2G   1% /run/user/1000
/dev/nvme0n1p2           3.0G  2.1G  960M  69% /mnt

(nvme0n1p2 here is a partition with Dell Recovery, it was already there when I got this laptop).

My question is: why the kernel image and initrd are being placed to /boot/efi partition, which looks not suitable for that purpose because of its small size (and I saw that 200M is a maximum size from specification of UEFI). Should I fix it so these files will be placed in /boot as it was before the upgrade? Or should I get rid of /boot partition itself?
What is the default partitioning option for Fedora for now if I install the system from scratch?

17

@viteksafronov if you use grub and if your kernel are installed in a /boot/efi/xxxxxxx/5.17.yyyy directory ( with xxxxxxx the machine id you can find in the /etc/machine-id file ) then remove the /boot/efi/xxxxxxx directory and “dnf reinstall kernel-core” it should reinstall the kernel in /boot

2 Likes
18

This is two users I have seen with the kernels placed in a /boot/efi/xxxxxxx/5.17.yyyy directory. I have no clue why this happens, but it is IME totally non-standard so the user may have done something to cause it.

I hope those with this issue will post their steps that created the problem so others will know what not to do.

19

Well, the only thing I did is that I installed Fedora 25 five years ago and then I was upgrading it with every new stable release (except the last one, because this time I had upgraded while it still was beta).

Here is the part of my initial-setup-ks.cfg, which still lies in /root

# System bootloader configuration
bootloader --location=mbr --boot-drive=nvme0n1
# Partition clearing information
clearpart --initlabel --list=nvme0n1p3,nvme0n1p1
# Disk partitioning information
part pv.251 --fstype="lvmpv" --ondisk=nvme0n1 --size=207383
part /boot/efi --fstype="efi" --ondisk=nvme0n1 --size=200 --fsoptions="umask=0077,shortname=winnt"
part /boot --fstype="ext4" --ondisk=nvme0n1 --size=1024
part swap --fstype="swap" --noformat
volgroup fedora --pesize=4096 pv.251
logvol /home  --fstype="ext4" --grow --size=500 --name=home --vgname=fedora
logvol swap  --fstype="swap" --size=7951 --name=swap --vgname=fedora
logvol /  --fstype="ext4" --grow --size=1024 --name=root --vgname=fedora

So it looks like the partitioning scheme was chosen at install time and wasn’t changed after that.

20

This is the only thing I see strange.
With the /boot/efi partition I would not expect to see the bootloader as mbr.
Please post the output of sudo fdisk -l and lsblk as well.

21

On my end, on one laptop, I got the initial file and I also got the MBR thing and i’m 100% sure the disc was setup with GPT when I got it (windows was also setup on it when I started) I started on this computer on a fedora 25.

# System bootloader configuration
bootloader --location=mbr --boot-drive=nvme0n1
# Partition clearing information
clearpart --initlabel --list=nvme0n1p8,nvme0n1p7
# Disk partitioning information
part / --fstype="ext4" --ondisk=nvme0n1 --size=57220
part /boot/efi --fstype="efi" --ondisk=nvme0n1 --size=476 --fsoptions="umask=0077,shortname=winnt"
part btrfs.819 --fstype="btrfs" --ondisk=nvme0n1 --size=28610
part swap --fstype="swap" --ondisk=nvme0n1 --size=16384
part /opt --fstype="ext4" --ondisk=nvme0n1 --size=85830
part /home --fstype="ext4" --ondisk=nvme0n1 --size=42770
btrfs none --label=fedora btrfs.819
btrfs /var/lib/docker --subvol --name=var_lib_docker LABEL=fedora

Wndows has been removed long time ago, now the partition are:

/dev/nvme0n1p1       2048  204296191 204294144  97,4G Système de fichiers Linux
/dev/nvme0n1p8  204296192  205271039    974848   476M Système EFI
/dev/nvme0n1p9  527507456  703287295 175779840  83,8G Système de fichiers Linux
/dev/nvme0n1p10 703287296  820473855 117186560  55,9G Système de fichiers Linux
/dev/nvme0n1p11 820473856  879067135  58593280  27,9G Système de fichiers Linux
/dev/nvme0n1p12 879067136  912621567  33554432    16G Partition d'échange Linux
/dev/nvme0n1p13 912621568 1000214527  87592960  41,8G Système de fichiers Linux

nvme0n1      259:0    0 476,9G  0 disk 
├─nvme0n1p1  259:1    0  97,4G  0 part /hprof
├─nvme0n1p8  259:2    0   476M  0 part /boot/efi
├─nvme0n1p9  259:3    0  83,8G  0 part /opt
├─nvme0n1p10 259:4    0  55,9G  0 part /
├─nvme0n1p11 259:5    0  27,9G  0 part /var/lib/docker
├─nvme0n1p12 259:6    0    16G  0 part [SWAP]
└─nvme0n1p13 259:7    0  41,8G  0 part /home