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 <ykar...@csusb.edu> 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]
