Security Updates RHEL 7.1

Latest response

I installed the Server with Fujitsu ServerView Suite and RHEL 7.1 DVD's. Server is a TX1310-M1 and according to Fujits is 100% supported. I have server set to 7.1, subscription-manager release --set=7.1. When I try,
yum update --security --downloadonly --downloaddir=/mnt/RH-Security --skip-broken, I get an error, . What I don't understand is, that earlier I did a complete update and it worked fine. But then I had problems with our Software. That's why I wanted to do just security updates. I also want to save the files, because if this works, I will be installing many servers for our customers and they all have to have the same software stand.

Responses

I believe you need to be subscribed to the EUS channel for 7.1

Then why do the normal updates work?

Hello Roger,

They might update to RHEL 7.4 instead of remaining on RHEL 7.1.

check this by

yum update redhat-release-server

you might see

redhat-release-server-7.4-18.el7.x86_64

If so, you have updated parts of your OS to RHEL 7.4

Regards,

Jan Gerrit Kootstra

Not sure why, but it worked today. I only tried --skip-broken because it suggested it the first time. I could also install it too. Thanks. You can Close the ticket now.

Hi Roger,

--skip-broken is a dangerous option, it may break your installation.

I would suggest next time you post the error messages or open a Red Hat support case.

What do you mean by: You can Close the ticket now?

I am not a Red Hat employee or customer that opened a support case for you. If you opened a support case, you have to close it via the support case tab of access.redhat.com

I am a fellow customer who gives you advise in his spare time.

Regards,

Jan Gerrit

Hi Jan Gerrit,

I am curious, why do you say that --skip-broken is a dangerous option ? Doesn't it mean that packages with broken dependencies do not get updated in order to avoid conflicts and problems, which would make this option being a safe one to use ? Or am I wrong here and misunderstood this information -> http://yum.baseurl.org/wiki/SkipBroken ? :)

Regards,
Christian

Hi Christian,

Dangerous might not be the correct phrase, not the way I would advise is perhaps a better phrase.

E.g. You may end up with a kernel being patched, but still run an older version of glibc, so if you would have to compile VMware Tools this would use a different version of glibc then Red Hat used to compile the kernel and loading the VMware Tools kernel modules may fail or crash the kernel.

Therefor I prefer to solve the dependency issue instead of ignoring them.

Regards,

Jan Gerrit

Thank you for your explanation, Jan Gerrit, that made it clear and I agree, it is better to solve dependency issues rather than ignoring them and this is exactly what I always do. Although your example is worst case scenario, it's absolutely valid, a broken glibc package dependency issue makes the whole system unusable. Thanks again. :)

Regards,
Christian

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.