Open YellowOnion opened 9 months ago
We should also explore the fstab generator for multi-devices in systemd stage 1.
We should also explore the fstab generator for multi-devices in systemd stage 1.
I guess thats behing systemdStage1? The other option would be to not write to fstab, but generate the systemd mount and device units, as the fstab generator is not able to handle multi device filesystems yet. and we could potentially just generate those units using nix.
We should also explore the fstab generator for multi-devices in systemd stage 1.
I guess thats behing systemdStage1? The other option would be to not write to fstab, but generate the systemd mount and device units, as the fstab generator is not able to handle multi device filesystems yet. and we could potentially just generate those units using nix.
Well, it was not clear for me, it was behind systemdStage1
, yes we could generate mount units but how do you handle degraded mounting?
bcachefs-tools needs some improvements here too, a command so that we don't race with udev and a degraded timeout maybe.
We should also explore the fstab generator for multi-devices in systemd stage 1.
I guess thats behing systemdStage1? The other option would be to not write to fstab, but generate the systemd mount and device units, as the fstab generator is not able to handle multi device filesystems yet. and we could potentially just generate those units using nix.
This explains the issue I had ages back, thank you for the explanation! I would like to request that this be done with priority, since it's kinda one of the big uses for bcachefs imo.
linux_testing_bcachefs
is broken on release-23.11
and master
with no clear way to fix either.
Unless we find a way to fix the kernel on release-23.11
, we honestly may want to backport #268394.
We also have the option of aliasing linux_testing_bcachefs
to linux_testing
on release-23.11
.
linux_testing_bcachefs
is broken onrelease-23.11
andmaster
with no clear way to fix either. Unless we find a way to fix the kernel onrelease-23.11
, we honestly may want to backport #268394.
Cannot reproduce, is there an issue or a link towards the breakage?
linux_testing_bcachefs
is broken onrelease-23.11
andmaster
with no clear way to fix either. Unless we find a way to fix the kernel onrelease-23.11
, we honestly may want to backport #268394.Cannot reproduce, is there an issue or a link towards the breakage?
nix build -L --print-out-paths .#linux_testing_bcachefs
Same happens whether it's on master or release-23.11.
We should just reflow the patches?
We should just reflow the patches?
From what the log tells me, it's the same issue we usually have with this kernel.
Kent's repo is using a commit that has (now) been included in copy nix is using, and we're having a conflict because they're both the same patch.
I have absolutely no idea how to fix this in nixpkgs, other than reverting to just using Kent's kernel without patching the nix kernel.
Furthermore, this is one of the strongest reasons why I wanted to just get us on linux_testing
ASAP.
We should just reflow the patches?
From what the log tells me, it's the same issue we usually have with this kernel. Kent's repo is using a commit that has (now) been included in copy nix is using, and we're having a conflict because they're both the same patch. I have absolutely no idea how to fix this in nixpkgs. Furthermore, this is one of the strongest reasons why I wanted to just get us on
linux_testing
ASAP.
It is very simple to solve, if the generic radix tree stuff is 1:1 exactly what we have in the tree now, we only need to exclude it from the bcachefs patchset. If it's not, we can exclude it and re-add the deltas.
Did you ask Kent to rebase his tree for the newest stable?
Nonetheless, this is a trivial matter and at least one bcachefs maintainers ought to be able to do this. There's no reason to drop the ball just because of trivial conflicts.
If this quality bar is not attainable, I would rather ask everyone to wait for a stable release of bcachefs rather than rushing everything over testing. We already had breakage, and it's not like a lot of stuff is stabilized, we still don't have automatic repair to mount in the NixOS modules.
This is a filesystem, we are not in the development phase of bcachefs anymore, this will be used by people, so please be considerate of this.
diff --git i/pkgs/os-specific/linux/kernel/linux-testing-bcachefs.nix w/pkgs/os-specific/linux/kernel/linux-testing-bcachefs.nix
index c58c4e67e4d0..ba122ff92651 100644
--- i/pkgs/os-specific/linux/kernel/linux-testing-bcachefs.nix
+++ w/pkgs/os-specific/linux/kernel/linux-testing-bcachefs.nix
@@ -6,8 +6,8 @@
# bcachefs-tools stores the expected-revision in:
# https://evilpiepirate.org/git/bcachefs-tools.git/tree/.bcachefs_revision
# but this does not means that it'll be the latest-compatible revision
-, currentCommit ? "4d2faeb4fb58c389dc9f76b8d5ae991ef4497e04"
-, diffHash ? "sha256-DtMc8P4lTRzvS6PVvD7WtWEPsfnxIXSpqMsKKWs+edI="
+, currentCommit ? "08398d3534d8cdba7d90d2e37ac8bdb3e143dedf"
+, diffHash ? "sha256-diokoy0m6DeEAVe0lRkgSLkhx9xoDpVMyLJnPwLux+Q="
, kernelPatches # must always be defined in bcachefs' all-packages.nix entry because it's also a top-level attribute supplied by callPackage
, argsOverride ? {}
, ...
@@ -41,6 +41,10 @@
name = "bcachefs-${currentCommit}.diff";
url = "https://evilpiepirate.org/git/bcachefs.git/rawdiff/?id=${currentCommit}&id2=v${lib.versions.majorMinor kernel.version}";
sha256 = diffHash;
+ excludes = [
+ "include/linux/generic-radix-tree.h"
+ "lib/generic-radix-tree.c"
+ ];
};
} ] ++ kernelPatches;
}))
Here we go.
This requires to re-apply some specific patches to re-add genradix_for_each_reverse
inside the kernel or to adopt genradix_for_each_from
from upstream inside the fs/bcachefs/journal_io.c
code.
we only need to exclude it from the bcachefs patchset.
I had no idea we could exclude individual files/folders in the patch! Thanks!
Did you ask Kent to rebase his tree for the newest stable
I have not. To be frank I have a hard time seeing Kent making a bcachefs release just for 6.5.13 when his main focus is on 6.7 and 6.8.
This is a filesystem, we are not in the development phase of bcachefs anymore, this will be used by people, so please be considerate of this.
Yes, I agree. I was merely reiterating why I was so insistent on replacing linux_testing_bcachefs with linux_testing ASAP.
The maintenance part of that concern should be fixed now that excludes
has been made apparent.
I have not. To be frank I have a hard time seeing Kent making a bcachefs release just for 6.5.13 when his main focus is on 6.7 and 6.8.
The rebase seems also quite trivial, I just did it, I asked Kent about that. I think Kent can say when he's too busy or deem something as not a priority. :)
I think Kent can say when he's too busy or deem something as not a priority. :)
Cheers to the brave then. :rofl: Thank you for doing so much leg work, it'll be a while for me since I am currently recompiling most of the ROCm stack.
FWIW, I did a rebase of bcachefs onto 6.6 here: https://github.com/bendlas/linux/tree/bcachefs-2023-10-30_6.6.5
I used the 2023-10-30
release for that, because that's the last bcachefs tag, that works somewhat cleanly for me.
I tried the current state on unstable with 6.7 and the https://wiki.nixos.org/wiki/Bcachefs#NixOS_installation_on_bcachefs guide. So far all fine, the only issues I have is that if you have x encrypted filesystems during boot it will ask x times.
BCACHEFS
I assume over the next couple of months there's going be massive changes in bcachefs, especially from the tooling side.
After my recent PR, there we're a few regressions, and I would like to try and mitigate that again.
@Madouura @RaitoBezarius @Kloenk @pedrohlc @davidak @chayleaf Add a :+1: reaction to issues you find important.