[gentoo-user] problem with pam

[gentoo-user] problem with pam

[co]

[-- Attachment #1: Type: text/plain, Size: 130 bytes --]

I upgrade pad to 1.1.5 ,then openrc can't work,and can't login to system.
libpam.so.0 can't open shared object file.
please help!

[-- Attachment #2: Type: text/html, Size: 468 bytes --]

Re: [gentoo-user] problem with pam

[Adam Carter]

On Sat, Oct 29, 2011 at 8:55 PM, co <cuicle@gmail.com> wrote:
> I upgrade pad to 1.1.5 ,then openrc can't work,and can't login to system.
> libpam.so.0 can't open shared object file.
> please help!

I always run revdep-rebuild any time libs are updated, but in this
case the lib name stays the same.

What do you see if you run this command?

# ls -l /lib/libpam.so*
lrwxrwxrwx 1 root root    11 Oct 29 17:49 /lib/libpam.so -> libpam.so.0
lrwxrwxrwx 1 root root    16 Oct 29 17:49 /lib/libpam.so.0 -> libpam.so.0.83.1
-rwxr-xr-x 1 root root 55712 Oct 29 17:49 /lib/libpam.so.0.83.1

Re: [gentoo-user] problem with pam

[co]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

lrwxrwxrwx 1 root root    11 Oct 21 23:47 /lib32/libpam.so -> libpam.so.0
lrwxrwxrwx 1 root root    16 Oct 21 23:48 /lib32/libpam.so.0 ->
libpam.so.0.83.0
-rwxr-xr-x 1 root root 46520 Sep 28 19:37 /lib32/libpam.so.0.83.0

2011/10/29 Adam Carter <adamcarter3@gmail.com>

> On Sat, Oct 29, 2011 at 8:55 PM, co <cuicle@gmail.com> wrote:
> > I upgrade pad to 1.1.5 ,then openrc can't work,and can't login to system.
> > libpam.so.0 can't open shared object file.
> > please help!
>
> I always run revdep-rebuild any time libs are updated, but in this
> case the lib name stays the same.
>
> What do you see if you run this command?
>
> # ls -l /lib/libpam.so*
> lrwxrwxrwx 1 root root    11 Oct 29 17:49 /lib/libpam.so -> libpam.so.0
> lrwxrwxrwx 1 root root    16 Oct 29 17:49 /lib/libpam.so.0 ->
> libpam.so.0.83.1
> -rwxr-xr-x 1 root root 55712 Oct 29 17:49 /lib/libpam.so.0.83.1
>
>

[-- Attachment #2: Type: text/html, Size: 1317 bytes --]

Re: [gentoo-user] problem with pam

[co]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

And when i revdep-rebuild ,it still warning libpam.so.0,when finished ,it
still can't work.
And i try to re-emerge pam,but i can't

2011/10/29 co <cuicle@gmail.com>

> lrwxrwxrwx 1 root root    11 Oct 21 23:47 /lib32/libpam.so -> libpam.so.0
> lrwxrwxrwx 1 root root    16 Oct 21 23:48 /lib32/libpam.so.0 ->
> libpam.so.0.83.0
> -rwxr-xr-x 1 root root 46520 Sep 28 19:37 /lib32/libpam.so.0.83.0
>
> 2011/10/29 Adam Carter <adamcarter3@gmail.com>
>
>> On Sat, Oct 29, 2011 at 8:55 PM, co <cuicle@gmail.com> wrote:
>> > I upgrade pad to 1.1.5 ,then openrc can't work,and can't login to
>> system.
>> > libpam.so.0 can't open shared object file.
>> > please help!
>>
>> I always run revdep-rebuild any time libs are updated, but in this
>> case the lib name stays the same.
>>
>> What do you see if you run this command?
>>
>> # ls -l /lib/libpam.so*
>> lrwxrwxrwx 1 root root    11 Oct 29 17:49 /lib/libpam.so -> libpam.so.0
>> lrwxrwxrwx 1 root root    16 Oct 29 17:49 /lib/libpam.so.0 ->
>> libpam.so.0.83.1
>> -rwxr-xr-x 1 root root 55712 Oct 29 17:49 /lib/libpam.so.0.83.1
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 1801 bytes --]

Re: [gentoo-user] problem with pam

[Adam Carter]

> And i try to re-emerge pam,but i can't

With the old file and links there I don't understand why your system
doesn't work, but re-emerging pam it definitely worth trying. What
fails when you try to re-emerge?

Also, what about
# ldd /sbin/rc

Re: [gentoo-user] problem with pam

[co]

[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

#ldd /sbin/rc
linux-vdso.so.1 =>  (0x00007fff69fff000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f617f00d000)
 librc.so.1 => /lib64/librc.so.1 (0x00007f617ee01000)
libeinfo.so.1 => /lib64/libeinfo.so.1 (0x00007f617ebfb000)
 libdl.so.2 => /lib64/libdl.so.2 (0x00007f617e9f7000)
libpam.so.0 => not found
 libc.so.6 => /lib64/libc.so.6 (0x00007f617e691000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f617e440000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f617f210000)
thank you ahead.


2011/10/29 Adam Carter <adamcarter3@gmail.com>

> > And i try to re-emerge pam,but i can't
>
> With the old file and links there I don't understand why your system
> doesn't work, but re-emerging pam it definitely worth trying. What
> fails when you try to re-emerge?
>
> Also, what about
> # ldd /sbin/rc
>
>

[-- Attachment #2: Type: text/html, Size: 1806 bytes --]

Re: [gentoo-user] problem with pam

[co]

[-- Attachment #1: Type: text/plain, Size: 9117 bytes --]

These are the packages that would be merged, in order:

Calculating dependencies  .... done!
[ebuild   R    ] sys-libs/pam-1.1.5  USE="berkdb cracklib nls vim-syntax
-audit -debug -nis (-selinux) -test" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB


>>> Verifying ebuild manifests

>>> Emerging (1 of 1) sys-libs/pam-1.1.5
 * Linux-PAM-1.1.5.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...               [
ok ]
 * Linux-PAM-1.1.5-docs.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...          [
ok ]
>>> Unpacking source...
>>> Unpacking Linux-PAM-1.1.5.tar.bz2 to
/var/tmp/portage/sys-libs/pam-1.1.5/work
tar: Linux-PAM-1.1.5/INSTALL: Cannot open: Invalid argument
tar: Linux-PAM-1.1.5/ABOUT-NLS: Cannot open: Invalid argument
tar: Linux-PAM-1.1.5/ChangeLog: Cannot open: Invalid argument
tar: Linux-PAM-1.1.5/COPYING: Cannot open: Invalid argument
tar: Linux-PAM-1.1.5/Make.xml.rules: Cannot open: Invalid argument
tar: Exiting with failure status due to previous errors
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 * ERROR: sys-libs/pam-1.1.5 failed (unpack phase):
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 *   failure unpacking Linux-PAM-1.1.5.tar.bz2
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 *
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 * Call stack:
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 *               ebuild.sh, line   56:  Called src_unpack
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 *             environment, line 3487:  Called _eapi0_src_unpack
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 *               ebuild.sh, line  622:  Called unpack
'Linux-PAM-1.1.5.tar.bz2' 'Linux-PAM-1.1.5-docs.tar.bz2'
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 *               ebuild.sh, line  401:  Called _unpack_tar 'bzip2 -d'
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 *               ebuild.sh, line  371:  Called assert_sigpipe_ok 'failure
unpacking Linux-PAM-1.1.5.tar.bz2'
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 *   isolated-functions.sh, line   37:  Called die
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 * The specific snippet of code:
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 *   [[ $x -ne 0 && $x -ne ${PORTAGE_SIGPIPE_STATUS:-141} ]] && die "$@"
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 *
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 * If you need support, post the output of 'emerge --info
=sys-libs/pam-1.1.5',
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 * the complete build log and the output of 'emerge -pqv
=sys-libs/pam-1.1.5'.
/usr/lib64/portage/bin/isolated-functions.sh: line 211:
/var/tmp/portage/sys-libs/pam-1.1.5/.die_hooks: Invalid argument
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 * The complete build log is located at
'/var/tmp/portage/sys-libs/pam-1.1.5/temp/build.log'.
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 * The ebuild environment file is located at
'/var/tmp/portage/sys-libs/pam-1.1.5/temp/environment'.
/usr/lib64/portage/bin/isolated-functions.sh: line 264:
/var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
 * S: '/var/tmp/portage/sys-libs/pam-1.1.5/work/Linux-PAM-1.1.5'
Traceback (most recent call last):
  File "/usr/lib64/portage/bin/ebuild-ipc.py", line 276, in <module>
    sys.exit(ebuild_ipc_main(sys.argv[1:]))
  File "/usr/lib64/portage/bin/ebuild-ipc.py", line 273, in ebuild_ipc_main
    return ebuild_ipc.communicate(args)
  File "/usr/lib64/portage/bin/ebuild-ipc.py", line 63, in communicate
    lock_obj = portage.locks.lockfile(self.ipc_lock_file, unlinkfile=True)
  File "/usr/lib64/portage/pym/portage/locks.py", line 73, in lockfile
    myfd = os.open(lockfilename, os.O_CREAT|os.O_RDWR, 0o660)
  File "/usr/lib64/portage/pym/portage/__init__.py", line 215, in __call__
    rval = self._func(*wrapped_args, **wrapped_kwargs)
OSError: [Errno 22] Invalid argument:
'/var/tmp/portage/sys-libs/pam-1.1.5/.ipc_lock'
 * The ebuild phase 'unpack' has exited unexpectedly. This type of behavior
 * is known to be triggered by things such as failed variable assignments
 * (bug #190128) or bad substitution errors (bug #200313). Normally, before
 * exiting, bash should have displayed an error message above. If bash did
 * not produce an error message above, it's possible that the ebuild has
 * called `exit` when it should have called `die` instead. This behavior
 * may also be triggered by a corrupt bash binary or a hardware problem
 * such as memory or cpu malfunction. If the problem is not reproducible or
 * it appears to occur randomly, then it is likely to be triggered by a
 * hardware problem. If you suspect a hardware problem then you should try
 * some basic hardware diagnostics such as memtest. Please do not report
 * this as a bug unless it is consistently reproducible and you are sure
 * that your bash binary and hardware are functioning properly.
/usr/lib64/portage/bin/misc-functions.sh: line 978:
/var/tmp/portage/sys-libs/pam-1.1.5/.die_hooks: Invalid argument
Traceback (most recent call last):
  File "/usr/lib64/portage/bin/ebuild-ipc.py", line 276, in <module>
    sys.exit(ebuild_ipc_main(sys.argv[1:]))
  File "/usr/lib64/portage/bin/ebuild-ipc.py", line 273, in ebuild_ipc_main
    return ebuild_ipc.communicate(args)
  File "/usr/lib64/portage/bin/ebuild-ipc.py", line 63, in communicate
    lock_obj = portage.locks.lockfile(self.ipc_lock_file, unlinkfile=True)
  File "/usr/lib64/portage/pym/portage/locks.py", line 73, in lockfile
    myfd = os.open(lockfilename, os.O_CREAT|os.O_RDWR, 0o660)
  File "/usr/lib64/portage/pym/portage/__init__.py", line 215, in __call__
    rval = self._func(*wrapped_args, **wrapped_kwargs)
OSError: [Errno 22] Invalid argument:
'/var/tmp/portage/sys-libs/pam-1.1.5/.ipc_lock'
 * The ebuild phase 'die_hooks' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.

>>> Failed to emerge sys-libs/pam-1.1.5, Log file:

>>>  '/var/tmp/portage/sys-libs/pam-1.1.5/temp/build.log'

 * Messages for package sys-libs/pam-1.1.5:

2011/10/29 co <cuicle@gmail.com>

> #ldd /sbin/rc
> linux-vdso.so.1 =>  (0x00007fff69fff000)
>  libutil.so.1 => /lib64/libutil.so.1 (0x00007f617f00d000)
>  librc.so.1 => /lib64/librc.so.1 (0x00007f617ee01000)
> libeinfo.so.1 => /lib64/libeinfo.so.1 (0x00007f617ebfb000)
>  libdl.so.2 => /lib64/libdl.so.2 (0x00007f617e9f7000)
> libpam.so.0 => not found
>  libc.so.6 => /lib64/libc.so.6 (0x00007f617e691000)
> libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f617e440000)
>  /lib64/ld-linux-x86-64.so.2 (0x00007f617f210000)
> thank you ahead.
>
>
> 2011/10/29 Adam Carter <adamcarter3@gmail.com>
>
>> > And i try to re-emerge pam,but i can't
>>
>> With the old file and links there I don't understand why your system
>> doesn't work, but re-emerging pam it definitely worth trying. What
>> fails when you try to re-emerge?
>>
>> Also, what about
>> # ldd /sbin/rc
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 11962 bytes --]

Re: [gentoo-user] problem with pam

[co]

[-- Attachment #1: Type: text/plain, Size: 10137 bytes --]

emerge --info
Traceback (most recent call last):
  File "/usr/bin/emerge", line 43, in <module>
    retval = emerge_main()
  File "/usr/lib64/portage/pym/_emerge/main.py", line 1879, in emerge_main
    return action_info(settings, trees, myopts, valid_atoms)
  File "/usr/lib64/portage/pym/_emerge/actions.py", line 1407, in
action_info
    repo = vardb.aux_get(cpv, ["repository"])[0]
  File "/usr/lib64/portage/pym/portage/dbapi/vartree.py", line 659, in
aux_get
    self._aux_get(mycpv, aux_keys, st=mydir_stat)):
  File "/usr/lib64/portage/pym/portage/dbapi/vartree.py", line 690, in
_aux_get
    raise KeyError(mycpv)
KeyError: u'dev-lang/python-3.1.4-r3'

2011/10/29 co <cuicle@gmail.com>

>
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies  .... done!
> [ebuild   R    ] sys-libs/pam-1.1.5  USE="berkdb cracklib nls vim-syntax
> -audit -debug -nis (-selinux) -test" 0 kB
>
> Total: 1 package (1 reinstall), Size of downloads: 0 kB
>
>
> >>> Verifying ebuild manifests
>
> >>> Emerging (1 of 1) sys-libs/pam-1.1.5
>  * Linux-PAM-1.1.5.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...               [
> ok ]
>  * Linux-PAM-1.1.5-docs.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...          [
> ok ]
> >>> Unpacking source...
> >>> Unpacking Linux-PAM-1.1.5.tar.bz2 to
> /var/tmp/portage/sys-libs/pam-1.1.5/work
> tar: Linux-PAM-1.1.5/INSTALL: Cannot open: Invalid argument
> tar: Linux-PAM-1.1.5/ABOUT-NLS: Cannot open: Invalid argument
> tar: Linux-PAM-1.1.5/ChangeLog: Cannot open: Invalid argument
> tar: Linux-PAM-1.1.5/COPYING: Cannot open: Invalid argument
> tar: Linux-PAM-1.1.5/Make.xml.rules: Cannot open: Invalid argument
> tar: Exiting with failure status due to previous errors
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  * ERROR: sys-libs/pam-1.1.5 failed (unpack phase):
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  *   failure unpacking Linux-PAM-1.1.5.tar.bz2
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  *
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  * Call stack:
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  *               ebuild.sh, line   56:  Called src_unpack
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  *             environment, line 3487:  Called _eapi0_src_unpack
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  *               ebuild.sh, line  622:  Called unpack
> 'Linux-PAM-1.1.5.tar.bz2' 'Linux-PAM-1.1.5-docs.tar.bz2'
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  *               ebuild.sh, line  401:  Called _unpack_tar 'bzip2 -d'
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  *               ebuild.sh, line  371:  Called assert_sigpipe_ok 'failure
> unpacking Linux-PAM-1.1.5.tar.bz2'
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  *   isolated-functions.sh, line   37:  Called die
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  * The specific snippet of code:
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  *   [[ $x -ne 0 && $x -ne ${PORTAGE_SIGPIPE_STATUS:-141} ]] && die "$@"
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  *
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  * If you need support, post the output of 'emerge --info
> =sys-libs/pam-1.1.5',
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  * the complete build log and the output of 'emerge -pqv
> =sys-libs/pam-1.1.5'.
> /usr/lib64/portage/bin/isolated-functions.sh: line 211:
> /var/tmp/portage/sys-libs/pam-1.1.5/.die_hooks: Invalid argument
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  * The complete build log is located at
> '/var/tmp/portage/sys-libs/pam-1.1.5/temp/build.log'.
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  * The ebuild environment file is located at
> '/var/tmp/portage/sys-libs/pam-1.1.5/temp/environment'.
> /usr/lib64/portage/bin/isolated-functions.sh: line 264:
> /var/tmp/portage/sys-libs/pam-1.1.5/temp/logging/unpack: Invalid argument
>  * S: '/var/tmp/portage/sys-libs/pam-1.1.5/work/Linux-PAM-1.1.5'
> Traceback (most recent call last):
>   File "/usr/lib64/portage/bin/ebuild-ipc.py", line 276, in <module>
>     sys.exit(ebuild_ipc_main(sys.argv[1:]))
>   File "/usr/lib64/portage/bin/ebuild-ipc.py", line 273, in ebuild_ipc_main
>     return ebuild_ipc.communicate(args)
>   File "/usr/lib64/portage/bin/ebuild-ipc.py", line 63, in communicate
>     lock_obj = portage.locks.lockfile(self.ipc_lock_file, unlinkfile=True)
>   File "/usr/lib64/portage/pym/portage/locks.py", line 73, in lockfile
>     myfd = os.open(lockfilename, os.O_CREAT|os.O_RDWR, 0o660)
>   File "/usr/lib64/portage/pym/portage/__init__.py", line 215, in __call__
>     rval = self._func(*wrapped_args, **wrapped_kwargs)
> OSError: [Errno 22] Invalid argument:
> '/var/tmp/portage/sys-libs/pam-1.1.5/.ipc_lock'
>  * The ebuild phase 'unpack' has exited unexpectedly. This type of behavior
>  * is known to be triggered by things such as failed variable assignments
>  * (bug #190128) or bad substitution errors (bug #200313). Normally, before
>  * exiting, bash should have displayed an error message above. If bash did
>  * not produce an error message above, it's possible that the ebuild has
>  * called `exit` when it should have called `die` instead. This behavior
>  * may also be triggered by a corrupt bash binary or a hardware problem
>  * such as memory or cpu malfunction. If the problem is not reproducible or
>  * it appears to occur randomly, then it is likely to be triggered by a
>  * hardware problem. If you suspect a hardware problem then you should try
>  * some basic hardware diagnostics such as memtest. Please do not report
>  * this as a bug unless it is consistently reproducible and you are sure
>  * that your bash binary and hardware are functioning properly.
> /usr/lib64/portage/bin/misc-functions.sh: line 978:
> /var/tmp/portage/sys-libs/pam-1.1.5/.die_hooks: Invalid argument
> Traceback (most recent call last):
>   File "/usr/lib64/portage/bin/ebuild-ipc.py", line 276, in <module>
>     sys.exit(ebuild_ipc_main(sys.argv[1:]))
>   File "/usr/lib64/portage/bin/ebuild-ipc.py", line 273, in ebuild_ipc_main
>     return ebuild_ipc.communicate(args)
>   File "/usr/lib64/portage/bin/ebuild-ipc.py", line 63, in communicate
>     lock_obj = portage.locks.lockfile(self.ipc_lock_file, unlinkfile=True)
>   File "/usr/lib64/portage/pym/portage/locks.py", line 73, in lockfile
>     myfd = os.open(lockfilename, os.O_CREAT|os.O_RDWR, 0o660)
>   File "/usr/lib64/portage/pym/portage/__init__.py", line 215, in __call__
>     rval = self._func(*wrapped_args, **wrapped_kwargs)
> OSError: [Errno 22] Invalid argument:
> '/var/tmp/portage/sys-libs/pam-1.1.5/.ipc_lock'
>  * The ebuild phase 'die_hooks' has exited unexpectedly. This type of
>  * behavior is known to be triggered by things such as failed variable
>  * assignments (bug #190128) or bad substitution errors (bug #200313).
>  * Normally, before exiting, bash should have displayed an error message
>  * above. If bash did not produce an error message above, it's possible
>  * that the ebuild has called `exit` when it should have called `die`
>  * instead. This behavior may also be triggered by a corrupt bash binary or
>  * a hardware problem such as memory or cpu malfunction. If the problem is
>  * not reproducible or it appears to occur randomly, then it is likely to
>  * be triggered by a hardware problem. If you suspect a hardware problem
>  * then you should try some basic hardware diagnostics such as memtest.
>  * Please do not report this as a bug unless it is consistently
>  * reproducible and you are sure that your bash binary and hardware are
>  * functioning properly.
>
> >>> Failed to emerge sys-libs/pam-1.1.5, Log file:
>
> >>>  '/var/tmp/portage/sys-libs/pam-1.1.5/temp/build.log'
>
>  * Messages for package sys-libs/pam-1.1.5:
>
> 2011/10/29 co <cuicle@gmail.com>
>
>> #ldd /sbin/rc
>> linux-vdso.so.1 =>  (0x00007fff69fff000)
>>  libutil.so.1 => /lib64/libutil.so.1 (0x00007f617f00d000)
>>  librc.so.1 => /lib64/librc.so.1 (0x00007f617ee01000)
>> libeinfo.so.1 => /lib64/libeinfo.so.1 (0x00007f617ebfb000)
>>  libdl.so.2 => /lib64/libdl.so.2 (0x00007f617e9f7000)
>> libpam.so.0 => not found
>>  libc.so.6 => /lib64/libc.so.6 (0x00007f617e691000)
>> libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f617e440000)
>>  /lib64/ld-linux-x86-64.so.2 (0x00007f617f210000)
>> thank you ahead.
>>
>>
>> 2011/10/29 Adam Carter <adamcarter3@gmail.com>
>>
>>> > And i try to re-emerge pam,but i can't
>>>
>>> With the old file and links there I don't understand why your system
>>> doesn't work, but re-emerging pam it definitely worth trying. What
>>> fails when you try to re-emerge?
>>>
>>> Also, what about
>>> # ldd /sbin/rc
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 16625 bytes --]

Re: [gentoo-user] problem with pam

[Andrea Conti]

On 29/10/11 13.10, co wrote:

>>     # ls -l /lib/libpam.so*

> lrwxrwxrwx 1 root root    11 Oct 21 23:47 /lib32/libpam.so -> libpam.so.0
> lrwxrwxrwx 1 root root    16 Oct 21 23:48 /lib32/libpam.so.0 ->
> libpam.so.0.83.0
> -rwxr-xr-x 1 root root 46520 Sep 28 19:37 /lib32/libpam.so.0.83.0

That's not what you were asked for (ie /lib32 != /lib, as you seem to be
on amd64).
Are you by any chance trying to rescue your system by booting from an
install cd? If so, make sure you use an amd64 ISO, and don't forget to
chroot to your system installation.

>>>> Unpacking Linux-PAM-1.1.5.tar.bz2 to /var/tmp/portage/sys-libs/pam-1.1.5/work
> tar: Linux-PAM-1.1.5/INSTALL: Cannot open: Invalid argument
> tar: Linux-PAM-1.1.5/ABOUT-NLS: Cannot open: Invalid argument

I think this is the real problem. Whatever is causing this also has
probably something to do with your openrc issues. What kind of
filesystem is your /var/tmp/portage directory on? Is it free of errors?
Is there any free space left?

Can you create a new file on it? Try
# echo test >/var/tmp/portage/test

andrea

Re: [gentoo-user] problem with pam

[co]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

My system is amd64,and livecd is amd64 too. I always chroot.And it's exf4.
Wait a second,I will try it now.Thank you so much.

2011/10/30 Andrea Conti <alyf@alyf.net>

> On 29/10/11 13.10, co wrote:
>
> >>     # ls -l /lib/libpam.so*
>
> > lrwxrwxrwx 1 root root    11 Oct 21 23:47 /lib32/libpam.so -> libpam.so.0
> > lrwxrwxrwx 1 root root    16 Oct 21 23:48 /lib32/libpam.so.0 ->
> > libpam.so.0.83.0
> > -rwxr-xr-x 1 root root 46520 Sep 28 19:37 /lib32/libpam.so.0.83.0
>
> That's not what you were asked for (ie /lib32 != /lib, as you seem to be
> on amd64).
> Are you by any chance trying to rescue your system by booting from an
> install cd? If so, make sure you use an amd64 ISO, and don't forget to
> chroot to your system installation.
>
> >>>> Unpacking Linux-PAM-1.1.5.tar.bz2 to
> /var/tmp/portage/sys-libs/pam-1.1.5/work
> > tar: Linux-PAM-1.1.5/INSTALL: Cannot open: Invalid argument
> > tar: Linux-PAM-1.1.5/ABOUT-NLS: Cannot open: Invalid argument
>
> I think this is the real problem. Whatever is causing this also has
> probably something to do with your openrc issues. What kind of
> filesystem is your /var/tmp/portage directory on? Is it free of errors?
> Is there any free space left?
>
> Can you create a new file on it? Try
> # echo test >/var/tmp/portage/test
>
> andrea
>
>

[-- Attachment #2: Type: text/html, Size: 1783 bytes --]

Re: [gentoo-user] problem with pam

[co]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

After I run e2fsck -c on /var partition.I have re-emerged pam. So I think
there is something wrong with my hard disc. And there is still something
Error and Warning on boot time,and after startx mouse can't move. So how to
fix the hard disc now? Forgive my poor English....Thank you again....

2011/10/30 Andrea Conti <alyf@alyf.net>

> On 29/10/11 13.10, co wrote:
>
> >>     # ls -l /lib/libpam.so*
>
> > lrwxrwxrwx 1 root root    11 Oct 21 23:47 /lib32/libpam.so -> libpam.so.0
> > lrwxrwxrwx 1 root root    16 Oct 21 23:48 /lib32/libpam.so.0 ->
> > libpam.so.0.83.0
> > -rwxr-xr-x 1 root root 46520 Sep 28 19:37 /lib32/libpam.so.0.83.0
>
> That's not what you were asked for (ie /lib32 != /lib, as you seem to be
> on amd64).
> Are you by any chance trying to rescue your system by booting from an
> install cd? If so, make sure you use an amd64 ISO, and don't forget to
> chroot to your system installation.
>
> >>>> Unpacking Linux-PAM-1.1.5.tar.bz2 to
> /var/tmp/portage/sys-libs/pam-1.1.5/work
> > tar: Linux-PAM-1.1.5/INSTALL: Cannot open: Invalid argument
> > tar: Linux-PAM-1.1.5/ABOUT-NLS: Cannot open: Invalid argument
>
> I think this is the real problem. Whatever is causing this also has
> probably something to do with your openrc issues. What kind of
> filesystem is your /var/tmp/portage directory on? Is it free of errors?
> Is there any free space left?
>
> Can you create a new file on it? Try
> # echo test >/var/tmp/portage/test
>
> andrea
>
>

[-- Attachment #2: Type: text/html, Size: 1952 bytes --]

Re: [gentoo-user] problem with pam

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1307 bytes --]

On Saturday 29 Oct 2011 18:47:58 co wrote:
> After I run e2fsck -c on /var partition.I have re-emerged pam. So I think
> there is something wrong with my hard disc. 

This looks like a fs corruption.  It may be a disk problem, or a memory 
problem.

To check for the former you better install smartmontools and run the necessary 
tests (look at the man page and google for details).

To check the latter you can run memtest86+ from a LiveCD overnight, or for a 
few hours.


> And there is still something
> Error and Warning on boot time,and after startx mouse can't move. So how to
> fix the hard disc now? 

You cannot fix a hard disk.  If it is broken you better replace it before it 
breaks completely.

You can fix a file system (if you're lucky) or the installation on it.  You've 
already run the e2fsck command, so there's not much more you can do to fix the 
fs.  All that is left is to reinstall the OS:

emerge -eDNva world

Of course you would not need to do this, if you had a back up?


> Forgive my poor English....Thank you again....

There's nothing wrong with your English ... the problem seems to be with your 
netiquette!  Please do not top post, trim and thread your responses and add 
error messages when things fail to work.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] problem with pam

[Andrea Conti]

On 29/10/11 19.47, co wrote:
> After I run e2fsck -c on /var partition.I have re-emerged pam. So I　
> think there is something wrong with my hard disc.

Why do you think that? Did badblocks identify any specific problems?

A failing hard disk generally shows very obvious symptoms (noises,
periodic system lockups due to read retries, I/O errors in the kernel
log) before getting to the point of causing the widespread filesystem
corruption you seem to be experiencing.

Ext4 is generally quite resilient even when handled roughly, so I would
tend to suspect a memory issue. That's just a guess, though, since you
didn't provide much information.

> something Error and Warning on boot time,and after startx mouse can't
> move. So how to fix the hard disc now?

As Mick said, you don't fix a hard disk, you try to salvage whatever is
on it and then you go for a replacement.

However, your first priority should be to rule out memory issues: doing
any kind of data recovery operation on a machine with defective memory
is a recipe for disaster.

andrea