Red HatThis forum is for the discussion of Red Hat Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
We are running RHEL 7.2 on one of our servers, and we are preparing to do a patch upgrade on the system. The plan is to utilize the yum utility with the following command syntax:
Code:
yum -y update
Prior to the update, we would like to do a test run, in other words simulate but not actually install the packages, of the update to determine if there are any issues that need to be dealt with prior to the event. The results are to be shown on screen, as well as saved to file. The command syntax that I was planning on using the following:
Code:
yum -y update --setopt tsflags=test | tee /root/yumupdateresults.txt
Is the command syntax correct, or did I miss something?
Hello --
We are running RHEL 7.2 on one of our servers, and we are preparing to do a patch upgrade on the system. The plan is to utilize the yum utility with the following command syntax:
Code:
yum -y update
Prior to the update, we would like to do a test run, in other words simulate but not actually install the packages, of the update to determine if there are any issues that need to be dealt with prior to the event. The results are to be shown on screen, as well as saved to file. The command syntax that I was planning on using the following:
Code:
yum -y update --setopt tsflags=test | tee /root/yumupdateresults.txt
Is the command syntax correct, or did I miss something?
It appears to be, but (AGAIN), since you are using RHEL, you can verify this by contacting Red Hat support. Have you done so? That's been told to you many times previously, and you seem to ignore this advice. And since the yum command won't work unless you *ARE* paying...seems like an easy thing to do.
Also, your question and plan are not sound. Because aside from any dependency issues (which you will have by the armload if you don't pay for RHEL and try an update), it won't show any other 'issues' that could arise. Things like going from one version of a program to another, for example, or having options change. In place upgrades are always too risky in my opinion...better to test and do this on a test machine first, and make SURE things work. Then do a format/install/reload-from-backup to make sure your machine is stable. And a side benefit of this is you get to test your backup/restore procedures and make sure THEY work.
The reason that I am posting my questions in this forum first, is due to my attempt to get feedback from my peers prior to my contacting Red Hat Support. The purpose of this exercise is to get as much information as possible so when I do call support I will be better informed, and thereby making the call more productive. Also for the record, we do have paid support available. I see my posting questions here, and subsequently contacting Red Hat Support as an opportunity to learn and thereby become less dependent.
We do not have a development machine available so we do not have the luxury of avoiding an in-place upgrade. That is why I posted this thread about the syntax. If I could do this upgrade on a non-production system, I would do so.
I have NOT ignored your advice. As stated previously, I am simply asking learned colleagues for feedback on a major project.
The reason that I am posting my questions in this forum first, is due to my attempt to get feedback from my peers prior to my contacting Red Hat Support. The purpose of this exercise is to get as much information as possible so when I do call support I will be better informed, and thereby making the call more productive. Also for the record, we do have paid support available. I see my posting questions here, and subsequently contacting Red Hat Support as an opportunity to learn and thereby become less dependent.
Sorry, this makes no sense at all. Using the paid support gets you an accurate answer much faster, and being 'better informed' makes no sense in this context, since having a question in the first place means you do NOT have the information you need.
Quote:
We do not have a development machine available so we do not have the luxury of avoiding an in-place upgrade. That is why I posted this thread about the syntax. If I could do this upgrade on a non-production system, I would do so. I have NOT ignored your advice. As stated previously, I am simply asking learned colleagues for feedback on a major project.
Using RHEL support has been told to you many times in the past, but you have never acknowledged even reading such things. Your 'learned colleagues' are telling you that in-place upgrades are a bad thing to do, and to contact RHEL support for concerns about the product you're claiming to pay for. You are responding by (again) ignoring the advice you were given, and continuing to ask.
And doing a fresh load can happen on ANY PC you have laying around, since what you need to test is the functionality of the software and services. THAT is the only way you are going to know of any 'issues' that arise from your upgrade...which again is what you were told previously.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.