Bug 1116670

sos itself doesn't load any kernel modules so this must be a side-effect of something else that's run during collection.

Verifying the modules list after each plugin invocation points the finger at grub2:

# rmmod ext4 btrfs
# lsmod | egrep 'ext4|btrfs'
# time sosreport --batch --debug --build --quiet -o grub2
# lsmod | egrep 'ext4|btrfs'
btrfs                 856675  0 
ext4                  528957  0 
zlib_deflate           26914  1 btrfs
raid6_pq               97812  1 btrfs
xor                    21411  1 btrfs
mbcache                14958  1 ext4
jbd2                   98341  1 ext4
libcrc32c              12644  2 xfs,btrfs

Manual testing confirms it's grub2-mkconfig:

# rmmod ext4 btrfs
# grub2-mkconfig &> /dev/null
# lsmod | egrep 'ext4|btrfs'
btrfs                 856675  0 
ext4                  528957  0 
zlib_deflate           26914  1 btrfs
raid6_pq               97812  1 btrfs
xor                    21411  1 btrfs
mbcache                14958  1 ext4
jbd2                   98341  1 ext4
libcrc32c              12644  2 xfs,btrfs

Changing component to grub2.

There's really not a reasonable way to do this - os-prober is just doing "mount -t btrfs", and there's no way for it to know what modules got loaded as a result, what modules you should or should not have loaded, what else may have loaded a module at the same time, etc.  So we can't really choose what to unload, and we can't really implement something like snapshots of the module list that we try to roll back to by unloading.

There's not really any *problem* with having extra modules loaded which you're not using, either.  So if this is a big issue for you, the best thing would be to to make sure sosreport isn't running its module that's calling os-prober.

(In reply to Peter Jones from comment #4)
> There's really not a reasonable way to do this - os-prober is just doing
> "mount -t btrfs", and there's no way for it to know what modules got loaded
> as a result, what modules you should or should not have loaded, what else
> may have loaded a module at the same time, etc.  So we can't really choose
> what to unload, and we can't really implement something like snapshots of
> the module list that we try to roll back to by unloading.
> 
> There's not really any *problem* with having extra modules loaded which
> you're not using, either.  So if this is a big issue for you, the best thing
> would be to to make sure sosreport isn't running its module that's calling
> os-prober.

This is my understanding as well. Running sosreport may redundantly load some kernel modules that wont be unloaded by sosreport itself. That consumes some small amount of resources like memory - just for the very first run of sosreport on the machine (since reboot).

Is there some other impact than that?

(In reply to Peter Jones from comment #4)
> There's not really any *problem* with having extra modules loaded which
> you're not using, either.

Except that sosreport *explicitly* promises that it will not make any changes to the system configuration, so the current behavior leads to extremely poor user experience.

See PR: https://github.com/sosreport/sos/pull/616

And commit: https://github.com/sosreport/sos/commit/08f5b211dbbf143b3f3ce5e8328947f01adb86cd

too late to accept to 7.2, should be in 7.3

devel_ack+ due to patch in upstream via commit 08f5b211dbbf143b3f3ce5e8328947f01adb86cd

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

*** Bug 1333911 has been marked as a duplicate of this bug. ***

Per comment:

https://github.com/sosreport/sos/pull/822#discussion_r64427095

this is not supposed to be fixed in sosreport. Since:

- grub2-mkconfig collects such valuable information for CEE associates that it needs to be present in sosreport regardless of some kernel module currently loaded or not. I.e. even on systems with e.g. ext4 module unloaded, the command output needs to be collected.

- theoretically, sos can (after running grub2-mkconfig) manually unload the modules not loaded before the command execution, but exactly this sanity work should be done by the grub2-mkconfig program itself.

Therefore, I am changing component from sos to grub2.



Updated bugzilla report for grub2 / grub2-mkconfig:

Description of problem:
Even a system which is not using btrfs at all, grub2-mkconfig loads btrfs
and ext4 kernel modules and never unloads them.

Version-Release number of selected component (if applicable):
grub2-tools-2.02-0.34.el7_2.x86_64

How reproducible:
Always

Steps to Reproduce:
0. Install OS on xfs filesystem. No btrfs on the system.
1. run commands:
lsmod > /tmp/lsmod.before
grub2-mkconfig > /dev/null 2>&1
lsmod > /tmp/lsmod.after 
diff /tmp/lsmod.before /tmp/lsmod.after

Actual results:

# diff /tmp/lsmod.before /tmp/lsmod.after
1a2,3
> btrfs                 960776  0 
> ext4                  578819  0 
3,5c5,7
< zlib_deflate           26914  0 
< raid6_pq               97812  0 
< xor                    21411  0 
---
> zlib_deflate           26914  1 btrfs
> raid6_pq               97812  1 btrfs
> xor                    21411  1 btrfs
10,11c12,13
< mbcache                14958  0 
< jbd2                  102940  0 
---
> mbcache                14958  1 ext4
> jbd2                  102940  1 ext4
81c83
< crc32c_intel           22079  1 
---
> crc32c_intel           22079  2 

Expected results:
empty diff / btrfs and ext4 modules unloaded at the end.

> - theoretically, sos can (after running grub2-mkconfig) manually unload the
> modules

No it can't (in theory or otherwise) for essentially the same reasons Peter outlines in comment #4 - if os-prober/grub2-mkconfig cannot do this then sos certainly can't either.

The only way this can work is if there is a way to tell os-prober to not attempt anything that could load a module.

This is still not a grub2 or os-prober bug.  They are both working as intended, and the things you seem not to like are required features.

If you want grub2-mkconfig but need to avoid the side effects os-prober has, the best answer may be invoking grub2-mkconfig with GRUB_DISABLE_OS_PROBER=true in the environment, which will skip the os probes entirely.

(In reply to Peter Jones from comment #20)
> This is still not a grub2 or os-prober bug.  They are both working as
> intended, and the things you seem not to like are required features.
> 
> If you want grub2-mkconfig but need to avoid the side effects os-prober has,
> the best answer may be invoking grub2-mkconfig with
> GRUB_DISABLE_OS_PROBER=true in the environment, which will skip the os
> probes entirely.

Thanks, that works.

Updated sos PR: https://github.com/sosreport/sos/pull/822#commits-pushed-637d96d

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2380.html