Change:
lib, stdenv, fetchFromGitHub, <ins> fetchpatch, </ins> pkg-config, libuuid, libsodium,

Discussion:
I'm using bcachefs and it fails to boot on 05/05 (latest as of right now). Stage 1 fails. Other generations boot fine. Steps to reproduce the behavior: nixos A clear and concise description of what you expected to happen. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I believe it's an issue with the new bcachefs-tools
Are you using systemd in initrd? () Bcachefs as root won't boot with that. Please provide logs so we can help further.
I'm not using . Where do you want logs from?
The bcachefs error messages you see on the screen are normal though. You can see them by booting in a "working" generation, and running . Also does this happen on 6.8 kernel?
I get the same error message on 6.8.9 about stage 1 failing
I am on 6.8.9 kernel and I have no trouble booting. Could be related to your specific configuration. First test if it's actually coming from bcachefs-tools, I'll recommend pinning only bcachefs-tools to the previous version , and use an to fetch system bcachefs-tools from that nixpkgs commit.
I'm using encryption on bcachefs so that could be it. I'll try using an overlay from that commit and see if it boots or not
I pinned bcachefs-tools to and it boots. Using an overlay like you showed.
Few tests I would like you to run, does it work using the latest commit from this It has a flake, so you can use after adding the flake in your If it works, I'd like you to test the branch.
The latest commit from master doesn't boot. I'll try v1.7.0. Edit: v1.7.0 doesn't boot either
Could you share part of your configuration related to disks and encryption? Just so we are clear you have been using the latest rc kernel between these tests? Pinging for his input.

EDIT: Kent, they are using encryption with compression in their , could that be it?
Yes I've been using rc6 for these tests. This is my entire configuration as of right now:
This doesn't seem to be a packaging problem, and I don't see anything weird per say in your NixOS configuration. But I'll have to redirect you to or as Kent is pretty active over there on Reddit. Keeping this issue open for the time being.
I can confirm this happening on my machine updating today. Sadly lacking time to debug further but gonna watch this and possible upstream issues for when I've got more time. Updated 6.8.8-6.8.9 kernel, nixos-unstable, also with bcache root fs with enabled encryption. Possibly relevant configuration:
Note: Issue title should be updated to like "booting with bcachefs compression on is broken". EDIT: mention that you are using both compression and encryption in the issue description, share a code snippet like above from your hardware configuration and add to issue description.
Having the same issue here: It looks like an issue with bcachefs-tools version 1.6.4 forward. Would it make sense to either downgrade the nixpkgs version to 1.6.3 or mark the package broken?
I am inclined to downgrade the version to 1.6.3 for 24.05 release unless a fix is provided in upstream within the NixOS 24.05 merge window (4th week of May). Though, this only affects few chunk of users who are using this experimental filesystem, with encryption on. Those who are facing this bug, please report it to the with logs in This will help Kent fix this faster.
What kernel version is 24.05 expected to ship with? I ask because the 1.6.x series of bcachefs-tools should match bcachefs disk format 1.6 (kernel 6.8.x); whereas 1.7.x matches the disk format in 6.9.x. I know there's been thought put into making the tools cross-compatible so everything should be fine with version mismatches? But at the same time, unless we're planning to take a 6.9 series kernel I'm not sure there's a pressing need to bump the tools to 1.7.x quite yet.

(Also - I'm hitting this issue without compression enabled; so this issue is probably incorrectly named...)
TLDR: 6.9, I'm tracking this, and will downgrade at the end of the merge window for 24.05, if it comes to it.
Why wasn't this caught by `?