Re: [Linux-PowerEdge] iDRAC6 Serial Access to RACADM

[Cameron Smith]

I usually just ssh to the DRAC IP to run racadm commands


Cameron Smith
Technical Operations Manager
Network Redux, LLC
5200 SW Macadam Ave Ste 450
Portland, Oregon 97239
Cell:   503-926-4928

On Thu, May 5, 2016 at 4:16 PM, Adonis Peralta <doni...@gmail.com> wrote:

> For the life of me I can’t figure out how to connect to the iDRAC6 (racadm
> login) (Im on a Dell R710 - iDRAC6 Enterprise) via the serial port. I go
> into the bios and have Serial with Console Redirection to COM2. I then
> Enable RACADM serial via the web gui. I then proceed to try to connect to
> the COM2 serial port via minicom and I just keep getting nothing. Minicom
> says not connected - Just a blank screen. I followed the manual and
> performed the  +  <9> command and nothing. I also went into the
> bios and remove the console redirection so that it’d just say Serial
> enabled without console redirection. I then set external console port to
> COM2 and still nothing. Same problem.
>
> I am not trying to connect to the serial console (a display of what the OS
> has). I want to serial into the iDRAC itself so that I can run the racadm
> commands. Looking at the manual it implies this can be done but nothing I
> am trying works.
>
> Thanks,
> Adonis
> ___
> Linux-PowerEdge mailing list
> Linux-PowerEdge@dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] iDRAC6 Serial Access to RACADM

[Cameron Smith]

iDRAC has the ability to change the port for ssh to something other than 22.
It also has the ability to upload ssh keys so you make the password complex
and rely on the keys.

Sorry I don't have more help for serial access to DRAC.


Cameron Smith
Technical Operations Manager
Network Redux, LLC
5200 SW Macadam Ave Ste 450
Portland, Oregon 97239
Cell:   503-926-4928

On Thu, May 5, 2016 at 4:40 PM, Adonis Peralta <doni...@gmail.com> wrote:

> Yea, unfortunately the scenario I'm trying to handle is a bit different.
> My iDrac is on a public facing network unfortunately without much of a
> choice so I have ssh disabled remote ipmi disabled and only allow access to
> a few ips. I do this for security hardening. The problem becomes that those
> Ips can change and I'll be locked out of iDrac when they do. I have access
> to local ipmi via the os but I cant disable the IP filtering via ipmi
> because I dont know the raw command to do it (if there is one). That leaves
> one option for me which is connect via serial :(. Really looking for some
> suggestions on this.
>
> On Thu, May 5, 2016 at 7:33 PM Cameron Smith <came...@networkredux.com>
> wrote:
>
>> I usually just ssh to the DRAC IP to run racadm commands
>>
>>
>> Cameron Smith
>> Technical Operations Manager
>> Network Redux, LLC
>> 5200 SW Macadam Ave Ste 450
>> Portland, Oregon 97239
>> Cell:   503-926-4928
>>
>> On Thu, May 5, 2016 at 4:16 PM, Adonis Peralta <doni...@gmail.com> wrote:
>>
>>> For the life of me I can’t figure out how to connect to the iDRAC6
>>> (racadm login) (Im on a Dell R710 - iDRAC6 Enterprise) via the serial port.
>>> I go into the bios and have Serial with Console Redirection to COM2. I then
>>> Enable RACADM serial via the web gui. I then proceed to try to connect to
>>> the COM2 serial port via minicom and I just keep getting nothing. Minicom
>>> says not connected - Just a blank screen. I followed the manual and
>>> performed the  +  <9> command and nothing. I also went into the
>>> bios and remove the console redirection so that it’d just say Serial
>>> enabled without console redirection. I then set external console port to
>>> COM2 and still nothing. Same problem.
>>>
>>> I am not trying to connect to the serial console (a display of what the
>>> OS has). I want to serial into the iDRAC itself so that I can run the
>>> racadm commands. Looking at the manual it implies this can be done but
>>> nothing I am trying works.
>>>
>>> Thanks,
>>> Adonis
>>>
>> ___
>>> Linux-PowerEdge mailing list
>>> Linux-PowerEdge@dell.com
>>> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>>>
>>
>>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] R720XD and X540-AT2 NICs overheating

[Cameron Smith]

Are you running the latest firmware for the NICs and the BIOS?

Cameron

On Fri, Jan 20, 2017 at 1:18 PM, Russell Kackley  wrote:

> Hi Tuc,
>
> We had what sounds like a similar problem to yours. Fortunately, the
> change to the fan speed offset solved the problem for us. Here are the
> details:
>
> We have 3 PE R720 servers that were purchased in mid-2013. All of them
> have Intel X540/2P I350 rNDC 10 Gb/s NIC's in them. I'm guessing that is
> similar to what you have in your R720XD. Two of the servers have worked
> flawlessly for the past three years. However, one of them, even from the
> early days of use, would intermittently report the following error:
>
> The system board NDC PG voltage is outside of range.
>
> That would cause a reboot event, which was obviously a serious problem.
> The server was under warranty and the technician tried replaced both the
> NIC and the motherboard. We still got the same error and reboot problem.
> Eventually, the issue got elevated to a L3 technician at Dell and they
> advised us to set the "Fan speed offset" to the "Low Fan Speed Offset""
> setting. We made that change to the problem server and its performance has
> been perfectly fine since then. I'm guessing that the fan speed change
> solved the NIC overheating problem.
>
> I'm sorry to hear that it doesn't seem to have solved your problem. I
> think that the iDRAC Settings-Thermal GUI offers the "High Fan Speed
> Offset", which runs the fans faster than the "Low Fan Speed Offset"
> setting. Did you try the "High Fan Speed Offset" setting to see if that
> corrects the problem?
>
> On Fri, Jan 20, 2017 at 6:47 AM, Tuc at Beach House 
> wrote:
>
>> Hi,
>>
>> We have an older R720XD (Ship date: September 07, 2012) that has X540-AT2
>> NICs (10G). The system seems to shut down the NICS for overheating.
>> Apparently, Dell told them just to change the "Thermal Profile" to Max, and
>> the "Fan Speed Offset" to low. That worked for a while, but now its
>> happening again. The unit isn't under warranty, so I can't call Dell
>> anymore.
>>
>> Has anyone else found a way around this. Its a hadoop node that just
>> "disappears" on us and causes problems.
>>
>> Thanks, Tuc
>>
>> ___
>> Linux-PowerEdge mailing list
>> Linux-PowerEdge@dell.com
>> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>>
>>
>
>
> --
> Russell Kackley
> Subaru Telescope
> Hilo, Hawaii
>
>
> ___
> Linux-PowerEdge mailing list
> Linux-PowerEdge@dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] Dell System Update or Dell Linux Repository which is better

