Hello Kevin, Sorry for the long delay replying.
Kevin Locke <[email protected]> writes: > On Fri, 2025-11-07 at 20:57 -0500, Nicholas D Steeves wrote: >> Kevin Locke <[email protected]> writes: >>> After upgrading to Trixie, btrfs-progs causes the following error to >>> be printed from the initramfs: >>> >>> modprobe: module btrfs not found in modules.dep >> >> What is the output of >> >> grep 'MODULES=' /etc/initramfs-tools/initramfs.conf > > MODULES=most The definition for this is "Add most filesystem and all harddrive drivers." >>> I believe this is due to >>> /usr/share/initramfs-tools/scripts/local-premount/btrfs calling >>> `modprobe btrfs` even though the btrfs module may not be present in >>> the initramfs. (It is not present on this system due to not having >>> any btrfs partitions. btrfs-progs is installed for working with >>> external media.) >>> >>> A few potential solutions: >>> >>> 1. Only add the btrfs executable to the initramfs when there is a >>> btrfs partition in use (i.e. cases when the btrfs module is added). Lets talk about the module for this bug. The utility/executable is a secondary or tertiary concern...but more on this later! :) >> Why is the additional complexity needed to implement this justified, and >> how do you propose to make it robust? Is there a precedent for this >> with any other FS? Ie: XFS? > > Warning messages place a burden on system administrators of both > expertise and effort to investigate and mitigate, which is duplicated > across the number of people and systems affected. I advise weighing > it against the burden of additional complexity on the developer(s). > > For this specific solution, perhaps considering a low-complexity > implementation like `if grep -q btrfs /proc/mounts ...` would be a > reasonable place to start? If you think an approach like this might > be acceptable, lets discuss any robustness or complexity issues you > see. If not, is there another approach you'd consider? Otherwise, > lets focus on solution 3. This suggestion appears to describe the MODULES=dep case because it is an example of "Try and guess which modules to load." Agreed? I'm guessing we both agree, and that this is worth supporting. > For reference, I have not observed warnings after installing > f2fs-tools, ntfs-3g, or xfsprogs. It appears that none of these > packages, nor zfsutils-linux, provide initramfs hooks. > > Correction: ntfs-3g does have an initramfs hook! Not sure how I > missed it. It does not include fuse.ko in the initramfs itself[1] and > only calls `modprobe fuse` if $ROOTFSTYPE or $LOOPFSTYPE is ntfs or > ntfs-3g[2] (presumably relying on the initramfs-tools to include > fuse.ko when necessary). > > What would you think about using a similar approach for btrfs? > Thank you for your investigation! The problem is "presumably relying on the initramfs-tools to include fuse.ko when necessary" is that "when necessary" is currently appears to be buggy for btrfs. I dug around and found another precedent at /usr/share/initramfs-tools/hooks/lvm2: manual_add_modules dm_mod dm_snapshot dm_mirror dm_raid raid0 raid1 raid10 raid456 it looks to me like lvm2 unconditionally adds its modules even when the rootfs isn't on LVM. That's how I planned to implement option 3. >>> 3. Unconditionally add the btrfs module to initramfs from >>> /usr/share/initramfs-tools/hooks/btrfs by calling >>> manual_add_modules. >> [snip] >> >> 76K kernel/lib/raid6/raid6_pq.ko.xz >> 8.0K kernel/crypto/xor.ko.xz >> 4.0K kernel/lib/libcrc32c.ko.xz >> 760K kernel/fs/btrfs/btrfs.ko.xz >> 848K total > > That's acceptable to me. I'm happy to hear that. [snip] It feels to me like the primary question is what "Add most filesystem and all harddrive drivers." means. At this point I think that MODULES=most should include btrfs drivers, because btrfs is an in-tree filesystem unlike zfs or ntfs-3g, because of the lvm2 precedent, and because of the user experience issues you've noted. I seem to remember that it's also the case that dkms insures that zfs drivers are always present in the initramfs even when the rootfs isn't zfs. Based on what you're saying it sounds like there's also an initramfs bug, because MODULES=most should arguably put btrfs.ko in the initramfs even when btrfs-progs isn't installed. I also think that it would be reasonable to clone this bug; the second bug would be a request to support MODULES=dep. MODULES=dep is defined as a "best attempt" heuristic. 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. [snip] > 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... Cheers, Nicholas
signature.asc
Description: PGP signature
