Curtis Brown | 1 Mar 2009 06:07

upgrading to Debian 5.0


Jared wrote:
> The biggest thing that worries me based on what I've read so far is the
> mdadm/RAID issue.  I have a PERC5/i on a PE 2950.  Is this something
> that I should look out for?  I'm using hardware RAID w/ LVM, and I
> believe that mdadm only comes into play with software RAIDs, so I think
> I should be safe here.  I'd rather be safe than sorry, though.

I just wanted to offer my experiences. Although it's not Debian 
related, this sounds a lot like a problem I ran into with mdadm 
and SCSI disks.

I was tasked to install RedHat Fedora 10 on a PowerEdge 2650. 
The install seemed to work fine. I made my logical volumes, set 
the hostname, ip, timezone, etc. It downloaded RPMs and processed 
them just fine. Everything looked smooth until the reboot into 
the newly installed kernel. The kernel loaded up and then hung 
around a line saying "waiting for root filesystem". I tried a 
couple of things like smart scan the disks, redo the install, and 
so on. But I had to google for an answer.

I found a long-winded dicussion here...
http://forums.fedoraforum.org/showthread.php?t=205115

The problem seemed to center around mdadm not waiting for some 
kind of scsi scan to complete, at the best I could understand. 
The most touted answer had to do with mounting your /boot 
filesystem, chroot'ing to it and then use mkinitrd with a 
--with=scsi_wait_scan option. Other people described using UUIDs 
in grub's menu.lst. What had worked for me was a reletively easy 
(Continue reading)

Tim Robertson | 1 Mar 2009 22:27
Picon
Favicon

perc6 managed raid, disks randomly going into "unknown" state

Hi everyone,

We have a perc6-managed RAID array whose disks have recently begun
entering  "unknown" states, seemingly at random, with no data loss.
Have any of you experienced this before?  None of the drives have
failures predicted, the hardware is quite new (all within the last
year), and the unknown states are sporadic and random (i.e. different
disks will go "unknown" at different times).  I have so far been able
to re-set the states by restarting the server.

Have any of you ever experienced this sort of thing?  Should we be
anticipating a failure?

Thanks in advance for your help,

Tim

_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge <at> dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq

Avleen Vig | 2 Mar 2009 04:47
Picon

Megasas driver lock?

Poweredge 2950
PERC 6/i
Running Ubuntu with a 2.6.24-23 kernel.

For a few months, a seeming "random" times, the server has been crashing
and resetting or locking up, with no diagnostic data returned.

Running various diagnostic tools hadn't revealed anything.
Most of the crashes I'm aware of had a common trait, where there was a
lot of disk activity (lots of interrupts from megasas).
I tried to reproduce it a few times with bonnie but couldn't make the
system crash.

It happened again tonight, and I saw this on a terminal I fortunately
had open:
  kernel: [3542884.516547] Disabling IRQ #16
IRQ16 is megasas.

This was moments after our monitoring system reported a system load of
just over 85.
The box deadlocked.

Does anyone have any suggestions? I'm out of ideas.

--

-- 
Avleen Vig
Systems Administrator
Personal: www.silverwraith.com

_______________________________________________
(Continue reading)

Sid Young | 2 Mar 2009 05:06
Picon

PS5000 Serial Console

 

G’Day,

 

I am trying to connect an iSCSI based PS5000 to a del 2950 via iSCSI but I don’t know the serial console account and password of the PS5000 array, is there a default account and password that comes with the array when shipped from the factory?

 

 

 

Sid Young

 

General Notice and Disclaimer: GXS, Access Business Information, UrbisPro, RealtyPro, Webmap, SearchAus, Inspex, Aussearch, OnlineLegal, Open Practice and OP Solutions are wholly owned entities of GlobalX Information Services Pty Ltd (GIS) ABN 00 073 436 414. GIS believes that the information contained in this document is accurate when issued. However, e-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore GIS does not warrant that such information is accurate, reliable, complete or up to date, and, to the fullest extent permitted by law, disclaims all liability of GIS and its Associates for any loss or damage suffered by any person by reason of the use by that person of, or their reliance on, any information contained in this document or any error or defect in this document, whether arising from the negligence of GIS or its Associates or otherwise. Confidential Communication: Should this email contain confidential within the subject line, then this e-mail message and any attachments contain copyright material of GIS and/or information that is confidential and subject to privilege. If you are not the intended recipient of this e-mail, please contact GIS immediately by return e-mail or by telephone on 1300 362 585 or +61 2 9429 8900. In this case, you must not read, print, disseminate, copy, store or act in reliance on this e-mail or any of the accompanying attachments; and you must destroy all copies of this e-mail message. This notice should not be removed.
_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge <at> dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq
Harald_Jensas | 2 Mar 2009 08:06
Picon
Favicon

