I recently upgraded an SP3 system to SP4, and my 4GB /usr directory is full of non-local files/packages from what I think are previous updates (SP3 and SP2). Is there any zypper magic that can get rid of duplicate SP3 packages that aren’t needed after the SP4 update?
Thanks!
Care to share examples? Arbitrarily removing files seems like a risky
maneuver on a system you like, but I suppose it depends on which files you
happen to delete and whether or not they are used. An upgrade of a
package, or a removal of a package, should remove old versions of files
where necessary, though it’s possible something could be missed.
I presume, by your post, that you’ve done some work to determine these are
orphaned files; knowing how that work was done would be interesting.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
I was updating to SP4 from SP3, and received some dependency errors, one if which was:
Problem: Open_Enterprise_Server-release-cd-11.2-1.267.x86_64 requires product(SUSE_SLES) = 11.3, but this requirement cannot be provided
Problem: some dependency problem
In the resultant dialog, the script asks you if you want to keep or delete the offending packages (of which there were a bunch), and I selected keep. After the upgrade completed, /usr was very full and the update didn’t remove the older files, like it did with the other dependency (kernel files) it reported.
Thanks!
rhaskins67 Wrote in message:
[color=blue]
I was updating to SP4 from SP3, and received some dependency errors, one
if which was:Problem: Open_Enterprise_Server-release-cd-11.2-1.267.x86_64 requires
product(SUSE_SLES) = 11.3, but this requirement cannot be provided
Problem: some dependency problemIn the resultant dialog, the script asks you if you want to keep or
delete the offending packages (of which there were a bunch), and I
selected keep. After the upgrade completed, /usr was very full and the
update didn’t remove the older files, like it did with the other
dependency (kernel files) it reported.[/color]
Whoa hold on a minute - does the reference to the
Open_Enterprise_Server-cd package above suggest that this server
is running OES and is not just a “regular” SLES server? If that
is the case how did you upgrade from SP3 to SP4? If OES is in the
mix you have to upgrade both SLES and OES and the same time
otherwise you will cause yourself problems.
Simon Flood
SUSE Knowledge Partner
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
Let me ask this a different way. Is it safe to delete all the files related to SLES11 SP3 which are associated with an SP3 repository, after updating the system to SLES11 SP4?
[QUOTE=smflood;34493]rhaskins67 Wrote in message:
[color=blue]
I was updating to SP4 from SP3, and received some dependency errors, one
if which was:Problem: Open_Enterprise_Server-release-cd-11.2-1.267.x86_64 requires
product(SUSE_SLES) = 11.3, but this requirement cannot be provided
Problem: some dependency problemIn the resultant dialog, the script asks you if you want to keep or
delete the offending packages (of which there were a bunch), and I
selected keep. After the upgrade completed, /usr was very full and the
update didn’t remove the older files, like it did with the other
dependency (kernel files) it reported.[/color]
Whoa hold on a minute - does the reference to the
Open_Enterprise_Server-cd package above suggest that this server
is running OES and is not just a “regular” SLES server? If that
is the case how did you upgrade from SP3 to SP4? If OES is in the
mix you have to upgrade both SLES and OES and the same time
otherwise you will cause yourself problems.
Simon Flood
SUSE Knowledge Partner
----Android NewsGroup Reader----
http://usenet.sinaapp.com/[/QUOTE]
On 09/27/2016 05:54 PM, rhaskins67 wrote:[color=blue]
Let me ask this a different way. Is it safe to delete all the files
related to SLES11 SP3 which are associated with an SP3 repository, after
updating the system to SLES11 SP4?[/color]
I think you would be better off considering what Simon wrote. Open
Enterprise Server (OES) is closely tied to SLES in its versions, and
upgrading the SLES portion without doing the OES portion is a great way to
both void support and break the system all at the same time. You should
not do it, or try to do it, or anything, ever. The OES channels include
the SLES patches, and the upgrades are meant to happen simultaneously.
Going back to your new question: If you chose to “keep” as you indicated,
then the package owning those files is still installed, meaning you still
should not have orphaned files as I originally thought you did. Those
files, though perhaps from SP3, are still owned by a package, and you can
still remove that package to get rid of them, though the OES error may
indicate that removing them will break other dependencies, so if the
system warns you again about the package being in use, then pulling it out
may break things.
Since you haven’t specified what the package is, or what is depending on
it, I think you should start there. The package management system’s
entire job is to keep your system healthy, partially by maintaining
dependencies where needed. It would seem, based on your post that
mentioned the OES requirement, that you are trying to work around this.
Without more information detailing why you think this should be done, it
seems to me that you are trying to work around the system that is
protecting you from doing bad things. It may be justified, what you are
doing, but you haven’t given us information making that justification so far.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
ab Wrote in message:
[color=blue]
I think you would be better off considering what Simon wrote. Open
Enterprise Server (OES) is closely tied to SLES in its versions, and
upgrading the SLES portion without doing the OES portion is a great way to
both void support and break the system all at the same time. You should
not do it, or try to do it, or anything, ever. The OES channels include
the SLES patches, and the upgrades are meant to happen simultaneously.Going back to your new question: If you chose to “keep” as you indicated,
then the package owning those files is still installed, meaning you still
should not have orphaned files as I originally thought you did. Those
files, though perhaps from SP3, are still owned by a package, and you can
still remove that package to get rid of them, though the OES error may
indicate that removing them will break other dependencies, so if the
system warns you again about the package being in use, then pulling it out
may break things.Since you haven’t specified what the package is, or what is depending on
it, I think you should start there. The package management system’s
entire job is to keep your system healthy, partially by maintaining
dependencies where needed. It would seem, based on your post that
mentioned the OES requirement, that you are trying to work around this.
Without more information detailing why you think this should be done, it
seems to me that you are trying to work around the system that is
protecting you from doing bad things. It may be justified, what you are
doing, but you haven’t given us information making that justification so far.[/color]
I think before we can help further we need clarification whether
this server is running “regular” SLES or Micro Focus Open
Enterprise Server (OES). The output from “cat /etc/*release”
would help.
Simon Flood
SUSE Knowledge Partner
----Android NewsGroup Reader----
http://usenet.sinaapp.com/