https://bugzilla.redhat.com/show_bug.cgi?id=1982438
Bug ID: 1982438
Summary: [RFE] weak-modules just do initramfs
Product: Fedora
Version: rawhide
Hardware: All
OS: Linux
Status: NEW
Component: kmod
Assignee: kmod-maint(a)lists.fedoraproject.org
Reporter: riehecky(a)fnal.gov
QA Contact: extras-qa(a)fedoraproject.org
CC: jonathan(a)jonmasters.org,
kmod-maint(a)lists.fedoraproject.org,
skozina(a)redhat.com, ykaliuta(a)redhat.com
Target Milestone: ---
Classification: Fedora
Created attachment 1801653
--> https://bugzilla.redhat.com/attachment.cgi?id=1801653&action=edit
Possible patch
Description of problem:
When loading packages containing external modules, it is helpful if I can just
rebuild the initramfs as a separate - direct - step.
Version-Release number of selected component (if applicable):29-3.f35
How reproducible:100%
Steps to Reproduce:
1. Look for clear way to engage weak-modules just for initramfs
2.
3.
Actual results:
No entry point
Expected results:
Simple entry point
Additional info:
This is most obviously helpful with the EL kernels (and our friends at ELRepo)
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1962841
Bug ID: 1962841
Summary: kmod should not ship /usr/sbin/weak-modules because it
is useless and dangerous for DKMS modules
Product: Fedora
Version: 33
Status: NEW
Component: kmod
Assignee: kmod-maint(a)lists.fedoraproject.org
Reporter: cks-rhbugzilla(a)cs.toronto.edu
QA Contact: extras-qa(a)fedoraproject.org
CC: jonathan(a)jonmasters.org,
kmod-maint(a)lists.fedoraproject.org,
skozina(a)redhat.com, ykaliuta(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
Fedora specifically adds the /usr/sbin/weak-modules script to the kmod RPM;
it's not part of the upstream version. However, weak-modules does not work
properly on Fedora, as it believes that a module built for one kernel version
can be compatible with another kernel version, and will create
/lib/modules/*/weak-updates symlinks reflecting this under at least some
circumstances. After these symlinks exist, modprobe of the relevant module(s)
will fail with eg:
version magic '5.11.15-200.fc33.x86_64 SMP mod_unload ' should be
'5.10.23-200.fc33.x86_64 SMP mod_unload '
Fedora does not set CONFIG_MODVERSIONS in its kernel configurations, so I
believe this will always fail and as a result /usr/sbin/weak-modules's checks
are irrelevant and evidently incorrect.
This failure is sufficiently well known that the upstream DKMS manpage contains
a warning that everyone writing a dkms.conf must specifically disable running
/usr/sbin/weak-modules on Fedora (the 'NO_WEAK_MODULES' setting and the
discussion of it in the manpage). It should come as no surprise that not all
dkms.conf files contain this setting.
This issue is especially dangerous because it seems to primarily affects people
when they are reverting to a previous kernel, where some of their modules may
not load.
Version-Release number of selected component (if applicable):
kmod-27-3.fc33.x86_64
How reproducible:
Completely.
Steps to Reproduce:
1. Install a DKMS module with a dkms.conf that doesn't specify
NO_WEAK_MODULES=yes. It will modprobe on your current kernel.
2. Install a kernel upgrade.
3. Reboot into the current kernel (not the new upgraded kernel) and observe
that your DKMS module no longer modprobes, failing with a version magic error.
4. see that /lib/modules/$(uname -r)/weak-modules contains a symlink for your
DKMS module that points to /lib/modules/<new-kernel>/.../<dkms-module>.ko.xz.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1962980
Bug ID: 1962980
Summary: kmod-29 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: kmod
Keywords: FutureFeature, Triaged
Assignee: kmod-maint(a)lists.fedoraproject.org
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: jonathan(a)jonmasters.org,
kmod-maint(a)lists.fedoraproject.org,
skozina(a)redhat.com, ykaliuta(a)redhat.com
Target Milestone: ---
Classification: Fedora
Latest upstream release: 29
Current version/release in rawhide: 28-2.fc34
URL: https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from anitya:
https://release-monitoring.org/project/1517/
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1951176
Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jonathan(a)jonmasters.org,
| |kmod-maint(a)lists.fedoraproj
| |ect.org,
| |skozina(a)redhat.com,
| |ykaliuta(a)redhat.com
Component|systemd |kmod
Assignee|systemd-maint(a)redhat.com |kmod-maint(a)lists.fedoraproj
| |ect.org
--- Comment #2 from Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> ---
Hmm, this is strange. When executed in the real system, we correctly detect
that the module is built-in:
$ systemd-modules-load /usr/lib/modules-load.d/fwupd-msr.conf
Module 'msr' is built in
But when executed in the initramfs, this doesn't work for some reason.
$ chroot /var/tmp/initrd
(chroot)# /usr/lib/systemd/systemd-modules-load
/usr/lib/modules-load.d/fwupd-msr.conf
Failed to find module 'msr'
/usr/lib/modules/5.12.0-198.fc34.x86_64/modules.builtin in the initrafms does
list kernel/arch/x86/kernel/msr.ko.
But for some reason libkmod not not grok that.
$ grep -w msr /usr/lib/modules/5.12.0-198.fc34.x86_64/*
/usr/lib/modules/5.12.0-198.fc34.x86_64/modules.builtin:kernel/arch/x86/kernel/msr.ko
grep: /usr/lib/modules/5.12.0-198.fc34.x86_64/modules.builtin.modinfo: binary
file matches
grep: /usr/lib/modules/5.12.0-198.fc34.x86_64/modules.symbols.bin: binary file
matches
grep: /usr/lib/modules/5.12.0-198.fc34.x86_64/vmlinuz: binary file matches
$ grep -w msr /var/tmp/initrd/usr/lib/modules/5.12.0-198.fc34.x86_64/*
/var/tmp/initrd/usr/lib/modules/5.12.0-198.fc34.x86_64/modules.builtin:kernel/arch/x86/kernel/msr.ko
It seems that dracut is doing something wrong in constructing the module lists.
kmod maintainers, any advice?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1808430
Bug ID: 1808430
Summary: depmod: tools/depmod.c:416: index_write: Assertion
`initial_offset >= 0' failed.
Product: Fedora
Version: rawhide
Status: NEW
Component: kmod
Assignee: kmod-maint(a)lists.fedoraproject.org
Reporter: yaneti(a)declera.com
QA Contact: extras-qa(a)fedoraproject.org
CC: jonathan(a)jonmasters.org,
kmod-maint(a)lists.fedoraproject.org,
skozina(a)redhat.com, ykaliuta(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
depmod -n 5.6.0-0.rc3.git2.2.fc33.x86_64
....
depmod: tools/depmod.c:416: index_write: Assertion `initial_offset >= 0'
failed.
Aborted (core dumped)
Version-Release number of selected component (if applicable):
kmod-27-1.fc33.x86_64
Additional info:
kmod-26-5.fc32 works fine
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1913949
Bug ID: 1913949
Summary: kmod-28 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: kmod
Keywords: FutureFeature, Triaged
Assignee: kmod-maint(a)lists.fedoraproject.org
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: jonathan(a)jonmasters.org,
kmod-maint(a)lists.fedoraproject.org,
skozina(a)redhat.com, ykaliuta(a)redhat.com
Target Milestone: ---
Classification: Fedora
Latest upstream release: 28
Current version/release in rawhide: 27-3.fc33
URL: https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from anitya:
https://release-monitoring.org/project/1517/
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1900596
Brian Lane <bcl(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Fixed In Version| |lorax-34.6-1.fc34
Resolution|--- |RAWHIDE
Last Closed| |2020-12-16 22:17:21
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1900596
Brian Lane <bcl(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #3 from Brian Lane <bcl(a)redhat.com> ---
https://github.com/weldr/lorax/pull/1101
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1900596
Vojtech Trefny <vtrefny(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|kmod |lorax
Assignee|kmod-maint(a)lists.fedoraproj |bcl(a)redhat.com
|ect.org |
--- Comment #2 from Vojtech Trefny <vtrefny(a)redhat.com> ---
I'm moving this back to lorax, feel free to close it as "wontfix" or "cantfix",
but this is a problem in lmc, see my "expected results" -- I expect lmc to exit
with error in this case and not to be stuck forever. I know what is the
problem: it's the kvdo module which is broken in Fedora and I don't expect lmc
to fix this.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1900596
Brian Lane <bcl(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jonathan(a)jonmasters.org,
| |kmod-maint(a)lists.fedoraproj
| |ect.org,
| |skozina(a)redhat.com,
| |ykaliuta(a)redhat.com
Component|lorax |kmod
Assignee|bcl(a)redhat.com |kmod-maint(a)lists.fedoraproj
| |ect.org
--- Comment #1 from Brian Lane <bcl(a)redhat.com> ---
There's nothing lmc can do about script errors. The package needs to fix their
script. Please check to see if there are any additional details in the various
logs, there may or may not be, debugging script errors can be tricky.
The "Connection refused" errors are unrelated, IIRC that comes from python-meh
trying to report the crash.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.