Re: [Linux-PowerEdge] yum update fails on libsmbios.so.2 dependency error with srvadmin-storage-9.1.0-2757.12163.el7

[Anssi Johansson]

francis picabia kirjoitti 20.4.2018 klo 15.25:


Running Redhat 7.4 and srvadmin packages of version 9.1.0-2757.12173

When updating the system I see a dependency error.


For the record, there is a RH Bugzilla entry for this issue at 
https://bugzilla.redhat.com/show_bug.cgi?id=1570019


Hopefully Red Hat and Dell can cooperate to fix this issue somehow.

___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] PE Update Strategy & Questions

[Rob.Schnitzlein]

The reason we use the phrase "Tech Release" is that it currently does not have 
feature parity with OMEssentials.  Later this year we will reach a 'cutover' 
point where OMEnterprise has caught up, and all new development will be there.  
Bug fixes for OMEssentials will continue as necessary. 

And yes, we are all VERY excited for the move to HTML5! 

Here is a great place to get started - 
http://en.community.dell.com/techcenter/systems-management/w/wiki/12404.openmanage-enterprise

-Original Message-
From: linux-poweredge-bounces-Lists On Behalf Of Tim Mooney
Sent: Friday, April 20, 2018 3:41 PM
To: linux-poweredge-Lists
Subject: Re: [Linux-PowerEdge] PE Update Strategy & Questions

In regard to: Re: [Linux-PowerEdge] PE Update Strategy & Questions,...:

> OpenManage Enterprise  the successor to OpeManage Essentials (both OME 
> for simplicity) is available now. It is supplied as a CentOS based 
> virtual appliance which can run on VMware, Hyper-V or KVM - so yes OME 
> is available for Linux.
>
> If you want more information, let me know and I will provide when I am online.

I certainly would be interested in more information on OM Enterprise.

Everything I've been able to find on dell.com still says "Tech Release", which 
although listed as "fully supported", makes it sound fairly beta-ish.

Just seeing that it uses HTML5 (rather than Silverlight (!)) makes me more 
interested in the product than I ever was in Essentials.

Thanks,

Tim

>  Original message 
> From: Cameron Smith 
> Date: 20/04/2018 19:22 (GMT+00:00)
> To: R S 
> Cc: linux-poweredge-Lists 
> Subject: Re: [Linux-PowerEdge] PE Update Strategy & Questions
>
> You are welcome!
>
> Sadly OME is not Linux ready yet. I have heard rumors that it might be in the 
> works but I wouldn't hold my breath.
>
> If using the .EXEs in the DRAC GUI here are some tips.
>
> Before you start, go to the Lifecycle Controller job queue which is the Job 
> Queue link on the main DRAC page and see if there is anything already in 
> there. If there are any jobs in there that are failed or pending (that you 
> don't want) delete them.
>
> Reboot the DRAC from the main drac page with the Reset link (This does 
> not affect the OS)
>
> Once DRAC is back up which is usually within 90 seconds then do your firmware 
> uploads. You can set these to immediately reboot the server and run or to be 
> queued to run when the server is rebooted by you at a later time manually.
>
> Then go to the Job Queue and monitor their status.
>
> Cameron
>
> On Fri, Apr 20, 2018 at 11:11 AM, R S 
> > wrote:
> Thanks for sharing this. Makes me want to spent time and try out OME.
> I used the 64bit EXEs in iDRAC just recently for the first time wondering how 
> the iDRAC can handle EXEs?!?! :) It worked though.
> Is OME available for GNU/Linux?
>
> On Fri, Apr 20, 2018 at 12:37 PM, Cameron Smith 
> > wrote:
> For localizing the repo you can look into Dell Repo Manager:
>
> https://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driv
> erId=2GY7P
>
> You can customize the repo if you need to hold back a version for anything 
> and it's a great tool. Runs on Linux now!!!
>
> For firmware updates I used to use .BIN files in the OS. I then moved to 
> 64-bit .exe files through DRAC. I now use OME to DRAC for almost everything 
> for managing about 600 servers (11/12/13Gen).
>
> OME has gotten much better. Based on your numbers though I believe you would 
> need to run multiple installs of OME as I "think" it maxes out at close to 
> 2000 devices. It's is also good to batch update smaller groups of devices at 
> a time (20 or so) rather than trying to update 1000 at a time. Just something 
> to think about if you need to end up going this route.
>
> Cameron
>
> On Fri, Apr 20, 2018 at 6:32 AM, Prashant Sun 
> > wrote:
> Thanks RS & Florian for your suggestions.
>
> I intend to use Catalog.xml file as my primary tool to approve updates that 
> are applied by iDRAC or dsu. I plan to download this Catalog.xml and publish 
> via ftp/http internally and do a phased roll-out. Say dev servers get first.I 
> understand the firmware behaves differently even on same model at different 
> times but that's a risk we are willing to take.
>
> Couple of more questions:
>
> Q1) Does anyone here use iDrac or dsu based updates? Do you mirror the 
> upstream repo locally and point to it somehow? Please respond to this list or 
> directly so we can talk further.
>
> Q2) Any other strategies for updating large(3000+) servers that is OS 
> agnostic? I am keeping OME as last option.
>
>
> Thanks all
>
> On Thu, Apr 19, 2018 at 2:40 AM, Florian Haller-Casagrande 
> 

Re: [Linux-PowerEdge] PE Update Strategy & Questions

[Tim Mooney]

In regard to: Re: [Linux-PowerEdge] PE Update Strategy & Questions,...:


OpenManage Enterprise  the successor to OpeManage Essentials (both OME
for simplicity) is available now. It is supplied as a CentOS based
virtual appliance which can run on VMware, Hyper-V or KVM - so yes OME
is available for Linux.

If you want more information, let me know and I will provide when I am online.


I certainly would be interested in more information on OM Enterprise.

Everything I've been able to find on dell.com still says "Tech Release",
which although listed as "fully supported", makes it sound fairly
beta-ish.

Just seeing that it uses HTML5 (rather than Silverlight (!)) makes me
more interested in the product than I ever was in Essentials.

Thanks,

Tim


 Original message 
