Upgrading PE4400 from RH7.0 to RH7.3?

Mon Aug 4 12:27:01 CDT 2003

It is fairly easy to replace LILO with GRUB, even before the upgrade. I can
send you steps if need be.

-----Original Message-----
From: Brian P Kasper [mailto:Brian.P.Kasper at aero.org] 
Sent: Monday, August 04, 2003 10:55 AM
To: jason andrade
Cc: linux-poweredge at dell.com
Subject: Re: Upgrading PE4400 from RH7.0 to RH7.3?

Jason --

First of all, thanks for taking the time to provide such a thoughtful &
detailed response.  Much obliged.

>4 * 36G drives (no hot spare ? tsk tsk..).

Heh.  Yep, you're right, it's a bit dangerous.  I should fix that.  I'm not
sure off the top of my head how to reconfigure the container with afacli,
but I'll look into it.

>AFAIK there are no specific bios requirements that were released for 
>any redhat versions.  The BIOS releases can be divided into the 
>o System BIOS
>o ESM/Backplane firmware
>o On Board SCSI firmware
>o other PCI card's firmware
>From talking with Dell engineers the general approach has usually been 
>to only upgrade the firmware if you hit a problem.  However there is 
>usually no problems with upgrading to the latest versions, particularly 
>on the system and onboard scsi firmware.

That's good to know.  After reading the BIOS requirements for the latest
version of ARCServe Backup, I think we're OK there, and if there's nothing
specific about 7.3, I won't worry about it unless I hit a snag.

>> My plan is to purchase the RH7.3 CDs from Dell and use them to 
>> perform
>that's nice of you - though it really isn't mandatory.  you could 
>download the redhat ISOs from your closest mirror and burn them.  
>however don't let me stop you buying CDs (and hence supporting 

I've actually already got the 7.3/X86 CDs somewhere, but I want to buy them
officially from Dell to pump up their "number of people using Linux"

>> 1) How can I determine the relevant BIOS revisions in the system 
>> without powering it off?  It's currently in very heavy use and I'd 
>> prefer to avoid downtime.
>the easiest way would have been to install/use the Dell OpenManage 
>System Administrator but that might actually be easier after you finish 
>the upgrade.  is there a specific reason you want to work out the 
>current bios revisions ?  one approach is to simply prepare all the 
>floppies in advance and then when you boot into them to upgrade you can 
>compare versions at that point (and make a decision to upgrade)

I have no specific reason and I'm not experiencing any problems, so I agree
with you, from the "if it ain't broke don't fix it" perspective, I really
*don't* want to update the BIOSes.  I asked just in case someone came back
and said "WHOA!  Yep, check Red Hat document foo, 7.3 will crash without
Adaptec AHA-2940 BIOS X.XX ...."

>see above.  i cannot comment on specifically upgrading your powervault 
>bios (you didn't say you had one or what sort above, i assumed your 
>disks were internal to the 4400!)

Yes, I have 8 drive bays, 4 of which are populated with my no-hot-spare

>> 4) When I perform the upgrade, how can I tell if I have a Utility 
>> Partition on my drive and how do I avoid clobbering it with GRUB?  Is 
>> it as simple as not installing GRUB into the boot partition?
>the utility partition will be /dev/sda1 and approx 30M in size.  i 
>believe you can avoid clobbering it by installing not into the master 
>boot record but into the boot partition (e.g /dev/sda2).  if you search 
>through the archives you'll see a better summary of how to do this from 
>one of the dell guys.

Thanks, it turns out I have one -- since I bought the system with 7.0
installed, I wasn't sure.

>personally, why do you care about having the utility partition (apart 
>from having it work when you hit F10..) since it will run fine off the 
>cdrom whenever needed which is usually only for diagnostic purposes.

I've never used it once -- I just wanted to make sure I could figure out my
exact partition configuration so I have less of a chance of doing something

>> 4a) If I upgrade 7.0 to 7.3 and switch to GRUB, does the system boot 
>> process need to be reconfigured to launch GRUB rather than LILO?
>good question.  i haven't tried to go from 7.0 to 7.3 so i can't 
>specifically say if grub will replace LILO in the mbr.. it should..

I'll look into this in the RH documentation.  I would assume that they have
a LILO-->GRUB path, but I've never tried it.  When, for fun, I tried
upgrading my home box from 7.0 to 9.0, I discovered a slew of physical
errors on my Linux drive and was unable to complete the upgrade.  Had to
pull-and-replace the drive, but it was an incredibly old 4GB SCSI drive with
nothing important on it, so it was no big deal.

