Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
As a standard and when possible I like to do raid1 just for failover or easy recovery. I was my first time I wanted to try the onboard HW raid controller and all the trouble I have ran into I gave up on it and found a true HW raid controller. I am going to try it this morning. If it fails I will do the traditional SW raid. On 5/16/2012 12:02 AM, Eric Shubert wrote: FWIW, stay away from raid-5 if at all possible. Raid-1 is best, raid-10 ok. -- David Milholen Project Engineer P:501-318-1300
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
IMHO, data protection is a MUST, and thus RAID is a MUST for QMAIL (and other client services like web servers and the like). The question isn't about RAID/NO-RAID, it is about WHICH RAID and HOW: To my mind, RAID decisions come in TWO flavors: - RAID TECHNOLOGY (e.g.: RAID-1 vs RAID-5 vs. RAID-10 -- the 3 most common types of RAID today), and - RAID IMPLEMENTATION (e.g.: Motherboard RAID [aka: Fake-RAID], Hardware RAID, and Software [Linux md] RAID) MY OPINIONS are: _From a RAID IMPLEMENTATION perspective, I have found the following to be true:_ - Motherboard-based (firmware-based) RAID (any flavor) = *UNSTABLE *in most Linux environments -- _*AVOID*_ - *Hardware RAID = BEST performance, BEST reliability, more expensive* - Software (Linux-based) RAID = GOOD performance, GOOD reliability, LOWEST EXPENSE (a common choice -- I know others favor the Linux RAID, and I'll admit that I'm still a hardware RAID snob! -- but these are MY opinions! _When it comes to RAID TECHNOLOGY, for me the choice is rather clear:_ - RAID 10 = BEST STABILITY, BEST PERFORMANCE, HIGH EXPENSE - IMHO not usually worth the cost/complexity unless you need a HUGE or FAST volume - *RAID 1 = BEST STABILITY, GOOD PERFORMANCE, MODERATE EXPENSE - IMHO overall best HW RAID bang-for-the-buck (and my usual choice)* - RAID 5 = GOOD STABILITY, IFFY PERFORMANCE, LOWEST EXPENSE - undegraded performance same as RAID 1, DEGRADED performance is POOR So you'll see that I agree with David and Eric on some of these points... and I know we differ on others... that's what opinions are all about! Dan McAllister IT4SOHO On 5/16/2012 7:58 AM, David Milholen wrote: As a standard and when possible I like to do raid1 just for failover or easy recovery. I was my first time I wanted to try the onboard HW raid controller and all the trouble I have ran into I gave up on it and found a true HW raid controller. I am going to try it this morning. If it fails I will do the traditional SW raid. On 5/16/2012 12:02 AM, Eric Shubert wrote: FWIW, stay away from raid-5 if at all possible. Raid-1 is best, raid-10 ok. -- David Milholen Project Engineer P:501-318-1300 -- IT4SOHO, LLC PO Box 507 St. Petersburg, FL 33731-0507 CALL TOLL FREE: 877-IT4SOHO We have support plans for QMail!
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
I never did alot with RAIDs, but all were hardware and not one ever worked as advertised for recovery. I prefer a solid mirrored backup. To each his own. On 05/16/2012 07:59 AM, Dan McAllister wrote: IMHO, data protection is a MUST, and thus RAID is a MUST for QMAIL (and other client services like web servers and the like). The question isn't about RAID/NO-RAID, it is about WHICH RAID and HOW: To my mind, RAID decisions come in TWO flavors: - RAID TECHNOLOGY (e.g.: RAID-1 vs RAID-5 vs. RAID-10 -- the 3 most common types of RAID today), and - RAID IMPLEMENTATION (e.g.: Motherboard RAID [aka: Fake-RAID], Hardware RAID, and Software [Linux md] RAID) MY OPINIONS are: From a RAID IMPLEMENTATION perspective, I have found the following to be true: - Motherboard-based (firmware-based) RAID (any flavor) = UNSTABLE in most Linux environments -- AVOID - Hardware RAID = BEST performance, BEST reliability, more expensive - Software (Linux-based) RAID = GOOD performance, GOOD reliability, LOWEST EXPENSE (a common choice -- I know others favor the Linux RAID, and I'll admit that I'm still a hardware RAID snob! -- but these are MY opinions! When it comes to RAID TECHNOLOGY, for me the choice is rather clear: - RAID 10 = BEST STABILITY, BEST PERFORMANCE, HIGH EXPENSE - IMHO not usually worth the cost/complexity unless you need a HUGE or FAST volume - RAID 1 = BEST STABILITY, GOOD PERFORMANCE, MODERATE EXPENSE - IMHO overall best HW RAID bang-for-the-buck (and my usual choice) - RAID 5 = GOOD STABILITY, IFFY PERFORMANCE, LOWEST EXPENSE - undegraded performance same as RAID 1, DEGRADED performance is POOR So you'll see that I agree with David and Eric on some of these points... and I know we differ on others... that's what opinions are all about! Dan McAllister IT4SOHO On 5/16/2012 7:58 AM, David Milholen wrote: As a standard and when possible I like to do raid1 just for failover or easy recovery. I was my first time I wanted to try the onboard HW raid controller and all the trouble I have ran into I gave up on it and found a true HW raid controller. I am going to try it this morning. If it fails I will do the traditional SW raid. On 5/16/2012 12:02 AM, Eric Shubert wrote: FWIW, stay away from raid-5 if at all possible. Raid-1 is best, raid-10 ok. -- David Milholen Project Engineer P:501-318-1300 -- IT4SOHO, LLC PO Box 507 St. Petersburg, FL 33731-0507 CALL TOLL FREE: 877-IT4SOHO We have support plans for QMail! --
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
I used to be a fan of ADAPTEC RAID, but TWICE I had an issue where a RAID1 mirror recovered from the wrong disk, thus erasing TONS of data that had to be recovered from backups (archives, to be more language-correct). In both cases, ADAPTEC admitted that it was a flaw in their firmware that re-numbered the disks without warning. (Admittedly, both were issues where the hot-swap capability was not available, and so the RAID card was booting cold with 2 drives and had to determine which was the good drive -- not the most optimal method of recovering a RAID-1 array!) Back in the early 2000's, I had good success with Promise TX-1000's (for IDE-based RAID1) -- but that is a Fake-RAID product, and while stable in RedHat 5-9, it became less so in the RHEL era. I dumped Promise when they reported that they had no plans to write drivers for the 2.6 kernel. So, I switched to 3ware (now LSI) -- and I couldn't be happier! They have given me a product (both the 9550 [PCI-X] and 9650se [PCI-E] lines] that has performed FLAWLESSLY for me for both Windows AND Linux servers. When (not IF) a drive fails, I can hot-swap in a new one -- even from a different manufacturer -- and it rebuilds the RAID 1 (or RAID-10) array without interference or input at all -- just plug and play! I have also started to use the 9750 [also PCI-E, but 6Gbps SATA/SAS], but I honestly don't have any experience with this card in a failure mode, so I'm not in a position to review it. My lowest-end servers use Linux md-RAID, and as with the 9750, I just don't have enough failure experience to judge it Just my thoughts -- you know I like to share them! :-) Dan On 5/16/2012 11:16 AM, Maxwell Smart wrote: I never did alot with RAIDs, but all were hardware and not one ever worked as advertised for recovery. I prefer a solid mirrored backup. To each his own. -- IT4SOHO, LLC PO Box 507 St. Petersburg, FL 33731-0507 CALL TOLL FREE: 877-IT4SOHO We have support plans for QMail!
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
First, that is an excellent differentiation to make Eric -- although I do sometimes use SOFTWARE RAID to MIRROR a hardware RAID drive set (essentially creating a 3rd mirror) as a form of backup... not preferred, but a valid (if expensive) way to get a point-in-time copy of the filesystem. But to me, *the MOST important thing about backups *(to tape, to hard drive, or to the cloud) *is that they *(or at least one copy, if there are many) *MUST be located AWAY from the primary data storage location! * Storing your backup media in the same building as your primary data is just begging for trouble! (Think fire, flood, meteor strike, etc!) I also found it interesting, Eric, how I'm willing to pay for the HW controller, but do NOT use RAID on my backup location, while you prefer to save on the HW controller but spend on the redundancy in the backup storage! Different histories create different priorities! :-) If my backups fail, they get restored when the backup runs again)... the only time I could get hosed would be if my backup drive(s) failed and I had a catastrophic (RAID) failure at the same time -- and since they're a continent apart (geographically), I think the risk is acceptable (given the added cost my hosting company applies to using multiple drives! As for my experience with HW cards, the Adaptec issue dates to the mid-1990's SCSI (I guess I should've made that more clear, perhaps -- yes, I've been in this business a long LONG time!) My later issue with Promise was 2-fold: a) I wasn't aware it was Fake-RAID until I'd already installed about a dozen of them, and b) in spite of the Fake-RAID implementation, it was a solid performer and did well when a drive failed... the only real problem was Promise's failure to support it in a 2.6 kernel. (By the time it was natively supported in the 2.6 kernel, I had moved on to 3ware, and as I've said before, I've had nothing but EXCELLENT results there.) FWIW - I went to Promise RAID for IDE drives when the Linux software raid (kernels 2.2 and 2.4) botched a few client's systems by continually trying to boot off a broken array with the wrong drive (a known issue at the time -- caused by BIOS re-arranging of the device mapping when the drive went away completely). I guess you could say I was gun-shy of Linux RAID until I was forced to use it for a non-profit client who literally had no money, but whose data (they are, after all, a MUSEUM) just could not be risked! But enough history - I need to suck up to the boss (er, agree with Eric) more: *Assuming a server-based SATA controller (with AHCI and NCQ enabled), I would fully agree that the performance differences between my 3ware and Eric's md (Linux) RAID would be /minimal /*-- at least on live (both drives are healthy) systems. However, the performance I look at when evaluating RAID (both technology and implementation) is the /degraded /performance -- as that's likely to be the only measurement with significant differentiation. For me, that's where the HW RAID excels... and I absolutely LOVE it when I walk into a client's office and explain to them that a drive failed in the server AND THEY NEVER EVEN NOTICED! To be fair, I have never had a problem with Linux RAID in the 2.6 kernel, but I also only have a small handful of installs running that solution. Interesting discussion - I love to hear other people's views on these topics, as it helps me to re-evaluate my own decisions and examine my own reasons for doing certain things (its far too easy to fall into the I've always done it that way trap!) Dan McAllister IT4SOHO On 5/16/2012 12:31 PM, Eric Shubert wrote: Let's be clear, that raid is *not* a backup solution. The purpose of raid is to keep the system running in the event of a hard drive failure. Sort of like a UPS does for power. You still need a backup / disaster recovery solution above and beyond raid. I recommend off-site backups (or archives if you prefer) with redundant drives there as well. I do agree with Dan for the most part as he wrote before, however I prefer a software raid implementation over hardware (as we've discussed here recently). I think SW provides best reliability while HW provides good reliability, and I'm apparently more frugal regarding expense. While HW provides slightly better performance, I don't think the improvement is worth the cost. I'm a little confused why Dan rates HW as best reliability (previous email) given the experiences he's had. ;) To be honest, I have very little experience with HW raid, but I don't have any horror stories to go along with it either. On 05/16/2012 08:34 AM, Dan McAllister wrote: I used to be a fan of ADAPTEC RAID, but TWICE I had an issue where a RAID1 mirror recovered from the wrong disk, thus erasing TONS of data that had to be recovered from backups (archives, to be more language-correct). In both cases, ADAPTEC admitted that it was a flaw in
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
Ok, So I did go with the 3ware-8006-2lp card and no issues yet.. I do prefer HW raid if it is at my disposal but its been a while since I have had to deal with this. I do remember about firmware or onboard raid was fake but did not dawn on me till I had the update issue. Went back and researched the onboard chipset and it does not support linux. So another face palm on my part. But I do like the older 3ware (ol-reliable) cards to do HW raid. I have not worked with any of the new LSI gear yet. I do Like the Supermicro servers though (FAST).. Dave On 5/16/2012 3:07 PM, Eric Shubert wrote: On 05/16/2012 11:54 AM, Dan McAllister wrote: I also found it interesting, Eric, how I'm willing to pay for the HW controller, but do NOT use RAID on my backup location, while you prefer to save on the HW controller but spend on the redundancy in the backup storage! Different histories create different priorities! :-) Yep. I think the drives are considerably less than the controllers these days. ;) Besides which, I have an ulterior motive for using a raid-1 array for backup drives. While the backups are done over the internet, I wouldn't want to even think of doing a recovery across the internet. In the event of a recovery, I would remove one of the drives from the array (they're external drives), and take it to the recovery location. That way recovery is much speedier, and the other backup drive is left online to be of service to other backups. This way the recovery process is speedy, and doesn't affect other backups that may share the same raid-1 array. Also, an extra copy of the data is left at the backup site for use in the event that something were to happen to the drive being transported. Once the recovery is complete, the drive is returned to the array and data is re-sync'd. If my backups fail, they get restored when the backup runs again)... the only time I could get hosed would be if my backup drive(s) failed and I had a catastrophic (RAID) failure at the same time -- and since they're a continent apart (geographically), I think the risk is acceptable (given the added cost my hosting company applies to using multiple drives! I don't use a hosting company. I think that self hosting is a better way to go in some cases, and I expect to see more of it in the future. I know I'm bucking against the cloud. Time will tell. However, the performance I look at when evaluating RAID (both technology and implementation) is the /degraded /performance -- as that's likely to be the only measurement with significant differentiation. Degraded performance isn't much different. However, re-synchronizing makes a big impact indeed. A 1TB drive typically resyncs in 6 hours or so though (iirc), so it's tolerable so long as the re-sync is done during off hours (presuming there are off hours). -- David Milholen Project Engineer P:501-318-1300
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
Ok, I was doing some more comparison and experimentation on this machine I want to work with HW raid. here is what I get when I run this [root@localhost ~]# blkid | sort /dev/hda: LABEL=CentQMT5-1.2.1 TYPE=iso9660 /dev/sda1: LABEL=/boot UUID=16efa862-46f7-4d34-b2e0-a2a7c8df9a3f TYPE=ext3 /dev/sda2: LABEL=/1 UUID=cb0fdf32-bcd5-4112-b6e8-9908ef872b8c SEC_TYPE=ext2 TYPE=ext3 /dev/sda3: LABEL=SWAP-isw_ddfebj TYPE=swap /dev/sdb1: LABEL=/boot UUID=16efa862-46f7-4d34-b2e0-a2a7c8df9a3f SEC_TYPE=ext2 TYPE=ext3 /dev/sdb2: LABEL=/1 UUID=cb0fdf32-bcd5-4112-b6e8-9908ef872b8c TYPE=ext3 /dev/sdb3: LABEL=SWAP-isw_ddfebj TYPE=swap I can see both drives and the LABEL has the /1 in it which I do not understand. On 05/14/2012 11:37 AM, David wrote: Here is what the default image installs before an update and it will reboot with no issue. # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/mapper/isw_digeehiaa_Raid_0p2 # initrd /initrd-version.img #boot=/dev/mapper/isw_digeehiaa_Raid_0 default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-194.8.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-194.8.1.el5 ro root=LABEL=/ initrd /initrd-2.6.18-194.8.1.el5.img The only thing different is the LABEL=/1 vs LABEL=/ I wonder if it tried to relabel but failed. more to come On 05/14/2012 10:15 AM, Eric Shubert wrote: I presume that you cannot boot the previous kernel as well? I would try modifying the root= parameter as it appears in the comment. BL appears to be that the root filesystem no longer has a label=\1, so grub cannot find it. Alternatively, you might try putting a label on the root filesystem. Sorry, but I'm not familiar off hand with how hardware raid appears to grub (I prefer software raid myself). - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com attachment: dmilholen.vcf- Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
Here is what fstab has in it.. These are all snapshots before I do the upgrade LABEL=/1/ ext3defaults1 1 LABEL=/boot /boot ext3defaults1 2 tmpfs /dev/shmtmpfs defaults0 0 devpts /dev/ptsdevpts gid=5,mode=620 0 0 sysfs /syssysfs defaults0 0 proc/proc procdefaults0 0 LABEL=SWAP-isw_ddfebj swapswapdefaults0 0 On 05/14/2012 11:37 AM, David wrote: Here is what the default image installs before an update and it will reboot with no issue. # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/mapper/isw_digeehiaa_Raid_0p2 # initrd /initrd-version.img #boot=/dev/mapper/isw_digeehiaa_Raid_0 default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-194.8.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-194.8.1.el5 ro root=LABEL=/ initrd /initrd-2.6.18-194.8.1.el5.img The only thing different is the LABEL=/1 vs LABEL=/ I wonder if it tried to relabel but failed. more to come On 05/14/2012 10:15 AM, Eric Shubert wrote: I presume that you cannot boot the previous kernel as well? I would try modifying the root= parameter as it appears in the comment. BL appears to be that the root filesystem no longer has a label=\1, so grub cannot find it. Alternatively, you might try putting a label on the root filesystem. Sorry, but I'm not familiar off hand with how hardware raid appears to grub (I prefer software raid myself). - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com attachment: dmilholen.vcf- Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
Ok, here is the device.map file in grub.. # this device map was generated by anaconda (hd0) /dev/mapper/isw_ddfebjifef_RAID_Volume0 On 05/14/2012 11:37 AM, David wrote: Here is what the default image installs before an update and it will reboot with no issue. # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/mapper/isw_digeehiaa_Raid_0p2 # initrd /initrd-version.img #boot=/dev/mapper/isw_digeehiaa_Raid_0 default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-194.8.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-194.8.1.el5 ro root=LABEL=/ initrd /initrd-2.6.18-194.8.1.el5.img The only thing different is the LABEL=/1 vs LABEL=/ I wonder if it tried to relabel but failed. more to come On 05/14/2012 10:15 AM, Eric Shubert wrote: I presume that you cannot boot the previous kernel as well? I would try modifying the root= parameter as it appears in the comment. BL appears to be that the root filesystem no longer has a label=\1, so grub cannot find it. Alternatively, you might try putting a label on the root filesystem. Sorry, but I'm not familiar off hand with how hardware raid appears to grub (I prefer software raid myself). - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com attachment: dmilholen.vcf- Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
Ok, here is the only file I find that has changed grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/mapper/isw_ddfebjifef_RAID_Volu$ # initrd /initrd-version.img #boot=/dev/mapper/isw_ddfebjifef_RAID_Volume0 default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-308.4.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-308.4.1.el5 ro root=LABEL=/1 initrd /initrd-2.6.18-308.4.1.el5.img title CentOS (2.6.18-194.8.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-194.8.1.el5 ro root=LABEL=/1 initrd /initrd-2.6.18-194.8.1.el5.img Everything else remained the same. On 05/15/2012 11:57 AM, David wrote: Ok, here is the device.map file in grub.. # this device map was generated by anaconda (hd0) /dev/mapper/isw_ddfebjifef_RAID_Volume0 On 05/14/2012 11:37 AM, David wrote: Here is what the default image installs before an update and it will reboot with no issue. # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/mapper/isw_digeehiaa_Raid_0p2 # initrd /initrd-version.img #boot=/dev/mapper/isw_digeehiaa_Raid_0 default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-194.8.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-194.8.1.el5 ro root=LABEL=/ initrd /initrd-2.6.18-194.8.1.el5.img The only thing different is the LABEL=/1 vs LABEL=/ I wonder if it tried to relabel but failed. more to come On 05/14/2012 10:15 AM, Eric Shubert wrote: I presume that you cannot boot the previous kernel as well? I would try modifying the root= parameter as it appears in the comment. BL appears to be that the root filesystem no longer has a label=\1, so grub cannot find it. Alternatively, you might try putting a label on the root filesystem. Sorry, but I'm not familiar off hand with how hardware raid appears to grub (I prefer software raid myself). - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com attachment: dmilholen.vcf- Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
Yes it is raid on the motherboard ie Intel application controller. Well, How do I get Jakes Iso to let me configure software raid? I does everything so autonomously that I do not see where or how to do that. Thanks Dave On 05/15/2012 12:30 PM, Eric Shubert wrote: IIRC, HW raid should not be showing the individual drives to linux. They should appear as a single device. I would check the raid card configuration. Did the battery on it die or something? Are you using a 'real' raid card, or raid on the MB? Raid on the MB is fake-raid, and you should steer clear of that. attachment: dmilholen.vcf- Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
I found it right after I posted ... FACE PALM:) I also dug up a 3ware true HW raid card to give a whirl and see what happens. thanks Dave On 5/15/2012 4:56 PM, Eric Shubert wrote: I don't know off hand. http://wiki.qmailtoaster.com/index.php/QMT-ISO says that there's an advanced option, which will allow you to specify the drive configuration. This is where you would defined the raid partitions and arrays. -- David Milholen Project Engineer P:501-318-1300
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
Here is what is in the menu.lst after the yum update: # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/mapper/isw_digeehiaa_Raid_0p2 # initrd /initrd-version.img #boot=/dev/mapper/isw_digeehiaa_Raid_0 default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-308.4.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-308.4.1.el5 ro root=LABEL=/1 initrd /initrd-2.6.18-308.4.1.el5.img title CentOS (2.6.18-194.8.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-194.8.1.el5 ro root=LABEL=/1 initrd /initrd-2.6.18-194.8.1.el5.img On 05/13/2012 09:46 AM, Eric Shubert wrote: On 05/12/2012 08:58 PM, David Milholen wrote: I am trying to do a yum update on a new install of QMT-ISO5-1.2 that I got from Jakes site. Only thing is when I do. The server will not boot the new kernel . It boots into Grub and a prompt and thats it. The server is running Hardware Raid. Any ideas ? Thanks Dave -- David Milholen Project Engineer P:501-318-1300 Can you boot the previous kernel? You might want to post your grub.conf contents. attachment: dmilholen.vcf- Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Qmailtoaster iso upgrade issue
Here is what the default image installs before an update and it will reboot with no issue. # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/mapper/isw_digeehiaa_Raid_0p2 # initrd /initrd-version.img #boot=/dev/mapper/isw_digeehiaa_Raid_0 default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-194.8.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-194.8.1.el5 ro root=LABEL=/ initrd /initrd-2.6.18-194.8.1.el5.img The only thing different is the LABEL=/1 vs LABEL=/ I wonder if it tried to relabel but failed. more to come On 05/14/2012 10:15 AM, Eric Shubert wrote: I presume that you cannot boot the previous kernel as well? I would try modifying the root= parameter as it appears in the comment. BL appears to be that the root filesystem no longer has a label=\1, so grub cannot find it. Alternatively, you might try putting a label on the root filesystem. Sorry, but I'm not familiar off hand with how hardware raid appears to grub (I prefer software raid myself). attachment: dmilholen.vcf- Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