RE: PS5000 Serial Console

From: linux-poweredge-bounces <at> dell.com [mailto:linux-poweredge-bounces <at> dell.com] On Behalf Of
Sid Young
Sent: den 2 mars 2009 05:06
To: linux-poweredge-Lists
Subject: PS5000 Serial Console

Factory default on EQL boxes is:

User: 	grpadmin
Password: 	grpadmin 

Regerds
Harald Jensås 

_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge <at> dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq

Christopher Stura | 2 Mar 2009 08:36
Picon

Re: Megasas driver lock?

I had the same problem using kernel 2.6.18 on a configuration identical 
to yours. Here is the trick. you have to download the dell omsa (open 
manage package) which will install a program that will load a 
supplimentary mptsas module into the kernel (supposedly) so that 
openmanage can comunicate with the controller. Once you install this 
package (which will load a module) that wraps calls to the megasas 
driver, you should no longer get crashes on the machine, but randomic 
crashes of the megasas module under the wrapper driver. (this is not 
good) however the machine stay's up and running and you only experince 
random delays in writeback to the disk array.

In the end with the error's produced once the wrapper driver was 
installed which you will find in dmesg, and not anywhere else, DELL in 
the end replace the backplain and the Perc SAS controller on my 2950, 
and even the random writeback crashes disapeared. It took me 45 days 
with DELL tecnical support to get to this solution. (the only thing is 
that you might need to revert to kernel 2.6.18) to get the wrapper 
driver to work on your server. I am sure you can find a Ubuntu kernel 
2.6.18 for your distribution if that is a problem.

Hope this helps

Chris.

Avleen Vig wrote:
> Poweredge 2950
> PERC 6/i
> Running Ubuntu with a 2.6.24-23 kernel.
>
> For a few months, a seeming "random" times, the server has been crashing
> and resetting or locking up, with no diagnostic data returned.
>
> Running various diagnostic tools hadn't revealed anything.
> Most of the crashes I'm aware of had a common trait, where there was a
> lot of disk activity (lots of interrupts from megasas).
> I tried to reproduce it a few times with bonnie but couldn't make the
> system crash.
>
> It happened again tonight, and I saw this on a terminal I fortunately
> had open:
>   kernel: [3542884.516547] Disabling IRQ #16
> IRQ16 is megasas.
>
> This was moments after our monitoring system reported a system load of
> just over 85.
> The box deadlocked.
>
>
> Does anyone have any suggestions? I'm out of ideas.
>
>   

_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge <at> dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq

John LLOYD | 2 Mar 2009 17:27

RE: upgrading to Debian 5.0

> I found a long-winded dicussion here...
> http://forums.fedoraforum.org/showthread.php?t=205115
> 
> The problem seemed to center around mdadm not waiting for some 
> kind of scsi scan to complete, at the best I could understand. 
> The most touted answer had to do with mounting your /boot 
> filesystem, chroot'ing to it and then use mkinitrd with a 
> --with=scsi_wait_scan option. Other people described using UUIDs 
> in grub's menu.lst. What had worked for me was a reletively easy 
> solution: adding scsi_mod.scan=sync to the kernel line in menu.lst.

I didn't see any discussion of mdadm in a (very quick) scan over that
list.  In any case, if that was indeed the problem, if you are using lvm
then md is presumably not necessary. Why wouldn't you just turn off
mdadm in the system startup?  

Just curious.

--John

_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge <at> dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq

Jason Slagle | 2 Mar 2009 20:18
Gravatar

HUGE Repo mirror..

Hi guys,

I'm currently reposyncing the OMSA 5.5 repo down to my local Yum 
repository (Cobbler).

However, it seems to be HUGE:

dell                                                           21714/21714

It takes forever for dependancies to resolve now.

I'm rsyncing using -H as suggested.

Thoughts?  Advice?

Jason

--

-- 
Jason Slagle - RHCE
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ /   ASCII Ribbon Campaign  .
  X  - NO HTML/RTF in e-mail  .
