[elrepo] kmod-sata_via module for CentOS7

Wed Jul 21 16:01:42 EDT 2021

On 21/07/2021 18:53, Manuel Wolfshant wrote:
> 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
> 

A very simple way to see if the elrepo driver is loaded in 
/var/log/messages is to look for the following message which the kernel 
produces when loading all elrepo drivers, assuming you are not using 
SecureBoot. All our drivers are signed with our SecureBoot key, and when 
the driver loads, and you've not imported our SB public key, you'll see 
the following warning message - perfectly normal, just the kernel 
telling you it couldn't verify the key.

Jul 21 20:55:57 quad kernel: Request for unknown module key 'The ELRepo 
Project (http://elrepo.org): ELRepo.org Secure Boot Key: 
f365ad3481a7b20e3427b61b2a26635b83fe427b' err -11

So when the driver is loaded, if it's the elrepo driver, expect to see 
the above in messages right next to where the driver loads.

Phil