Security Updates RHEL 7.1
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
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
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
