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 <jmci...@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
>
>
> jmci...@bclc.com
> BCLC.com
>
>
>
>
> -----Original Message-----
> From: spacewalk-list-boun...@redhat.com <spacewalk-list-boun...@redhat.com>
> On Behalf Of spacewalk-list-requ...@redhat.com
> Sent: March 5, 2020 9:00 AM
> To: spacewalk-list@redhat.com
> Subject: Spacewalk-list Digest, Vol 142, Issue 9
>
> Send Spacewalk-list mailing list submissions to
> spacewalk-list@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-requ...@redhat.com
>
> You can reach the person managing the list at
> spacewalk-list-ow...@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 <mian...@gmail.com>
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] metadata_expire and Spacewalk updates
> Message-ID:
> <cackp6kkszqum5fw9xpekxznz_v+mp-7bynrwstnt2-fjmz9...@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 <briandl...@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 <briandl...@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@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/36824d1c/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list@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@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
_______________________________________________
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