From: Cameron Smith 
Date: 20/04/2018 19:22 (GMT+00:00)
To: R S 
Cc: linux-poweredge-Lists 
Subject: Re: [Linux-PowerEdge] PE Update Strategy & Questions

You are welcome!

Sadly OME is not Linux ready yet. I have heard rumors that it might be in the 
works but I wouldn't hold my breath.

If using the .EXEs in the DRAC GUI here are some tips.

Before you start, go to the Lifecycle Controller job queue which is the Job 
Queue link on the main DRAC page and see if there is anything already in there. 
If there are any jobs in there that are failed or pending (that you don't want) 
delete them.

Reboot the DRAC from the main drac page with the Reset link (This does not 
affect the OS)

Once DRAC is back up which is usually within 90 seconds then do your firmware 
uploads. You can set these to immediately reboot the server and run or to be 
queued to run when the server is rebooted by you at a later time manually.

Then go to the Job Queue and monitor their status.

Cameron

On Fri, Apr 20, 2018 at 11:11 AM, R S 
> wrote:
Thanks for sharing this. Makes me want to spent time and try out OME.
I used the 64bit EXEs in iDRAC just recently for the first time wondering how 
the iDRAC can handle EXEs?!?! :) It worked though.
Is OME available for GNU/Linux?

On Fri, Apr 20, 2018 at 12:37 PM, Cameron Smith 
> wrote:
For localizing the repo you can look into Dell Repo Manager:

https://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=2GY7P

You can customize the repo if you need to hold back a version for anything and 
it's a great tool. Runs on Linux now!!!

For firmware updates I used to use .BIN files in the OS. I then moved to 64-bit 
.exe files through DRAC. I now use OME to DRAC for almost everything for 
managing about 600 servers (11/12/13Gen).

OME has gotten much better. Based on your numbers though I believe you would need to run 
multiple installs of OME as I "think" it maxes out at close to 2000 devices. 
It's is also good to batch update smaller groups of devices at a time (20 or so) rather 
than trying to update 1000 at a time. Just something to think about if you need to end up 
going this route.

Cameron

On Fri, Apr 20, 2018 at 6:32 AM, Prashant Sun 
> wrote:
Thanks RS & Florian for your suggestions.

I intend to use Catalog.xml file as my primary tool to approve updates that are 
applied by iDRAC or dsu. I plan to download this Catalog.xml and publish via 
ftp/http internally and do a phased roll-out. Say dev servers get first.I 
understand the firmware behaves differently even on same model at different 
times but that's a risk we are willing to take.

Couple of more questions:

Q1) Does anyone here use iDrac or dsu based updates? Do you mirror the upstream 
repo locally and point to it somehow? Please respond to this list or directly 
so we can talk further.

Q2) Any other strategies for updating large(3000+) servers that is OS agnostic? 
I am keeping OME as last option.


Thanks all

On Thu, Apr 19, 2018 at 2:40 AM, Florian Haller-Casagrande 
> 
wrote:

Hi,


Another solution is to setup an OpenManage Essential server (or "OME", 
available for free on Dell website), let is scan your network and find all you iDRAC (no 
need to go further, like OS-level or with OMSA agents). It will then display you all the 
available updates for your machines, and you will be able to schedule them (or apply them 
immediately), through the iDRAC (and the LC).


That is clearly, IMHO, the easiest way to go with dozens/hundreds of servers.


But, these are some limitations I have with this solution :

- OME is heavy, requiring a SQL server (embedded) and eating a lot of CPU/RAM 
when you have hundreds of machines ;

- OME offers many features, such as managing iDRAC/BIOS/etc configurations, 
licenses, hardwares issues and so on, but it is not easy to handle, and to be 
honest I only 

Re: [Linux-PowerEdge] PE Update Strategy & Questions

[Prashant Sun]

Thanks Kevin.

I tried DRM for Linux(v3.0.0.385) on Centos 7.4 and it is buggy. After
creating the repo and updating preferences, it just suddenly disappeared
from console. I can't create a new repo or change preferences it just keeps
circling on the dots. Seems very unstable to me.

Can you share the link to OME Linux download? Not the appliance version. Is
it GA or still in tech preview?


Thanks

On Fri, Apr 20, 2018 at 3:45 PM,  wrote:

> OpenManage Enterprise  the successor to OpeManage Essentials (both OME for
> simplicity) is available now. It is supplied as a CentOS based virtual
> appliance which can run on VMware, Hyper-V or KVM - so yes OME is available
> for Linux.
>
> If you want more information, let me know and I will provide when I am
> online.
>
>
>
> Sent from my Samsung Galaxy smartphone.
>
>
>  Original message 
> From: Cameron Smith 
> Date: 20/04/2018 19:22 (GMT+00:00)
> To: R S 
> Cc: linux-poweredge-Lists 
> Subject: Re: [Linux-PowerEdge] PE Update Strategy & Questions
>
> You are welcome!
>
> Sadly OME is not Linux ready yet. I have heard rumors that it might be in
> the works but I wouldn't hold my breath.
>
> If using the .EXEs in the DRAC GUI here are some tips.
>
> Before you start, go to the Lifecycle Controller job queue which is the
> Job Queue link on the main DRAC page and see if there is anything already
> in there. If there are any jobs in there that are failed or pending (that
> you don't want) delete them.
>
> Reboot the DRAC from the main drac page with the Reset link (This does not
> affect the OS)
>
> Once DRAC is back up which is usually within 90 seconds then do your
> firmware uploads. You can set these to immediately reboot the server and
> run or to be queued to run when the server is rebooted by you at a later
> time manually.
>
> Then go to the Job Queue and monitor their status.
>
> Cameron
>
> On Fri, Apr 20, 2018 at 11:11 AM, R S  wrote:
>
>> Thanks for sharing this. Makes me want to spent time and try out OME.
>> I used the 64bit EXEs in iDRAC just recently for the first time wondering
>> how the iDRAC can handle EXEs?!?! :) It worked though.
>> Is OME available for GNU/Linux?
>>
>> On Fri, Apr 20, 2018 at 12:37 PM, Cameron Smith > > wrote:
>>
>>> For localizing the repo you can look into Dell Repo Manager:
>>>
>>> https://www.dell.com/support/home/us/en/04/Drivers/DriversDe
>>> tails?driverId=2GY7P
>>>
>>> You can customize the repo if you need to hold back a version for
>>> anything and it's a great tool. Runs on Linux now!!!
>>>
>>> For firmware updates I used to use .BIN files in the OS. I then moved to
>>> 64-bit .exe files through DRAC. I now use OME to DRAC for almost everything
>>> for managing about 600 servers (11/12/13Gen).
>>>
>>> OME has gotten much better. Based on your numbers though I believe you
>>> would need to run multiple installs of OME as I "think" it maxes out at
>>> close to 2000 devices. It's is also good to batch update smaller groups of
>>> devices at a time (20 or so) rather than trying to update 1000 at a time.
>>> Just something to think about if you need to end up going this route.
>>>
>>> Cameron
>>>
>>> On Fri, Apr 20, 2018 at 6:32 AM, Prashant Sun >> > wrote:
>>>
 Thanks RS & Florian for your suggestions.

 I intend to use Catalog.xml file as my primary tool to approve updates
 that are applied by iDRAC or dsu. I plan to download this Catalog.xml and
 publish via ftp/http internally and do a phased roll-out. Say dev servers
 get first.I understand the firmware behaves differently even on same model
 at different times but that's a risk we are willing to take.

 Couple of more questions:

 Q1) Does anyone here use iDrac or dsu based updates? Do you mirror the
 upstream repo locally and point to it somehow? Please respond to this list
 or directly so we can talk further.

 Q2) Any other strategies for updating large(3000+) servers that is OS
 agnostic? I am keeping OME as last option.


 Thanks all

 On Thu, Apr 19, 2018 at 2:40 AM, Florian Haller-Casagrande <
 florian.haller-casagra...@smile.fr> wrote:

