Control: tag -1 -moreinfo Hi Nicholas,
Thanks for taking the time to consider and discuss! 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 >> 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). > > 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. 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. >> 2. Send modprobe stderr to /dev/null. > > It sounds like you know that it's not an error, but a warning, and that > for your specific use case the warning is cosmetic and can be ignored. > Meanwhile, this proposal, if implemented, would hide legitimate errors. I know it now that I've paid the cost to investigate the error. Other users will have to pay the same cost and implement the same solution. I agree about hiding legitimate errors and am not a fan of this solution. Lets set it aside. >> 3. Unconditionally add the btrfs module to initramfs from >> /usr/share/initramfs-tools/hooks/btrfs by calling >> manual_add_modules. > > If "btrfs is installed for working with external media" then a user may > also expect to be use the initramfs as a lightweight rescue system in > combination with external media (ie: GRUB can still load the kernel and > the initramfs, but the user modifies the kernel command line to pivot to > the rootfs on the external media). Thus far, this looks like the best > solution to me, and the cost is: > > 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'd expect using btrfs rescue media while booted from the system initramfs on a non-btrfs system to be uncommon, but if you think it's important or common enough to justify the size increase, or avoid the complexity of other solutions, I'd defer to your judgement. It's your call. > for (popcon) 20486 users, only one of whom has complained about the 848K. Although I'm the only user who has taken the time to investigate and open an issue about the warning, it's unlikely I'm the only one who has either seen or investigated the warning. No complaints about the 848K for my current use cases though. >> I'm sure there are other solutions as well. > > 4. Locally implement option #2. > > 5. Do nothing. Sure. With the caveat that it's only a solution for me and not for other users. >> I'd prefer solutions which minimize the amount of unnecessary >> initramfs code on systems not using btrfs for system partitions. > > Isn't this a non-btrfs-specific wishlist bug in initramfs? I'm sorry, I don't understand. Are you suggesting initramfs-tools could determine which code is necessary and remove unnecessary code generically? Or provide an interface to make it easier for hook developers to conditionally exclude their own code? Or a common system for determining which code is necessary? How would you summarize the wishlist bug? Thanks again for considering and discussing this issue, and for maintaining btrfs-progs in general. Cheers, Kevin
