View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000930 | channel: elrepo/el8 | --elrepo--request-for-enhancement-- | public | 2019-09-05 18:52 | 2019-09-17 23:50 |
Reporter | conathan | Assigned To | toracat | ||
Priority | normal | Severity | feature | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Summary | 0000930: Request for kmod-megaraid_mbox and kmod-megaraid_mm (not part of RHEL 8) | ||||
Description | The megaraid_mbox and megaraid_mm drivers are no longer part of RHEL 8 (or 7). We still utilize some servers that make use of these Raid Cards (SCSI U320). For Centos 7, we just built an RPM utilizing the same kernel source used to build the kernel package. Attached is a spec file which seems to build fine on RHEL 8 Beta | ||||
Tags | No tags attached. | ||||
Attached Files | mega-kmod.spec (6,270 bytes)
# Define the kmod package name here. %define kmod_name mega # If kmod_kernel_version isn't defined on the rpmbuild line, define it here. %{!?kmod_kernel_version: %define kmod_kernel_version 4.18.0-107.el8} %{!?dist: %define dist .el8} Name: kmod-%{kmod_name} Version: 4.18.0.107 Release: 1%{?dist} Summary: %{kmod_name} kernel module(s) Group: System Environment/Kernel License: GPLv2 URL: http://www.kernel.org/ # Sources. Source0: linux-%{kmod_kernel_version}.tar.xz %define findpat %( echo "%""P" ) %define __find_requires /usr/lib/rpm/redhat/find-requires.ksyms %define __find_provides /usr/lib/rpm/redhat/find-provides.ksyms %{kmod_name} %{?epoch:%{epoch}:}%{version}-%{release} %define dup_state_dir %{_localstatedir}/lib/rpm-state/kmod-dups %define kver_state_dir %{dup_state_dir}/kver %define kver_state_file %{kver_state_dir}/%{kmod_kernel_version}.%{_arch} %define dup_module_list %{dup_state_dir}/rpm-kmod-%{kmod_name}-modules %define debug_package %{nil} %global _use_internal_dependency_generator 0 %global kernel_source() %{_usrsrc}/kernels/%{kmod_kernel_version}.%{_arch} BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) ExclusiveArch: x86_64 BuildRequires: elfutils-libelf-devel BuildRequires: kernel-devel = %{kmod_kernel_version} BuildRequires: kernel-abi-whitelists BuildRequires: kernel-rpm-macros BuildRequires: redhat-rpm-config Provides: kernel-modules >= %{kmod_kernel_version}.%{_arch} Provides: kmod-%{kmod_name} = %{?epoch:%{epoch}:}%{version}-%{release} Requires(post): %{_sbindir}/weak-modules Requires(postun): %{_sbindir}/weak-modules Requires: kernel >= %{kmod_kernel_version} %description This package provides the %{kmod_name} kernel module(s). It is built to depend upon the specific ABI provided by a range of releases of the same variant of the Linux kernel and not on any one specific build. %prep %setup -q -n linux-%{kmod_kernel_version} echo "override megaraid_mbox * weak-updates/megaraid_mbox" > kmod-%{kmod_name}.conf echo "override megaraid_mm * weak-updates/megaraid_mm" >> kmod-%{kmod_name}.conf %build %{__make} -C %{kernel_source} modules M="$PWD/drivers/scsi/megaraid" CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m whitelist="/lib/modules/kabi-current/kabi_whitelist_%{_target_cpu}" for modules in $( find drivers/scsi/megaraid/ -name "*.ko" -type f -printf "%{findpat}\n" | sed 's|\.ko$||' | sed 's@drivers/scsi/megaraid/@@' | sort -u ) ; do # update greylist nm -u drivers/scsi/megaraid/$modules.ko | sed 's/.*U //' | sed 's/^\.//' | sort -u | while read -r symbol; do grep -q "^\s*$symbol\$" $whitelist || echo "$symbol" >> ./greylist done done sort -u greylist | uniq > greylist.txt %install %{__install} -d %{buildroot}/lib/modules/%{kmod_kernel_version}.%{_arch}/extra/%{kmod_name}/ %{__install} drivers/scsi/megaraid/megaraid_mbox.ko %{buildroot}/lib/modules/%{kmod_kernel_version}.%{_arch}/extra/%{kmod_name}/ %{__install} drivers/scsi/megaraid/megaraid_mm.ko %{buildroot}/lib/modules/%{kmod_kernel_version}.%{_arch}/extra/%{kmod_name}/ %{__install} -d %{buildroot}%{_sysconfdir}/depmod.d/ %{__install} -m 0644 kmod-%{kmod_name}.conf %{buildroot}%{_sysconfdir}/depmod.d/ %{__install} -d %{buildroot}%{_defaultdocdir}/kmod-%{kmod_name}-%{version}/ %{__install} -m 0644 greylist.txt %{buildroot}%{_defaultdocdir}/kmod-%{kmod_name}-%{version}/ # strip the modules(s) find %{buildroot} -type f -name \*.ko -exec %{__strip} --strip-debug \{\} \; %clean %{__rm} -rf %{buildroot} %post modules=( $(find /lib/modules/%{kmod_kernel_version}.x86_64/extra/%{kmod_name} | grep '\.ko$') ) printf '%s\n' "${modules[@]}" | %{_sbindir}/weak-modules --add-modules --no-initramfs mkdir -p "%{kver_state_dir}" touch "%{kver_state_file}" exit 0 %posttrans # We have to re-implement part of weak-modules here because it doesn't allow # calling initramfs regeneration separately if [ -f "%{kver_state_file}" ]; then kver_base="%{kmod_kernel_version}" kvers=$(ls -d "/lib/modules/${kver_base%%.*}"*) for k_dir in $kvers; do k="${k_dir#/lib/modules/}" tmp_initramfs="/boot/initramfs-$k.tmp" dst_initramfs="/boot/initramfs-$k.img" # The same check as in weak-modules: we assume that the kernel present # if the symvers file exists. if [ -e "/boot/symvers-$k.gz" ]; then /usr/bin/dracut -f "$tmp_initramfs" "$k" || exit 1 cmp -s "$tmp_initramfs" "$dst_initramfs" if [ "$?" = 1 ]; then mv "$tmp_initramfs" "$dst_initramfs" else rm -f "$tmp_initramfs" fi fi done rm -f "%{kver_state_file}" rmdir "%{kver_state_dir}" 2> /dev/null fi rmdir "%{dup_state_dir}" 2> /dev/null exit 0 %preun if rpm -q --filetriggers kmod 2> /dev/null| grep -q "Trigger for weak-modules call on kmod removal"; then mkdir -p "%{kver_state_dir}" touch "%{kver_state_file}" fi mkdir -p "%{dup_state_dir}" rpm -ql kmod-%{kmod_name}-%{version}-%{release}.%{_arch} | grep '\.ko$' > "%{dup_module_list}" %postun if rpm -q --filetriggers kmod 2> /dev/null| grep -q "Trigger for weak-modules call on kmod removal"; then initramfs_opt="--no-initramfs" else initramfs_opt="" fi modules=( $(cat "%{dup_module_list}") ) rm -f "%{dup_module_list}" printf '%s\n' "${modules[@]}" | %{_sbindir}/weak-modules --remove-modules $initramfs_opt rmdir "%{dup_state_dir}" 2> /dev/null exit 0 %files %defattr(644,root,root,755) /lib/modules/%{kmod_kernel_version}.%{_arch}/ %config /etc/depmod.d/kmod-%{kmod_name}.conf %doc /usr/share/doc/kmod-%{kmod_name}-%{version}/ %changelog * Tue Sep 3 2019 Nathan Coulson <nathan@bravenet.com> - 4.18.0.107-1 - Rebuilt for Centos 8 * Wed May 16 2018 Nathan Coulson <nathan@bravenet.com> - 3.10.0.862-1 - Updated to the latest upstream centos 7 kernel * Wed Aug 17 2016 Nathan Coulson <nathan@bravenet.com> - 1.0-1 - Initial el7 build of the kmod package. From e1000e-kmod | ||||
|
Is this a case of one hardware card requiring multiple driver modules, in which case these should all be shipped in one kmod package, or are these separate drivers (supporting separate hardware) requiring separate kmod packages? |
|
For our use in Centos 7, We always packaged it as one driver, Specifically megaraid_mbox depends on megaraid_mm. (Also how I packaged it when I built it on the RHEL 8 beta mock server I was experimenting with). root@aquarius [/root]# lsmod | grep mega megaraid_mbox 40203 3 megaraid_mm 18253 1 megaraid_mbox Saying that, I do not know if there are any other drivers that depend on the megaraid_mm. (For Centos 7, was the only storage adapter we needed that was not part of Centos 7). |
|
Is this a request for a DUD image? And that iso must contain both drivers in a single kmod? |
|
For our use, we don't install the OS on these raid controllers, so we don't need a DUD image. We just install the kmod after installation. |
|
OK, in that case, I suggest we provide the individual kmod packages, and add dependency for megaraid_mm to the megaraid_mbox package. As you noted, there could be other driver that requires megaraid_mm. |
|
Either way works for us. Don't need DUD, and either as 1 or 2 rpm's. (But expanding on my last reply, went looking to see if I could find anything else depending on megaraid_mm) drivers/scsi/megaraid/Kconfig.megaraid: config MEGARAID_MAILBOX is the only thing I see that has 'depends on MEGARAID_MM'. (I won't claim I know what I am doing here, so I could be wrong). But in addition to that, Centos 7 and elrepo(afaik) never had megaraid_mm available (no requests for any drivers that depended on it at least I am assuming). * Ignoring the rpm I threw together for our own use Note: not advocating single rpm over 2, just adding additional information. |
|
Hi, I've built a kmod-megaraid_mbox package which also ships the megaraid_mm module. megaraid_mbox must be built against megaraid_mm as it requires symbols exported by megaraid_mm so makes sense to build and ship them together, rather than as separate packages. The following package has been released and is currently uploading to mirror sites: kmod-megaraid_mbox-2.20.5.1-1.el8_0.elrepo.x86_64.rpm If you are able to test, that would be great. I've done very simple testing and confirmed both modules load as expected, but don't have the hardware to test further. |
|
Testing, all looks well. Raid array's appear as a block device (as it always has), and megamgr (at least as far as the driver goes), is connecting and using /dev/megadev0 perfectly fine. Verified by listing the drives. Thank you. |
|
Great. Many thanks for the feedback - marking resolved. |
Date Modified | Username | Field | Change |
---|---|---|---|
2019-09-05 18:52 | conathan | New Issue | |
2019-09-05 18:52 | conathan | Status | new => assigned |
2019-09-05 18:52 | conathan | Assigned To | => toracat |
2019-09-05 18:52 | conathan | File Added: mega-kmod.spec | |
2019-09-06 00:19 | pperry | Note Added: 0006431 | |
2019-09-06 00:20 | pperry | Note Edited: 0006431 | |
2019-09-06 00:21 | pperry | Note Edited: 0006431 | |
2019-09-06 00:21 | pperry | Note View State: 6431: public | |
2019-09-06 11:36 | conathan | Note Added: 0006434 | |
2019-09-07 09:34 | toracat | Note Added: 0006442 | |
2019-09-07 12:10 | conathan | Note Added: 0006443 | |
2019-09-07 12:18 | toracat | Note Added: 0006444 | |
2019-09-07 13:31 | conathan | Note Added: 0006446 | |
2019-09-15 10:30 | pperry | Note Added: 0006470 | |
2019-09-17 20:57 | conathan | Note Added: 0006473 | |
2019-09-17 23:49 | pperry | Note Added: 0006474 | |
2019-09-17 23:50 | pperry | Status | assigned => resolved |
2019-09-17 23:50 | pperry | Resolution | open => fixed |