[Cameron Smith]

All of these issues are why I use OME for firmware.


Cameron Smith
Technical Operations Manager
Network Redux, LLC
5200 SW Macadam Ave Ste 450
Portland, Oregon 97239
Cell:   503-926-4928

On Thu, Dec 15, 2016 at 6:36 AM, Kilian Cavalotti <
kilian.cavalotti.w...@gmail.com> wrote:

> On Thu, Dec 15, 2016 at 11:55 AM,  <soorej_ponna...@dell.com> wrote:
> >   Dell Linux Repository (DLR) is deprecated by the new Dell System Update
> > (DSU). DSU has lot many features added and easy to use.
>
> Mmh, could you please give an example of one such feature? As far as I
> know, DSU is just merely catching up in terms of features to what DLR
> had been doing just fine for years. And I'm not mentioning code
> quality here, just features...
>
> > The DSU update
> > repository is refreshed every month.
>
> Well, yes, and in very interesting ways. For instance, the last
> 1.3.1-16.12.00 update now wants to downgrade BIOS versions that were
> already quite behind. To be precise: until now, the latest BIOS
> version that DSU proposed for R630s was 2.2.5 (when the latest BIOS
> version on support.dell.com has been 2.3.4 for quite a while). But
> with the latest version, DSU now wants to downgrade 2.2.5 to 2.1.7:
>
> -- 8< 
> 
> # dmidecode -s system-product-name
> PowerEdge R630
> # dsu -v
> dsu (Dell System Update) 1.3.1
> Copyright (C) 2014 Dell Proprietary.
> # dsu
> Verifying catalog installation ...
> [...]
> Getting System Inventory ...
> Determining Applicable Updates ...
>
> [...]
>
> [ ]1 BIOS
>  Current Version : 2.2.5 Downgrade to : 2.1.7
> -- 8< 
> 
>
> So, in its current state, DSU does not provide any useful updates for
> my servers, and worse, it actually tried to downgrade the already
> outdated versions that are installed.
> That's the very base feature of DSU: check local BIOS versions them
> against what's available in the repo. And I'm sorry, but it can't even
> get that right.
>
> Cheers,
> --
> Kilian
>
> ___
> Linux-PowerEdge mailing list
> Linux-PowerEdge@dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] Dell System Update or Dell Linux Repository which is better

[Cameron Smith]

Agreed as we are a 100% linux shop as well except for OME and SanHQ but I
have found it it to be a more stable way (with more control when leveraging
Dell Repo Manager with a custom catalog) to manage the firmware on our
hundreds of Dell servers than Dell's in-OS based tools. Just my 2 cents.
Support Assist Enterprise just got released for Linux and hopefully OME is
headed that way.

Cameron

On Thu, Dec 15, 2016 at 9:26 AM, Jeff Palmer <j...@palmerit.net> wrote:

> With all due respect, this response isn't overly helpful. Standing up a
> windows server specifically to manage a 100℅ Linux shop isn't a solution,
> it's a hack.
>
> The tools provided should work as advertised without having to resort to
> supporting/maintaining an entirely new OS and product/environment to get
> the same functionality.
>
> On Dec 15, 2016 12:07 PM, "Cameron Smith" <came...@networkredux.com>
> wrote:
>
>> All of these issues are why I use OME for firmware.
>>
>>
>> Cameron Smith
>> Technical Operations Manager
>> Network Redux, LLC
>> 5200 SW Macadam Ave Ste 450
>> Portland, Oregon 97239
>> Cell:   503-926-4928 <(503)%20926-4928>
>>
>> On Thu, Dec 15, 2016 at 6:36 AM, Kilian Cavalotti <
>> kilian.cavalotti.w...@gmail.com> wrote:
>>
>>> On Thu, Dec 15, 2016 at 11:55 AM,  <soorej_ponna...@dell.com> wrote:
>>> >   Dell Linux Repository (DLR) is deprecated by the new Dell System
>>> Update
>>> > (DSU). DSU has lot many features added and easy to use.
>>>
>>> Mmh, could you please give an example of one such feature? As far as I
>>> know, DSU is just merely catching up in terms of features to what DLR
>>> had been doing just fine for years. And I'm not mentioning code
>>> quality here, just features...
>>>
>>> > The DSU update
>>> > repository is refreshed every month.
>>>
>>> Well, yes, and in very interesting ways. For instance, the last
>>> 1.3.1-16.12.00 update now wants to downgrade BIOS versions that were
>>> already quite behind. To be precise: until now, the latest BIOS
>>> version that DSU proposed for R630s was 2.2.5 (when the latest BIOS
>>> version on support.dell.com has been 2.3.4 for quite a while). But
>>> with the latest version, DSU now wants to downgrade 2.2.5 to 2.1.7:
>>>
>>> -- 8< 
>>> 
>>> # dmidecode -s system-product-name
>>> PowerEdge R630
>>> # dsu -v
>>> dsu (Dell System Update) 1.3.1
>>> Copyright (C) 2014 Dell Proprietary.
>>> # dsu
>>> Verifying catalog installation ...
>>> [...]
>>> Getting System Inventory ...
>>> Determining Applicable Updates ...
>>>
>>> [...]
>>>
>>> [ ]1 BIOS
>>>  Current Version : 2.2.5 Downgrade to : 2.1.7
>>> -- 8< 
>>> 
>>>
>>> So, in its current state, DSU does not provide any useful updates for
>>> my servers, and worse, it actually tried to downgrade the already
>>> outdated versions that are installed.
>>> That's the very base feature of DSU: check local BIOS versions them
>>> against what's available in the repo. And I'm sorry, but it can't even
>>> get that right.
>>>
>>> Cheers,
>>> --
>>> Kilian
>>>
>>> ___
>>> Linux-PowerEdge mailing list
>>> Linux-PowerEdge@dell.com
>>> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>>>
>>
>>
>> ___
>> Linux-PowerEdge mailing list
>> Linux-PowerEdge@dell.com
>> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>>
>>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] dell-system-update package 1.4.0-17.02.00

