off line upgrade to 7.5 from 7 previous [3] (was Re;)
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 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
Re: off line upgrade to 7.5 from 7 previous
On Wed, Aug 22, 2018 at 1:41 PM Yasha Karant 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.
> Thanks,
>
> Yasha Karant
>
> On 08/21/2018 03:47 PM, Nico Kadel-Garcia wrote:
> > On Tue, Aug 21, 2018 at 5:53 PM Yasha Karant 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 ykar...@gmail.com. Any assistance would be appreciated.
> >>
> >> Yasha Karant
Re: off line upgrade to 7.5 from 7 previous [3]
On Fri, Aug 24, 2018 at 2:13 AM Yasha Karant 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=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=hjaUISXTxcYgW6W-uGgZnd2OCi2FD6KjF41CYpZbHEA=UhoMe2yWOrvF-XYZQqLGOG62ksAu5fjKA00OMrO4qaQ=. 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.
off line upgrade to 7.5 from 7 previous [3]
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: Model: ATA TOSHIBA DT01ACA2 (scsi) Disk /dev/sda: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 32.3kB 41.1MB 41.1MB primary fat16 diag 2 41.9MB 11.1GB 11.1GB primary ntfs boot, diag 3 11.1GB 51.1GB 40.0GB primary xfs 4 51.1GB 2000GB 1949GB extended 5 51.1GB 1051GB 1000GB logical xfs 6 1051GB 1251GB 200GB logical xfs 7 1251GB 1451GB 200GB logical xfs 8 1451GB 1651GB 200GB logical xfs 9 1651GB 1751GB 100GB logical xfs 10 1751GB 1791GB 40.0GB logical linux-swap(v1) 11 1791GB 1941GB 150GB logical xfs Model: ATA TOSHIBA DT01ACA2 (scsi) Disk /dev/sdb: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 32.3kB 41.1MB 41.1MB primary fat16 diag 2 41.9MB 11.1GB 11.1GB primary ntfs boot, diag 3 11.1GB 51.1GB 40.0GB primary xfs 4 51.1GB 2000GB 1949GB extended 5 51.1GB 1051GB 1000GB logical xfs 6 1051GB 1251GB 200GB logical xfs 7 1251GB 1451GB 200GB logical xfs 8 1451GB 1651GB 200GB logical xfs 9 1651GB 1751GB 100GB logical xfs 10 1751GB 1791GB 40.0GB logical linux-swap(v1) 11 1791GB 1941GB 150GB logical xfs Model: Linux Software RAID Array (md) Disk /dev/md126: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 32.3kB 41.1MB 41.1MB primary fat16 diag 2 41.9MB 11.1GB 11.1GB primary ntfs boot, diag 3 11.1GB 51.1GB 40.0GB primary xfs 4 51.1GB 2000GB 1949GB extended 5 51.1GB 1051GB 1000GB logical xfs 6 1051GB 1251GB 200GB logical xfs 7 1251GB 1451GB 200GB logical xfs 8 1451GB 1651GB 200GB logical xfs 9 1651GB 1751GB 100GB logical xfs 10 1751GB 1791GB 40.0GB logical linux-swap(v1) 11 1791GB 1941GB 150GB logical xfs End output. An external USB 2 Tbyte drive is mounted by this system as /dev/sdg Is there any reason that as root dd if=/dev/sda of=/dev/sdg would not image the mirrored "RAID" drives from one of the mirror set? 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 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. However, the older system image does boot as the above output serves to 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
Re: off line upgrade to 7.5 from 7 previous [2]
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 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
Re: off line upgrade to 7.5 from 7 previous [2]
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 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 ykar...@gmail.com. Any assistance would be appreciated.
Yasha Karant
Re: off line upgrade to 7.5 from 7 previous
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
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?
Does anyone have a mechanism for SL7.5 to perform an upgrade rather than
a new install booting from the install ISO image file?
Thanks,
Yasha Karant
On 08/21/2018 03:47 PM, Nico Kadel-Garcia wrote:
On Tue, Aug 21, 2018 at 5:53 PM Yasha Karant 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 ykar...@gmail.com. Any assistance would be appreciated.
Yasha Karant
Re: off line upgrade to 7.5 from 7 previous
On Tue, Aug 21, 2018 at 5:53 PM Yasha Karant 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 ykar...@gmail.com. Any assistance would be appreciated.
>
> Yasha Karant
off line upgrade to 7.5 from 7 previous
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. 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? Please reply to ykar...@gmail.com. Any assistance would be appreciated. Yasha Karant https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2Dus_red-5Fhat-5Fenterprise-5Flinux_5_html_deployment-5Fguide_s1-2Dyum-2Dupgrade-2Dsystem=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=VIBZAPLSw5i79APlbk9o7bb7-I8Ng0G_fvWaaH3Ayb0=_Mk6MJ3Ff8HTunQdaQhWLUrVysCAIcVDqWQc9u7T-DQ= 14.5. Upgrading the System Off-line with ISO and Yum For systems that are disconnected from the Internet or Red Hat Network, using the yum update command with the Red Hat Enterprise Linux installation ISO image is an easy and quick way to upgrade systems to the latest minor version. The following steps illustrate the upgrading process: Create a target directory to mount your ISO image. This directory is not automatically created when mounting, so create it before proceeding to the next step, as root, type: mkdir mount_dir Replace mount_dir with a path to the mount directory. Typicaly, users create it as a subdirectory in the /media/ directory. Mount the Red Hat Enterprise Linux 5 installation ISO image to the previously created target directory. As root, type: mount -o loop iso_name mount_dir Replace iso_name with a path to your ISO image and mount_dir with a path to the target directory. Here, the -o loop option is required to mount the file as a block device. Check the numeric value found on the first line of the .discinfo file from the mount directory: head -n1 mount_dir/.discinfo The output of this command is an identification number of the ISO image, you need to know it to perform the following step. Create a new file in the /etc/yum.repos.d/ directory, named for instance new.repo, and add a content in the following form. Note that configuration files in this directory must have the .repo extension to function properly. [repository] mediaid=media_id name=repository_name baseurl=repository_url gpgkey=gpg_key enabled=1 gpgcheck=1 Replace media_id with the numeric value found in mount_dir/.discinfo. Set the repository name instead of repository_name, replace repository_url with a path to a repository directory in the mount point and gpg_key with a path to the GPG key. For example, the repository settings for Red Hat Enterprise Linux 5 Server ISO can look as follows: [rhel5-Server] mediaid=1354216429.587870 name=RHEL5-Server baseurl=file:///media/rhel5/Server gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release enabled=1 gpgcheck=1 Update all yum repositories including /etc/yum.repos.d/new.repo created in previous steps. As root, type: yum update This upgrades your system to the version provided by the mounted ISO image. After successful upgrade, you can unmount the ISO image, with the root privileges: umount mount_dir where mount_dir is a path to your mount directory. Also, you can remove the mount directory created in the first step. As root, type: rmdir mount_dir If you will not use the previously created configuration file for another installation or update, you can remove it. As root, type: rm /etc/yum.repos.d/new.repo Example 14.1. Upgrading from Red Hat Enterprise Linux 5.8 to 5.9 Imagine you need to upgrade your system without access to the Internet connection. To do so, you want to use an ISO image with the newer version of the system, called for instance RHEL5.9-Server-20121129.0-x86_64-DVD1.iso. You have crated a target directory /media/rhel5/. As root, change into the directory with your ISO image and type: ~]# mount -o loop RHEL5.9-Server-20121129.0-x86_64-DVD1.iso /media/rhel5/ To find the identification number of the mounted image, run: ~]# head -n1 /media/rhel5/.discinfo 1354216429.587870 You need this number to configure your mount point as a yum repository. Create
