Yes we have used it, yes we have gone through the same pains and the
ridiculousness that is jumping through a lot of hoops for very little
(real) reason that I can see.
This all started many many years ago for me when I wrote essentially a
web scrapper for a Nagios check to make sure the warra
[EXTERNAL EMAIL]
The short version:
You need to look into whatever is causing http connections to take so
long to the Dell linux yum repository and from the looks of it every
other repo on there, but a really fast fix, is to have your mirror
script return https instead of http, which is probabl
Dell team, are all of the packages no signed with the new GPG key? Or
are we going to have to hold onto the old key as well as the new one?
-Erinn
On 06/27/2018 09:44 AM, John Hodrien wrote:
> On Wed, 27 Jun 2018, Paul Raines wrote:
>
>> Definitely should have used https instead of http at least
ry.
>
>
> Failing package is: srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64
> GPG Keys are configured as: http://linux.dell.com/repo/hardware/dsu/public.key
> -
>
> FWIW, the repository configuration didn't change on that host, and it has
>
Same here just to confirm your findings.
On 06/21/2018 01:33 PM, Kilian Cavalotti wrote:
> Hi,
>
> Did the RPM repository GPG keys change somehow?
>
> Trying to update srvadmin packages today leads to the following error:
>
> -
> Retrieving key from http://linux.dell.com/r
I ran into a problem with the latest release of OM 6.3, I noticed that
the firmware packages for the DRACs were not being updated on systems
that already had the package installed, but were being installed with a
newer version of the payload on fresh installs.
Let me try and break that down into
Just wanted to throw these instructions out there for anyone who is
looking to configure a mirror of the dell linux repositories. I just
went through this process yesterday, I didn't really find anything that
covered all of this, or anything much at all except the location for
rsyncing. There
Looks like the firmware repo is falling out of date. This happened
before when it was unofficial. Maybe now that it is official something
can be done?
Anyway two examples:
Drac5 firmware:
repo version 1.50
Support.dell version 1.51
sas backplane firmware:
repo version 1.05
support.dell version
Matt,
Thanks for the info. I will run through tech support, if I come up with
anything good I will post it to the list.
-Erinn
-Original Message-
From: Matt Domsch [mailto:matt_dom...@dell.com]
Sent: Wednesday, January 20, 2010 9:06 PM
To: Erinn Looney-Triggs
Cc: linux-powere
I run an automatic provisioning and installation service via cobbler for
our RedHat installs. Now as my laziness increases, I am trying to find a
way to auto-configure a few extra things. I would like for the script to
detect whether it is on a PowerEdge system and if so link in the Dell
Reposi
I have run into several bugs with the openmanage automatic firmware
installation tools. Specifically I can't get the BMC to install on
anything but 2950 systems. There are sporadic failures on other systems
as well, unable to install PERC firmwares, BIOSs etc. I can't find a
place to report the
On 12/23/2009 11:07 AM, jeffrey_l_mend...@dell.com wrote:
>> It appears that doing a yum install
>> dell_ft_install pulled in two extra packages one of which appears to
>> fix
>> the issue.
>>
>> The package is:
>> srvadmin-storelib-sysfs
>>
>> The other package that is pulled in is:
>> srvadmin-st
My apologies if this has already been posted up. I too ran into the "No
controllers found" issue after updating some of my systems to openmanage
6.2, I noticed however that after installing the firmware update
packages the issue went away. It appears that doing a yum install
dell_ft_install pul
13 matches
Mail list logo
