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

Jody McIvor JMcIvor at bclc.com
Tue Mar 10 16:06:08 UTC 2020


Thanks for the responses Alex & Brian!

Alex's response was the resolution. I added a %post section and moved the depmod command into there. Install went great and we are now into QA. Thanks a ton! This was my first time needing to build an RPM so been soaking up as much knowledge as possible and this was a learning experience. I'll definitely be checking out that link, Brian, thanks!

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 10, 2020 9:00 AM
To: spacewalk-list at redhat.com
Subject: Spacewalk-list Digest, Vol 142, Issue 12

Send Spacewalk-list mailing list submissions to
spacewalk-list at redhat.com

To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/spacewalk-list
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: Deploy *.ko driver via spacewalk (Brian Long)


----------------------------------------------------------------------

Message: 1
Date: Mon, 9 Mar 2020 17:30:25 -0400
From: Brian Long <briandlong at gmail.com>
To: spacewalk-list at redhat.com
Subject: Re: [Spacewalk-list] Deploy *.ko driver via spacewalk
Message-ID:
<CANzVr1Y7bnY3sqaYFdiVn8Amw7-1AAZaR=Mxdq5q8WGjXi4PhA at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

I've done this many years ago and quickly found a reference you might enjoy.  Take a peek at this Red Hat Summit 2009 presentation and look at page 43 specifically:
https://docs.huihoo.com/redhat/2009/pwaterman_130_rpm-ifying.pdf

Basically you want to use %triggerin on the kernel RPM so each time a new kernel is installed, you copy your kernel mod from wherever your RPM stores files into the kernel /lib/modules tree and run the appropriate depmod command for each kernel that is installed.  If I remember correctly, you should be installing your custom driver in the proper subdirectory that is used for extra kernel modules not part of the kernel RPM itself (i.e.
/lib/modules/3.10.0-1062.9.1.el7.x86_64/extra).

/Brian/

On Mon, Mar 9, 2020 at 4:41 PM Jody McIvor <JMcIvor at bclc.com> wrote:
>
> 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://www.redhat.com/mailman/listinfo/spacewalk-list
> 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://www.redhat.com/mailman/listinfo/spacewalk-list
> >
> >
>
> --
> Steven M. Miano
> (727)244-9990
> http://stevenmiano.com
> 1811 C2CB 8219 4F52
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> <https://www.redhat.com/archives/spacewalk-list/attachments/20200304/3
> 6824d1c/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> 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://www.redhat.com/mailman/listinfo/spacewalk-list
>




------------------------------

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

End of Spacewalk-list Digest, Vol 142, Issue 12
***********************************************

________________________________
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.





More information about the Spacewalk-list mailing list