[Cameron Smith]

Dells OOB options work quite well.

Either OME to fully update firmware remotely over DRAC connection or just
use OME for firmware version awareness and manually update firmware
through DRAC.

I left Dell OS level tools years ago due to memory leaks and
incompatibility issues.

Cameron

On Tue, Apr 4, 2017 at 2:42 AM, Diego Santa Cruz <
diego.santac...@spinetix.com> wrote:

> Hi Dell,
>
> I had already removed OMSA from my servers due to issues like this. But I
> kept DSU on the assumption that as it was much simpler there was much less
> room for it to break things and I have now been proved wrong. I will now be
> removing DSU as well, so much for an easy way to update firmware... Sigh!
>
> It is really sad to see that Dell does not take proper enterprise
> seriously and allows for such problems to go on and on. Dell should really
> consider assigning someone with systems administration experience to
> counsel the DSU dev team and review their decisions.
>
> Next time I need to purchase more servers I'll take a good look at other
> manufacturers..., I like Dell but this kind of problems really make my life
> more difficult.
>
> Best,
>
> --
> Diego Santa Cruz, PhD
> IT Administrator
> T +41 21 341 15 50
> diego.santac...@spinetix.com
> spinetix.com
>
> -Original Message-
> From: linux-poweredge-boun...@dell.com [mailto:linux-poweredge-
> boun...@dell.com] On Behalf Of Tim Mooney
> Sent: 03 April 2017 21:52
> To: linux-poweredge@dell.com
> Subject: Re: [Linux-PowerEdge] dell-system-update package 1.4.0-17.02.00
>
> In regard to: Re: [Linux-PowerEdge] dell-system-update package...:
>
> > I will say as a sysadmin that many project devs seem to just use
> > newest versions of libs in their apps just "because they can" with out
> > an real need and thus agrevate sysadmins supporting older OSes like
> > RHEL6 for no good reason.  Very much a pet peeve of mine.
>
> +1, and that's really crucial for developers to understand.  They should
> be depending on system libraries (and system commands) provided by the OS
> vendor if at all possible, and there should be an extremely good reason
> (not just "I want to", or "it's new and shiny") provided (and it should be
> clearly communicated to the customer!) when they deviate from that.
>
> Even if Dell had carefully insulated their shadow copies of various
> libraries from the rest of the OS, I still have a problem with needlessly
> shipping their own variants -- security updates.  OS vendors are typically
> quick and coordinated when it comes to releasing updates for security flaws.
> If Dell's software depended on system libraries and commands only, then
> DSU and other tools would get the security updates when the rest of the OS
> does.  Dell's response to nearly every issue I've seen reported via this
> list is "we'll fix it in 3-6 months in the next feature release", which
> wouldn't cut it if there were a security issue with their local copy of
> some command or library.
>
> Tim
> --
> Tim Mooney tim.moo...@ndsu.edu
> Enterprise Computing & Infrastructure  701-231-1076
> (Voice)
> Room 242-J6, Quentin Burdick Building  701-231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
>
> ___
> Linux-PowerEdge mailing list
> Linux-PowerEdge@dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
> ___
> Linux-PowerEdge mailing list
> Linux-PowerEdge@dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] dell-system-update package 1.4.0-17.02.00

[Cameron Smith]

Hi Jeff,

We have dual direction monitoring.
1) OME does regular status polling of all devices. This is just a dumb "hey
are you there" check.

2) We have all DRACs configured to send snmp alerts to OME and we have all
alert options enabled.

We have OME configured to send critical alert notifications it receives to
our NOC.

For 12 and 13 gen servers, this set up allows us to receive notification if
a hard drive has failed or if a virtual disk is in a degraded state, if a
DIMM, CPU, FAN etc needs to be replaced, voltage errors etc. We do the same
for 11Gen but their level of reports is severely limited. I have to install
MegaCli on all our 11Gen with custom bash scripts in a cron to alert our
NOC of storage health issues.

I manage hardware health of about 450 Dell servers this way.
I use OME to upgrade the firmware on any server being reprovisioned but I
prefer to do firmware upgrades on production machines manually uploading
the updates through the DRAC GUI.

OME is great for knowing what firmware versions are installed on your
servers and knowing what the latest version available is and being able to
easily access that file.

Cameron

On Tue, Apr 4, 2017 at 8:40 AM, Jeff Palmer <j...@palmerit.net> wrote:

