Upgrading PE4400 from RH7.0 to RH7.3?
Brian P Kasper
Brian.P.Kasper at aero.org
Mon Aug 4 10:55:00 CDT 2003
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 following:
>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 dell/redhat!)
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 array.
>> 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
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
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 every
> 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 released
> 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
More information about the Linux-PowerEdge