>> 4b) Or can I simply keep my current LILO-based boot process?
>probably.. again, i guess someone who has actually done this should 
>reply in more detail.  i have played with using lilo as a replacement 
>to grub in 7.3/8/9 installations and it's possible but i hadn't gotten 
>around to figuring out how to back out back to grub yet :-)

Hmm, food for thought.  I'll see what happens.

>> 5) In general, is the upgrade process as straightforward as booting 
>> from the CD-ROM and following prompts?  Are there any special 
>> gotchas?
>yep.  at least it was from 7.2 -> 7.3

Cool.  I was hoping that was the case.

>> 6) I've installed the Bastille hardening script on the system; is 
>> anyone aware of incompatabilities between RH7.0 and RH7.3 for 
>> Bastille Linux?
>don't know.  but a rule of thumb is that if you change things at a 
>system level then you might have upgrade issues as the upgrade process 
>is based around the concept of going from one known state to another.  
>there is _some_ intelligence in the process but the more changes made 
>means the chance of less success during an upgrade.

OK, thanks again -- I'll keep grovelling through the Bastille web site to
see if they have any documentation.

>as the sysadmin i would say the first thing you want to look at is your 
>backup and recovery procedures.  if it all turns to custard how are you 
>going back to a known working state (to live to fight another day..) 
>and exactly how long will it take you.

Great advice!  I'd considered that, and so far the most interesting thing
I've found is a WWW page entitled "Procedure for making a bootable
recovery/rescue CD-ROM for Linux servers with non-standard vendor-supported
hardware".  I'm still investigating it.  I have current tape backups, but I
have to make sure I can use them to restore the system from scratch.

>in particular how supportive are your management (in terms of spending
>$$) of this system ?  is it a possibility for you to do something 
>lateral like buying 4 more 36G disks and as part of the process do a 
>fresh install onto a new raid set (removing the old drives and putting 
>them on a shelf as a recovery method in addition to your tape backups) 
>and then restoring data/applications onto the system ?

You know, the idea of a fresh install to new disks hadn't occurred to me.

I called RH technical support, and when they told me that there is no
upgrade path from RHL 7.x, 8.x, or 9.x to RH Enterprise Linux ES 2.1, I
scaled back to investigating 7.3, since backing up and wiping my install and
trusting that I could get everything working again after a clean install
would be really dumb.

I may actually be able to purchase new drives, perform a clean install of
RHEL-ES 2.1, migrate all the old data and settings from the old RAID
container, and then wipe and reuse the old drives.  Interesting idea; thanks
again for taking the time to think about this and respond.

>> I'm performing this upgrade because I believe that the latest version 
>> of our tape backup software (BrightStor ARCServe Backup for Linux, 
>> nee ARCServeIT for Linux) needs at least 7.3 and because I think the 
>> 2.4.x kernel will be more efficient with this system than the 2.2.x 
>> series.
>you should also consider that Red Hat 7.3 will be End of Service Lifed 
>within 4 months.  i believe this means no more patches after Dec 2003 
>(just how strictly they enforce this will be interesting) and Red Hat 
>have announce a fundamental change in the way they are doing Linux..

Yeah, I've been reading about the upcoming distinction between Enterprise
Linux and Community Linux.  Given the criticality of this system, I'd prefer
to go with Enterprise Linux anyway, and your above suggestion shows me a
low-risk way to do it.

>o Red Hat Community Linux (aka RHL 7.3, 8, 9..) which will be released 
>  4-6 months and have patch support for 1 year from release.
>o Red Hat Enterprise Linux (aka RHEL 2.1 AS/ES/WS) which will be 
>  every 18 (?) months and have patch support for 2.5 years from release.
>The current version of RHEL 2.1/ES in my experience is based on RH 7.2 
>so it might be a candidate for you to consider as an upgrade.. it 
>depends on how 'production' you consider this system to be and what 
>your future direction is with Linux in your organization.

Thanks again, Jason.  You've given me some great ideas.  I really appreciate


Linux-PowerEdge mailing list
Linux-PowerEdge at dell.com
Please read the FAQ at http://lists.us.dell.com/faq or search the list
archives at http://lists.us.dell.com/htdig/

More information about the Linux-PowerEdge mailing list