/ \ - NO Word docs in e-mail .

_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge <at> dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq

Ray Van Dolson | 2 Mar 2009 20:22
Favicon

Re: HUGE Repo mirror..

On Mon, Mar 02, 2009 at 11:18:04AM -0800, Jason Slagle wrote:
> Hi guys,
> 
> I'm currently reposyncing the OMSA 5.5 repo down to my local Yum 
> repository (Cobbler).
> 
> However, it seems to be HUGE:
> 
> dell                                                           21714/21714
> 
> It takes forever for dependancies to resolve now.
> 
> I'm rsyncing using -H as suggested.
> 
> Thoughts?  Advice?
> 
> Jason

No advice but I've been thinking about mirroring it as well and am
curious how much space it takes up when you're finished. :-)

Ray

_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge <at> dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq

Jeff Boyce | 2 Mar 2009 20:40

Re: Expanding RAID5 guidance - SOLUTION/RESULTS

See posting at bottom.

----- Original Message ----- 
From: "Jeff Boyce" <jboyce <at> meridianenv.com>
To: <linux-poweredge <at> dell.com>
Sent: Friday, January 30, 2009 2:33 PM
Subject: Expanding RAID5 guidance

> Greetings -
>
> I am a novice Linux user that manages a file server for a small business 
> and am looking for a little general guidance on understanding the right 
> steps for expanding the storage capacity on a Dell Server.  Sorry for the 
> long post, but I know how irritating it is when people don't describe 
> their objective or provide all the details for someone else to understand 
> the problem.
>
> Existing Server Setup:
>   Dell PE 2600
>   PERC 4/Di
>   3 - 36GB hard drives in Raid5
>   1 - 36GB dedicated hot spare
>   No LVM used
>   RHEL 3 update 9
>   OMSA 5.1
>   Used as small office Samba file server
>
> Proposed Objective:
>   Add 2 - 36GB drives in remaining spare slots
>   Expand Raid5 to include the added space
>   Make use of the added space by users of the file server
>
> I know the first rule of thumb with managing raids and file systems is to 
> have good backups (multiple backups are better) and I am writing up a 
> detailed list of additional files to backup besides my home and data 
> directories, so I think I have this covered.  My second task has been to 
> make sure that I have a rescue disk or reinstallation disks available in 
> case its needed.  If OS installation becomes necessary for some reason I 
> am considering upgrading to 5.2 (but that is beside the point).
>
> I have read through the OMSA user guide and feel comfortable going through 
> the task to physically install the new drives, and the steps for 
> reconfiguring the existing virtual disk.  This point is were my 
> information and comfort level begins to fall apart.  The first questions 
> that I would like answered is:
>
> 1.  How long does the reconfiguration process take (I will do this on a 
> weekend when no one is using the system)?
> 2.  How do I know when the reconfiguration process is done (something the 
> user guide doesn't describe)?  As you can see I want to know what to 
> expect (good or bad) prior to completing the reconfiguration.
>
> Then from my reading of numerous descriptions of expanding raids through 
> google searches (including a decent summary of the steps written by Matt 
> Domsch (Expanding Storage on Linux-based Servers, Feb. 2003) it appears 
> that I will need to expand the file system to use the new space; but do I 
> also need to add/create a new partition for this space, or can I expand an 
> existing partition into this space.  What I would like to do is just 
> expand one or two existing partitions and distribute this space among 
> them, if that is possible (see fstab listed below).  So my next questions 
> would be:
>
> 3.  What are the general steps that I need to do after my raid 
> reconfiguration is complete to achieve my general objective?
> 4.  Would it be possible to add the new space to one or two existing 
> partitions?  I am thinking sda2 and sda10 (/ecosystem is our samba share 
> data directory that would be given 90% of the new space).
> 5.  Will I need to add/create a new partition (and samba mount point) to 
> make use of the new space?  If so I could reorganize our data files to 
> make use of two samba mount points.
> 6.  Any other pitfalls I should be aware of, such as what steps need to be 
> done on unmounted drives?
>
> Thanks for any and all comments and suggestions; good howto links are 
> always welcome.
>
> FSTAB
> -------------------------
> LABEL=/                 /                       ext3    defaults        1 
> 1
> LABEL=/boot             /boot                   ext2    defaults        1 
> 2
> none                    /dev/pts                devpts  gid=5,mode=620  0 
> 0
> none                    /proc                   proc    defaults        0 
> 0
> none                    /dev/shm                tmpfs   defaults        0 
> 0
> LABEL=/tmp              /tmp                    ext3    defaults        1 
> 2
> LABEL=/usr              /usr                    ext3    defaults        1 
> 2
> LABEL=/var              /var                    ext3    defaults        1 
> 2
> /dev/sda9               swap                    swap    defaults        0 
> 0
> /dev/sda2  /home  ext3  defaults 1 2
> /dev/cdrom              /mnt/cdrom              udf,iso9660 
> noauto,owner,kudzu,ro 0 0
> /dev/fd0                /mnt/floppy             auto    noauto,owner,kudzu 
> 0 0
> /dev/st0  /mnt/tape  ext3 noauto,owner,kudzu 0 0
> /dev/sda10 /ecosystem ext3 defaults 1 2
>
> RECENT LOGWATCH OUTPUT
> ------------------ Disk Space --------------------
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sda7             2.0G  1.5G  385M  80% /
> /dev/sda3             190M   54M  128M  30% /boot
> none                  501M     0  501M   0% /dev/shm
> /dev/sda8            1012M   33M  928M   4% /tmp
> /dev/sda5             9.7G  2.8G  6.4G  31% /usr
> /dev/sda6             9.7G  2.9G  6.3G  32% /var
> /dev/sda2             2.5G  2.0G  443M  82% /home
> /dev/sda10             40G   35G  3.7G  91% /ecosystem
>
>
> Jeff Boyce
> www.meridianenv.com

I finally had my scheduled maintenance down time and completed this task.  I 
thought I would share generally what I did and how I did it in case there 
are other novice administrators out there interested.

1.  Ran my normal tape backup on the Friday night before the down weekend to 
backup all data files.
2.  Rebooted the system to verify it shuts down and restarts properly. 
System had been up 450+ days so this initiated a file system check which was 
also my plan.
3.  Modified my /etc/fstab so that I could mount a usb flash drive and a usb 
connected portable hard drive.
4.  Copied some specific rpm's and system files to the flash drive.
5.  Installed GParted LiveCD and rebooted so that the drives were not 
mounted.
6.  Made an image of the server onto the usb connected portable hard drive. 
In case something goes very wrong in subsequent steps.
        # dd if=/dev/sda of=/dev/sdb bs=8192 conv=noerror,sync
        This does not give any progress report to indicate how long it would 
take so I opened another terminal and ran the following command to force the 
dd command to give me a periodic status report.
        # watch -n120 -- pkill -USR1 ^dd$
        Since the usb transfer rate was 1.1 MB/sec it took about 18 hours to 
transfer about 70 GB.
7.  Unmounted the usb portable drive, shut down GParted, and powered down 
the server.
8.  Vacuumed all the dust from the server and installed the two new hard 
drives in my last open slots.
9.  Rebooted the system in the standard OS in order to use OMSA tools.
10.  In OMSA selected the Virtual Disk, chose the reconfigure task, and 
selected execute to step through the steps to select the new physical disks 
to include in the virtual disk, the raid type, and the size for the 
reconfigured virtual disk.
11.  OMSA gives a progress report during the reconfiguration process.  It 
took about 1 hour and 10 minutes to complete reconfiguring a 3 disk raid 5 
of 67GB to a 5 disk raid 5 of 135GB.
12.  Reboot the server using the GParted LiveCD so that the drives were not 
mounted.
13.  My goal was to just expand my existing last partition (sda10) into the 
new space.  However I realized that I had to expand my existing "extended 
partition" (sda4) first to include the new space, then expand the last 
partition (sda10) and grow the filesystem into the space.
14.  Remove the GParted LiveCD and rebooted to the standard OS.
15.  Checked OMSA Virtual Disk and it indicated that it was conducting a 
background initialization, which took about 1 hour to complete.
16.  Checked the new size of the Samba share (sda10) on a Windows client box 
and everything looked good.

When I returned to the office on Monday morning the staff was working on the 
Samba share without even noticing anything had changed.  I am glad no one 
noticed the change.  Success goes unnoticed by normal users, failure gets 
noticed.  I would like to thank everyone that educated me and gave me 
guidance (both on- an off-list) on how to complete this task and what to 
expect.  And I hope now that some other novice might learn from my 
description.

Jeff Boyce
www.meridianenv.com

_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge <at> dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq


Gmane