[elrepo] kmod-sata_via module for CentOS7
Tristan Evans
azurepancake at gmail.com
Wed Jul 21 17:00:32 EDT 2021
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 at 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 at 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 <phil at 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 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
>
>
> _______________________________________________
> elrepo mailing list
> elrepo at lists.elrepo.org
> http://lists.elrepo.org/mailman/listinfo/elrepo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elrepo.org/pipermail/elrepo/attachments/20210721/68331f5c/attachment-0001.html>
More information about the elrepo
mailing list