<div dir="ltr">
<div>Hey Wolfy,</div><div><br></div><div>I examined the %postinstall section of the package and ran it (just copied it into a script and ran it with `bash -x`):</div><div><br></div><div>[anaconda root@unknown001a6443e48f tmp]# bash -x ./post_install.sh<br>+ echo 'Working. This may take some time ...'<br>Working. This may take some time ...<br>+ '[' -e /boot/System.map-3.10.0-1160.el7.x86_64 ']'<br>+ modules=($(find /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via | grep '\.ko\.xz$'))<br>++ grep '\.ko\.xz$'<br>++ find /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via<br>+ '[' -x /sbin/weak-modules ']'<br>+ /sbin/weak-modules --add-modules<br>+ printf '%s\n'<br>weak-modules: this tool requires a dracut-enabled kernel<br>+ echo Done.<br>Done.<br></div><div><br></div><div>Is that normal for it not to be able to find `dracut`? <br></div><div><br></div><div><br></div><div>Hi Phil,</div><div><br></div><div>I followed your instructions for creating the DUD and they worked great, thank you! Unfortunately it didn't change any of my results, but at least I now know how to do it and I can cross that off the list of possible issues!</div><div><br></div><div>So I went through the manual process of distributing the kmod RPM files to the installation media. Here is what was logged in the kernel ring buffer as soon as I loaded the module (note the "ELRepo.org Secure Boot Key" message Phil had mentioned):</div><div><br></div><div>[ 500.993314] Request for unknown module key 'The ELRepo Project (<a href="http://elrepo.org">http://elrepo.org</a>): ELRepo.org Secure Boot Key: f365ad3481a7b20e3427b61b2a26635b83fe427b' err -11<br>[ 500.993335] sata_via: loading out-of-tree module taints kernel.<br>[ 500.993598] sata_via: module verification failed: signature and/or required key missing - tainting kernel<br>[ 500.998404] sata_via 0000:00:0f.0: version 2.6<br>[ 500.998647] sata_via 0000:00:0f.0: routed to hard irq line 10<br>[ 501.011067] scsi host6: sata_via<br>[ 501.015070] scsi host7: sata_via<br>[ 501.015217] ata5: SATA max UDMA/133 cmd 0xfc00 ctl 0xf800 bmdma 0xec00 irq 21<br>[ 501.015224] ata6: SATA max UDMA/133 cmd 0xf400 ctl 0xf000 bmdma 0xec08 irq 21<br>[ 501.383973] irq 21: nobody cared (try booting with the "irqpoll" option)<br>[ 501.383986] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE ------------ 3.10.0-1160.el7.x86_64 #1<br>[ 501.383989] Hardware name: IBM CORPORATION 4800743/P4M900/VT8251/DME1737, BIOS 85KT210 10/15/2008<br>[ 501.383991] Call Trace:<br>[ 61.599582] intel_powerclamp: No package C-state available<br>[ 501.383996] <IRQ><br>[ 501.384008] [<ffffffff9ab81340>] dump_stack+0x19/0x1b<br>[ 501.384014] [<ffffffff9a552562>] __report_bad_irq+0x32/0xd0<br>[ 501.384018] [<ffffffff9a552982>] note_interrupt+0x132/0x1f0<br>[ 501.384022] [<ffffffff9a550025>] handle_irq_event_percpu+0x55/0x80<br>[ 501.384026] [<ffffffff9a55008c>] handle_irq_event+0x3c/0x60<br>[ 501.384029] [<ffffffff9a55372d>] handle_fasteoi_irq+0x5d/0x110<br>[ 501.384034] [<ffffffff9a42f5f4>] handle_irq+0xe4/0x1a0<br>[ 501.384039] [<ffffffff9a510e4c>] ? tick_check_idle+0x8c/0xd0<br>[ 501.384044] [<ffffffff9ab9892d>] do_IRQ+0x4d/0xf0<br>[ 501.384048] [<ffffffff9ab8a36a>] common_interrupt+0x16a/0x16a<br>[ 501.384050] <EOI> [<ffffffff9ab89000>] ? __cpuidle_text_start+0x8/0x8<br>[ 501.384056] [<ffffffff9ab8924b>] ? native_safe_halt+0xb/0x20<br>[ 501.384059] [<ffffffff9ab8901e>] default_idle+0x1e/0xc0<br>[ 501.384063] [<ffffffff9a437ca0>] arch_cpu_idle+0x20/0xc0<br>[ 501.384068] [<ffffffff9a5011ea>] cpu_startup_entry+0x14a/0x1e0<br>[ 501.384072] [<ffffffff9ab6f9c7>] rest_init+0x77/0x80<br>[ 501.384077] [<ffffffff9b18b1cf>] start_kernel+0x44b/0x46c<br>[ 501.384081] [<ffffffff9b18ab84>] ? repair_env_string+0x5c/0x5c<br>[ 501.384084] [<ffffffff9b18a120>] ? early_idt_handler_array+0x120/0x120<br>[ 501.384087] [<ffffffff9b18a738>] x86_64_start_reservations+0x24/0x26<br>[ 501.384089] [<ffffffff9b18a88e>] x86_64_start_kernel+0x154/0x177<br>[ 501.384093] [<ffffffff9a4000d5>] start_cpu+0x5/0x14<br>[ 501.384095] handlers:<br>[ 501.384101] [<ffffffff9a90ee30>] usb_hcd_irq<br>[ 501.384133] [<ffffffffc05e12c0>] ata_bmdma_interrupt [libata]<br>[ 501.384136] Disabling IRQ #21<br>[ 503.678067] ata5.00: SATA link up 3.0 Gbps (SStatus 23 SControl 300)<br>[ 503.678084] ata5.01: SATA link down (SStatus 11 SControl 300)<br>[ 503.788052] ata5.00: ATA-8: WD1602ABYS-23B7A0 39M4507 42C0462IBM, 02.03B04, max UDMA/133<br>[ 503.788058] ata5.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 0/32)<br>[ 503.888053] ata5.00: configured for UDMA/133<br>[ 503.888240] scsi 6:0:0:0: Direct-Access ATA WD1602ABYS-23B7A 3B04 PQ: 0 ANSI: 5<br>[ 503.891445] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149 GiB)<br>[ 503.891529] sd 6:0:0:0: [sdc] Write Protect is off<br>[ 503.891534] sd 6:0:0:0: [sdc] Mode Sense: 00 3a 00 00<br>[ 503.891574] sd 6:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA<br>[ 503.892606] sd 6:0:0:0: Attached scsi generic sg2 type 0<br>[ 503.988118] sdc: sdc1 sdc2<br>[ 503.988726] sd 6:0:0:0: [sdc] Attached SCSI disk<br>[ 508.230795] type=1400 audit(1626900565.870:36): avc: denied { write } for pid=1587 comm="in:imjournal" name="/" dev="dm-0" ino=2 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=1<br>[ 508.230812] type=1400 audit(1626900565.870:37): avc: denied { add_name } for pid=1587 comm="in:imjournal" name="imjournal.state.tmp" scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=1<br>[ 508.230991] type=1400 audit(1626900565.870:38): avc: denied { remove_name } for pid=1587 comm="in:imjournal" name="imjournal.state.tmp" dev="dm-0" ino=658 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=1<br>[ 508.321816] ata6.00: SATA link down (SStatus 11 SControl 300)<br>[ 508.321833] ata6.01: SATA link down (SStatus 11 SControl 300)<br>[ 527.203507] type=1400 audit(1626900584.843:39): avc: denied { create } for pid=1587 comm="in:imjournal" name="imjournal.state.tmp" scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=1<br>[ 527.203709] type=1400 audit(1626900584.843:40): avc: denied { write open } for pid=1587 comm="in:imjournal" path="/imjournal.state.tmp" dev="dm-0" ino=659 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=1<br>[ 527.203745] type=1400 audit(1626900584.843:41): avc: denied { getattr } for pid=1587 comm="in:imjournal" path="/imjournal.state.tmp" dev="dm-0" ino=659 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=1<br>[ 527.203812] type=1400 audit(1626900584.843:42): avc: denied { rename } for pid=1587 comm="in:imjournal" name="imjournal.state.tmp" dev="dm-0" ino=659 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=1<br>[ 527.203823] type=1400 audit(1626900584.843:43): avc: denied { unlink } for pid=1587 comm="in:imjournal" name="imjournal.state" dev="dm-0" ino=658 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=1</div><div><br></div><div>So it seems to be loading it? Sadly however, my disk test results are the same:</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: 256 MB in 2.00 seconds = 127.89 MB/sec<br> Timing buffered disk reads: 4 MB in 3.09 seconds = 1.30 MB/sec<br></div><div><br></div><div>I'm definitely scratching my head here.. I'm not sure what to even try at this point.</div><div><br></div><div>Thanks again folks.<br></div>
</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 21, 2021 at 4:06 PM Phil Perry <<a href="mailto:phil@elrepo.org">phil@elrepo.org</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 21/07/2021 18:53, Manuel Wolfshant wrote:<br>
> On 7/21/21 8:16 PM, Tristan Evans wrote:<br>
>> Thanks so much everyone for not only creating the kmod that fixes my <br>
>> issue, but also for the suggestions on handing it during installation.<br>
>><br>
>> Phil, that makes a lot of sense regarding using `inst.dd` and the <br>
>> conflicting modules. I do wonder though.. These installations are to <br>
>> be automated using a kickstart script, so I wonder if in the "pre" <br>
>> section (before any storage settings are applied and installation <br>
>> begins) it can do some finagling to unload the intree module and <br>
>> replace it with the kmod.. Not sure if that is better/worse than just <br>
>> using a custom kernel image, but it got me thinking.<br>
> <br>
> There is also an inst.blacklist parameter for anaconda. I do not know <br>
> though if it would blacklist only the module provided by the stock <br>
> kernel or it would also affect the kmod.<br>
> <br>
> As of fiddling with the module.. this should not be needed. If the DUD <br>
> is correctly created, the kmod package is used during install time. The <br>
> PC I am typing from has an r8125 chip ( actually two but this does not <br>
> matter :) ) which is not supported out of the box so normally there <br>
> would be no network access during install.<br>
> <br>
> However I wanted to do a network based install ( in order to use the <br>
> updates repo at install time, as well as set NTP ) on it so I downloaded <br>
> the kmod from elrepo, created a DUD on which I also copied my kickstart <br>
> and everything worked exactly as intended: network was activated and <br>
> everything worked as advertised.<br>
> <br>
> The only doubt I have is that unlike for you, in my case there was no <br>
> default kernel module to replace but just a new one to add.<br>
> <br>
> <br>
>><br>
>> To do some testing, I booted into the CentOS installer media and <br>
>> started trying some things:<br>
>><br>
>> Extracted the RPM:<br>
>><br>
>> 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<br>
>><br>
>> I copied the files to their specific locations:<br>
>><br>
>> cp ./etc/depmod.d/kmod-sata_via.conf /etc/depmod.d/<br>
>> cp ./lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz <br>
>> /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/<br>
>><br>
>> Note that I made a quick update to "kmod-sata_via.conf". It seems it <br>
>> was configured to look into "weak-updates/sata_via", but the RPM would <br>
>> install the module to "extra/sata_via".<br>
> <br>
> For the kmods it ships. ElRepo takes advantage of the stable ABI of the <br>
> kernels provided by RedHat. The modules are placed below /extra but via <br>
> the weak-update mechanism provided by RH ( basically invoked by the rpm <br>
> postinstall scripts as "/sbin/weak-modules --add-modules"), symlinks <br>
> are created which ensure that the module is used by all the kernel packages.<br>
> <br>
> <br>
>><br>
>> I then ran `depmod -a` and now it seems the OS recognizes the kmod <br>
>> sata_via driver:<br>
>><br>
>> [anaconda root@unknown001a6443e48f sata_via]# modinfo sata_via<br>
>> filename: <br>
>> /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" rel="noreferrer" target="_blank">http://elrepo.org</a> <br>
>> <<a href="http://elrepo.org" rel="noreferrer" target="_blank">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 <br>
>> (0=Don't support, 1=support) (int)<br>
> <br>
> good...<br>
> <br>
> <br>
> <br>
>><br>
>> So I then load the module (notice it does indeed appear to be finding <br>
>> the kmod module):<br>
>><br>
>> [anaconda root@unknown001a6443e48f 3.10.0-1160.el7.x86_64]# modprobe <br>
>> -v sata_via<br>
>> insmod /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz<br>
>><br>
> ... seems fine...<br>
> <br>
> <br>
>> But to my surprise, the disk speed test is behaving like I'm still <br>
>> using the old module!<br>
>><br>
>> [anaconda root@unknown001a6443e48f 3.10.0-1160.el7.x86_64]# hdparm -Tt <br>
>> /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<br>
>><br>
> ouch !<br>
> <br>
> <br>
>> I'm so confused. I swear that it works great when installed by the RPM <br>
>> in the installed OS. Am I maybe overlooking something here?<br>
> <br>
> I have a strong feeling that the system is not not really using the <br>
> replacement driver. did you look in /var/log/messages for any info <br>
> related to this driver ?<br>
> <br>
> What I would attempt do is to read the %postinstall section of "rpm -q <br>
> --scripts kmod-sata_via"and run manually the depmod and weak-modules <br>
> commands.<br>
> <br>
> <br>
> wolfy<br>
> <br>
<br>
A very simple way to see if the elrepo driver is loaded in <br>
/var/log/messages is to look for the following message which the kernel <br>
produces when loading all elrepo drivers, assuming you are not using <br>
SecureBoot. All our drivers are signed with our SecureBoot key, and when <br>
the driver loads, and you've not imported our SB public key, you'll see <br>
the following warning message - perfectly normal, just the kernel <br>
telling you it couldn't verify the key.<br>
<br>
Jul 21 20:55:57 quad kernel: Request for unknown module key 'The ELRepo <br>
Project (<a href="http://elrepo.org" rel="noreferrer" target="_blank">http://elrepo.org</a>): ELRepo.org Secure Boot Key: <br>
f365ad3481a7b20e3427b61b2a26635b83fe427b' err -11<br>
<br>
So when the driver is loaded, if it's the elrepo driver, expect to see <br>
the above in messages right next to where the driver loads.<br>
<br>
Phil<br>
<br>
<br>
_______________________________________________<br>
elrepo mailing list<br>
<a href="mailto:elrepo@lists.elrepo.org" target="_blank">elrepo@lists.elrepo.org</a><br>
<a href="http://lists.elrepo.org/mailman/listinfo/elrepo" rel="noreferrer" target="_blank">http://lists.elrepo.org/mailman/listinfo/elrepo</a><br>
</blockquote></div>