[elrepo] kmod-sata_via module for CentOS7

[Manuel Wolfshant]

On 7/21/21 8:16 PM, Tristan Evans wrote:
> Thanks so much everyone for not only creating the kmod that fixes my 
> issue, but also for the suggestions on handing it during installation.
>
> Phil, that makes a lot of sense regarding using `inst.dd` and the 
> conflicting modules. I do wonder though.. These installations are to 
> be automated using a kickstart script, so I wonder if in the "pre" 
> section (before any storage settings are applied and installation 
> begins) it can do some finagling to unload the intree module and 
> replace it with the kmod.. Not sure if that is better/worse than just 
> using a custom kernel image, but it got me thinking.

There is also an inst.blacklist parameter for anaconda. I do not know 
though if it would blacklist only the module provided by the stock 
kernel or it would also affect the kmod.

As of fiddling with the module.. this should not be needed. If the DUD 
is correctly created, the kmod package is used during install time. The 
PC I am typing from has an r8125 chip ( actually two but this does not 
matter :) ) which is not supported out of the box so normally there 
would be no network access during install.

However I wanted to do a network based install ( in order to use the 
updates repo at install time, as well as set NTP ) on it so I downloaded 
the kmod from elrepo, created a DUD on which I also copied my kickstart 
and everything worked exactly as intended: network was activated and 
everything worked as advertised.

The only doubt I have is that unlike for you, in my case there was no 
default kernel module to replace but just a new one to add.


>
> To do some testing, I booted into the CentOS installer media and 
> started trying some things:
>
> Extracted the RPM:
>
> rpm2cpio ./kmod-sata_via-2.6-1.el7_9.elrepo.x86_64.rpm | cpio -idmv
> ./etc/depmod.d/kmod-sata_via.conf
> ./lib/modules/3.10.0-1160.el7.x86_64
> ./lib/modules/3.10.0-1160.el7.x86_64/extra
> ./lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via
> ./lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz
> ./usr/share/doc/kmod-sata_via-2.6
> ./usr/share/doc/kmod-sata_via-2.6/GPL-v2.0.txt
>
> I copied the files to their specific locations:
>
> cp ./etc/depmod.d/kmod-sata_via.conf /etc/depmod.d/
> cp ./lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz 
> /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/
>
> Note that I made a quick update to "kmod-sata_via.conf". It seems it 
> was configured to look into "weak-updates/sata_via", but the RPM would 
> install the module to "extra/sata_via".

For the kmods it ships. ElRepo takes advantage of the stable ABI of the 
kernels provided by RedHat. The modules are placed below /extra but via 
the weak-update mechanism provided by RH ( basically invoked by the rpm 
postinstall  scripts as "/sbin/weak-modules --add-modules"), symlinks 
are created which ensure that the module is used by all the kernel packages.


