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@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@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@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
<wo...@nobugconsulting.ro <mailto:wo...@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
_______________________________________________
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