> Cameron,
>
> I'd be interested in hearing how you monitor hardware conditions via
> the OOB/drac.
>
> We currently use nagios to query the omsa tools via the
> check_openmanage plugin.  But if there is a sane way to do the
> equivalent via drac, I'd be all for it.
> I tried a plugin once a while back that promised such functionality,
> but we'd get alerts from OMSA,   and the drac plugin would hum along
> like everything was fine.   Really frustrating for failed
> disks/degraded arrays.  So, I never got to where I trusted it (and
> eventually gave up on it)
>
>
>
>
>
> On Tue, Apr 4, 2017 at 11:14 AM, Cameron Smith <came...@networkredux.com>
> wrote:
> > Dells OOB options work quite well.
> >
> > Either OME to fully update firmware remotely over DRAC connection or just
> > use OME for firmware version awareness and manually update firmware
> through
> > DRAC.
> >
> > I left Dell OS level tools years ago due to memory leaks and
> incompatibility
> > issues.
> >
> > Cameron
> >
> > On Tue, Apr 4, 2017 at 2:42 AM, Diego Santa Cruz
> > <diego.santac...@spinetix.com> wrote:
> >>
> >> Hi Dell,
> >>
> >> I had already removed OMSA from my servers due to issues like this. But
> I
> >> kept DSU on the assumption that as it was much simpler there was much
> less
> >> room for it to break things and I have now been proved wrong. I will
> now be
> >> removing DSU as well, so much for an easy way to update firmware...
> Sigh!
> >>
> >> It is really sad to see that Dell does not take proper enterprise
> >> seriously and allows for such problems to go on and on. Dell should
> really
> >> consider assigning someone with systems administration experience to
> counsel
> >> the DSU dev team and review their decisions.
> >>
> >> Next time I need to purchase more servers I'll take a good look at other
> >> manufacturers..., I like Dell but this kind of problems really make my
> life
> >> more difficult.
> >>
> >> Best,
> >>
> >> --
> >> Diego Santa Cruz, PhD
> >> IT Administrator
> >> T +41 21 341 15 50
> >> diego.santac...@spinetix.com
> >> spinetix.com
> >>
> >> -Original Message-
> >> From: linux-poweredge-boun...@dell.com
> >> [mailto:linux-poweredge-boun...@dell.com] On Behalf Of Tim Mooney
> >> Sent: 03 April 2017 21:52
> >> To: linux-poweredge@dell.com
> >> Subject: Re: [Linux-PowerEdge] dell-system-update package 1.4.0-17.02.00
> >>
> >> In regard to: Re: [Linux-PowerEdge] dell-system-update package...:
> >>
> >> > I will say as a sysadmin that many project devs seem to just use
> >> > newest versions of libs in their apps just "because they can" with out
> >> > an real need and thus agrevate sysadmins supporting older OSes like
> >> > RHEL6 for no good reason.  Very much a pet peeve of mine.
> >>
> >> +1, and that's really crucial for developers to understand.  They should
> >> be depending on system libraries (and system commands) provided by the
> OS
> >> vendor if at all possible, and there should be an extremely good reason
> (not
> >> just "I want to", or "it's new and shiny") provided (and it should be
> >> clearly communicated to the customer!) when they dev

Re: [Linux-PowerEdge] dell-system-update package 1.4.0-17.02.00

[Cameron Smith]

Hi Killian,

Yes sadly OME is windows.
We have hundreds of Linux servers with 10s of thousands of virtual servers
all linux and only 2 windows installs. One for OME and one for SANHQ. I
believe Dell is working towards a Linux version as some of their other
tools have made it into that space  .. finally!

Cameron

On Tue, Apr 4, 2017 at 8:51 AM, Kilian Cavalotti <
kilian.cavalotti.w...@gmail.com> wrote:

> Hi Cameron,
>
> On Tue, Apr 4, 2017 at 8:14 AM, Cameron Smith <came...@networkredux.com>
> wrote:
> > Either OME to fully update firmware remotely over DRAC connection or just
> > use OME for firmware version awareness and manually update firmware
> through
> > DRAC.
>
> Please feel free to correct me if I'm wrong, but OME is a
> Windows-based solution, right? That's a big no-go for me.
>
> > I left Dell OS level tools years ago due to memory leaks and
> incompatibility
> > issues.
>
> That's unfortunately the sad state of things many of us are in.
>
> Cheers,
> --
> Kilian
>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] [E] Re: replacing a failed hard drive with PERC HBA mode

[Cameron Smith]

In regard to: Re: [Linux-PowerEdge] [E] Re: replacing a failed hard
> drive...:
>
> > On 08/10/2017 05:49 PM, Tim Mooney wrote:
>
> >> The particular system that has the failed drive happens to not be at the
> >> 2.x release for iDRAC 7.
> >>
> >> We're going to schedule an outage for this weekend and remedy that.
> We're
> >> also going to pull a report from our OME system to try identify any
> other
> >> systems that don't have recent iDRAC 7 or iDRAC 8 versions.
>
> > Shouldn't need any downtime. Just download and run
> > https://downloads.dell.com/FOLDER04020316M/1/iDRAC-with-
> Lifecycle-Controller_Firmware_XTPX4_LN_2.41.40.40_A00.BIN
>
> I've done that kind of thing for smaller version bumps for things like
> the NIC, but considering it's iDRAC and we're going from 1.57.something
> to 2.41.40.40, I felt like it would be a lot safer to do this during
> an outage.  I also didn't know if there were any dependencies involved,
> with other component versions (other things also needing to be updated,
> in a particular order, because of the change in major version # of
> the iDRAC).
>
> I appreciate the tip though!  If we find any other systems that have
> iDRAC that's in the 1.x series and the system isn't as critical, I may
> give the individual .BIN update a try.
>
> Tim
>
>
Using the 64-bit EXE through the DRAC should be just fine.
I recommend to clear out anything left over in the lifecycle controller job
queue and then reset the drac from the DRAC main page before you start.

After you upload it to the DRAC using the DRAC GUI in iDRAC Settings >
Update and Rollback and set it to run it's a good idea to ping the drac IP.
The installation usually takes a few minutes and then you should see the IP
go down while the DRAC reboots and then usually after about 2 minutes it
comes back up. You should then be able to log back into the DRAC and see it
running on the new version.

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

Re: [Linux-PowerEdge] Is the concept of the Lifecycle Controller just being abandoned by Dell?

[Cameron Smith]

IMHO The Lifecycle Controller works great and I manually upload firmware
upgrades to it's job queue all the time. It is also what handles updates
sent from OME which I also use.

ftp.dell.com on the other hand is a joke.
It needs to be rearchitected to handle the bandwidth to deliver files
quickly at modern (not dial-up modem) speeds all the time.

DSU is iffy and has it's own problems :)

Cameron

On Mon, Jul 3, 2017 at 3:11 PM, Shane Forsythe  wrote:

