[Linux-PowerEdge] Removing storage connected to external HBA on running server

[Chris Lajoie]

Hi, I need to remove an old MD1000 array that is connected via external HBA on 
one of my servers, and I need to do it without shutting the server down. This 
appears to be possible but there are many steps to get it done safely. The 
server runs XenServer 6.5, so I plan to roughly follow the instructions 
provided by RedHat for RHEL 5.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/removing_devices.html

After following those instructions to remove all references to the device from 
the running OS, I guess I need to remove it from the controller config so it 
doesn't think something is wrong when its missing... this is the part where I'm 
not sure what needs to be done. Do I just remove the vdisk with 
omconfig storage vdisk action=deletevdisk controller= vdisk=

Is that all that is needed to get the controller to forget about this disk 
array?

As a small bit of clarification, there is only 1 vdisk that encompasses the 
entire array.

I would appreciate any advice or instructions you can provide. Thank you.

Chris

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

Re: [Linux-PowerEdge] dsu performs a 'yum upgrade -y' when upgrading firmware

[Giulio]

On Mon, Mar 7, 2016 at 5:02 PM,   wrote:

> DSU only facilitates the system updates using the packages provided by
> various teams.

Can you explain this:

# strings /usr/sbin/dsu | grep "yum.*upgrade"
yum upgrade -y
#

what's the purpose of dsu using "yum upgrade -y"?


# rpm -q dell-system-update
dell-system-update-1.2-16.02.00.x86_64
#

Thanks

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

Re: [Linux-PowerEdge] Segfaults, unable to detect RAID controller

[Kyle Johnson]

Thanks for this fix. I noticed my path was a little different as well..
Instead of

*sed -i -e 's/\x00release_date\x00/\x00version\x00\x00\x00\x00\x00\x00/'
/opt/dell/srvadmin/lib64/libstorelib.so.4.20.1-0*

*I have:*

*sed -i -e 's/\x00release_date\x00/\x00version\x00\x00\x00\x00\x00\x00/'
/opt/dell/srvadmin/lib/libstorelib.so.4.14-0*


On Fri, Mar 4, 2016 at 12:30 PM, Mike Leong  wrote:

> I got it fix by binary patching the libstorelib.so as described here:
>
> http://lists.us.dell.com/pipermail/linux-poweredge/2015-May/049784.html
>
> Note: the filename on my setup is libstorelib.so.4.14-0 not .20 as in the
> link.
>
> mike
>
> On Fri, Mar 4, 2016 at 9:33 AM, Mike Leong  wrote:
>
>> Our R620 w/ on Ubuntu 14.04 and 3.13.0-43-generic kernel works fine w/
>> OMSA.  Have you tried that kernel?
>>
>> On Wed, Mar 2, 2016 at 7:02 AM, Kyle Johnson 
>> wrote:
>>
>>> If someone does has a way to fix this, I'd love to know it as well.  I
>>> get the exact same message with my setup on my R510.  Worked fine prior to
>>> 14.04
>>>
>>> On Mon, Feb 29, 2016 at 12:57 PM, Mike Leong 
>>> wrote:
>>>
 I'm running Ubuntu 14.04 amd64 w/ kernel 3.19.0-26-generic and OMSA
 7.4.0.  (Note: I have to run that kernel as that's certified/supported by a
 product we're using).

 I'm getting this:
 root@ams1poscmp12:~# omreport storage controller
 No controllers found

 Other checks such as "omreport chassis" works fine

 
 On dmesg:
 [  408.523894] traps: dsm_sa_datamgrd[9316] general protection
 ip:7f14dc2fc99d sp:7f14d7f98e40 error:0 in
 libdcsupt.so.7.4.0[7f14dc2db000+2d000]
 [  408.541446] Core dump to |/usr/share/apport/apport 9096 11 0 9096
 pipe failed

 Note: /usr/share/apport/apport doesn't seems to exist on ubuntu

 -
 on /var/log/syslog:
 Server_Administrator: 15110 2314 - Storage Service  The initialization
 sequence of SAS components failed during system startup. SAS management and
 monitoring is not possible.

 Any ideas on how to troubleshoot this?

 mike

 ___
 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] dsu performs a 'yum upgrade -y' when upgrading firmware

[Soorej_Ponnandi]

Dell - Internal Use - Confidential
Hi,

DSU only facilitates the system updates using the packages provided by various 
teams. We are currently facing issues with OMSA updates using yum and we are 
working with OMSA engg: team to make the experience better. This will be 
addressed soon.

Thanks,
Soorej


-Original Message-
From: linux-poweredge-bounces-Lists On Behalf Of Kilian Cavalotti
Sent: Saturday, March 5, 2016 4:23 AM
To: Luke Pyzowski
Cc: linux-poweredge-Lists
Subject: Re: [Linux-PowerEdge] dsu performs a 'yum upgrade -y' when upgrading 
firmware

On Fri, Mar 4, 2016 at 12:23 PM, Luke Pyzowski wrote:
> Why does dsu perform a "yum upgrade -y" when installing firmware? (Run
> strings on the dsu binary to verify for yourself) This command will
> upgrade everything on a system - and often system administrators may
> put something into custom yum repos but not install it intentionally.
> This is extremely poor behavior on the part of the dsu tool and I was
> very surprised to see it. This option must be configurable by the
> administrator. Further, it should only upgrade dell related items -
> at the very most. You are specifying to update _all_ system software
> on the OS AND you pass the -y argument to it to approve the install
> without letting an administrator intervene. This behavior is
> completely unacceptable and needs to be addressed.

I absolutely agree. Reading this mailing list for the past few months has been 
an absolutely flooring experience.

At this point, it's time to realize that DSU is a failure: it is so riddled 
with design flaws that it would only make sense to start again from scratch. 
That's exactly what happened to the previous firmware-tools, which have been 
working fine for years, until somebody decided to scrap it for unknown reasons. 
DSU is not up to the mark, by far. Competitors have better tools now, and what 
once made Dell lead the field of linux management tools is no more.

If you guys want to retain that advantage, that made a lot of us prefer to deal 
with Dell hardware instead of others', this needs to be fixed.

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