On Fri, Aug 24, 2018 at 2:13 AM Yasha Karant <ykar...@csusb.edu> wrote: > > The pre SL 7.5 machine for which yum crashed during an upgrade does > boot. I ran parted as root on the hard drive with the following output: >
[ RAID information snipped ] "RAID" can means a lot of different settings, most of which are not evident from the data you published. You've sometimes tried to outsmart standard settings, so it's not clear if the XFS partitions are elements in a RAID array, or have been gathered into LVM groups, or what. > would not image the mirrored "RAID" drives from one of the mirror set? In theory, mirroring a drive by replicating to a another drive or a disk image should copy all the content. But it can also confuse the system, because it copies the uuid's of the partitions to the new disk or disk image. Chaos can ensue. Having both drives attached at the same time, in that setup, can be..... well, it could trigger adventures. That kind of thing is partly why I recommended using a live CD or DVD image, even if it's on a USB drive. > By this means, all of /home , /opt and the like should be recoverable? > There may be minor discrepancies but as the system was not being used > other than for root to run yum, the image should have all vital > configuration files as > well as all end-user home directories. > > Also, as the system does boot, is there anyway to start yum "fresh" and > force an upgrade at this point? Only the Xwindows system fails under It would help your models if you looked, not at "yum", but at the underlying "rpm" tool that yum actually uses. yum is a wrapper for RPM, organizing *what* packages to manipulate with RPM underlying RPM commands like "instlal", "update", or "delete". It's why I suggest reinstalling all the packages with "rpm -U --replacepkgs", from a list of installed packages. Since you have a 2 TB drive lying around, you can even pre-mirror the current yum repositories to directories there and work from local copies. There are scripts for just that sort of mirroring at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_nkadel_nkadel-2Drsync-2Dscripts&d=DwIBaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=hjaUISXTxcYgW6W-uGgZnd2OCi2FD6KjF41CYpZbHEA&s=UhoMe2yWOrvF-XYZQqLGOG62ksAu5fjKA00OMrO4qaQ&e=. They're a bit out of date, but there is one there specifically for Scientific Linux. > the old system. During the boot sequence, one can choose the SL7.5 > image, but this one fails with a panic due to the yum upgrade failure. See what I've been saying about "re-installing all your RPM's, with the 'rpm -U --replacepkgs'" options. > However, the older system image does boot as the above output serves t > verify. My guess is there are one or more yum bookkeeping files that > need modification for a "fresh" yum update to be enabled. > > Any further assistance would be appreciated. > > Yasha Karant Maybe a "grubby" misconfiguration when the kernel was being installed? Like I keep saying, "re-install the RPMs". I suspect that will address your issues. And, if I may say from personally recovering critical systems from failed upgrades, including incompatible kernels? Been there, done that. The re-install can be done from a live DVD or USB drive, and it's pretty effective. Slow, but effective.