> This is not specific to Linux, I'm frustratingly still at the point where
> trying to apply updates before can goto install linux.
>
> For awhile now there have been numerous posts about how absolutely horrid
> trying to do firmware updates via the Lifecycle Controller via
> ftp.dell.com has become.  The bandwidth or hardware devoted to
> ftp.dell.com does not remotely seem up to the task, when the site is
> actually up and you can connect, it seems to take many hours for it to
> actually download the catalog.
>
> Numerous times on Dell Support forums it be suggested to download a
> bootable ISO that will do all the updates.   I literally just spoke with
> support as I was having trouble even reaching ftp.dell.com , and that was
> the verbatim answer they gave me.
>
>
> Is that the preferred suggested course of action to upgrade Dell hardware
> currently?
> Once a month manually download an iso for each unique piece of hardware
> you are running?
>
> I was forced to download the one for my new unboxed R730xd , and am
> astonished how bad it is.
>
> There are 111 potential updates.  There is no central logic, or inventory
> collection.
>
> Each and every updated package is executed sequentially.
>
> Each and every update package , separately does "Collecting Inventory" (
> which takes a non trivial amount of time  ).  If that specific update
> doesn't apply to your hardware, you get  "This Update package is not
> compatible with your system configuration"
>
> Even the most basic engineering effort could be made to simplify and
> streamline this process, this is most bare bones out of the box possible
> solution that could have been devised.
>
> The Lifecycle controller was sold as an innovative intelligent solution by
> Dell to completely automate the process, each step applied in the Dell
> approved order ... The initial marketing spiel used to sell it (the
> Lifecycle contoller)  used the old out dated modes of manually download  as
> an example of what an improvement this would be!
>
> Has the Lifecycle controller method of updating via ftp just fallen out of
> favor?
> Is the current vision/plan to just push out the bare bones ISO ?
> Will there be improvements to the infrastructure that back ftp.dell.com?
>
>
> ___
> Linux-PowerEdge mailing list
> Linux-PowerEdge@dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] R610 - system services disabled and iDrac6 (entrerpise) communication failure

[Cameron Smith]

Are you able to access the DRAC GUI? If so you can update there with the
.usc file in the firmware update section.


Cameron Smith
Technical Operations Manager
Network Redux, LLC
Cell:   503-926-4928

On Fri, May 12, 2017 at 7:26 AM, Ricardo Stella <ste...@rider.edu> wrote:

