I am unable to boot a fresh Bazzite installation.

[H1ghlivE]

Describe the bug

What happens:
The installation completes successfully and a Bazzite boot entry is created in UEFI.

On first boot I consistently get:

error: ../../grub-core/fs/fshelp.c:257:file '/ostree/default-.../vmlinuz-6.19.14-...'
not found.

error: ../../grub-core/loader/i386/efi/linux.c:grub_cmd_initrd:260:
you need to load the kernel first.

I reinstalled multiple times and received the same result.

What I checked:

• Secure Boot disabled during installation
• CSM disabled
• UEFI boot mode
• Separate EFI partition for Bazzite
• Boot entry is created correctly
• ostree deployment exists
• vmlinuz exists under /boot/ostree/...
• initramfs exists under /boot/ostree/...
• ostree-1.conf points to the correct kernel and initramfs files
• grub.cfg and bootuuid.cfg were inspected and appear valid
• tested both: Bazzite Desktop KDE and Bazzite Desktop GNOME

The interesting part is that GRUB reports the kernel file as missing even though the file is present on disk.

What did you expect to happen?

System should boot normally after installation.

Session Logs

https://paste.centos.org/view/raw/6f4198d9

Hardware

Hardware:

• AMD Ryzen 7 9800X3D
• AMD Radeon RX 9070 XT 16 GB
• Lexar NM790 2 TB NVMe SSD
• Gigabyte B650 Gaming X AX V2

Extra information or context

I reproduced the issue after a complete reinstall. The deployment hash changed, but the boot failure remained identical.
I also verified that both the kernel (vmlinuz) and initramfs files exist under /boot/ostree/... and are referenced correctly in ostree-1.conf.

The system never booted successfully, so no logs from the failing installation are available.
The attached session logs were generated from the Bazzite Live ISO installer environment after the issue occurred.

[nyx1d]

Thanks for the detailed report and the Live ISO logs.

The attached journal appears to come from the Live ISO environment rather than the installed deployment:

BOOT_IMAGE=/images/pxeboot/vmlinuz
root=live:CDLABEL=Bazzite-Live
rd.live.image

Because the installed kernel is never loaded, this log does not show the failing GRUB lookup directly.

The error still looks like a GRUB root or /boot partition mismatch: the kernel exists under /boot/ostree/... when inspected from Linux, while GRUB tries to load /ostree/.... That path is normally correct if GRUB is reading the separate /boot filesystem as its root, but it will fail if GRUB selects the wrong partition or UUID.

Could you please attach the output of:

lsblk -o NAME,FSTYPE,FSVER,LABEL,UUID,PARTUUID,SIZE,MOUNTPOINTS
sudo blkid
sudo fdisk -l

It would also help to include:

sudo cat /boot/grub2/bootuuid.cfg
sudo cat /boot/loader/entries/ostree-1.conf

Please also clarify whether you created a separate ext4 /boot partition in addition to the EFI System Partition mounted at /boot/efi.

One additional detail: the Live ISO log reports:

secureboot: Secure boot enabled
Kernel is locked down from EFI Secure Boot mode

This may be unrelated to the missing file error, but could you confirm whether Secure Boot is currently enabled or disabled in firmware?

[H1ghlivE]

Sure

Secure Boot was disabled during installation. But at the moment Secure Boot is currently enabled.

After the installation I tested both Secure Boot enabled and disabled in the BIOS/UEFI firmware.
The system failed to boot in both cases with the same GRUB error.

I manually created the Bazzite EFI partition because the installer repeatedly tried to use the existing Windows EFI partition. Therefore, the system now has two EFI System Partitions:
Windows EFI partition: /dev/nvme0n1p1
Bazzite EFI partition: /dev/nvme0n1p5 (BAZZITE-EFI)
The ext4 partition /dev/nvme0n1p6 was also created during this process.

Terminal Output:

liveuser@localhost-live:~$ sudo mkdir -p /mnt/bazzite
liveuser@localhost-live:~$ sudo mount /dev/nvme0n1p6 /mnt/bazzite
liveuser@localhost-live:~$ ls /mnt/bazzite
boot  dev  home  lost+found  ostree  proc  root  run  sys  tmp
liveuser@localhost-live:~$ ls /mnt/bazzite/boot
boot  bootupd-state.json  efi  grub2  loader  loader.0  ostree
liveuser@localhost-live:~$ ls -R /mnt/bazzite/boot/ostree | head -30
/mnt/bazzite/boot/ostree:
default-a43727179e00f357b97e26b7bc6850f86cb9687b2e0b04dfeca9306d879498ef

/mnt/bazzite/boot/ostree/default-a43727179e00f357b97e26b7bc6850f86cb9687b2e0b04dfeca9306d879498ef:
initramfs-6.19.14-ogc5.1.fc44.x86_64.img
vmlinuz-6.19.14-ogc5.1.fc44.x86_64

