e2fsprogs: 1.46.6 -> 1.47.0

[lucky9-cyou]

Changelog: https://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.47.0

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[lucky9-cyou]

Related issue: #229450 (comment)

[vcunat]

@ofborg eval

[risicle]

These should be squashed into a single commit with the commit message e2fsprogs: 1.46.6 -> 1.47.0

[pkern]

I think it'd be good to queue this up for backporting. It looks like if you create a filesystem on unstable, e2fsck will refuse to check it on stable:

[    7.164612] stage-1-init: [Wed Jun 21 21:16:08 UTC 2023] /dev/disk/by-label/nixos has unsupported feature(s): FEATURE_C12
[    7.172009] stage-1-init: [Wed Jun 21 21:16:08 UTC 2023] e2fsck: Get a newer version of e2fsck!

And that's blocking boot. To be fair, I used the kexec method to install nixos and that did not use the release branch of my Flake, so there's that.

[vcunat]

Man, I'd expect at least a bit of compatibility 🤦🏽

[vcunat]

But I'm afraid that simply backporting this upgrade might just propagate the breakage further.

[pkern]

So in Debian we stopped the bleeding by disabling the offending features by default. :/

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031622

[pkern]

So one solution might be to backport the version and also disable the setting of the options. That would fix e2fsck to work with newer ext4 filesystems but not generate new incompatible filesystems.

[alyssais]

Is there any urgency in getting these features enabled by default? The safe thing to do would be to disable these new features by default, and then enable them after 23.11 branches off.

[vcunat]

As for kernels, the feature (orphan_file) is said to be first supported in 5.15. We default to 6.1 in NixOS 23.05 already, but I'm still a little afraid for usability of older kernels we have, especially as this thing behaves relatively impurely.

[pkern]

For what it's worth: If you are lucky enough that you can unmount the filesystem, you can do tune2fs -O ^orphan_file <fs> with the new e2fsprogs and undo the damage.

[vlaci]

It looks like x86_64 darwin builds are failing after this https://hydra.nixos.org/build/225290219
c311c7c5cc5

[alyssais]

It looks like x86_64 darwin builds are failing after this

Previous discussion in #236656 (comment).

[emilazy]

See #238791, will hopefully be fixed soon. I have a workaround I can PR if the need is urgent though.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/removing-the-need-for-a-password-with-internal-drives/35848/11