[Spacewalk-list] Deploy *.ko driver via spacewalk

Mon Mar 9 21:03:45 UTC 2020

Your depmod is only being called during rpmbuild. Not when you install the rpm. You need to do it in a %post section.

Sent from my iPhone

> On 9 Mar 2020, at 20:41, Jody McIvor <JMcIvor at bclc.com> wrote:
> 
> Caution:  EXTERNAL email
> 
> Hi Everyone,
> 
> Hope you all had a good weekend!
> 
> I'm trying to deploy a custom driver to a few thousand Centos 7 devices. Naturally I first tried packaging it into an RPM, but the %INSTALL% portion of the SPEC file runs all commands fine, CPing my *.ko, creating and removing folders, etc, all just fine. The weird part is it juts ignores my depmod call within this script. The RPM installs fine, but since it skips the depmod, the driver only works if I manually log onto the device and run depmod manually.
> 
> Researching the issue, I only find a TON of other's having similar issues, and some hints that *.ko should not be deployed via RPM, as a good practice.
> 
> If that is the case, my question naturally becomes, How should I be deploying this driver via spacewalk if not via RPM?
> 
> Any suggestions?
> 
> I've included my SPEC, below (With comments):
> =========================================
> Name:           RealtekWifiDriver
> Version:        1.06
> Release:        1%{?dist}
> Summary:        Wifi Driver for USB WIFI Dongle
> License:            None
> 
> %description
> Wifi Driver for USB WIFI Dongle
> 
> %install
> #This command succeeds
> mkdir -p %{buildroot}/usr/lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek/driver
> #This command succeeds
> cp ../SOURCES/driver.ko %{buildroot}/usr/lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek/driver/driver.ko
> #This command succeeds
> mkdir -p %{buildroot}/etc/udev/rules.d
> #This command succeeds
> cp ../SOURCES/93-driver.ko.rules %{buildroot}/etc/udev/rules.d/93-driver.ko.rules
> #This command doesn't seem to take effect, although running manually after RPM install, works just fine. I've also tried /usr/sbin/depmod and /sbin/depmod as well as adding the -a flag and specifying version instead of using uname -r. No idea where these commands are logged, so not sure what output is.
> depmod $(uname -r)
> 
> 
> %files
> /etc/udev/rules.d/93-driver.ko.rules
> /usr/lib/modules/3.10.0-514.6.1.el7.x86_64/kernel/drivers/net/wireless/realtek/driver/driver.ko
> =========================================
> 
> Jody McIvor
> Sr. Systems Administrator, Integration
> Les Services D'intégration
> [TEL] (250) 852-5202
> 
> 
> jmcivor at bclc.com
> BCLC.com
> 
> 
> 
> 
> -----Original Message-----
> From: spacewalk-list-bounces at redhat.com <spacewalk-list-bounces at redhat.com> On Behalf Of spacewalk-list-request at redhat.com
> Sent: March 5, 2020 9:00 AM
> To: spacewalk-list at redhat.com
> Subject: Spacewalk-list Digest, Vol 142, Issue 9
> 
> Send Spacewalk-list mailing list submissions to
> spacewalk-list at redhat.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_spacewalk-2Dlist&d=DwIF-g&c=O3LcjD-V2Iepl5V0N1424A&r=MW8D_KLIjbkgPV4I3ExMPW-6rQA8xlUsAXjzeSmCE80&m=LLU-iCdvHk--2KFUGKPTsimkKnH8u_S2Og0MLoY-yHc&s=O8webpwFvv7to50hO6Rqhlemjy0362c-U9mIjnKFF5Q&e= 
> or, via email, send a message with subject or body 'help' to
> spacewalk-list-request at redhat.com
> 
> You can reach the person managing the list at
> spacewalk-list-owner at redhat.com
> 
> When replying, please edit your Subject line so it is more specific than "Re: Contents of Spacewalk-list digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: metadata_expire and Spacewalk updates (Steven Miano)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 4 Mar 2020 15:22:25 -0500
> From: Steven Miano <mianosm at gmail.com>
> To: spacewalk-list at redhat.com
> Subject: Re: [Spacewalk-list] metadata_expire and Spacewalk updates
> Message-ID:
> <CACkP6kksZQuM5fw9xpekxzNZ_v+mp-7Bynrwstnt2-fjMZ9dVQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> We're on the opposite side of this lean, and have approximately 22,000 clients that are on very limited circuits (as many as 6,000 clients on a 30mbps link).
> 
> In the past we were running Salt Stack to ensure packages were in place, and checking for a latest version of said packages (Salt Stack will auto expire and refresh the meta data when it does that).
> 
> In order to alleviate some of the pain of having 6,000 machines attempt to download a 20MB metadata file, we're now no longer forcing the latest packages with each highstate, and have opened/releaxed the metadata refreshes out to 96 hours (4 days).
> 
> If you were to want to be so aggressive, I could/can recommend a frequent high state schedule through salt stack demanding the latest packages within certain states.
> 
> Good luck!
> 
>> On Wed, Mar 4, 2020 at 7:40 AM Brian Long <briandlong at gmail.com> wrote:
>> 
>> "I cannot push updates to a channel and then immediately tell a client
>> to update itself and reboot.  Depending on where it is in that
>> metadata_expire window, it won't see the newest changes.   Another way
>> to say this is that I have
>> to update my channels and wait six hours before telling Spacewalk to
>> push the updates out; otherwise a lot of my clients will not get the
>> latest updates.  rhn_check checks in, sees no updates and the task is
>> done."
>> 
>> Has anyone else found a solution to this?  Am I overlooking something
>> really simple I can enable in Spacewalk to force a client metadata
>> update before trying to update?
>> 
>> /Brian/
>> 
>>> On Mon, Feb 24, 2020 at 9:10 AM Brian Long <briandlong at gmail.com> wrote:
>>> 
>>> Dennis, thanks for your response, but I'm not concerned with the
>>> Spacewalk side of the metadata.  I'm interesting in getting my
>>> clients updating their metadata as soon as a Spacewalk channel is updated.
>>> With default configuration, it could take six hours before they see
>>> the channel has been updated since yum's default metadata_expire
>>> setting is six hours.  I'm wondering if other users of Spacewalk are
>>> somehow forcing client-side metadata updates before telling
>>> Spacewalk to update their clients?  Or are people configuring each
>>> of their client yum.conf files to specify a smaller metadata_expire
>>> setting to fix this behavior?
>>> 
>>> When yum-based Linux installs are Internet-connected and trying to
>>> download updates from upstream mirrors like Fedora, CentOS, etc. I
>>> understand metadata_expire being set to six hours out-of-the-box.
>>> The problem is operationalizing Spacewalk, I cannot push updates to
>>> a channel and then immediately tell a client to update itself and
>>> reboot.  Depending on where it is in that metadata_expire window, it
>>> won't see the newest changes.   Another way to say this is that I have
>>> to update my channels and wait six hours before telling Spacewalk to
>>> push the updates out; otherwise a lot of my clients will not get the
>>> latest updates.  rhn_check checks in, sees no updates and the task
>>> is done.  Does that make more sense?
>>> 
>>> /Brian/
>> 
>> 
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_spacewalk-2Dlist&d=DwIF-g&c=O3LcjD-V2Iepl5V0N1424A&r=MW8D_KLIjbkgPV4I3ExMPW-6rQA8xlUsAXjzeSmCE80&m=LLU-iCdvHk--2KFUGKPTsimkKnH8u_S2Og0MLoY-yHc&s=O8webpwFvv7to50hO6Rqhlemjy0362c-U9mIjnKFF5Q&e= 
>> 
>> 
> 
> --
> Steven M. Miano
> (727)244-9990
> https://urldefense.proofpoint.com/v2/url?u=http-3A__stevenmiano.com&d=DwIF-g&c=O3LcjD-V2Iepl5V0N1424A&r=MW8D_KLIjbkgPV4I3ExMPW-6rQA8xlUsAXjzeSmCE80&m=LLU-iCdvHk--2KFUGKPTsimkKnH8u_S2Og0MLoY-yHc&s=1QBXBiA9lEZ5s8zmXNgvUHNy6U9I4iQt6A1pVCz5UjA&e= 
> 1811 C2CB 8219 4F52
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_archives_spacewalk-2Dlist_attachments_20200304_36824d1c_attachment.html&d=DwIF-g&c=O3LcjD-V2Iepl5V0N1424A&r=MW8D_KLIjbkgPV4I3ExMPW-6rQA8xlUsAXjzeSmCE80&m=LLU-iCdvHk--2KFUGKPTsimkKnH8u_S2Og0MLoY-yHc&s=YMNjC7C_aZnch2ipIJ3geUeSTke8o7Nfz05Zy1dAZCg&e= >
> 
> ------------------------------
> 
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_spacewalk-2Dlist&d=DwIF-g&c=O3LcjD-V2Iepl5V0N1424A&r=MW8D_KLIjbkgPV4I3ExMPW-6rQA8xlUsAXjzeSmCE80&m=LLU-iCdvHk--2KFUGKPTsimkKnH8u_S2Og0MLoY-yHc&s=O8webpwFvv7to50hO6Rqhlemjy0362c-U9mIjnKFF5Q&e= 
> 
> End of Spacewalk-list Digest, Vol 142, Issue 9
> **********************************************
> 
> ________________________________
> This email is intended only for the addressee. It may contain confidential or proprietary information that cannot be disclosed without BCLC's permission. If you have received this email in error, please notify the sender immediately and delete the email.
> 
> 
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_spacewalk-2Dlist&d=DwIF-g&c=O3LcjD-V2Iepl5V0N1424A&r=MW8D_KLIjbkgPV4I3ExMPW-6rQA8xlUsAXjzeSmCE80&m=LLU-iCdvHk--2KFUGKPTsimkKnH8u_S2Og0MLoY-yHc&s=O8webpwFvv7to50hO6Rqhlemjy0362c-U9mIjnKFF5Q&e= 
> 