liveuser@localhost-live:~$ ls /mnt/bazzite/boot/loader.0/entries
ostree-1.conf
liveuser@localhost-live:~$ ls /mnt/bazzite/boot/loader.0/entries/*.conf
/mnt/bazzite/boot/loader.0/entries/ostree-1.conf
liveuser@localhost-live:~$ cat /mnt/bazzite/boot/loader.0/entries/*.conf
title Bazzite (ostree:0)
version 1
options ostree=/ostree/boot.0/default/a43727179e00f357b97e26b7bc6850f86cb9687b2e0b04dfeca9306d879498ef/0 rhgb quiet root=UUID=d517aeef-776c-4051-a6ca-9514a30dbb5d vconsole.keymap=ch rw
linux /ostree/default-a43727179e00f357b97e26b7bc6850f86cb9687b2e0b04dfeca9306d879498ef/vmlinuz-6.19.14-ogc5.1.fc44.x86_64
initrd /ostree/default-a43727179e00f357b97e26b7bc6850f86cb9687b2e0b04dfeca9306d879498ef/initramfs-6.19.14-ogc5.1.fc44.x86_64.img

liveuser@localhost-live:~$ sudo blkid
/dev/sda1: BLOCK_SIZE="2048" UUID="2026-05-15-07-40-26-00" LABEL="Bazzite-Live" TYPE="iso9660" PARTLABEL="ISO9660" PARTUUID="f7f97d7b-1baa-4968-ac2e-fe4d1f81db9a"
/dev/nvme0n1p5: LABEL_FATBOOT="BAZZITE-EFI" LABEL="BAZZITE-EFI" UUID="700A-2178" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="6962b4d8-0e3e-4de5-a538-2df6c3890d98"
/dev/nvme0n1p3: BLOCK_SIZE="512" UUID="B280FD1E80FCEA2D" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="2712442f-d8a8-4bd8-8e5d-743020b36d40"
/dev/nvme0n1p1: UUID="08FB-69A9" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Basic data partition" PARTUUID="4f1ae882-2555-4bba-9bf0-32673b376997"
/dev/nvme0n1p6: LABEL="bazzite_xboot" UUID="d517aeef-776c-4051-a6ca-9514a30dbb5d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0d470db3-993f-4b1e-99f4-72f404b08de9"
/dev/nvme0n1p4: BLOCK_SIZE="512" UUID="50EC2767EC274716" TYPE="ntfs" PARTUUID="dadec594-0cf1-4029-a826-c517f9b37f7f"
/dev/loop0: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/sda2: UUID="DEA0-74CF" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Appended2" PARTUUID="f7f97d7b-1baa-4968-ac2d-fe4d1f81db9a"
/dev/zram0: LABEL="zram0" UUID="12eae712-1f86-478d-8fc9-588b277558e6" TYPE="swap"
/dev/nvme0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="2ea5b295-f230-4b4b-82ec-e195e1cf8492"
/dev/sda3: PARTLABEL="Gap1" PARTUUID="f7f97d7b-1baa-4968-ac2c-fe4d1f81db9a


liveuser@localhost-live:~$ sudo ls /mnt/bazzite/boot/grub2
bootuuid.cfg  grub.cfg	grubenv
liveuser@localhost-live:~$ sudo ls /mnt/bazzite/boot/grub2/bootuuid.cfg
/mnt/bazzite/boot/grub2/bootuuid.cfg
liveuser@localhost-live:~$ sudo ls -la /mnt/bazzite/boot/grub2
total 20
drwx------. 2 root root 4096 Jun 10 22:45 .
drwxr-xr-x. 6 root root 4096 Jun 10 22:45 ..
-rw-------. 1 root root   53 Jun 10 22:45 bootuuid.cfg
-rw-------. 1 root root 3882 Jun 10 22:45 grub.cfg
-rw-------. 1 root root 1024 Jun 10 22:45 grubenv



liveuser@localhost-live:~$ sudo cat /mnt/bazzite/boot/grub2/bootuuid.cfg
set BOOT_UUID="d517aeef-776c-4051-a6ca-9514a30dbb5d"
liveuser@localhost-live:~$ sudo cat /mnt/bazzite/boot/grub2/grub.cfg | head -50
# Generated by bootupd / do not edit

# This file is copied from https://github.com/coreos/coreos-assembler/blob/0eb25d1c718c88414c0b9aedd19dc56c09afbda8/src/grub.cfg
# Changes:
#   - Dropped Ignition glue, that can be injected into platform.cfg
# petitboot doesn't support -e and doesn't support an empty path part
if [ -d (md/md-boot)/grub2 ]; then
  # fcct currently creates /boot RAID with superblock 1.0, which allows
  # component partitions to be read directly as filesystems.  This is
  # necessary because transposefs doesn't yet rerun grub2-install on BIOS,
  # so GRUB still expects /boot to be a partition on the first disk.
  #
  # There are two consequences:
  # 1. On BIOS and UEFI, the search command might pick an individual RAID
  #    component, but we want it to use the full RAID in case there are bad
  #    sectors etc.  The undocumented --hint option is supposed to support
  #    this sort of override, but it doesn't seem to work, so we set $boot
  #    directly.
  # 2. On BIOS, the "normal" module has already been loaded from an
  #    individual RAID component, and $prefix still points there.  We want
  #    future module loads to come from the RAID, so we reset $prefix.
  #    (On UEFI, the stub grub.cfg has already set $prefix properly.)
  set boot=md/md-boot
  set prefix=($boot)/grub2
else
  if [ -f ${config_directory}/bootuuid.cfg ]; then
    source ${config_directory}/bootuuid.cfg
  fi
  if [ -n "${BOOT_UUID}" ]; then
    search --fs-uuid "${BOOT_UUID}" --set boot --no-floppy
  else
    search --label boot --set boot --no-floppy
  fi
fi
set root=$boot

if [ -f ${config_directory}/grubenv ]; then
  load_env -f ${config_directory}/grubenv
elif [ -s $prefix/grubenv ]; then
  load_env
fi

if [ -f $prefix/console.cfg ]; then
  # Source in any GRUB console settings if provided by the user/platform
  source $prefix/console.cfg
fi

menuentry_id_option="--id"

function load_video {


liveuser@localhost-live:~$ lsblk -o NAME,FSTYPE,FSVER,LABEL,UUID,PARTUUID,SIZE,MOUNTPOINTS
NAME        FSTYPE   FSVER LABEL         UUID                                 PARTUUID                               SIZE MOUNTPOINTS
loop0       squashfs 4.0                                                                                             5.7G /run/rootfsbase
sda         iso9660        Bazzite-Live  2026-05-15-07-40-26-00                                                     14.9G 
├─sda1      iso9660        Bazzite-Live  2026-05-15-07-40-26-00               f7f97d7b-1baa-4968-ac2e-fe4d1f81db9a     6G /run/initramfs/live
├─sda2      vfat     FAT32               DEA0-74CF                            f7f97d7b-1baa-4968-ac2d-fe4d1f81db9a   100M 
└─sda3                                                                        f7f97d7b-1baa-4968-ac2c-fe4d1f81db9a   300K 
zram0       swap     1     zram0         12eae712-1f86-478d-8fc9-588b277558e6                                       15.2G [SWAP]
nvme0n1                                                                                                              1.9T 
├─nvme0n1p1 vfat     FAT32               08FB-69A9                            4f1ae882-2555-4bba-9bf0-32673b376997   100M 
├─nvme0n1p2                                                                   2ea5b295-f230-4b4b-82ec-e195e1cf8492    16M 
├─nvme0n1p3 ntfs                         B280FD1E80FCEA2D                     2712442f-d8a8-4bd8-8e5d-743020b36d40   1.5T 
├─nvme0n1p4 ntfs                         50EC2767EC274716                     dadec594-0cf1-4029-a826-c517f9b37f7f   813M 
├─nvme0n1p5 vfat     FAT32 BAZZITE-EFI   700A-2178                            6962b4d8-0e3e-4de5-a538-2df6c3890d98   572M 
└─nvme0n1p6 ext4     1.0   bazzite_xboot d517aeef-776c-4051-a6ca-9514a30dbb5d 0d470db3-993f-4b1e-99f4-72f404b08de9 341.2G /var/mnt/bazzite
liveuser@localhost-live:~$ sudo fdisk -l
Disk /dev/nvme0n1: 1.86 TiB, 2048408248320 bytes, 4000797360 sectors
Disk model: Lexar SSD NM790 2TB                     
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CF0D485D-346B-48A6-83C5-8EC6066BD4D7

Device              Start        End    Sectors   Size Type
/dev/nvme0n1p1       2048     206847     204800   100M EFI System
/dev/nvme0n1p2     206848     239615      32768    16M Microsoft reserved
/dev/nvme0n1p3     239616 3282329599 3282089984   1.5T Microsoft basic data
/dev/nvme0n1p4 3999129600 4000794623    1665024   813M Windows recovery environment
/dev/nvme0n1p5 3282329600 3283501055    1171456   572M EFI System
/dev/nvme0n1p6 3283501056 3999129599  715628544 341.2G Linux filesystem

Partition table entries are not in disk order.
GPT PMBR size mismatch (12762651 != 31252479) will be corrected by write.


Disk /dev/sda: 14.9 GiB, 16001269760 bytes, 31252480 sectors
Disk model: TF10            
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F7F97D7B-1BAA-4968-AC2F-FE4D1F81DB9A

Device        Start      End  Sectors  Size Type
/dev/sda1        64 12557187 12557124    6G Microsoft basic data
/dev/sda2  12557188 12761987   204800  100M EFI System
/dev/sda3  12761988 12762587      600  300K Microsoft basic data


Disk /dev/loop0: 5.68 GiB, 6104104960 bytes, 11922080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/zram0: 15.23 GiB, 16349396992 bytes, 3991552 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

[nyx1d]

Thanks, this output makes the cause much clearer.

bootuuid.cfg appears to be correct: it points to /dev/nvme0n1p6, and GRUB successfully selects that filesystem as its root.

However, the filesystem layout on /dev/nvme0n1p6 does not match the paths in the loader entry.

The loader entry tells GRUB to load:

/ostree/default-a437.../vmlinuz-6.19.14-ogc5.1.fc44.x86_64

But the file actually exists at:

/boot/ostree/default-a437.../vmlinuz-6.19.14-ogc5.1.fc44.x86_64

relative to the same filesystem.

The partition layout also shows only two Bazzite-related partitions:

/dev/nvme0n1p5  vfat  BAZZITE-EFI
/dev/nvme0n1p6  ext4  bazzite_xboot

There is no separate BTRFS root partition. After mounting /dev/nvme0n1p6, it contains root-level directories such as boot, dev, home, ostree, proc, root, run, and sys, so it appears to be used as the root filesystem rather than as a dedicated /boot partition.

Bazzite expects a layout with separate filesystems for:

/boot/efi   EFI System Partition
/boot       ext4
/           BTRFS

In a valid layout, GRUB selects the dedicated /boot filesystem, so /ostree/... is the correct relative path. In the current layout, the kernel files are nested under /boot/ostree/..., which is why GRUB cannot find them.

I would recommend reinstalling with a dedicated ext4 /boot partition and a separate BTRFS / partition. Since the current Live ISO primarily expects automatic partitioning, using the legacy ISO may be necessary if you need full manual partitioning for this dual-boot setup.

As a diagnostic experiment only, changing the loader entry paths from /ostree/... to /boot/ostree/... may confirm the mismatch, but I would not treat that as a permanent fix because the current root filesystem layout is unsupported and may break again after an update.

[H1ghlivE]

So I modified ostree-1.conf and changed the paths from /ostree/... to /boot/ostree/... as a diagnostic test.

The change was saved successfully and verified with cat.

During the first boot attempt I briefly saw the Bazzite "Preparing System" screen, but afterwards the system unexpectedly booted into Windows

On subsequent boot attempts, the system returned to the same GRUB error showing /ostree/.../vmlinuz not found

After that, I cleared all partitions on the Bazzite drives and performed a fresh installation of Bazzite KDE with Secure Boot enabled. During the installation, I also created a separate 2 GB /boot partition.

The installation completed successfully and the system booted correctly. What I observed was that, on the first boot, the Bazzite "Preparing System" screen appeared. After that, the system automatically restarted. I then had to select and boot Bazzite again, and it started normally.

This makes me wonder whether, during my earlier test with the modified ostree-1.conf, after i saw the grub error again if i would set the path again to boot/ostree/ would result in starting Bazzite correctly.

[nyx1d]

Thanks for confirming this.

The new partition layout shown in the screenshot looks correct:

/boot/efi   600 MB
/boot       2.00 GB
/           364 GB

This matches the expected layout with a dedicated EFI System Partition, a separate /boot filesystem, and a separate root filesystem.

The earlier diagnostic edit from:

/ostree/...

to:

/boot/ostree/...

briefly working also confirms the original cause.

In the previous installation, the kernel files were physically stored under:

/boot/ostree/...

while the generated loader entry instructed GRUB to load them from:

/ostree/...

That path is correct only when GRUB is reading a dedicated /boot filesystem as its root. Without a separate /boot partition, the generated path no longer matched the actual filesystem layout.

The manual change was useful as a diagnostic test, but it would not be a reliable permanent fix because the loader entry may be regenerated during first boot, deployment changes, or updates. That would explain why the original /ostree/... path appeared again afterwards.

Since the fresh installation with a separate 2 GB /boot partition now boots correctly, the immediate issue appears resolved.

However, this may still point to an installer UX or validation issue.

Could the current installer allow a manual partitioning layout without a dedicated /boot filesystem, while still generating OSTree loader entries that assume one exists?

If so, it may be worth adding one of the following:

• validation that rejects unsupported manual partitioning layouts;
• a clear warning that /boot, /boot/efi, and / must be separate filesystems;
• documentation or installer guidance for dual-boot setups where the user wants a separate EFI System Partition for Bazzite.

The first reboot after the Preparing System screen also sounds consistent with first-boot initialization. If the machine boots into Windows after that restart, the remaining issue may simply be that the firmware still prioritizes Windows Boot Manager in the boot order.