Error with Couldn't find locked package 'kernel-5.11.15-200.fc33.x86_64' (pkgs matching NEVRA: 0;mismatched checksums:0) when build FCOS with changed kernel version

I tried to modify kernel to 5.11.15 in manifest-lock.overrides.x86-64.yaml and build FCOS with this kernel version, but met error:
'error with Couldn’t find locked package ‘kernel-5.11.15-200.fc33.x86_64’ (pkgs matching NEVRA: 0;mismatched checksums:0) when run cosa fetch. but some other version such as 5.11.14 can got work, what is wrong with it?

I find choose verison from this link:Index of /packages/kernel

Note: I assume you’re doing a local build using cosa.

cosa needs to know where to grab the package from (yum repo) or you need to have it locally. The easist thing to do is just download the rpm locally into overrides/rpm/ (from the base of your working directory). cosa will automatically pick it up when you cosa build.

Thanks Mabe, work for me.

And could you share how to build kernel-core.rpm and kernel-module.rpm if I want to replace my built kernel? it seems 3 kernel rpms are must. but I just can build out kernel.rpm.

I can build out 3 kernel RPMs with my change now, but CoreOS built system can not recognize them when I put them into overrides/rpm and still install the default kernel version from manifest-lock.overrides.x86_64.yaml, why? And what is special check for rpm-ostree?

I checked that the command and the contents in /srv/tmp/override/local-overrides.json are correct which are my built kernel info.

sudo -E rpm-ostree compose tree --repo=/srv/tmp/repo --touch-if-changed /srv/tmp/treecompose.changed --cachedir=/srv/cache --unified-core /srv/tmp/override/coreos-assembler-override-manifest.yaml --cache-only --force-nocache --add-metadata-from-json /srv/tmp/build/tmp/commit-metadata-input.json --write-composejson-to /srv/tmp/compose.json --ex-write-lockfile-to /srv/tmp/repo/tmp/manifest-lock.generated.x86_64.json.tmp --ex-lockfile=/srv/src/config/manifest-lock.x86_64.json --ex-lockfile=/srv/src/config/manifest-lock.overrides.x86_64.yaml --no-parent --previous-commit 0ba6058ebb7736869ac940e9ac5a2ee45594a399e8c11a1c3bdc4534b73fdf27 --ex-lockfile=/srv/tmp/override/local-overrides.json

Make sure to use a different release tag in your built RPMs so that it doesn’t match a kernel RPM already in the repos.

Did you also add an entry to /srv/src/config/manifest-lock.overrides.x86_64.yaml ?

If you leave them around then you’d want to add an entry there for the kernel. You can choose to just remove the lockfiles (manifest-lock.overrides.x86_64.yaml and manifest-lock.x86_64.json) from your filesystem and just let it pull in whatever is latest. As @jlebon mentioned you’ll want to make sure the rpms you built have a higher (and different) version than what is in the Fedora repos, though.

Thanks all, it works with my release build verison(I used the debug rpms before).

But It seem also failed when I updated rpm built package name in rpm spec, such as from kernel-5.12.0-0.rc8.191.fc35.x86_64.rpm to fedora-coreos-kernel-5.12.0-0.rc8.191.fc35.x86_64.rpm. it is also rpm-ostree special check, right?

Renaming the kernel package is indeed going to cause problems right now. I would avoid doing that.

Thanks Walters.

And I have another question is that I saw CoreOS doc just shows 'provisioning it on qemu with grub boot, but does Fedora CoreOS support qemu with kernel direct boot?

I tried to add kernel but met an error ‘’[ 2.245254] VFS: Cannot open root device “vdb4” or unknown-block(0,0): error -6" when I specify to start with kernel and set vdb4 as rootfs mount point.
$ sudo qemu-system-x86_64 -m 2048 -nographic -snapshot -drive if=none,file=/home/fcos/tmp/my-coreos/builds/33.20210518.dev.0/x86_64/fedora-coreos-33.20210518.dev.0-qemu.x86_64.qcow2,format=raw -fw_cfg name=opt/com.coreos/config,file=/home/fcos/Downloads/example.ign -kernel bzImage -append "root=/dev/vdb4 console=hvc0 earlyprintk=ttyS0"

kernel panic:
[ 2.240621] VFS: Cannot open root device “vdb4” or unknown-block(0,0): error -6
[ 2.240991] Please append a correct “root=” boot option; here are the available partitions:
[ 2.241732] 0b00 1048575 sr0
[ 2.241782] driver: sr
[ 2.242339] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 2.242930] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc8+ #1
[ 2.243377] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[ 2.244001] Call Trace:
[ 2.245136] dump_stack+0x64/0x7c
[ 2.245470] panic+0xf6/0x2b7
[ 2.245658] mount_block_root+0x196/0x21a
[ 2.245950] mount_root+0xec/0x10a
[ 2.246147] prepare_namespace+0x136/0x165
[ 2.246392] kernel_init_freeable+0x1d6/0x1e1
[ 2.246627] ? rest_init+0xa4/0xa4
[ 2.246806] kernel_init+0x5/0xfc
[ 2.246982] ret_from_fork+0x22/0x30
[ 2.247842] Kernel Offset: 0x34a00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 2.248733] —[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]—

You can direct-boot the kernel by adapting the live PXE instructions. Note that live PXE works differently than an installed system, since the OS runs from RAM. You won’t get automatic updates or a persistent root filesystem, though you can still create persistent data partitions.

If you want to do direct boot with a persistent root filesystem, you could probably hack something together, but that’d take you beyond the functionality that we test or try to support.