> Hi,
>
>
> Another solution is to setup an OpenManage Essential server (or "OME",
> available for free on Dell website), let is scan your network and find all
> you iDRAC (no need to go further, like OS-level or with OMSA agents). It
> will then display you all the available updates for your machines, and you
> will be able to schedule them (or apply them immediately), through the
> iDRAC (and the LC).
>
>
> That is clearly, IMHO, the easiest way to go with dozens/hundreds of
> servers.
>
>
> But, these are some limitations I have with this solution :
>

Re: [Linux-PowerEdge] PE Update Strategy & Questions

[Kevin.M.Jones]

OpenManage Enterprise  the successor to OpeManage Essentials (both OME for 
simplicity) is available now. It is supplied as a CentOS based virtual 
appliance which can run on VMware, Hyper-V or KVM - so yes OME is available for 
Linux.

If you want more information, let me know and I will provide when I am online.



Sent from my Samsung Galaxy smartphone.


 Original message 
From: Cameron Smith 
Date: 20/04/2018 19:22 (GMT+00:00)
To: R S 
Cc: linux-poweredge-Lists 
Subject: Re: [Linux-PowerEdge] PE Update Strategy & Questions

You are welcome!

Sadly OME is not Linux ready yet. I have heard rumors that it might be in the 
works but I wouldn't hold my breath.

If using the .EXEs in the DRAC GUI here are some tips.

Before you start, go to the Lifecycle Controller job queue which is the Job 
Queue link on the main DRAC page and see if there is anything already in there. 
If there are any jobs in there that are failed or pending (that you don't want) 
delete them.

Reboot the DRAC from the main drac page with the Reset link (This does not 
affect the OS)

Once DRAC is back up which is usually within 90 seconds then do your firmware 
uploads. You can set these to immediately reboot the server and run or to be 
queued to run when the server is rebooted by you at a later time manually.

Then go to the Job Queue and monitor their status.

Cameron

On Fri, Apr 20, 2018 at 11:11 AM, R S 
> wrote:
Thanks for sharing this. Makes me want to spent time and try out OME.
I used the 64bit EXEs in iDRAC just recently for the first time wondering how 
the iDRAC can handle EXEs?!?! :) It worked though.
Is OME available for GNU/Linux?

On Fri, Apr 20, 2018 at 12:37 PM, Cameron Smith 
> wrote:
For localizing the repo you can look into Dell Repo Manager:

https://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=2GY7P

You can customize the repo if you need to hold back a version for anything and 
it's a great tool. Runs on Linux now!!!

For firmware updates I used to use .BIN files in the OS. I then moved to 64-bit 
.exe files through DRAC. I now use OME to DRAC for almost everything for 
managing about 600 servers (11/12/13Gen).

OME has gotten much better. Based on your numbers though I believe you would 
need to run multiple installs of OME as I "think" it maxes out at close to 2000 
devices. It's is also good to batch update smaller groups of devices at a time 
(20 or so) rather than trying to update 1000 at a time. Just something to think 
about if you need to end up going this route.

Cameron

On Fri, Apr 20, 2018 at 6:32 AM, Prashant Sun 
> wrote:
Thanks RS & Florian for your suggestions.

I intend to use Catalog.xml file as my primary tool to approve updates that are 
applied by iDRAC or dsu. I plan to download this Catalog.xml and publish via 
ftp/http internally and do a phased roll-out. Say dev servers get first.I 
understand the firmware behaves differently even on same model at different 
times but that's a risk we are willing to take.

Couple of more questions:

Q1) Does anyone here use iDrac or dsu based updates? Do you mirror the upstream 
repo locally and point to it somehow? Please respond to this list or directly 
so we can talk further.

Q2) Any other strategies for updating large(3000+) servers that is OS agnostic? 
I am keeping OME as last option.


Thanks all

On Thu, Apr 19, 2018 at 2:40 AM, Florian Haller-Casagrande 
> 
wrote:

Hi,


Another solution is to setup an OpenManage Essential server (or "OME", 
available for free on Dell website), let is scan your network and find all you 
iDRAC (no need to go further, like OS-level or with OMSA agents). It will then 
display you all the available updates for your machines, and you will be able 
to schedule them (or apply them immediately), through the iDRAC (and the LC).


That is clearly, IMHO, the easiest way to go with dozens/hundreds of servers.


But, these are some limitations I have with this solution :

- OME is heavy, requiring a SQL server (embedded) and eating a lot of CPU/RAM 
when you have hundreds of machines ;

