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