Hi Nicholas, On Tue, 2026-07-28 at 14:12 -0400, Nicholas D Steeves wrote: > Sorry for the long delay replying.
No worries. This issue seems low priority to me, and we all have limited time. No pressure on my end. 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: >>> What is the output of >>> >>> grep 'MODULES=' /etc/initramfs-tools/initramfs.conf >> >> MODULES=most My apologies; I've inadvertently mislead you. After confirming that btrfs.ko.xz is included in the initramfs on a fresh trixie install, as you observed, I found that I had an additional configuration file in /etc/initramfs-tools/conf.d/ which set MODULES=dep. Doh! My bad. 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) 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. > 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). >> Thanks again for considering and discussing this issue, and for >> maintaining btrfs-progs in general. > > You're welcome! 'wish I had more free time and energy to make all the > improvements I planned to back in 2012... You and me both! Cheers, Kevin