- OME offers many features, such as managing iDRAC/BIOS/etc configurations, 
licenses, hardwares issues and so on, but it is not easy to handle, and to be 
honest I only use it to update my firmwares ;

- 80% of my servers are pretty well detected, but for some of them the 
inventory task fail, and they are not listed (so I can't update them with OME, 
I still need to go with a Dell ISO or whatever) ;

- As Rene Shuster said, BIOS and LC updates are (almost) the first to run. 
Personally, I first update all the iDRACs, as OME will go through it to push 
updates to 

Re: [Linux-PowerEdge] PE Update Strategy & Questions

[Stephen John Smoogen]

On 20 April 2018 at 14:11, R S  wrote:

> Thanks for sharing this. Makes me want to spent time and try out OME.
> I used the 64bit EXEs in iDRAC just recently for the first time wondering
> how the iDRAC can handle EXEs?!?! :) It worked though.
> Is OME available for GNU/Linux?
>
>
My understanding is that the EXE is a zip wrapper with the data that the
idrac can use embedded inside of it. The idrac doesn't use the EXE but
considers parts of it header/footer data with a bundle of other items
archived inside. It looks for data it wants, checks the sums with what it
is supposed to be and then takes apart the archive inside for what it
wants. The EXE when run in windows does some extra housekeeping to talk to
the idrac over the internal bus.



