<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 7/21/21 8:16 PM, Tristan Evans
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGkpgciwiFWYSSTG5Y1x3McwMSgpwNQJDZRCheRY+fkA2-ejFw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Thanks so much everyone for not only creating the
kmod that fixes my issue, but also for the suggestions on
handing it during installation.
<div><br>
</div>
<div>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.<br>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p>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.</p>
<p> 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.</p>
<p>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.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAGkpgciwiFWYSSTG5Y1x3McwMSgpwNQJDZRCheRY+fkA2-ejFw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>To do some testing, I booted into the CentOS installer
media and started trying some things:</div>
<div><br>
</div>
<div>Extracted the RPM:</div>
<div><br>
</div>
<div>rpm2cpio ./kmod-sata_via-2.6-1.el7_9.elrepo.x86_64.rpm |
cpio -idmv<br>
./etc/depmod.d/kmod-sata_via.conf<br>
./lib/modules/3.10.0-1160.el7.x86_64<br>
./lib/modules/3.10.0-1160.el7.x86_64/extra<br>
./lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via<br>
./lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz<br>
./usr/share/doc/kmod-sata_via-2.6<br>
./usr/share/doc/kmod-sata_via-2.6/GPL-v2.0.txt</div>
<div><br>
</div>
<div>I copied the files to their specific locations:</div>
<div><br>
</div>
<div>cp ./etc/depmod.d/kmod-sata_via.conf /etc/depmod.d/</div>
<div>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/</div>
<div><br>
</div>
<div>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".</div>
</div>
</blockquote>
<p>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.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAGkpgciwiFWYSSTG5Y1x3McwMSgpwNQJDZRCheRY+fkA2-ejFw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>I then ran `depmod -a` and now it seems the OS recognizes
the kmod sata_via driver:</div>
<div><br>
</div>
<div>[anaconda root@unknown001a6443e48f sata_via]# modinfo
sata_via<br>
filename:
/lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz<br>
version: 2.6<br>
license: GPL<br>
description: SCSI low-level driver for VIA SATA controllers<br>
author: Jeff Garzik<br>
retpoline: Y<br>
rhelversion: 7.9<br>
srcversion: D02B8C752BDC9941B11FCCB<br>
alias: pci:v00001106d00009000sv*sd*bc*sc*i*<br>
alias: pci:v00001106d00005287sv*sd*bc*sc*i*<br>
alias: pci:v00001106d00007372sv*sd*bc*sc*i*<br>
alias: pci:v00001106d00005372sv*sd*bc*sc*i*<br>
alias: pci:v00001106d00003249sv*sd*bc*sc*i*<br>
alias: pci:v00001106d00003149sv*sd*bc*sc*i*<br>
alias: pci:v00001106d00000591sv*sd*bc*sc*i*<br>
alias: pci:v00001106d00005337sv*sd*bc*sc*i*<br>
depends: libata<br>
vermagic: 3.10.0-1160.el7.x86_64 SMP mod_unload
modversions<br>
signer: The ELRepo Project (<a
href="http://elrepo.org" moz-do-not-send="true">http://elrepo.org</a>):
ELRepo.org Secure Boot Key<br>
sig_key:
F3:65:AD:34:81:A7:B2:0E:34:27:B6:1B:2A:26:63:5B:83:FE:42:7B<br>
sig_hashalgo: sha256<br>
parm: vt6420_hotplug:Enable hot-plug support for
VT6420 (0=Don't support, 1=support) (int)</div>
</div>
</blockquote>
<p>good...</p>
<br>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAGkpgciwiFWYSSTG5Y1x3McwMSgpwNQJDZRCheRY+fkA2-ejFw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>So I then load the module (notice it does indeed appear to
be finding the kmod module):</div>
<div><br>
</div>
<div>[anaconda root@unknown001a6443e48f 3.10.0-1160.el7.x86_64]#
modprobe -v sata_via<br>
insmod
/lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz<br>
</div>
<div><br>
</div>
</div>
</blockquote>
<p>... seems fine...</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAGkpgciwiFWYSSTG5Y1x3McwMSgpwNQJDZRCheRY+fkA2-ejFw@mail.gmail.com">
<div dir="ltr">
<div>But to my surprise, the disk speed test is behaving like
I'm still using the old module!</div>
<div><br>
</div>
<div>[anaconda root@unknown001a6443e48f 3.10.0-1160.el7.x86_64]#
hdparm -Tt /dev/sdc<br>
<br>
/dev/sdc:<br>
Timing cached reads: 2 MB in 6.39 seconds = 320.27
kB/sec<br>
Timing buffered disk reads: 4 MB in 3.09 seconds = 1.30
MB/sec</div>
<div><br>
</div>
</div>
</blockquote>
<p>ouch !</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAGkpgciwiFWYSSTG5Y1x3McwMSgpwNQJDZRCheRY+fkA2-ejFw@mail.gmail.com">
<div dir="ltr">
<div>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?</div>
</div>
</blockquote>
<p>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 ?<br>
</p>
<p>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.</p>
<p><br>
</p>
<p>wolfy</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAGkpgciwiFWYSSTG5Y1x3McwMSgpwNQJDZRCheRY+fkA2-ejFw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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!</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Tristan<br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jul 20, 2021 at 7:18
PM Manuel Wolfshant <<a
href="mailto:wolfy@nobugconsulting.ro" target="_blank"
moz-do-not-send="true">wolfy@nobugconsulting.ro</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
7/21/21 1:58 AM, Phil Perry wrote:<br>
> Hi Tristan,<br>
><br>
> That's great news, problem half solved!<br>
><br>
> Gmail decided to reject my off list email to you as it
didn't like the <br>
> binary attachments, hence you never received it.<br>
><br>
> We have published the script we use to make our ISO
images here:<br>
><br>
> <a
href="https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh</a><br>
><br>
> Just place the RPM and SRPM in the same directory, and
run the script:<br>
><br>
> ./mkdd.sh kmod-foo-version-release.el7.elrepo.x86_64.rpm<br>
><br>
> which will create the ISO image for you, which you can
then dd to a <br>
> usb drive.<br>
><br>
> Regarding the installation, I've only ever used the
`inst.dd` method <br>
> when installing a driver for unsupported hardware. I
think the issue <br>
> here is that the hardware *is* supported by the (buggy)
kernel driver. <br>
> When the kmod driver is _replacing_ (updating) an
existing kernel <br>
> driver, we use an /etc/depmod.d/kmod-sata_via.conf file
to tell depmod <br>
> to override the in-kernel driver with our updated kmod
driver. I <br>
> suspect that override process isn't working during the
installation <br>
> hence the installer is using the existing kernel driver.<br>
><br>
> In terms of a solution, if the `inst.dd` method isn't
working, I think <br>
> you would need to create custom CentOS installation media
with a <br>
> patched kernel. It's simple enough to patch the kernel
source code to <br>
> backport the sata_via driver as per our kmod, but I have
no idea how <br>
> to then go about creating custom installation media with
the patched <br>
> kernel.<br>
><br>
<br>
One can use the inst.stage2 anaconda parameter to load a
different <br>
kernel. That's what I used when I was testing a debug kernel
provided by <br>
RH when I found a bug in an SSD driver.<br>
<br>
<a
href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-anaconda-boot-options"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-anaconda-boot-options</a><br>
<br>
<br>
wolfy<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>