I am running zypper up on a SLES 11SP2 server. I get this error and cannot move on. This server receives its updates from my SMT server. Just did one other SLES11SP2 server and that went fine. Any idea what I can do to fix this. Let me know if you need additional information.
73 packages to upgrade, 1 new.
Overall download size: 139.7 MiB. After the operation, 950.0 KiB will be freed.
Continue? [y/n/?] (y): y
Installing: util-linux-2.19.1-6.33.47.1 [error]
Installation of util-linux-2.19.1-6.33.47.1 failed:
(with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /usr/bin/x86_64: cpio: rename failed - Is a directory
Installation of util-linux-2.19.1-6.33.47.1 failed:
(with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /usr/bin/x86_64: cpio: rename failed - Is a directory
on my machines, /usr/bin/x86_64 is a symlink
jmozdzen@xxx01:~> l /usr/bin/x86_64
lrwxrwxrwx 1 root root 7 28. Sep 19:37 /usr/bin/x86_64 -> setarch*
jmozdzen@xxx01:~> rpm -qf /usr/bin/x86_64
util-linux-2.19.1-6.48.12
jmozdzen@xxx01:~>
(this is a SLES11SP3 machine, so don’t worry about the different RPM level)
Run “rpm -V util-linux” and clean up (i.e. remove that “directory”, if reported as an error). Seems like some files might be corrupt on your file system(s), if rpm -V proves that, I recommend running “rpm -Va” (as i.e. some config files are reported as changed, that’ll be some manual check work on the resulting list, but if already one file is corrupt, it’s worth the time).
I ran rpm -V util-linux and got this:
/usr/bin/wall should be root:tty 2755. (wrong permissions 0755)
/usr/bin/write should be root:tty 2755. (wrong permissions 0755)
I fixed the permissions. chmod 2755 /usr/bin/wall chmod 2755 /usr/bin/write. Which are now -rwxr-sr-x 1 root tty
Then I ran rpm -Va util-linux and I get a whole lot of this: S.5…T /usr/bin/wall
…5…T /usr/bin/whereis
…5…T /usr/bin/which
S.5…T /usr/bin/write
.M…G. /usr/bin/x86_64
S.5…T d /usr/share/man/man1/hostid.1.gz
Never done this before so not sure what else you are suggesting I do.
Have run zypper up again and I receive the same error.
I ran rpm -V util-linux and got this:
/usr/bin/wall should be root:tty 2755. (wrong permissions 0755)
/usr/bin/write should be root:tty 2755. (wrong permissions 0755)
I fixed the permissions. chmod 2755 /usr/bin/wall chmod 2755 /usr/bin/write. Which are now -rwxr-sr-x 1 root tty
Then I ran rpm -Va util-linux and I get a whole lot of this: S.5…T /usr/bin/wall
…5…T /usr/bin/whereis
…5…T /usr/bin/which
S.5…T /usr/bin/write
.M…G. /usr/bin/x86_64[/QUOTE]
strange this didn’t pop up with “-V util-linux” (BTW, “-Va” means “verify all packages”, so the extra “util-linux” is… extra ). I’d say move it out of the way, /usr/bin/x86_64 ought to be a file, not a directory.
BTW, you might want to give that file system an extra forced fsck in advance, to clear out any file system inconsistencies that might have accumulated after months of uptime.
The “5” mean “md5 checksum is wrong”, verified against the values at installation time. So either someone tampered with those files, or your file system is in trouble (which is more likely). Via "rpm -qf " you can find out which RPM each file belongs to, and then re-install that RPM, i.e. via zypper… use force if required. Do this after the update - that may already clear up some of the files, as packages are updated.
Once the “directory” /usr/bin/x86_64 is out of the way, “util-linux” ought to be update-able again.
How do you know all this stuff!! Will I ever learn it! I renamed the x86_64 directory to x86_64.org. Ran zypper up and the patches installed. Yay. I can’t reboot for another hour so hope it all worked.
I did get this error at the end. Do you know what that means.
(Use the Enter or Space key to scroll the text by lines or pages.)
Message from package puppet:
Note:
If you’ve set the ‘certdnsnames’ option in your master’s
puppet.conf file, merely installing the updated packages is not
sufficient to fix this problem. You need to either pick a new DNS
name for the master and reconfigure all agents to use it or re-new
certificates on all agents.
Please refer to the documentation in
/usr/share/doc/packages/puppet/puppetlabs-cve20113872-0.0.5
for detailed instructions and scripts.
well, I read a lot… man pages, documentation, web pages
Please take the output from “rpm -Va” serious (if still persisting after that recent update), as other programs may be damaged, too - a probable cause is some file system or disk problem, so running “fsck -f” on that file system isn’t really optional now.
Yes. If you’re actually running puppet (rather than just having the software installed), you need to fix your configuration.
[QUOTE=kbannister;17597]Please refer to the documentation in
/usr/share/doc/packages/puppet/puppetlabs-cve20113872-0.0.5
for detailed instructions and scripts.
The local documentation and the FAQ tell you what this is about.
If you don’t actually run puppet, then remove it (or fix the config anyhow) - a later user may expect this to be fixed already and will not receive another notice, this would impose e security risk.
). I’d say move it out of the way, /usr/bin/x86_64 ought to be a file, not a directory.
If you’re actually running puppet (rather than just having the software installed), you need to fix your configuration.