Thank you for your assistance and information.

Several comments.

1.  All of the operations I performed were done using whatever is in the 
stock repos (SL, elrepo, and the like) and whatever is in stock yum for 
SL 7.1 (the base system that had not been fully updated in a while).  If 
yum does perform the operation by first downloading all of the required 
RPM files and then starting the upgrade, the files should be on the 
machine.  It appeared from what I observed that some were downloaded, 
the upgrade began, and others were being uploaded as the upgrade 
proceeded so that two operations were happening in a multi-threaded 
manner.  That is a guess as I do not know where to look for the detailed 
logs as the system will boot (but no Xwindows).

2.  The mirrored RAID was done using whatever was "stock" in SL7 at that 
epoch -- no outside special RAID was used.  Clearly, the information I 
provided is insufficient definitively identify the RAID in question.  
What scrolling terminal command(s) provide such information?

3.  What form of tar will copy a full directory (with both hard and soft 
links) to a file that can then be restored?  I would use this for /home, 
/opt , and whatever systems configurations directories that need to be 
kept (SSH keys were mentioned).  If tar will not do this, what dd 
command will?

4.  I have a USB drive that contains the full image of the bootable 
installation procedure of a standard (not "everything") SL 7.5 ISO.  
Presumably, this image contains all of the RPMs that one would need.

4.1 What is the explicit command that provides a list of all of the 
current RPMs used in the SL 7.1 installed system?

4.1.1  Some of these came from non-SL repositories (such as the nvidia 
update packages) that would not be in the SL 7.5 installation ISO -- how 
does one configure the "repair" rpm invocation (not yum) not to go to 
the network to get these missing files but still not "crash"?

4.2 How does one convert the bootable install ISO into a RPM 
"repository" from which the replace packages rpm command will run -- 
*NOT* using the network?  I found an upstream vendor old set of 
instructions, but these probably would not work for SL current.

4.2.1  Does the live system ISO bootable image require a network 
connection to update, or can it be configured to use local USB media 
from the bootable install ISO image?

4.3 My experience with updating packages (not a full system or 
kernel/driver update) is that a "replacement" rpm file may require 
additional rpm files that were not required by the package being 
updated.  yum "automatically" takes care of this situation -- does rpm ?

4.4  Assuming that the nvidia package comes from a different distro, 
could I first get an updated system without nvidia support, then install 
the nvidia RPMs from USB media?

The tower chassis in question is on the floor under a table (used as a 
desk) that has cables going from the back to the keyboard, monitor, 
pointing device, printer, small local UPS power supply, and the RJ45 
IEEE 802.3 LAN jack.  Note that the security system of the campus will 
not activate a LAN jack with a different MAC address than the one 
assigned to it -- replacing a 802.3 machine at this campus requires 
explicit contact with the local IT management controlling the campus 
LAN.  Moreover, if a system has been "off" too long, the security system 
will "drop" the machine and require a call to IT LAN management. Thus, 
removal of a hard drive is possible but tedious.  This has nothing to do 
with SL but with local campus IT management policy (imposed by the 
campus executive for "security").

The system did not "crash" panic  -- it simply hung for several hours 
with no "visible" progress -- and was then rebooted.  It did panic with 
the SL 7.5 kernel, but not the SL 7.1 kernel, just no Xwindows.

Thanks again for any assistance.

Yasha Karant

On 08/24/2018 03:54 AM, Nico Kadel-Garcia wrote:
> On Wed, Aug 22, 2018 at 1:41 PM Yasha Karant <[log in to unmask]> wrote:
>> Thanks for that approach.  As I can get to USB drives, would the
>> following work as root:
>>
>> 1.  Insert a blank multi byte external USB drive (e.g., Western Digital,
>> other vendors) on another machine and leave a blank format
>>
>> 2.  Assuming that the drive on the failed machine is /dev/sda (e.g.,
>> sda1 ... sdaN), and that the external drive appears as /dev/sdb,
>> issue
>>
>> dd if=/dev/sda of=/dev/sdb
> If you're going this route, you'll want to yank out the first hard
> drive while booting from the second. Put a filesystem on the second
> disk, and pour the first disk image into a file, not a raw disk.
>
> * dd if=/dev/sda of-/mnt/directory/filename.img
>
> Mount or manipulate the *image*, not the disk, so you don't see that
> disk image as scanned by your disk controllers at boot time. That lets
> you put ordinary "look up the disk names and mount them on the live
> system, or with a live CD if I have to"
>
>
>> thereby "imaging" the current harddrive but having exact images of
>> /home, /opt, and the like
>>
>> 3.  Install SL7.5 from the bootable USB iso install image, manually
>> partitioning to same sizes as on the existing drive
>>
>> 4.  cp -pr /home and the like from the USB image drive to the "new" SL
>> 7.5 system, thereby restoring all files
>>
>> Note that the above has far fewer manual steps than the suggested procedure.
>>
>> I often use yumex GUI to perform such updates.  If the network
>> "glitches"  during a yumex massive update, would the system again be in
>> an unbootable state?
> Network glitches..... shouldn't be a big issue, unless some smart !@#$
> wrote a customized RPM that violates RHEL standards and installs
> components on the fly. I've seen people do that one, especially to
> install third party drivers, and it works great until it doesn't work
> at all and completely mucks up the state of your system. yum normally
> downloads the packages, *then* runs RPM on them to actually install
> them. But you've several times said the system crashed. That's not a
> network glitch: that's a "we're stopping the system in the midst of
> the kernel doing what should be atomic operations, but we've
> interrupted them, moo-ha-ha". And some of those are database
> operations, namely the RPM database.
>
>> Does anyone have a mechanism for SL7.5 to perform an upgrade rather than
>> a new install booting from the install ISO image file?
> I've mentioned several: I think that the "rpm -U --replacepkgs"
> approach will get you far enough to complete with a yum update
> command.
[snip for brevity]