Koozali.org formerly Contribs.org

Non-fatal POSTIN scriptlet failure in rpm package sudo-1.7.2p1-14.el5_8.2.i386

Offline piran

  • ****
  • 502
Am having trouble with my comms supplier so don't know if this is a bug
which would affect every one and needs to be in bugzilla or just a comms
issue that messed up the yum update and which really just affects me.

Searching bugzilla with 'sudo' and then 'yum' does not show this issue,
there are no other forum reports so perhaps it just affects me.

The update apparently failed... so why does yum want to reboot?

If I *DO* reboot (I have not) am I likely to lose admin (sudo?) access?

Is there a way to over ride this specific yum reboot requirement?

Code: [Select]
Loaded plugins: fastestmirror, protect-packages, smeserver
Loading mirror speeds from cached hostfile
 * base: mirrors.ukfast.co.uk
 * smeaddons: mirror.pialasse.com
 * smeextras: mirror.pialasse.com
 * smeos: mirror.pialasse.com
 * smeupdates: mirror.pialasse.com
 * updates: mirrors.ukfast.co.uk
Excluding Packages from CentOS - os
Finished
Excluding Packages from CentOS - updates
Finished
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package sudo.i386 0:1.7.2p1-14.el5_8.2 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package       Arch          Version                     Repository        Size
================================================================================
Updating:
 sudo          i386          1.7.2p1-14.el5_8.2          updates          352 k

Transaction Summary
================================================================================
Install       0 Package(s)
Upgrade       1 Package(s)

Total download size: 352 k
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction

  Updating       : sudo                                                     1/2
/var/tmp/rpm-tmp.31614: line 17: restorecon: command not found
Non-fatal POSTIN scriptlet failure in rpm package sudo-1.7.2p1-14.el5_8.2.i386
error: %post(sudo-1.7.2p1-14.el5_8.2.i386) scriptlet failed, exit status 127

Updated:
  sudo.i386 0:1.7.2p1-14.el5_8.2                                               

Complete!
yum update sudo.i386 failed: 256

Offline Stefano

  • *
  • 10,810
  • Skype account: maghissimo
    • Smeserver italian community
restorecon is, from its man page
Quote
NAME
       restorecon - restore file(s) default SELinux security contexts.

SYNOPSIS
       restorecon [-o outfilename ] [-R] [-n] [-p] [-v] [-e directory ] pathname...

       restorecon -f infilename [-o outfilename ] [-e directory ] [-R] [-n] [-v] [-F]

DESCRIPTION
       This manual page describes the restorecon program.

       This program is primarily used to set the security context (extended attributes) on one or more files.

       It  can  be  run at any time to correct errors, to add support for new policy, or with the -n option it can just check whether the file contexts
       are all as you expect.

selinux is not active/implemented in SME AFAIK

anyway, the error message says "Non-fatal" and IMO you should not have any problem after a reboot
moreover, you can always log in as root and so sudo is not necessary
Consulente di Smeserver.it -  Soluzioni e supporto su Sme server in Italia

Offline janet

  • ****
  • 4,812
piran

That package updated OK for me just now on 32 bit system.


Please search before asking, an answer may already exist.
The Search & other links to useful information are at top of Forum.

Offline piran

  • ****
  • 502
Stefano----
Noted. Long time ago a Windows machine BIOS update ended with a similar
looking 'fail' message. Windows being what it is/was so as that message
was displayed the thing rebooted itself (with a bad BIOS) and that was
the last time that motherboard ever worked.
Hence my taking this one slowly.

Stefano----
AFAIK SELINUX is not used here.

Mary----
32bit here too.

OK, the prevailing feeling here seems to be
that my server ought to survive this reboot.
Here goes...

Offline piran

  • ****
  • 502
Server survived the reboot;~)
Took the precaution of hooking up a screen to the
server this time as the latter normally runs headless.
FWIW that sudo yum update was by itself.

After the reboot there are two more updates waiting
this time for backup and pop3. Those two result in no
such weird non-fatal message. Will now reboot again.