>
> So we had this older R610 which was put off production and was trying to
> give it a new life. Used Dell repository manager to create a firmware
> bundle and after this got the errors on the title.
>
> Obviously, the system didn't like the firmware updates, so has anyone else
> experienced this before and know of a way around it? System is out of
> warranty and all I'm able to get in touch with at Dell is basic support (ie
> motherboard is bad).
>
> Supposedly, the LCC repair package is what's needed (USC file) but do I
> need to install an OS on this first? Is there a live CD/DVD/USB with the
> Dell Linux Repository by any chance or a way to quickly build one? Or do I
> need to install an OS on this first?
>
> I have a second R610 (clone) that has not been updated and iDRAC does boot
> and I can get to the GUI, except it needs a password reset, and for some
> reason the box is not displaying any video.
>
> Any ideas? Thanks in advance.
>
> --
> °(((=((===°°°(((
>
> ___
> Linux-PowerEdge mailing list
> Linux-PowerEdge@dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] Rebuilding Array

[Cameron Smith]

I like using MegaCli to view the disk health, see if there are media
errors, see if there is a SMART warning etc. If the drive has lots of media
errors it would be prudent to not put it back into the raid and to replace
it. You can also use MegaCli to view the controller logs to actually see
what was happening and how often.

Cameron

On Mon, Jun 19, 2017 at 7:06 AM, Paul Raines 
wrote:

>
> Obviously it would be nice for Dell to tell us how to get omconfig to
> work, but you can use perccli right now as a workaround.
>
> http://www.dell.com/support/home/us/en/4/Drivers/DriversDeta
> ils?driverId=3PHVH
>
> It works fine for every PERC controller I tried it on in the past several
> years.   And the old 'storcli' from LSI works on even olders ones.
>
> For example:
>
>perccli64 /c0 show
>perccli64 /c0/e32/s5 start rebuild
>
> -- Paul Raines (http://help.nmr.mgh.harvard.edu)
>
>
>
> On Mon, 19 Jun 2017 9:38am, Steffan Cline wrote:
>
> This is exactly the issue. No matter what I do, I still get the “operation
>> disabled” message. Is there an enablement path?
>>
>> Is there a trick to making it work so I don’t have to take it down during
>> business hours?
>>
>> Is there an official answer on this other than update the firmware taking
>> the server down to rebuild it?
>>
>>
>> Thank you,
>> Steffan Cline
>> 602-793-0014
>>
>>
>>
>> On 6/19/17, 6:30 AM, "Paul Raines" > behalf of rai...@nmr.mgh.harvard.edu> wrote:
>>
>>
>>I have tried rebuild, offline, online, ... too with omconfig and get
>> that
>>"operation disabled" message.
>>
>>Using perccli I was able to get disk to rebuild, offline ... just fine.
>>Something is just broken with omconfig with respect to this.
>>
>>-- Paul Raines (http://help.nmr.mgh.harvard.edu)
>>
>>
>>
>>On Sun, 18 Jun 2017 3:07pm, Patrick Boutilier wrote:
>>
>>> You might have to bring the failed drive offline then bring it back
>> online. That may simulate a reseating, not sure.
>>>
>>>
>>> On June 18, 2017 3:31:29 PM ADT, Steffan Cline 
>> wrote:
>>>> I’m nowhere near the data center to reseat the drives. Trying to
>>>> rebuild it first using that same drive until I can get there. Last
>> time
>>>> I did it, it lasted a few months. Yes, drive replacement is a
>> definite
>>>> at this point.
>>>>
>>>>
>>>>
>>>> Still can’t figure out why I get that error when everything seems
>> to be
>>>> right per the manual.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thank you,
>>>>
>>>> Steffan Cline
>>>>
>>>> 602-793-0014
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From:  on behalf of Patrick
>> Boutilier
>>>> 
>>>> Date: Sunday, June 18, 2017 at 11:10 AM
>>>> To: 
>>>> Subject: Re: [Linux-PowerEdge] Rebuilding Array
>>>>
>>>>
>>>>
>>>> Are you trying to rebuild on the same drive without replacing it?
>> Have
>>>> you tried just reseating the drive? That should kick off a rebuild
>>>> automatically. Does in RAID-5, not sure about RAID-6.
>>>>
>>>> On June 18, 2017 2:15:20 PM ADT, Steffan Cline 
>>>> wrote:
>>>>
>>>> I ran into this issue a while back but completely forgot how I
>> handled
>>>> it.
>>>>
>>>>
>>>>
>>>> I have a drive in a RAID 6 config that failed. I was able to just
>>>> rebuild the RAID a while back and it’s been fine for months. I
>> think I
>>>> ended up doing it via the BIOS rather than the tools because I
>> couldn’t
>>>> get past the error.
>>>>
>>>>
>>>>
>>>> In running the report I see this:
>>>>
>>>>
>>>>
>>>> # omreport storage pdisk controller=0
>>>>
>>>> List of Physical Disks on Controller PERC H700 Integrated (Embedded)
>>>>
>>>>
>>>>
>>>> Controller PERC H700 Integrated (Embedded)
>>>>
>>>> …
>>>>
>>>> ID  : 0:0:3
>>>>
>>>> Status  : Critical
>>>>
>>>> Name: Physical Disk 0:0:3
>>>>
>>>> State   : Failed
>>>>
>>>> Power Status: Spun Up
>>>>
>>>> Bus Protocol: SAS
>>>>
>>>> Media   : HDD
>>>>
>>>> Part of Cache Pool  : Not Applicable
>>>>
>>>> Remaining Rated Write Endurance : Not Applicable
>>>>
>>>> Failure Predicted   : No
>>>>
>>>> Revision: FS64
>>>>
>>>> Driver Version  : Not Applicable
>>>>
>>>> Model Number: Not Applicable
>>>>
>>>> T10 PI Capable  : No
>>>>
>>>> Certified   : Yes
>>>>
>>>> 

Re: [Linux-PowerEdge] dsu woes

[Cameron Smith]

Why mess with the OS at all.

You could use scripted racadm commands.
http://en.community.dell.com/techcenter/b/techcenter/
archive/2013/04/17/idrac7-now-supports-updating-server-
components-using-racadm-and-web-gui

That outline is a little old and references 12Gen but gets you in the
ballpark.

This avoids the DSU catalog issue as you manually download the file you
want to use for the upgrade and reference it directly.

James - Are all your 1500 servers the same Gen? Same Model? Are your DRACs
up to date? Do your DRACs have a public SSH key from a central management
server uploaded to one of the DRAC accounts? It makes scripted automation
much easier.


Cameron Smith
Technical Operations Manager
Network Redux, LLC
Cell:   503-926-4928

On Wed, Jan 10, 2018 at 3:47 PM, Patrick Boutilier <bouti...@ednet.ns.ca>
wrote:

> For 1500 hosts it should be faster to update directly rather than using
> dsu I would think.
>
>
> For example something like
>
> ./BIOS_78R68_LN_2.7.0.BIN -q
>
> or
>
> ./BIOS_78R68_LN_2.7.0.BIN -r -q
>
>
>
> [root@vs07 ~]# ./BIOS_78R68_LN_2.7.0.BIN --help
> Command-line options for the Update Package
>
> Usage:  [options...]
>
> Options:
>
> -h,--help : Display command-line usage help
> -c: Determine if the update can be applied to the system (1)
> -f: Force a downgrade to an older version. (1)(2)
> -q: Execute the update package silently without user
> intervention
> -n: Execute the update package without security verification
> -r: Reboot if necessary after the update (2)
> -v,--version  : Display version information
> --list: Display contents of package (3)
> --installpath=: Install the update package in the specified path
> only if options (2) and (8)  are supported.
>
> --extract  : Extract files to specified path (3)(4)
> -qi, --queryinventory   : Inventory if selective update is supported. (2)
> (5)
> -su= or --selectiveupdate=:  give the list
> of devices to update.(2) (6) (7)
>
> (1) Can NOT use -f with the -c option
> (2) Only takes effect if used with -q
> (3) Can be used only before extracting the package
> (4) Can NOT use --extract with any other option
> (5) Can use only with -q option. Can NOT be used with -f, -c, -h, -n, -r,
> -v, --list, --extract, -su
> (6) Can NOT be used with -c, -h, -n, -v, --list, --extract, -qi
> (7) Device list should not contain any space.
> (8) Only Application DUP supports.
>
>
>
>
>
> On 01/10/2018 06:27 PM, Patrick Boutilier wrote:
>
>> What I would do is download the BIOS update file once and then create a
>> script to rsync it to the 1500 hosts and run the update. I presume you
>> would have a script to run dsu on the 1500 hosts anyway?
>>
>>
>>
>> On 01/10/2018 05:24 PM, James A. Peltier wrote:
>>
>>> I have 1500 hosts to patch.  This isn't an option.
>>>
>>> - On 9 Jan, 2018, at 18:31, Patrick Boutilier bouti...@ednet.ns.ca
>>> wrote:
>>>
>>> | What server model do you have? Newer models have the updated firmware
>>> on
>>> | the support web site.
>>> |
>>> |
>>> |
>>> | On 01/09/2018 09:52 PM, James A. Peltier wrote:
>>> |> This is an absolutely ridiculous thing for Dell to do!  Even
>>> Microsoft, Amazon,
>>> |> Google, and nVidia have all provided updates to mitigate the flaw out
>>> of step
>>> |> with their typical release schedules!
>>> |>
>>> |> We have a deadline set by CERN to patch by January 15th, 2018 or our
>>> site will
>>> |> be blacklisted.  I strongly urge Dell to release these patches
>>> immediately,
>>> |> regardless of your schedules.
>>> |>
>>> |> - On 8 Jan, 2018, at 01:43, Soorej Ponnandi
>>> soorej.ponna...@dell.com wrote:
>>> |>
>>> |> | Dell - Internal Use - Confidential
>>> |> |
>>> |> | The DSU repository is refreshed once in every month. I believe the
>>> BIOS v2.7.0
>>> |> | was released couple of days back. The next DSU repository with this
>>> latest BIOS
>>> |> | update will be available by end of next week.
>>> |> |
>>> |> | -Original Message-
>>> |> | From: linux-poweredge-bounces-Lists On Behalf Of Guillaume Courtois
>>> |> | Sent: Monday, January 8, 2018 2:47 PM
>>> |> | To: linux-poweredge-Lists <linux-powere...@lists.us.dell.com>
>>> |> | Subject: Re: [Linux-PowerEdge] dsu woes
>>> |> |
>>> |> | Le 07/01/2018 19:45, Rich Sudlow a écrit

Re: [Linux-PowerEdge] PE r710 - MegaCli not working

[Cameron Smith]

Alternating green/amber is a predictive failure.


Cameron

On Mon, Jan 22, 2018 at 8:53 AM, Howard, Chris  wrote:

>
> Hi,
>
> We have a PE R710 which is running Scientific Linux (A respin of RedHat).
> I have the MegaCli tool installed.
> I don't use it often but I think it was working.
> Now it is not working.  It always says there are no controllers.
>
> I have a link here to a video I took.
> We are getting a funny green/amber sequence on one of the drives.
> I don't know if that means a bad drive or maybe is telling
> us the controller is bad.
>
> We have two drives which are mirrored.
>
> The system seems to be running OK otherwise.
>
> https://photos.app.goo.gl/K4ojETOwedbeiIvu1[photos.app.goo.gl]
>
> Chris Howard
>
>
>
> ___
> Linux-PowerEdge mailing list
> Linux-PowerEdge@dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] dsu woes

[Cameron Smith]

https://ftp.dell.com/catalog/Catalog.cab was updated today and has the new
12Gen BIOS updates. I use it for OME and have access to them there now.

Cameron

On Mon, Mar 12, 2018 at 10:04 AM, Stefan M. Radman  wrote:

> Dell FTP site is not updated either.
>
> The Lifecycle Controller of an R620 did not "see" BIOS update 2.6.1 today.
>
> Stefan
>
> > On Mar 12, 2018, at 5:57 PM, Gregory Matthews <
> greg.matth...@diamond.ac.uk> wrote:
> >
> > seems like the firmware is available as a point and click download from
> the dell site but not from the repo. I just synced the repo and there is
> nothing newer than Feb 26 so 12G and older are not covered.
> >
> > GREG
> >
> > On 18/01/18 10:14, lheck...@users.sourceforge.net wrote:
> >> Guillaume Courtois writes:
> >>>
> >>>
> >>> Hi guys,
> >>>
> >>> It seems like the repo is updated now :
> >>>
> >>> http://linux.dell.com/repo/hardware/dsu/
> >>>
> >>> but I don't see the new BIOS, at least the one for R630 / R730 servers
> : it
> >>> is listed in the changelog :
> >>See http://www.dell.com/support/article/de/de/debsdt1/
> sln308588/microprocessor-side-channel-vulnerabilities--cve-
> 2017-5715--cve-2017-5753--cve-2017-5754---impact-on-dell-
> emc-products--dell-enterprise-servers--storage-and-networking-?lang=en
> >> ___
> >> Linux-PowerEdge mailing list
> >> Linux-PowerEdge@dell.com
> >> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
> >
> >
> > --
> > Greg Matthews01235 778658
> > Scientific Computing Group Leader
> > Diamond Light Source Ltd. OXON UK
> >
> > --
> > This e-mail and any attachments may contain confidential, copyright and
> or privileged material, and are for the use of the intended addressee only.
> If you are not the intended addressee or an authorised recipient of the
> addressee please notify us of receipt by returning the e-mail and do not
> use, copy, retain, distribute or disclose the information in or attached to
> the e-mail.
> > Any opinions expressed within this e-mail are those of the individual
> and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd.
> cannot guarantee that this e-mail or any attachments are free from viruses
> and we cannot accept liability for any damage which you may sustain as a
> result of software viruses which may be transmitted in or with the message.
> > Diamond Light Source Limited (company no. 4375679). Registered in
> England and Wales with its registered office at Diamond House, Harwell
> Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
> >
> > ___
> > Linux-PowerEdge mailing list
> > Linux-PowerEdge@dell.com
> > https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
>
>
> 
>
> NOTICE OF CONFIDENTIALITY:  This communication may contain privileged and
> confidential information, or may otherwise be protected from disclosure,
> and is intended solely for use of the intended recipient(s). If you are not
> the intended recipient of this communication, please notify the sender that
> you have received this communication in error and delete and destroy all
> copies in your possession.
>
> ___
> Linux-PowerEdge mailing list
> Linux-PowerEdge@dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

[Linux-PowerEdge] Catalog Updates

[Cameron Smith]

I see that the catalog at https://ftp.dell.com/catalog/ has not been
updated since March 22 2018.
The 11Gen 6.5 BIOS updates that were released on March 20 are not in that
catalog so we are three weeks out on critical BIOS updates.

Will the catalog be updated soon?

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

Re: [Linux-PowerEdge] Catalog Updates

[Cameron Smith]

Thanks Rob! :)

Looks like 2nd and 4th Friday fell on weird spans for March/April causing a
longer gap. I will check for the update this Friday.

Cameron
On Wed, Apr 11, 2018 at 11:51 AM, <rob.schnitzl...@dell.com> wrote:

> The catalog is updated on the 2nd and 4th Friday of each month.  It
> unfortunately must not have made the cut before the last publication.  We
> should check again in 2 days when the next update occurs.
>
> From: linux-poweredge-bounces-Lists On Behalf Of Cameron Smith
> Sent: Wednesday, April 11, 2018 1:37 PM
> To: linux-poweredge-Lists
> Subject: [Linux-PowerEdge] Catalog Updates
>
> I see that the catalog at https://ftp.dell.com/catalog/ has not been
> updated since March 22 2018.
> The 11Gen 6.5 BIOS updates that were released on March 20 are not in that
> catalog so we are three weeks out on critical BIOS updates.
>
> Will the catalog be updated soon?
>
> Cameron
>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

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] Disk temperature

[Cameron Smith]

[EXTERNAL EMAIL] 

I install use MegaCLI for this:

MegaCli -PDList -aALL |grep Temperature

Cameron



On Thu, Oct 10, 2019 at 9:04 AM Onno Zweers  wrote:

> Hi all,
>
> Does anyone know how to get the temperature of the disks connected to a
> Perc H730?
>
> Kind regards
> Onno
> --
> Onno Zweers, systems expert
> Online Data Services
> SURFsara, the Dutch national supercomputing center
> https://www.surfsara.nl
> onno.zwe...@surfsara.nl
> Phone +31-(0)6-19039004
>
>
>
>
> ___
> Linux-PowerEdge mailing list
> Linux-PowerEdge@dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
___
Linux-PowerEdge mailing list
Linux-PowerEdge@dell.com
https://lists.us.dell.com/mailman/listinfo/linux-poweredge

Re: [Linux-PowerEdge] Latest DSU - Not updating CPLD or PS firmware.

[Cameron Smith]

@Klaas

This is why I moved to OME years ago.

Cameron



On Tue, Mar 3, 2020 at 11:53 PM  wrote:

> Hi,
> so is it recommended that I update it on all my Dell Servers or not? :)
>  From a customer point of view: If you want me to update CPLD regularly
> I would expect it to show up in the default yum repo and I would expect
> DSU to be able to handle the CPLD updates properly (ie not applying them
> with other updates). Otherwise this means I have to do a lot of manual
> work or write my own dsu replacement
>
> Greetings
> Klaas
>
> On 02.03.20 21:57, james.har...@dell.com wrote:
> > Dell Customer Communication - Confidential
> >
> > Hello All,
> >
> > Just to interject, the CPLD has to be applied independent of all other
> firmware updates, failure to do so can result in a motherboard failure. For
> this reason it was removed from the repo. Updating the CPLD is perfectly
> fine as long as its done independent of all other firmware updates.
> >
> >
> https://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverid=5j9kp=wst14=poweredge-r740
> >
> > NOTE:
> > The server should never be powered down while this update is executing.
> >
> > When updating CPLD using IDRAC/Lifecycle Controller, DUP update should
> always be executed as a standalone task and never queued up with other
> updates.
> >
> >
> >
> > -Original Message-
> > From: linux-poweredge-bounces-Lists <
> linux-poweredge-boun...@lists.us.dell.com> On Behalf Of S, Muniswamy
> Setty_K
> > Sent: Wednesday, February 26, 2020 11:09 AM
> > To: klaasdem...@gmail.com; Schnitzlein, Rob; Gore, Santosh;
> linux-poweredge-Lists
> > Subject: Re: [Linux-PowerEdge] Latest DSU - Not updating CPLD or PS
> firmware.
> >
> > Dell Customer Communication - Confidential
> >
> > Yes, your understanding is correct.
> >
> > -Regards,
> > Muni
> >
> > -Original Message-
> > From: linux-poweredge-bounces-Lists <
> linux-poweredge-boun...@lists.us.dell.com> On Behalf Of
> klaasdem...@gmail.com
> > Sent: Wednesday, February 26, 2020 9:42 PM
> > To: Schnitzlein, Rob; Gore, Santosh; linux-poweredge-Lists
> > Subject: Re: [Linux-PowerEdge] Latest DSU - Not updating CPLD or PS
> firmware.
> >
> > Just to be clear that I am understanding this correctly:
> > Dells recommendation for CPLD and power supply upgrades is "don't do
> them unless prompted by support" and that's why they are not part of the
> default catalog?
> >
> >
> > Greetings
> > Klaas
> >
> > On 26.02.20 16:40, rob.schnitzl...@dell.com wrote:
> >> Dell Customer Communication - Confidential
> >>
> >> I've run into this before, and the feedback I got from engineering is
> that the risk of something going wrong during a CPLD update (any sort of
> power fluctuation) could brick the server.  And CPLD updates should only be
> run to fix specific issues (such as the 13G blade issue we saw
> previously).  This isn't like BIOS or NIC FW where there are relatively
> frequent updates.
> >>
> >> -Original Message-
> >> From: linux-poweredge-bounces-Lists
> >>  On Behalf Of
> >> klaasdem...@gmail.com
> >> Sent: Wednesday, February 26, 2020 3:33 AM
> >> To: Gore, Santosh; linux-poweredge-Lists
> >> Subject: Re: [Linux-PowerEdge] Latest DSU - Not updating CPLD or PS
> firmware.
> >>
> >> Why are those two components excluded from the default?
> >>
> >>
> >> On 26.02.20 09:37, santosh.g...@dell.com wrote:
> >>> Sorry for typo in below email…. The CPLD and Power Supply firmware
> >>> packages are *NOT* included in the default catalog
> >>>
> >>> *From:* linux-poweredge-bounces-Lists
> >>>  *On Behalf Of *Gore,
> >>> Santosh
> >>> *Sent:* Wednesday, February 26, 2020 1:45 PM
> >>> *To:* nathanial.ma...@hostopia.com.au; linux-poweredge-Lists
> >>> *Subject:* Re: [Linux-PowerEdge] Latest DSU - Not updating CPLD or PS
> >>> firmware.
> >>>
> >>> Hi
> >>>
> >>> The CPLD and Power Supply firmware packages are *NOT * included in
> >>> the default catalog. If you want to update the PowerSupply and CPLD
> >>> then create a repository with DellEMC Repository Manager ( DRM) tool
> >>> by importing PowerSupply and CPLD components in repository. Then use
> >>> exported repository to update CPLD and PowerSupply components using
> DSU.
> >>>
> >>> The information and download of DRM is available in link -
> >>> https://www.dell.com/support/article/us/en/04/sln283183/support-for-d
> >>> e ll-emc-repository-manager-drm?lang=en#download
> >>>
> >>> Thanks
> >>>
> >>> Santosh
> >>>
> >>> *From:* linux-poweredge-bounces-Lists
> >>>  >>> > *On Behalf Of
> >>> *Nathanial Marsh
> >>> *Sent:* Wednesday, February 26, 2020 1:35 PM
> >>> *To:* linux-poweredge-Lists
> >>> *Subject:* [Linux-PowerEdge] Latest DSU - Not updating CPLD or PS
> >>> firmware.
> >>>
> >>> [EXTERNAL EMAIL]
> >>>
> >>> Hi All
> >>>
> >>> We have been using a Linux Live OS with some Ansible magic for quite
> >>> some time now to update our servers except it has recently come to my
> >>> attention