The response below does not seem to agree with what I observed.

The downloads strictly were from the specified repos for an update, all 
from the web (no local NFS, etc., caching).  If what is stated below is 
correct, unless yum is not re-entrant, once the installation (update) 
had started, all of the necessary RPMS (perhaps one hundred) should be 
on the harddrive. Because the old SL 7 system will boot (no X11), and
the files should be on the hard drive, then yum should be able to 
re-enter where it "left off".

If the RPM files are kept in a temporary directory that is erased upon 
re-boot, an unfinished update could (would) fail.

Assuming that the bootable SL system can get to the network (or will 
this require "network manager"?), is there a way to force yum to start 
the update from the beginning?

In the interim, I am going to image the system hard drive to a 2 Tbyte  
external USB hard drive using dd.

If I cannot get yum to "restart", I will do a full install from the USB 
ISO SL 7.5 install image, and then restore /home , /opt, ssh-keys, and 
the like from the
image, unless a better approach appears in response.

Yasha Karant

On 08/23/2018 11:37 AM, Chris Schanzle wrote:
> If you do the first paragraph below, you'll have a unknown mess and 
> will always consider the system "flaky".  Please:  reinstall from 
> scratch and restore your home directory data.  You'll at least be in a 
> well-known state and that's worth a lot to your peace of mind.  Maybe 
> try to save/restore your /etc/ssh/ directory to keep your host keys or 
> other /etc data in case you need it for service reconfiguration.
>
> Yum does not require the network after the installation begins. I.e., 
> it downloads the packages to local disk first, then starts the install.
>
> The system may have hung for other reasons (e.g., NFS mounts), but not 
> because yum needed the network.
>
> Hope that helps!
>
> On 08/22/2018 02:16 PM, Yasha Karant wrote:
>> Another approach to consider:  the failed system is SL 7.2 and does 
>> boot but does not bring up the GUI (e.g., ctrl-alt-F3 brings up a 
>> login prompt on a scrolling terminal screen and all users, including 
>> root, may log into the system).  I have other working SL 7.2 systems 
>> (I have had no time to update and have no GSRAs or Staff right now to 
>> help). If I cp -pr /usr , /bin , whatever (but not /home and the 
>> like) from a working system to the failed system, will the failed 
>> system then be able to use other mechanisms for an update rather than 
>> a full new install of SL 7.5 followed by a restore of /home and the 
>> like?
>>
>> Why was this system being upgraded?  It appears that the Palo Alto 
>> security systems on the end-users 802.3 network segment was 
>> "complaining", hopefully "fixed" by SL 7 current.  (Different 
>> security is used on the 802.11 networks.)
>>
>> As the campus network where I work i not designed for reliable 
>> systems work but rather end-user files (if the network glitches, 
>> simply repeat the download, etc.), is there a mechanism to update 
>> from media, say using the iso install image from a USB thumb drive?
>>
>> Thanks for any assistance.
>>
>> Yasha Karant
>>
>> On 08/21/2018 03:47 PM, Nico Kadel-Garcia wrote:
>>> On Tue, Aug 21, 2018 at 5:53 PM Yasha Karant <[log in to unmask]> wrote:
>>>> During the upgrade of a SL 7 non-current system to SL 7 (via yum 
>>>> update
>>>> as root from the Internet), the campus network "glitched" and the 
>>>> system
>>>> hung.  The 7.5 partially installed system panics; it has not 
>>>> recovered.
>>>> The 7 non-current will boot but no X (no GUI), only a scrolling text
>>>> terminal, presumably from which yum can be executed.
>>> If you want to keep this beastie alive, I urge you to:
>>>
>>> * Boot from a live USB or DVD image with networking enabled
>>> * Mount the old partitions at /mnt/sysimage, with subpartitions
>>> appropriately under that
>>> * chroot to /mnt/sysimage
>>> * Run "rpm --rebuilddb", because it is probably corrupt
>>> * Get the list of installed packages with "rpm -qa --qf 
>>> '%{name}.%{arch}\n'"
>>> * For every package, use "yum upgrade $name" and "yum reinstall $name"
>>> * * yum reinstall may require enabling the obsolete repositories
>>> * One or more are likely to balk due to two distinct versions of the
>>> same package.  Resolve that balking package manually, downloading the
>>> current version and using "rpm -U --replacepkgs $name"
>>>
>>>> I have downloaded Scientific-7.5-Install-Dual-Layer-DVD-x86_64.iso and
>>>> then put this onto an USB flash "thumb" drive that I have confirmed is
>>>> bootable and will start the installation steps.  I do not want to do a
>>>> new install but rather an upgrade, not touching /home , /opt and 
>>>> the like.
>>>>
>>>> I have found old upstream vendor instructions for a previous upstream
>>>> vendor major release of the enterprise (not enthusiast) system; please
>>>> see below.  How are these to
>>>> be modified for SL 7.5?  If I boot the Install ISO image (from the USB
>>>> drive), is there a way to get to the old GUI upgrade option that seems
>>>> no longer available?
>>> It's nearly impossible to tell which components got messed up in a
>>> mass upgrade. Start from a cleaned up upgrade process, as described
>>> above.
>>>
>>>> Please reply to [log in to unmask] Any assistance would be 
>>>> appreciated.
>>>>
>>>> Yasha Karant
>
>
>