Control: retitle -1 btrfs-progs: Please support "MODULES=dep" in initramfs Control: tag -1 = confirmed
Hi Kevin, Kevin Locke <[email protected]> writes: > On Tue, 2026-07-28 at 14:12 -0400, Nicholas D Steeves wrote: >> Kevin Locke <[email protected]> writes: >>> On Fri, 2025-11-07 at 20:57 -0500, Nicholas D Steeves wrote: > > I believe this bug only appears in the MODULES=dep case and that > MODULES=most works as intended. > > What do you think about option 1 (use a heuristic to detect whether > btrfs is in use - possibly already implemented by initramfs-tools to > determine whether to include btrfs.ko) If that's the case, this bug should be reassigned to initramfs-tools. In addition to currently mounted fs, the heuristic should also include unmounted btrfs fs in /etc/fstab. If initramfs-tools has a plugin system that I'm unaware of then I'd appreciate it if someone could save me some time and spoons by pointing me in the right direction. > vs option 3 (unconditionally > add the btrfs module) for the MODULES=dep case? I'd lean toward > option 1, but I wouldn't be opposed to option 3 if it's more robust or > maintainable, especially given the lvm2 precedent you noted. We can do this in btrfs-progs, like lvm2. >> Meanwhile, I think it's wrong that btrfs-progs is stuffing btrfs-convert >> into everyone's initramfs when that's not even upstream's recommended >> migration protocol at this time, and when "convert" is an operation an >> extreme minority of people will use at most once. At the same time, we >> don't yet ship a useful fsck.btrfs (which ought to call 'btrfs check >> $DEVICE', then pause so the user can photograph the screen to include in >> a bug report); that should be in the initramfs when rootfs=btrfs. Then >> there are the initramfs<->btrfs race issues like #964906. > > Good catch! I completely agree about skipping btrfs-convert and would > love better handling of fsck for rootfs=btrfs and the race in #964906 > (although I realize those last two are likely much more involved). It's also a question of policy and user expectation. Fsck had the elegant interface of /forcefsck (per mount, IIRC) until (IIRC) systemd-mount killed that. I'm not sure if reimplementing that somewhere would be the best approach. Two user expectations are boot without fsck unless fatal error vs fsck if uncleanly shutdown because I'm using dangerous btrfs features. Cheers, Nicholas
signature.asc
Description: PGP signature
