Hey Wolfy, I examined the %postinstall section of the package and ran it (just copied it into a script and ran it with `bash -x`):
[anaconda root@unknown001a6443e48f tmp]# bash -x ./post_install.sh + echo 'Working. This may take some time ...' Working. This may take some time ... + '[' -e /boot/System.map-3.10.0-1160.el7.x86_64 ']' + modules=($(find /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via | grep '\.ko\.xz$')) ++ grep '\.ko\.xz$' ++ find /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via + '[' -x /sbin/weak-modules ']' + /sbin/weak-modules --add-modules + printf '%s\n' weak-modules: this tool requires a dracut-enabled kernel + echo Done. Done. Is that normal for it not to be able to find `dracut`? Hi Phil, 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! 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): [ 500.993314] Request for unknown module key 'The ELRepo Project ( http://elrepo.org): ELRepo.org Secure Boot Key: f365ad3481a7b20e3427b61b2a26635b83fe427b' err -11 [ 500.993335] sata_via: loading out-of-tree module taints kernel. [ 500.993598] sata_via: module verification failed: signature and/or required key missing - tainting kernel [ 500.998404] sata_via 0000:00:0f.0: version 2.6 [ 500.998647] sata_via 0000:00:0f.0: routed to hard irq line 10 [ 501.011067] scsi host6: sata_via [ 501.015070] scsi host7: sata_via [ 501.015217] ata5: SATA max UDMA/133 cmd 0xfc00 ctl 0xf800 bmdma 0xec00 irq 21 [ 501.015224] ata6: SATA max UDMA/133 cmd 0xf400 ctl 0xf000 bmdma 0xec08 irq 21 [ 501.383973] irq 21: nobody cared (try booting with the "irqpoll" option) [ 501.383986] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE ------------ 3.10.0-1160.el7.x86_64 #1 [ 501.383989] Hardware name: IBM CORPORATION 4800743/P4M900/VT8251/DME1737, BIOS 85KT210 10/15/2008 [ 501.383991] Call Trace: [ 61.599582] intel_powerclamp: No package C-state available [ 501.383996] <IRQ> [ 501.384008] [<ffffffff9ab81340>] dump_stack+0x19/0x1b [ 501.384014] [<ffffffff9a552562>] __report_bad_irq+0x32/0xd0 [ 501.384018] [<ffffffff9a552982>] note_interrupt+0x132/0x1f0 [ 501.384022] [<ffffffff9a550025>] handle_irq_event_percpu+0x55/0x80 [ 501.384026] [<ffffffff9a55008c>] handle_irq_event+0x3c/0x60 [ 501.384029] [<ffffffff9a55372d>] handle_fasteoi_irq+0x5d/0x110 [ 501.384034] [<ffffffff9a42f5f4>] handle_irq+0xe4/0x1a0 [ 501.384039] [<ffffffff9a510e4c>] ? tick_check_idle+0x8c/0xd0 [ 501.384044] [<ffffffff9ab9892d>] do_IRQ+0x4d/0xf0 [ 501.384048] [<ffffffff9ab8a36a>] common_interrupt+0x16a/0x16a [ 501.384050] <EOI> [<ffffffff9ab89000>] ? __cpuidle_text_start+0x8/0x8 [ 501.384056] [<ffffffff9ab8924b>] ? native_safe_halt+0xb/0x20 [ 501.384059] [<ffffffff9ab8901e>] default_idle+0x1e/0xc0 [ 501.384063] [<ffffffff9a437ca0>] arch_cpu_idle+0x20/0xc0 [ 501.384068] [<ffffffff9a5011ea>] cpu_startup_entry+0x14a/0x1e0 [ 501.384072] [<ffffffff9ab6f9c7>] rest_init+0x77/0x80 [ 501.384077] [<ffffffff9b18b1cf>] start_kernel+0x44b/0x46c [ 501.384081] [<ffffffff9b18ab84>] ? repair_env_string+0x5c/0x5c [ 501.384084] [<ffffffff9b18a120>] ? early_idt_handler_array+0x120/0x120 [ 501.384087] [<ffffffff9b18a738>] x86_64_start_reservations+0x24/0x26 [ 501.384089] [<ffffffff9b18a88e>] x86_64_start_kernel+0x154/0x177 [ 501.384093] [<ffffffff9a4000d5>] start_cpu+0x5/0x14 [ 501.384095] handlers: [ 501.384101] [<ffffffff9a90ee30>] usb_hcd_irq [ 501.384133] [<ffffffffc05e12c0>] ata_bmdma_interrupt [libata] [ 501.384136] Disabling IRQ #21 [ 503.678067] ata5.00: SATA link up 3.0 Gbps (SStatus 23 SControl 300) [ 503.678084] ata5.01: SATA link down (SStatus 11 SControl 300) [ 503.788052] ata5.00: ATA-8: WD1602ABYS-23B7A0 39M4507 42C0462IBM, 02.03B04, max UDMA/133 [ 503.788058] ata5.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 0/32) [ 503.888053] ata5.00: configured for UDMA/133 [ 503.888240] scsi 6:0:0:0: Direct-Access ATA WD1602ABYS-23B7A 3B04 PQ: 0 ANSI: 5 [ 503.891445] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149 GiB) [ 503.891529] sd 6:0:0:0: [sdc] Write Protect is off [ 503.891534] sd 6:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 503.891574] sd 6:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 503.892606] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 503.988118] sdc: sdc1 sdc2 [ 503.988726] sd 6:0:0:0: [sdc] Attached SCSI disk [ 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 [ 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 [ 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 [ 508.321816] ata6.00: SATA link down (SStatus 11 SControl 300) [ 508.321833] ata6.01: SATA link down (SStatus 11 SControl 300) [ 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 [ 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 [ 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 [ 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 [ 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 So it seems to be loading it? Sadly however, my disk test results are the same: [anaconda root@unknown001a6443e48f 3.10.0-1160.el7.x86_64]# hdparm -Tt /dev/sdc /dev/sdc: Timing cached reads: 256 MB in 2.00 seconds = 127.89 MB/sec Timing buffered disk reads: 4 MB in 3.09 seconds = 1.30 MB/sec I'm definitely scratching my head here.. I'm not sure what to even try at this point. Thanks again folks. On Wed, Jul 21, 2021 at 4:06 PM Phil Perry <p...@elrepo.org> wrote: > 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@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 > > > > 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 > > > _______________________________________________ > elrepo mailing list > elrepo@lists.elrepo.org > http://lists.elrepo.org/mailman/listinfo/elrepo >
_______________________________________________ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