>
> I then ran `depmod -a` and now it seems the OS recognizes the kmod 
> sata_via driver:
>
> [anaconda root at unknown001a6443e48f sata_via]# modinfo sata_via
> filename: 
> /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz
> version:        2.6
> license:        GPL
> description:    SCSI low-level driver for VIA SATA controllers
> author:         Jeff Garzik
> retpoline:      Y
> rhelversion:    7.9
> srcversion:     D02B8C752BDC9941B11FCCB
> alias:          pci:v00001106d00009000sv*sd*bc*sc*i*
> alias:          pci:v00001106d00005287sv*sd*bc*sc*i*
> alias:          pci:v00001106d00007372sv*sd*bc*sc*i*
> alias:          pci:v00001106d00005372sv*sd*bc*sc*i*
> alias:          pci:v00001106d00003249sv*sd*bc*sc*i*
> alias:          pci:v00001106d00003149sv*sd*bc*sc*i*
> alias:          pci:v00001106d00000591sv*sd*bc*sc*i*
> alias:          pci:v00001106d00005337sv*sd*bc*sc*i*
> depends:        libata
> vermagic:       3.10.0-1160.el7.x86_64 SMP mod_unload modversions
> signer:         The ELRepo Project (http://elrepo.org 
> <http://elrepo.org>): ELRepo.org Secure Boot Key
> sig_key:  F3:65:AD:34:81:A7:B2:0E:34:27:B6:1B:2A:26:63:5B:83:FE:42:7B
> sig_hashalgo:   sha256
> parm:           vt6420_hotplug:Enable hot-plug support for VT6420 
> (0=Don't support, 1=support) (int)

good...



>
> So I then load the module (notice it does indeed appear to be finding 
> the kmod module):
>
> [anaconda root at unknown001a6443e48f 3.10.0-1160.el7.x86_64]# modprobe 
> -v sata_via
> insmod /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz
>
... seems fine...


> But to my surprise, the disk speed test is behaving like I'm still 
> using the old module!
>
> [anaconda root at unknown001a6443e48f 3.10.0-1160.el7.x86_64]# hdparm -Tt 
> /dev/sdc
>
> /dev/sdc:
>  Timing cached reads:     2 MB in  6.39 seconds = 320.27 kB/sec
>  Timing buffered disk reads:   4 MB in  3.09 seconds =   1.30 MB/sec
>
ouch !


> I'm so confused. I swear that it works great when installed by the RPM 
> in the installed OS. Am I maybe overlooking something here?

I have a strong feeling that the system is not not really using the 
replacement driver. did you look in /var/log/messages for any info 
related to this driver ?

What I would attempt do is to read the %postinstall section of "rpm -q 
--scripts kmod-sata_via"and run manually the depmod and weak-modules 
commands.


wolfy



>
> I do like the idea of just patching the kernel. My only challenge with 
> that is I will ultimately be PXE booting these systems into the 
> installer environment with Foreman and I believe it kind of obfuscates 
> the boot kernel somewhere not easily accessed. Though maybe I can 
> somehow work around that using the `stage2` parameter per Wolfy's 
> suggestion.
>
> I know I am probably going beyond what this community generally 
> supports here and I totally understand if we're hitting that wall by 
> the way. I will continue chipping away at this, but if anyone has any 
> suggestions/tips/tricks, I would love 'em!
>
> Thanks,
> Tristan
>
>
> On Tue, Jul 20, 2021 at 7:18 PM Manuel Wolfshant 
> <wolfy at nobugconsulting.ro <mailto:wolfy at nobugconsulting.ro>> wrote:
>
>     On 7/21/21 1:58 AM, Phil Perry wrote:
>     > Hi Tristan,
>     >
>     > That's great news, problem half solved!
>     >
>     > Gmail decided to reject my off list email to you as it didn't
>     like the
>     > binary attachments, hence you never received it.
>     >
>     > We have published the script we use to make our ISO images here:
>     >
>     > https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh
>     <https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh>
>     >
>     > Just place the RPM and SRPM in the same directory, and run the
>     script:
>     >
>     > ./mkdd.sh kmod-foo-version-release.el7.elrepo.x86_64.rpm
>     >
>     > which will create the ISO image for you, which you can then dd to a
>     > usb drive.
>     >
>     > Regarding the installation, I've only ever used the `inst.dd`
>     method
>     > when installing a driver for unsupported hardware. I think the
>     issue
>     > here is that the hardware *is* supported by the (buggy) kernel
>     driver.
>     > When the kmod driver is _replacing_ (updating) an existing kernel
>     > driver, we use an /etc/depmod.d/kmod-sata_via.conf file to tell
>     depmod
>     > to override the in-kernel driver with our updated kmod driver. I
>     > suspect that override process isn't working during the installation
>     > hence the installer is using the existing kernel driver.
>     >
>     > In terms of a solution, if the `inst.dd` method isn't working, I
>     think
>     > you would need to create custom CentOS installation media with a
>     > patched kernel. It's simple enough to patch the kernel source
>     code to
>     > backport the sata_via driver as per our kmod, but I have no idea
>     how
>     > to then go about creating custom installation media with the
>     patched
>     > kernel.
>     >
>
>     One can use the inst.stage2 anaconda parameter to load a different
>     kernel. That's what I used when I was testing a debug kernel
>     provided by
>     RH when I found a bug in an SSD driver.
>
>     https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-anaconda-boot-options
>     <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-anaconda-boot-options>
>
>
>     wolfy
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elrepo.org/pipermail/elrepo/attachments/20210721/d6741791/attachment.html>