[elrepo] kmod-sata_via module for CentOS7

Wed Jul 21 13:16:37 EDT 2021

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.

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".

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): 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)

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

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

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 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>
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
> >
> > 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
>
>
> wolfy
>
> _______________________________________________
> elrepo mailing list
> elrepo at lists.elrepo.org
> http://lists.elrepo.org/mailman/listinfo/elrepo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elrepo.org/pipermail/elrepo/attachments/20210721/346be673/attachment.html>