> On Fri, Apr 20, 2018 at 12:37 PM, Cameron Smith 
> wrote:
>
>> For localizing the repo you can look into Dell Repo Manager:
>>
>> https://www.dell.com/support/home/us/en/04/Drivers/DriversDe
>> tails?driverId=2GY7P
>>
>> You can customize the repo if you need to hold back a version for
>> anything and it's a great tool. Runs on Linux now!!!
>>
>> For firmware updates I used to use .BIN files in the OS. I then moved to
>> 64-bit .exe files through DRAC. I now use OME to DRAC for almost everything
>> for managing about 600 servers (11/12/13Gen).
>>
>> OME has gotten much better. Based on your numbers though I believe you
>> would need to run multiple installs of OME as I "think" it maxes out at
>> close to 2000 devices. It's is also good to batch update smaller groups of
>> devices at a time (20 or so) rather than trying to update 1000 at a time.
>> Just something to think about if you need to end up going this route.
>>
>> Cameron
>>
>> On Fri, Apr 20, 2018 at 6:32 AM, Prashant Sun 
>> wrote:
>>
>>> Thanks RS & Florian for your suggestions.
>>>
>>> I intend to use Catalog.xml file as my primary tool to approve updates
>>> that are applied by iDRAC or dsu. I plan to download this Catalog.xml and
>>> publish via ftp/http internally and do a phased roll-out. Say dev servers
>>> get first.I understand the firmware behaves differently even on same model
>>> at different times but that's a risk we are willing to take.
>>>
>>> Couple of more questions:
>>>
>>> Q1) Does anyone here use iDrac or dsu based updates? Do you mirror the
>>> upstream repo locally and point to it somehow? Please respond to this list
>>> or directly so we can talk further.
>>>
>>> Q2) Any other strategies for updating large(3000+) servers that is OS
>>> agnostic? I am keeping OME as last option.
>>>
>>>
>>> Thanks all
>>>
>>> On Thu, Apr 19, 2018 at 2:40 AM, Florian Haller-Casagrande <
>>> florian.haller-casagra...@smile.fr> wrote:
>>>
 Hi,


 Another solution is to setup an OpenManage Essential server (or "OME",
 available for free on Dell website), let is scan your network and find all
 you iDRAC (no need to go further, like OS-level or with OMSA agents). It
 will then display you all the available updates for your machines, and you
 will be able to schedule them (or apply them immediately), through the
 iDRAC (and the LC).


 That is clearly, IMHO, the easiest way to go with dozens/hundreds of
 servers.


 But, these are some limitations I have with this solution :

 - OME is heavy, requiring a SQL server (embedded) and eating a lot of
 CPU/RAM when you have hundreds of machines ;

 - OME offers many features, such as managing iDRAC/BIOS/etc
 configurations, licenses, hardwares issues and so on, but it is not easy to
 handle, and to be honest I only use it to update my firmwares ;

 - 80% of my servers are pretty well detected, but for some of them the
 inventory task fail, and they are not listed (so I can't update them with
 OME, I still need to go with a Dell ISO or whatever) ;

 - As Rene Shuster said, BIOS and LC updates are (almost) the first to
 run. Personally, I first update all the iDRACs, as OME will go through it
 to push updates to the LC. So : iDRAC, then BIOS+LC, then everything else ;

 - I still have many iDRAC6, and the iDRAC update is strangely not
 "reboot-less" (if you upgrade through its webUI, no need to reboot the
 server, only the iDRAC). With OME, the update is loaded (into the LC ?),
 and waiting for server reboot to be applied...


 I was previously using the ISO solution, but having to connect to every
 single iDRAC, reboot and then go to PXE boot is time-consuming. And, most
 of the time, you have to reboot twice with the ISO, as some updates fail
 the first time because of some dependences (the Dell support teams are 
 very insistent
 on this point).


 As we have various Linux/*BSD systems, we can't rely on DSU or such
 tools (Dell still doesn't support Debian 9...), and that is why I focus on
 

Re: [Linux-PowerEdge] PE Update Strategy & Questions

[R S]

Thanks for sharing this. Makes me want to spent time and try out OME.
I used the 64bit EXEs in iDRAC just recently for the first time wondering
how the iDRAC can handle EXEs?!?! :) It worked though.
Is OME available for GNU/Linux?

On Fri, Apr 20, 2018 at 12:37 PM, Cameron Smith 
wrote:

> For localizing the repo you can look into Dell Repo Manager:
>
> https://www.dell.com/support/home/us/en/04/Drivers/DriversDe
> tails?driverId=2GY7P
>
> You can customize the repo if you need to hold back a version for anything
> and it's a great tool. Runs on Linux now!!!
>
> For firmware updates I used to use .BIN files in the OS. I then moved to
> 64-bit .exe files through DRAC. I now use OME to DRAC for almost everything
> for managing about 600 servers (11/12/13Gen).
>
> OME has gotten much better. Based on your numbers though I believe you
> would need to run multiple installs of OME as I "think" it maxes out at
> close to 2000 devices. It's is also good to batch update smaller groups of
> devices at a time (20 or so) rather than trying to update 1000 at a time.
> Just something to think about if you need to end up going this route.
>
> Cameron
>
> On Fri, Apr 20, 2018 at 6:32 AM, Prashant Sun 
> wrote:
>
>> Thanks RS & Florian for your suggestions.
>>
>> I intend to use Catalog.xml file as my primary tool to approve updates
>> that are applied by iDRAC or dsu. I plan to download this Catalog.xml and
>> publish via ftp/http internally and do a phased roll-out. Say dev servers
>> get first.I understand the firmware behaves differently even on same model
>> at different times but that's a risk we are willing to take.
>>
>> Couple of more questions:
>>
>> Q1) Does anyone here use iDrac or dsu based updates? Do you mirror the
>> upstream repo locally and point to it somehow? Please respond to this list
>> or directly so we can talk further.
>>
>> Q2) Any other strategies for updating large(3000+) servers that is OS
>> agnostic? I am keeping OME as last option.
>>
>>
>> Thanks all
>>
>> On Thu, Apr 19, 2018 at 2:40 AM, Florian Haller-Casagrande <
>> florian.haller-casagra...@smile.fr> wrote:
>>
>>> Hi,
>>>
>>>
>>> Another solution is to setup an OpenManage Essential server (or "OME",
>>> available for free on Dell website), let is scan your network and find all
>>> you iDRAC (no need to go further, like OS-level or with OMSA agents). It
>>> will then display you all the available updates for your machines, and you
>>> will be able to schedule them (or apply them immediately), through the
>>> iDRAC (and the LC).
>>>
>>>
>>> That is clearly, IMHO, the easiest way to go with dozens/hundreds of
>>> servers.
>>>
>>>
>>> But, these are some limitations I have with this solution :
>>>
>>> - OME is heavy, requiring a SQL server (embedded) and eating a lot of
>>> CPU/RAM when you have hundreds of machines ;
>>>
>>> - OME offers many features, such as managing iDRAC/BIOS/etc
>>> configurations, licenses, hardwares issues and so on, but it is not easy to
>>> handle, and to be honest I only use it to update my firmwares ;
>>>
>>> - 80% of my servers are pretty well detected, but for some of them the
>>> inventory task fail, and they are not listed (so I can't update them with
>>> OME, I still need to go with a Dell ISO or whatever) ;
>>>
>>> - As Rene Shuster said, BIOS and LC updates are (almost) the first to
>>> run. Personally, I first update all the iDRACs, as OME will go through it
>>> to push updates to the LC. So : iDRAC, then BIOS+LC, then everything else ;
>>>
>>> - I still have many iDRAC6, and the iDRAC update is strangely not
>>> "reboot-less" (if you upgrade through its webUI, no need to reboot the
>>> server, only the iDRAC). With OME, the update is loaded (into the LC ?),
>>> and waiting for server reboot to be applied...
>>>
>>>
>>> I was previously using the ISO solution, but having to connect to every
>>> single iDRAC, reboot and then go to PXE boot is time-consuming. And, most
>>> of the time, you have to reboot twice with the ISO, as some updates fail
>>> the first time because of some dependences (the Dell support teams are very 
>>> insistent
>>> on this point).
>>>
>>>
>>> As we have various Linux/*BSD systems, we can't rely on DSU or such
>>> tools (Dell still doesn't support Debian 9...), and that is why I focus on
>>> out-of-band solutions.
>>>
>>>
>>> My 2cts.
>>>
>>> [image: Logo] 
>>>
>>> 107 Boulevard de Stalingrad
>>> 69100 Lyon Villeurbanne
>>> www.smile.fr
>>> *Florian HALLER-CASAGRANDE*
>>> Ingénieur Infrastructures
>>> Email : florian.haller-casagra...@smile.fr
>>> Tel : +33 4 26 29 12 25
>>>
>>> [image: Facebook]  [image:
>>> Google%2B]  [image:
>>> LinkedIn]  [image: Twitter]
>>> 
>>>
>>>
>>>
>>> [image: eco]Pour la planète, n'imprimez ce mail que si c'est 

Re: [Linux-PowerEdge] PE Update Strategy & Questions

[Cameron Smith]

For localizing the repo you can look into Dell Repo Manager:

https://www.dell.com/support/home/us/en/04/Drivers/
DriversDetails?driverId=2GY7P

You can customize the repo if you need to hold back a version for anything
and it's a great tool. Runs on Linux now!!!

For firmware updates I used to use .BIN files in the OS. I then moved to
64-bit .exe files through DRAC. I now use OME to DRAC for almost everything
for managing about 600 servers (11/12/13Gen).

OME has gotten much better. Based on your numbers though I believe you
would need to run multiple installs of OME as I "think" it maxes out at
close to 2000 devices. It's is also good to batch update smaller groups of
devices at a time (20 or so) rather than trying to update 1000 at a time.
Just something to think about if you need to end up going this route.

Cameron

On Fri, Apr 20, 2018 at 6:32 AM, Prashant Sun 
wrote:

> Thanks RS & Florian for your suggestions.
>
> I intend to use Catalog.xml file as my primary tool to approve updates
> that are applied by iDRAC or dsu. I plan to download this Catalog.xml and
> publish via ftp/http internally and do a phased roll-out. Say dev servers
> get first.I understand the firmware behaves differently even on same model
> at different times but that's a risk we are willing to take.
>
> Couple of more questions:
>
> Q1) Does anyone here use iDrac or dsu based updates? Do you mirror the
> upstream repo locally and point to it somehow? Please respond to this list
> or directly so we can talk further.
>
> Q2) Any other strategies for updating large(3000+) servers that is OS
> agnostic? I am keeping OME as last option.
>
>
> Thanks all
>
> On Thu, Apr 19, 2018 at 2:40 AM, Florian Haller-Casagrande <
> florian.haller-casagra...@smile.fr> wrote:
>
>> Hi,
>>
>>
>> Another solution is to setup an OpenManage Essential server (or "OME",
>> available for free on Dell website), let is scan your network and find all
>> you iDRAC (no need to go further, like OS-level or with OMSA agents). It
>> will then display you all the available updates for your machines, and you
>> will be able to schedule them (or apply them immediately), through the
>> iDRAC (and the LC).
>>
>>
>> That is clearly, IMHO, the easiest way to go with dozens/hundreds of
>> servers.
>>
>>
>> But, these are some limitations I have with this solution :
>>
>> - OME is heavy, requiring a SQL server (embedded) and eating a lot of
>> CPU/RAM when you have hundreds of machines ;
>>
>> - OME offers many features, such as managing iDRAC/BIOS/etc
>> configurations, licenses, hardwares issues and so on, but it is not easy to
>> handle, and to be honest I only use it to update my firmwares ;
>>
>> - 80% of my servers are pretty well detected, but for some of them the
>> inventory task fail, and they are not listed (so I can't update them with
>> OME, I still need to go with a Dell ISO or whatever) ;
>>
>> - As Rene Shuster said, BIOS and LC updates are (almost) the first to
>> run. Personally, I first update all the iDRACs, as OME will go through it
>> to push updates to the LC. So : iDRAC, then BIOS+LC, then everything else ;
>>
>> - I still have many iDRAC6, and the iDRAC update is strangely not
>> "reboot-less" (if you upgrade through its webUI, no need to reboot the
>> server, only the iDRAC). With OME, the update is loaded (into the LC ?),
>> and waiting for server reboot to be applied...
>>
>>
>> I was previously using the ISO solution, but having to connect to every
>> single iDRAC, reboot and then go to PXE boot is time-consuming. And, most
>> of the time, you have to reboot twice with the ISO, as some updates fail
>> the first time because of some dependences (the Dell support teams are very 
>> insistent
>> on this point).
>>
>>
>> As we have various Linux/*BSD systems, we can't rely on DSU or such tools
>> (Dell still doesn't support Debian 9...), and that is why I focus on
>> out-of-band solutions.
>>
>>
>> My 2cts.
>>
>> [image: Logo] 
>>
>> 107 Boulevard de Stalingrad
>> 69100 Lyon Villeurbanne
>> www.smile.fr
>> *Florian HALLER-CASAGRANDE*
>> Ingénieur Infrastructures
>> Email : florian.haller-casagra...@smile.fr
>> Tel : +33 4 26 29 12 25
>>
>> [image: Facebook]  [image:
>> Google%2B]  [image:
>> LinkedIn]  [image: Twitter]
>> 
>>
>>
>>
>> [image: eco]Pour la planète, n'imprimez ce mail que si c'est nécessaire.
>> On 04/18/2018 09:27 PM, R S wrote:
>>
>> I recommend to apply BIOS update and LC update separately from all other
>> updates and do them first with whatever route you choose. They go together
>> is what DELL documentation says. BIOS first, then LC, then reboot and hope
>> for the best.
>>
>> Here are the pitfalls I encountered:
>> * updating the LC controller will result that all other updates chained
>> behind the LC update 

Re: [Linux-PowerEdge] yum update fails on libsmbios.so.2

[Sashi.K]

Hi,

We are looking in to the issue and will get back to you at the earliest.

Regards,
Sashi

-Original Message-
From: linux-poweredge-bounces-Lists On Behalf Of linux-poweredge-request-Lists
Sent: Friday, April 20, 2018 6:23 PM
To: linux-poweredge-Lists
Subject: Linux-PowerEdge Digest, Vol 167, Issue 18

Send Linux-PowerEdge mailing list submissions to
linux-poweredge@dell.com

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.us.dell.com/mailman/listinfo/linux-poweredge
or, via email, send a message with subject or body 'help' to
linux-poweredge-requ...@dell.com

You can reach the person managing the list at
linux-poweredge-ow...@dell.com

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Linux-PowerEdge digest..."


Today's Topics:

   1.  yum update fails on libsmbios.so.2 dependencyerror with
  srvadmin-storage-9.1.0-2757.12163.el7 (francis picabia)
   2. Re:  yum update fails on libsmbios.so.2 dependencyerror with
  srvadmin-storage-9.1.0-2757.12163.el7 (francis picabia)
   3.  Documentation on updates integrity (Prashant Sun)


--

Message: 1
Date: Fri, 20 Apr 2018 09:25:04 -0300
From: francis picabia <fpica...@gmail.com>
To: linux-poweredge@dell.com
Subject: [Linux-PowerEdge] yum update fails on libsmbios.so.2
dependency  error with srvadmin-storage-9.1.0-2757.12163.el7
Message-ID:
<CA+AKB6G0gfrQyMtE3fvAewugUGez5=MxpsMQwPSQTizO6V=e...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Running Redhat 7.4 and srvadmin packages of version 9.1.0-2757.12173

When updating the system I see a dependency error.

# cat /etc/yum.repos.d/dell-system-update.repo
[dell-system-update_independent]
name=dell-system-update_independent
baseurl=http://linux.dell.com/repo/hardware/dsu/os_independent/
gpgcheck=1
gpgkey=http://linux.dell.com/repo/hardware/dsu/public.key
enabled=1
exclude=dell-system-update*.i386

[dell-system-update_dependent]
name=dell-system-update_dependent
mirrorlist=
http://linux.dell.com/repo/hardware/dsu/mirrors.cgi?osname=el$releasever=$basearch=1
gpgcheck=1
gpgkey=http://linux.dell.com/repo/hardware/dsu/public.key
enabled=1


# yum update

{ ... }

--> Finished Dependency Resolution
Error: Package: srvadmin-storage-9.1.0-2757.12163.el7.x86_64
(@dell-system-update_dependent)
   Requires: libsmbios.so.2()(64bit)
   Removing: libsmbios-2.3.3-2.el7.x86_64 (@epel)
   libsmbios.so.2()(64bit)
   Updated By: libsmbios-2.3.3-6.el7.x86_64 (rhel-7-server-rpms)
   Not found
   Available: libsmbios-2.3.1-2757.12163.el7.x86_64
(dell-system-update_dependent)
   libsmbios.so.2()(64bit)
**
yum can be configured to try to resolve such errors by temporarily enabling 
disabled repos and searching for missing dependencies.
To enable this functionality please set 'notify_only=0' in 
/etc/yum/pluginconf.d/search-disabled-repos.conf
**

Error: Package: srvadmin-storage-9.1.0-2757.12163.el7.x86_64
(@dell-system-update_dependent)
   Requires: libsmbios.so.2()(64bit)
   Removing: libsmbios-2.3.3-2.el7.x86_64 (@epel)
   libsmbios.so.2()(64bit)
   Updated By: libsmbios-2.3.3-6.el7.x86_64 (rhel-7-server-rpms)
   Not found
   Available: libsmbios-2.3.1-2757.12163.el7.x86_64
(dell-system-update_dependent)
   libsmbios.so.2()(64bit)

===

Don't bother answering if you are going to suggest using --skip-broken
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20180420/95c70f54/attachment-0001.html>

--

Message: 2
Date: Fri, 20 Apr 2018 09:35:43 -0300
From: francis picabia <fpica...@gmail.com>
To: linux-poweredge@dell.com
Subject: Re: [Linux-PowerEdge] yum update fails on libsmbios.so.2
dependency  error with srvadmin-storage-9.1.0-2757.12163.el7
Message-ID:
<ca+akb6exuvrcb7avceb3mcvkmw2u+6zu4q4dwyhjshcohzu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

This issue is in Dell's side of the tennis court according to Redhat...

https://access.redhat.com/solutions/3409271

Until Dell EMC updates OMSA to remove the dependency on the deprecated c++ 
interface in libsmbios, customers will need to work around the issue by 
configuring yum to ignore/exclude the new version of libsmbios shipped by Red 
Hat.



On Fri, Apr 20, 2018 at 9:25 AM, francis picabia <fpica...@gmail.com> wrote:

>
> Running Redhat 7.4 and srvadmin packages of version 9.1.0-2757.

Re: [Linux-PowerEdge] PE Update Strategy & Questions

[Prashant Sun]

Thanks RS & Florian for your suggestions.

I intend to use Catalog.xml file as my primary tool to approve updates that
are applied by iDRAC or dsu. I plan to download this Catalog.xml and
publish via ftp/http internally and do a phased roll-out. Say dev servers
get first.I understand the firmware behaves differently even on same model
at different times but that's a risk we are willing to take.

Couple of more questions:

Q1) Does anyone here use iDrac or dsu based updates? Do you mirror the
upstream repo locally and point to it somehow? Please respond to this list
or directly so we can talk further.

Q2) Any other strategies for updating large(3000+) servers that is OS
agnostic? I am keeping OME as last option.


Thanks all

On Thu, Apr 19, 2018 at 2:40 AM, Florian Haller-Casagrande <
florian.haller-casagra...@smile.fr> wrote:

> Hi,
>
>
> Another solution is to setup an OpenManage Essential server (or "OME",
> available for free on Dell website), let is scan your network and find all
> you iDRAC (no need to go further, like OS-level or with OMSA agents). It
> will then display you all the available updates for your machines, and you
> will be able to schedule them (or apply them immediately), through the
> iDRAC (and the LC).
>
>
> That is clearly, IMHO, the easiest way to go with dozens/hundreds of
> servers.
>
>
> But, these are some limitations I have with this solution :
>
> - OME is heavy, requiring a SQL server (embedded) and eating a lot of
> CPU/RAM when you have hundreds of machines ;
>
> - OME offers many features, such as managing iDRAC/BIOS/etc
> configurations, licenses, hardwares issues and so on, but it is not easy to
> handle, and to be honest I only use it to update my firmwares ;
>
> - 80% of my servers are pretty well detected, but for some of them the
> inventory task fail, and they are not listed (so I can't update them with
> OME, I still need to go with a Dell ISO or whatever) ;
>
> - As Rene Shuster said, BIOS and LC updates are (almost) the first to run.
> Personally, I first update all the iDRACs, as OME will go through it to
> push updates to the LC. So : iDRAC, then BIOS+LC, then everything else ;
>
> - I still have many iDRAC6, and the iDRAC update is strangely not
> "reboot-less" (if you upgrade through its webUI, no need to reboot the
> server, only the iDRAC). With OME, the update is loaded (into the LC ?),
> and waiting for server reboot to be applied...
>
>
> I was previously using the ISO solution, but having to connect to every
> single iDRAC, reboot and then go to PXE boot is time-consuming. And, most
> of the time, you have to reboot twice with the ISO, as some updates fail
> the first time because of some dependences (the Dell support teams are very 
> insistent
> on this point).
>
>
> As we have various Linux/*BSD systems, we can't rely on DSU or such tools
> (Dell still doesn't support Debian 9...), and that is why I focus on
> out-of-band solutions.
>
>
> My 2cts.
>
> [image: Logo] 
>
> 107 Boulevard de Stalingrad
> 69100 Lyon Villeurbanne
> www.smile.fr
> *Florian HALLER-CASAGRANDE*
> Ingénieur Infrastructures
> Email : florian.haller-casagra...@smile.fr
> Tel : +33 4 26 29 12 25
>
> [image: Facebook]  [image:
> Google%2B]  [image:
> LinkedIn]  [image: Twitter]
> 
>
>
>
> [image: eco]Pour la planète, n'imprimez ce mail que si c'est nécessaire.
> On 04/18/2018 09:27 PM, R S wrote:
>
> I recommend to apply BIOS update and LC update separately from all other
> updates and do them first with whatever route you choose. They go together
> is what DELL documentation says. BIOS first, then LC, then reboot and hope
> for the best.
>
> Here are the pitfalls I encountered:
> * updating the LC controller will result that all other updates chained
> behind the LC update cannot be applied when using for example an ISO that
> has been created with DELL Repo Manager.
> * You might loose KVM capability when updating LC
> * There is a high chance that a LC update will render your iDRAC/LC into a
> brick
> * replacing a bricked iDRAC used to be swapping out the iDRAC card
> (available used for $60), starting with iDRAC7 DELL decided to solder it on
> the mainboard.
> * Check the warranty of all 3000 servers first as you will be opening
> tickets with DELL to get your mainboard replaced due to bricked iDRAC/LC if
> they are still under warranty.
> * a lot of PSU updates are not listed in the catalog and you will need to
> apply them in a different way. I do them last as they need up to 30 minutes
> to apply to both PSU. Don't make the mistake and get impatient and power
> the server on during the firmware update. The FW update will fail and you
> will need to start over
> * NIC updates sometimes fail to apply. Sometimes they need stepped
> updates, for example to fix the underlying issue of not 

[Linux-PowerEdge] Documentation on updates integrity

[Prashant Sun]

Hello all -

Is there a document that lists how the fw updates are verified before
applied? I see that Catalog.xml has md5hash but couldn't find a document
that says it is verified. Also does DSU or DRM check digital signatures or
does Dell leave it for end-users to do it onm their own by publishing
sha1/sha-256/md5 signatures?

Lastly, is the Catalog.xml published by Dell is protected in some ways that
is tamper proof?

Just curious as my security team is asking for some level of documentation.


Any links to PDF files is appreciated.


Best regards
P
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] yum update fails on libsmbios.so.2 dependency error with srvadmin-storage-9.1.0-2757.12163.el7

[francis picabia]

This issue is in Dell's side of the tennis court according to Redhat...

https://access.redhat.com/solutions/3409271

Until Dell EMC updates OMSA to remove the dependency on the deprecated c++
interface in libsmbios, customers will need to work around the issue by
configuring yum to ignore/exclude the new version of libsmbios shipped by
Red Hat.



On Fri, Apr 20, 2018 at 9:25 AM, francis picabia  wrote:

>
> Running Redhat 7.4 and srvadmin packages of version 9.1.0-2757.12173
>
> When updating the system I see a dependency error.
>
> # cat /etc/yum.repos.d/dell-system-update.repo
> [dell-system-update_independent]
> name=dell-system-update_independent
> baseurl=http://linux.dell.com/repo/hardware/dsu/os_independent/
> gpgcheck=1
> gpgkey=http://linux.dell.com/repo/hardware/dsu/public.key
> enabled=1
> exclude=dell-system-update*.i386
>
> [dell-system-update_dependent]
> name=dell-system-update_dependent
> mirrorlist=http://linux.dell.com/repo/hardware/dsu/mirrors.
> cgi?osname=el$releasever=$basearch=1
> gpgcheck=1
> gpgkey=http://linux.dell.com/repo/hardware/dsu/public.key
> enabled=1
>
>
> # yum update
>
> { ... }
>
> --> Finished Dependency Resolution
> Error: Package: srvadmin-storage-9.1.0-2757.12163.el7.x86_64
> (@dell-system-update_dependent)
>Requires: libsmbios.so.2()(64bit)
>Removing: libsmbios-2.3.3-2.el7.x86_64 (@epel)
>libsmbios.so.2()(64bit)
>Updated By: libsmbios-2.3.3-6.el7.x86_64 (rhel-7-server-rpms)
>Not found
>Available: libsmbios-2.3.1-2757.12163.el7.x86_64
> (dell-system-update_dependent)
>libsmbios.so.2()(64bit)
> **
> yum can be configured to try to resolve such errors by temporarily enabling
> disabled repos and searching for missing dependencies.
> To enable this functionality please set 'notify_only=0' in
> /etc/yum/pluginconf.d/search-disabled-repos.conf
> **
>
> Error: Package: srvadmin-storage-9.1.0-2757.12163.el7.x86_64
> (@dell-system-update_dependent)
>Requires: libsmbios.so.2()(64bit)
>Removing: libsmbios-2.3.3-2.el7.x86_64 (@epel)
>libsmbios.so.2()(64bit)
>Updated By: libsmbios-2.3.3-6.el7.x86_64 (rhel-7-server-rpms)
>Not found
>Available: libsmbios-2.3.1-2757.12163.el7.x86_64
> (dell-system-update_dependent)
>libsmbios.so.2()(64bit)
>
> ===
>
> Don't bother answering if you are going to suggest using --skip-broken
>
>
>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

[Linux-PowerEdge] yum update fails on libsmbios.so.2 dependency error with srvadmin-storage-9.1.0-2757.12163.el7

[francis picabia]

Running Redhat 7.4 and srvadmin packages of version 9.1.0-2757.12173

When updating the system I see a dependency error.

# cat /etc/yum.repos.d/dell-system-update.repo
[dell-system-update_independent]
name=dell-system-update_independent
baseurl=http://linux.dell.com/repo/hardware/dsu/os_independent/
gpgcheck=1
gpgkey=http://linux.dell.com/repo/hardware/dsu/public.key
enabled=1
exclude=dell-system-update*.i386

[dell-system-update_dependent]
name=dell-system-update_dependent
mirrorlist=
http://linux.dell.com/repo/hardware/dsu/mirrors.cgi?osname=el$releasever=$basearch=1
gpgcheck=1
gpgkey=http://linux.dell.com/repo/hardware/dsu/public.key
enabled=1


# yum update

{ ... }

--> Finished Dependency Resolution
Error: Package: srvadmin-storage-9.1.0-2757.12163.el7.x86_64
(@dell-system-update_dependent)
   Requires: libsmbios.so.2()(64bit)
   Removing: libsmbios-2.3.3-2.el7.x86_64 (@epel)
   libsmbios.so.2()(64bit)
   Updated By: libsmbios-2.3.3-6.el7.x86_64 (rhel-7-server-rpms)
   Not found
   Available: libsmbios-2.3.1-2757.12163.el7.x86_64
(dell-system-update_dependent)
   libsmbios.so.2()(64bit)
**
yum can be configured to try to resolve such errors by temporarily enabling
disabled repos and searching for missing dependencies.
To enable this functionality please set 'notify_only=0' in
/etc/yum/pluginconf.d/search-disabled-repos.conf
**

Error: Package: srvadmin-storage-9.1.0-2757.12163.el7.x86_64
(@dell-system-update_dependent)
   Requires: libsmbios.so.2()(64bit)
   Removing: libsmbios-2.3.3-2.el7.x86_64 (@epel)
   libsmbios.so.2()(64bit)
   Updated By: libsmbios-2.3.3-6.el7.x86_64 (rhel-7-server-rpms)
   Not found
   Available: libsmbios-2.3.1-2757.12163.el7.x86_64
(dell-system-update_dependent)
   libsmbios.so.2()(64bit)

===

Don't bother answering if you are going to suggest using --skip-broken
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge