[Solved] Re: [gentoo-user] Re: bash upgrading problem

[Jacques Montier]

Le lun. 21 janv. 2019 à 21:38, Nikos Chantziaras  a
écrit :

> On 21/01/2019 20:25, Jacques Montier wrote:
> > Le lun. 21 janv. 2019 à 19:04, Nikos Chantziaras  > > a écrit :
> >
> > I can't see why "emerge -uv bash" would ever invoke sudo. So I'd say
> > that you should first find out what command is being executed with
> > sudo.
> > To do that, try to emerge bash, and when the sudo prompt pops up,
> > switch
> > to another terminal window and do:
> >
> > ps aux | grep sudo
> >
> > What's the output of that?
> >
> > ps aux | grep sudo
> > 267:root 19845  0.0  0.0  54260  4304 pts/0S+   19:23   0:00
> > sudo eix-update
>
> Well, something is trying to execute a "sudo eix-update". The bash
> ebuild certainly doesn't, so you should check your installation for any
> weird scripts or aliases you might be using. A grep on /etc for
> "eix-update" might also reveal something:
>
>grep -r eix-update /etc
>
> And also check your env and aliases:
>
>which emerge
>alias | grep emerge
>env | grep eix
>
> These are general hints on where to look, since I have no clue myself as
> to why an "emerge -uv bash" would ever try and execute "sudo
> eix-update", so it seems you have digging to do.
>
>
>
Hello all,

I finally found what was wrong !
To save time, i had written a small bash script to run eix-update,
eix-test-obsolete and emerge --depclean.
This script was written just for test and was unfortunately calledtest.
So, when emerging bash, i think the configure phase launched that script
Well, of course it was my fault. Shame on me !
Sorry for all that noise, but you have been very helpful to me and i thank
you very much.

Cheers,

--
Jacques

[gentoo-user] Re: bash upgrading problem

[Nikos Chantziaras]

On 21/01/2019 20:25, Jacques Montier wrote:
Le lun. 21 janv. 2019 à 19:04, Nikos Chantziaras > a écrit :


I can't see why "emerge -uv bash" would ever invoke sudo. So I'd say
that you should first find out what command is being executed with
sudo.
To do that, try to emerge bash, and when the sudo prompt pops up,
switch
to another terminal window and do:

    ps aux | grep sudo

What's the output of that?

ps aux | grep sudo
267:root     19845  0.0  0.0  54260  4304 pts/0    S+   19:23   0:00 
sudo eix-update


Well, something is trying to execute a "sudo eix-update". The bash 
ebuild certainly doesn't, so you should check your installation for any 
weird scripts or aliases you might be using. A grep on /etc for 
"eix-update" might also reveal something:


  grep -r eix-update /etc

And also check your env and aliases:

  which emerge
  alias | grep emerge
  env | grep eix

These are general hints on where to look, since I have no clue myself as 
to why an "emerge -uv bash" would ever try and execute "sudo 
eix-update", so it seems you have digging to do.

Re: [gentoo-user] Re: bash upgrading problem

[Jack]

On 2019.01.21 13:41, Jacques Montier wrote:
Le lun. 21 janv. 2019 à 19:19, Jack   
a

écrit :

>
> I have a suspicion that this really might be sandbox related.
> /dev/fd/whatever are all in the live system, and if I understand
> correctly, emerge works within the sandbox, so you should not be  
able
> to get at those files (certainly not write to them, but it isn't  
clear

> what the ebuild is trying to do there.)
>
> However, if you are running the emerge (please do clarify that your  
are
> trying to emerge bash, not just manually build it) as root, I don't  
see

> any reason it should try to use sudo for anything.
>
> Just for a change, try logging in as root, not doing su, and see if  
the

> emerge works.
>
> Jack
>

Jack,
- I don't manually build bash. Just : #emerge bash
- CTRL+Alt+F1 to get out of X and go to TTY1
- logged as root with the root password
- emerge bash stops at password required.
Since you are logged in as root, have you tried the root password when  
sudo asks?  I wonder if it's looking for the portage password, which I  
don't think exists.  As someone else said - there is really no reason  
for sudo to be used if you are root.  However, during the emerge, I  
believe the effective UID is changed to portage.  Does this give anyone  
else any further ideas of what to check?

Re: [gentoo-user] Re: bash upgrading problem

[Jacques Montier]

Le lun. 21 janv. 2019 à 19:19, Jack  a
écrit :

>
> I have a suspicion that this really might be sandbox related.
> /dev/fd/whatever are all in the live system, and if I understand
> correctly, emerge works within the sandbox, so you should not be able
> to get at those files (certainly not write to them, but it isn't clear
> what the ebuild is trying to do there.)
>
> However, if you are running the emerge (please do clarify that your are
> trying to emerge bash, not just manually build it) as root, I don't see
> any reason it should try to use sudo for anything.
>
> Just for a change, try logging in as root, not doing su, and see if the
> emerge works.
>
> Jack
>

Jack,
- I don't manually build bash. Just : #emerge bash
- CTRL+Alt+F1 to get out of X and go to TTY1
- logged as root with the root password
- emerge bash stops at password required.

--
Jacques

Re: [gentoo-user] Re: bash upgrading problem

[Jacques Montier]

Le lun. 21 janv. 2019 à 19:04, Nikos Chantziaras  a
écrit :

>
> I can't see why "emerge -uv bash" would ever invoke sudo. So I'd say
> that you should first find out what command is being executed with sudo.
> To do that, try to emerge bash, and when the sudo prompt pops up, switch
> to another terminal window and do:
>
>ps aux | grep sudo
>
> What's the output of that?
>
>
>
ps aux | grep sudo
267:root 19845  0.0  0.0  54260  4304 pts/0S+   19:23   0:00 sudo
eix-update
269:root 19857  0.0  0.0  10856   916 pts/1S+   19:24   0:00 grep
-n sudo

--
Jacques

Re: [gentoo-user] Re: bash upgrading problem

[Jack]

On 2019.01.21 11:44, Jacques Montier wrote:

Le lun. 21 janv. 2019 à 15:37, Alexander Kapshuk <
alexander.kaps...@gmail.com> a écrit :

>
> (1). Are you attempting to build bash as yourself or as user root?
> (2). If the latter, what's in LD_PRELOAD and LD_LIBRARY_PATH?
>
> (3). What's the output of:
> ls -l /path/to/libsandbox.so?
> (4). And:
> file /path/to/libsandbox.so
>
>
(1) I always build bash as user root (su then password)
(2) there's no output with echo $LD_PRELOAD or $LD_LIBRARY_PATH
(3) libsandbox.so is located in /usr/lib32 and /usr/lib64
ls -al /usr/lib32/libsandbox.so
-rwxr-xr-x 1 root root 91720 19 janv. 19:14 /usr/lib32/libsandbox.so*
ls -al /usr/lib64/libsandbox.so
-rwxr-xr-x 1 root root 84520 19 janv. 19:14 /usr/lib64/libsandbox.so*

file /usr/lib32/libsandbox.so
/usr/lib32/libsandbox.so: ELF 32-bit LSB pie executable, Intel 80386,
version 1 (SYSV), dynamically linked, stripped
file /usr/lib64/libsandbox.so
/usr/lib64/libsandbox.so: ELF 64-bit LSB pie executable, x86-64,  
version 1

(SYSV), dynamically linked, stripped

---

BUT, i think the error is NOT libsandbox related.
As i said in a previous post, i could successfully emerge bash with a  
live

SystemRescuecd.
Here is the log (attached file) :
We could see the same error many times (>10) :

. snip
checking whether /dev/fd is available... ERROR: ld.so: object
'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open  
shared

object file): ignored.

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

sudo: no tty present and no askpass program specified

.snip

 Now the difference is : sudo: no tty present and no askpass program
specified

Does that mean that the problem comes from sudo (see the attached  
sudoers

file )?

Thanks again,

--
Jacques
I have a suspicion that this really might be sandbox related.   
/dev/fd/whatever are all in the live system, and if I understand  
correctly, emerge works within the sandbox, so you should not be able  
to get at those files (certainly not write to them, but it isn't clear  
what the ebuild is trying to do there.)


However, if you are running the emerge (please do clarify that your are  
trying to emerge bash, not just manually build it) as root, I don't see  
any reason it should try to use sudo for anything.


Just for a change, try logging in as root, not doing su, and see if the  
emerge works.


Jack

[gentoo-user] Re: bash upgrading problem

[Nikos Chantziaras]

On 19/01/2019 12:51, Jacques Montier wrote:

I did not have any problem with bash emerge so far.
Here is the attached log.
As usual, i successfully logged with my root password (su -) and then
#emerge -uv bash

The only thing i did some days ago, was to change my user jacques password.
In the sudoers file, i have the row : jacques ALL=(ALL) NOPASSWD: ALL
So with sudo, i don't have to write the root password.

It is not version bash related as i tried to re-emerge the 
installed app-shells/bash and it fails.


I can't see why "emerge -uv bash" would ever invoke sudo. So I'd say 
that you should first find out what command is being executed with sudo. 
To do that, try to emerge bash, and when the sudo prompt pops up, switch 
to another terminal window and do:


  ps aux | grep sudo

What's the output of that?

Re: [gentoo-user] Re: bash upgrading problem

[Alexander Kapshuk]

On Mon, Jan 21, 2019 at 3:43 PM Jacques Montier  wrote:
>
>
> Le lun. 21 janv. 2019 à 14:16, Alexander Kapshuk 
>  a écrit :
>>
>>
>>
>> What is the output of:
>> env | grep libsandbox.so
>>
>
> There is no output of env | grep libsandbox.so, but with env | grep sandbox, 
> i get this :
>
> $ env | grep sandbox
> 13:CONFIG_PROTECT_MASK=/etc/sandbox.d /etc/php/cli-php7.2/ext-active/ 
> /etc/php/cgi-php7.2/ext-active/ /etc/php/apache2-php7.2/ext-active/ 
> /etc/fonts/fonts.conf /etc/gentoo-release /etc/gconf /etc/terminfo /etc/dconf 
> /etc/ca-certificates.conf /etc/revdep-rebuild
>
> --
> Jacques
>

(1). Are you attempting to build bash as yourself or as user root?
(2). If the latter, what's in LD_PRELOAD and LD_LIBRARY_PATH?

(3). What's the output of:
ls -l /path/to/libsandbox.so?
(4). And:
file /path/to/libsandbox.so

Re: [gentoo-user] Re: bash upgrading problem

[Jacques Montier]

Le lun. 21 janv. 2019 à 14:16, Alexander Kapshuk <
alexander.kaps...@gmail.com> a écrit :

>
>
> What is the output of:
> env | grep libsandbox.so
>
>
There is no output of env | grep libsandbox.so, but with env | grep
sandbox, i get this :

$ env | grep sandbox
13:CONFIG_PROTECT_MASK=/etc/sandbox.d /etc/php/cli-php7.2/ext-active/
/etc/php/cgi-php7.2/ext-active/ /etc/php/apache2-php7.2/ext-active/
/etc/fonts/fonts.conf /etc/gentoo-release /etc/gconf /etc/terminfo
/etc/dconf /etc/ca-certificates.conf /etc/revdep-rebuild

--
Jacques

Re: [gentoo-user] Re: bash upgrading problem

[Alexander Kapshuk]

On Mon, Jan 21, 2019 at 3:03 PM Jacques Montier  wrote:
>
> Le lun. 21 janv. 2019 à 13:04, Alexander Kapshuk 
>  a écrit :
>>
>>
>>
>> What is the output of:
>> echo $LD_PRELOAD
>> echo $LD_LIBRARY_PATH
>>
>
> No output.
>
> --
> Jacques
>

So these variables are both unset. But the build log you supplied, had
a record saying the object 'libsandbox.so' could not be preloaded from
LD_PRELOAD.
Is that in your build environment, or in your regular user's
environment, or are they both the same on your system?

What is the output of:
env | grep libsandbox.so

Re: [gentoo-user] Re: bash upgrading problem

[Jacques Montier]

Le lun. 21 janv. 2019 à 13:04, Alexander Kapshuk <
alexander.kaps...@gmail.com> a écrit :

>
>
> What is the output of:
> echo $LD_PRELOAD
> echo $LD_LIBRARY_PATH
>
>
No output.

--
Jacques

Re: [gentoo-user] Re: bash upgrading problem

[Alexander Kapshuk]

On Mon, Jan 21, 2019 at 1:31 PM Jacques Montier  wrote:
>
>
>
> Le lun. 21 janv. 2019 à 12:11, Alexander Kapshuk 
>  a écrit :
>
>>
>> The /proc/PID directory listed by the ls command is the directory for
>> the process that executed the ls command. See below.
>>
>> % ls -ld /proc/self &
>> [1] 27318
>> % lrwxrwxrwx 1 root root 0 Sep 24 14:06 /proc/self -> 27318
>> [1] +  Done
>>
>> As for the user/group owning the files in /proc/self, they are owned
>> by the user who initiated the process that created those entries in
>> the proc file system.
>>
>
> Thanks Alexander for your explanation.
> Nevertheless, the bash rejected password remains a mystery to me. :-(
>
> Regards,
>
>

What is the output of:
echo $LD_PRELOAD
echo $LD_LIBRARY_PATH

Re: [gentoo-user] Re: bash upgrading problem

[Jacques Montier]

Le lun. 21 janv. 2019 à 12:11, Alexander Kapshuk <
alexander.kaps...@gmail.com> a écrit :


> The /proc/PID directory listed by the ls command is the directory for
> the process that executed the ls command. See below.
>
> % ls -ld /proc/self &
> [1] 27318
> % lrwxrwxrwx 1 root root 0 Sep 24 14:06 /proc/self -> 27318
> [1] +  Done
>
> As for the user/group owning the files in /proc/self, they are owned
> by the user who initiated the process that created those entries in
> the proc file system.
>
>
Thanks Alexander for your explanation.
Nevertheless, the bash rejected password remains a mystery to me. :-(

Regards,

Re: [gentoo-user] Re: bash upgrading problem

[Alexander Kapshuk]

On Mon, Jan 21, 2019 at 12:52 PM Jacques Montier  wrote:
>
>
> Le lun. 21 janv. 2019 à 11:21, Raffaele Belardi  a 
> écrit :
>>
>>
>> Well, they are owned by jacques instead of root. Could it be the reason why 
>> you're asked
>> for a password? Maybe some strange interaction with the sandbox?
>>
>> raffaele
>
>
>
> Yes, i noticed that, but how to explain my root password rejected when 
> emerging bash ?
>
> I also noticed something strange :
> $ ls -al /proc/self/fd
> total 0
> dr-x-- 2 jacques jacques  0 21 janv. 11:49 ./
> dr-xr-xr-x 9 jacques jacques  0 21 janv. 11:49 ../
> lrwx-- 1 jacques jacques 64 21 janv. 11:49 0 -> /dev/pts/1
> lrwx-- 1 jacques jacques 64 21 janv. 11:49 1 -> /dev/pts/1
> lrwx-- 1 jacques jacques 64 21 janv. 11:49 2 -> /dev/pts/1
> lr-x-- 1 jacques jacques 64 21 janv. 11:49 3 -> /proc/4461/fd/
>
> The /proc/4461 directory does not exist !
>
> --
> Jacques
>

The /proc/PID directory listed by the ls command is the directory for
the process that executed the ls command. See below.

% ls -ld /proc/self &
[1] 27318
% lrwxrwxrwx 1 root root 0 Sep 24 14:06 /proc/self -> 27318
[1] +  Done

As for the user/group owning the files in /proc/self, they are owned
by the user who initiated the process that created those entries in
the proc file system.

Re: [gentoo-user] Re: bash upgrading problem

[Jacques Montier]

Le lun. 21 janv. 2019 à 11:21, Raffaele Belardi  a
écrit :

>
> Well, they are owned by jacques instead of root. Could it be the reason
> why you're asked
> for a password? Maybe some strange interaction with the sandbox?
>
> raffaele
>


Yes, i noticed that, but how to explain my root password rejected when
emerging bash ?

I also noticed something strange :
$ ls -al /proc/self/fd
total 0
dr-x-- 2 jacques jacques  0 21 janv. 11:49 ./
dr-xr-xr-x 9 jacques jacques  0 21 janv. 11:49 ../
lrwx-- 1 jacques jacques 64 21 janv. 11:49 0 -> /dev/pts/1
lrwx-- 1 jacques jacques 64 21 janv. 11:49 1 -> /dev/pts/1
lrwx-- 1 jacques jacques 64 21 janv. 11:49 2 -> /dev/pts/1
lr-x-- 1 jacques jacques 64 21 janv. 11:49 3 -> /proc/4461/fd/

The /proc/4461 directory does not exist !

--
Jacques

Re: [gentoo-user] Re: bash upgrading problem

[Raffaele Belardi]

Jacques Montier wrote:
> /
> /
> Le lun. 21 janv. 2019 à 07:52, Raffaele Belardi  > a écrit :
> 
> Jacques Montier wrote:
> > checking whether /dev/fd is available... ERROR: ld.so: object 
> 'libsandbox.so' from
> LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
> 
> Just a guess. configure here is trying to read /dev/fd which is a symlink 
> to
> /proc/self/fd. Do you see anything strange with those two directories or 
> directory
> entries?
> 
> $ ll /dev/fd
> lrwxrwxrwx 1 root root 13 Jan 21 07:10 /dev/fd -> /proc/self/fd
> 
> 
> # ll /proc/self/fd
> total 0
> lrwx-- 1 root root 64 Jan 21 07:53 0 -> /dev/pts/3
> lrwx-- 1 root root 64 Jan 21 07:53 1 -> /dev/pts/3
> lrwx-- 1 root root 64 Jan 21 07:53 2 -> /dev/pts/3
> lr-x-- 1 root root 64 Jan 21 07:53 3 -> /proc/3744/fd
> 
> # ll /proc/self/
> total 0
> dr-x-- 2 root root 0 Jan 21 07:54 fd
> (snip)
> 
> 
> Thanks Raffaele,
> 
> No, i don't see anything strange with those two directories. Do you ?
> 
> $ ls -al /dev/fd
>  lrwxrwxrwx 1 root root 13 21 janv. 10:28 /dev/fd -> /proc/self/fd/
> 
> $ ls -al /proc/self/fd
> total 0
> dr-x-- 2 jacques jacques  0 21 janv. 10:43 ./
> dr-xr-xr-x 9 jacques jacques  0 21 janv. 10:43 ../
> lrwx-- 1 jacques jacques 64 21 janv. 10:43 0 -> /dev/pts/0
> lrwx-- 1 jacques jacques 64 21 janv. 10:43 1 -> /dev/pts/0
> lrwx-- 1 jacques jacques 64 21 janv. 10:43 2 -> /dev/pts/0
> lr-x-- 1 jacques jacques 64 21 janv. 10:43 3 -> /proc/5146/fd/
> 
> $ ls -al /proc/self/
> dr-x--   2 jacques jacques 0 21 janv. 10:44 fd/
> 

Well, they are owned by jacques instead of root. Could it be the reason why 
you're asked
for a password? Maybe some strange interaction with the sandbox?

raffaele

Re: [gentoo-user] Re: bash upgrading problem

[Jacques Montier]

Le lun. 21 janv. 2019 à 07:52, Raffaele Belardi  a
écrit :

> Jacques Montier wrote:
> > checking whether /dev/fd is available... ERROR: ld.so: object
> 'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared
> object file): ignored.
>
> Just a guess. configure here is trying to read /dev/fd which is a symlink
> to
> /proc/self/fd. Do you see anything strange with those two directories or
> directory entries?
>
> $ ll /dev/fd
> lrwxrwxrwx 1 root root 13 Jan 21 07:10 /dev/fd -> /proc/self/fd
>
>
> # ll /proc/self/fd
> total 0
> lrwx-- 1 root root 64 Jan 21 07:53 0 -> /dev/pts/3
> lrwx-- 1 root root 64 Jan 21 07:53 1 -> /dev/pts/3
> lrwx-- 1 root root 64 Jan 21 07:53 2 -> /dev/pts/3
> lr-x-- 1 root root 64 Jan 21 07:53 3 -> /proc/3744/fd
>
> # ll /proc/self/
> total 0
> dr-x-- 2 root root 0 Jan 21 07:54 fd
> (snip)
>
>
Thanks Raffaele,

No, i don't see anything strange with those two directories. Do you ?

$ ls -al /dev/fd
 lrwxrwxrwx 1 root root 13 21 janv. 10:28 /dev/fd -> /proc/self/fd/

$ ls -al /proc/self/fd
total 0
dr-x-- 2 jacques jacques  0 21 janv. 10:43 ./
dr-xr-xr-x 9 jacques jacques  0 21 janv. 10:43 ../
lrwx-- 1 jacques jacques 64 21 janv. 10:43 0 -> /dev/pts/0
lrwx-- 1 jacques jacques 64 21 janv. 10:43 1 -> /dev/pts/0
lrwx-- 1 jacques jacques 64 21 janv. 10:43 2 -> /dev/pts/0
lr-x-- 1 jacques jacques 64 21 janv. 10:43 3 -> /proc/5146/fd/

$ ls -al /proc/self/
dr-x--   2 jacques jacques 0 21 janv. 10:44 fd/

Regards,

--
Jacques

Re: [gentoo-user] Re: bash upgrading problem

[Raffaele Belardi]

Jacques Montier wrote:
> checking whether /dev/fd is available... ERROR: ld.so: object 'libsandbox.so' 
> from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

Just a guess. configure here is trying to read /dev/fd which is a symlink to
/proc/self/fd. Do you see anything strange with those two directories or 
directory entries?

$ ll /dev/fd
lrwxrwxrwx 1 root root 13 Jan 21 07:10 /dev/fd -> /proc/self/fd


# ll /proc/self/fd
total 0
lrwx-- 1 root root 64 Jan 21 07:53 0 -> /dev/pts/3
lrwx-- 1 root root 64 Jan 21 07:53 1 -> /dev/pts/3
lrwx-- 1 root root 64 Jan 21 07:53 2 -> /dev/pts/3
lr-x-- 1 root root 64 Jan 21 07:53 3 -> /proc/3744/fd

# ll /proc/self/
total 0
dr-x-- 2 root root 0 Jan 21 07:54 fd
(snip)

Re: [gentoo-user] Re: bash upgrading problem

[Jacques Montier]

Le sam. 19 janv. 2019 à 19:42, Jacques Montier  a
écrit :

>
> Thanks Jack,
>
> Le sam. 19 janv. 2019 à 19:03, Jack  a
> écrit :
>
>>
>> --quoted attachment
>> “app-shells:bash-4.4_p23-r1:20190119-102517.log”--
>> [snip much of emerge log]
>> So the problem occurs at the end of the ./configure stage.  You did not
>> include this in your original post.
>> > checking which library has the termcap functions... (cached) using
>> > libcurses
>> > checking whether /dev/fd is available...
>> > ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be
>> > preloaded (cannot open shared object file): ignored.
>> So this is the real error - portage can't (pre)load libsandbox.so.
>> 1) When is the last time you did a full upgrade?  I'm now wondering if
>> you have inconsistent versions of different packages installed.
>> 2) Try re-emerging sys-apps/sandbox.
>>
>
>  - I just did a full upgrade by : emerge -auvDN --with-bdeps=y
> --keep-going world => so i have to upgrade bash
> [ebuild U  ] app-shells/bash-4.4_p23-r1::gentoo [4.4_p12::gentoo]
> USE="net nls (readline) -afs -bashlogger -examples -mem-scramble -plugins"
> 0 KiB
> - Then emerge sandbox => OK
> - Then emerge bash => it stops asking for passwd. :-(
>
> 3) If that does not work, try running revdep-rebuild.  It should not
>> normally be necessary, but there are times.  Did an emerge world ever
>> get interrupted?
>>
>>
> - revdep-rebuild done without any error
>
>
> --
> Jacques
>


Hello all,

As i was backing up my gentoo system to an external USB drive via
SystemRescueCD, i tried one thing :

- i mounted all the partitions (/ , boot, home, etc.) and /dev, /sys, /proc
and chroot into the system

then
#emerge bash
and...it works ! No password asked !

After umounting all that stuff, reboot.

- I tried to re-emerge bash ; password : ? and it stops.

Anyone could explain that to me ? It would be great !

Thanks a lot !


*--*
*Jacques*

*https://sites.google.com/site/jacquesfr35/
*

Re: [gentoo-user] Re: bash upgrading problem

[Jacques Montier]

Thanks Jack,

Le sam. 19 janv. 2019 à 19:03, Jack  a
écrit :

>
> --quoted attachment
> “app-shells:bash-4.4_p23-r1:20190119-102517.log”--
> [snip much of emerge log]
> So the problem occurs at the end of the ./configure stage.  You did not
> include this in your original post.
> > checking which library has the termcap functions... (cached) using
> > libcurses
> > checking whether /dev/fd is available...
> > ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be
> > preloaded (cannot open shared object file): ignored.
> So this is the real error - portage can't (pre)load libsandbox.so.
> 1) When is the last time you did a full upgrade?  I'm now wondering if
> you have inconsistent versions of different packages installed.
> 2) Try re-emerging sys-apps/sandbox.
>

 - I just did a full upgrade by : emerge -auvDN --with-bdeps=y --keep-going
world => so i have to upgrade bash
[ebuild U  ] app-shells/bash-4.4_p23-r1::gentoo [4.4_p12::gentoo]
USE="net nls (readline) -afs -bashlogger -examples -mem-scramble -plugins"
0 KiB
- Then emerge sandbox => OK
- Then emerge bash => it stops asking for passwd. :-(

3) If that does not work, try running revdep-rebuild.  It should not
> normally be necessary, but there are times.  Did an emerge world ever
> get interrupted?
>
>
- revdep-rebuild done without any error


--
Jacques

Re: [gentoo-user] Re: bash upgrading problem

[Jack]

On 2019.01.19 05:51, Jacques Montier wrote:
Le ven. 18 janv. 2019 à 21:36, Nikos Chantziaras  a  
écrit :

> On 18/01/2019 13:29, Jacques Montier wrote:

[snip]

Thanks Jack and Nikos,

I did not have any problem with bash emerge so far.
It is not clear if you do not have any problem with the emerge, or if  
it is still failing.

Here is the attached log.

[snip]
The only thing i did some days ago, was to change my user jacques  
password. In the sudoers file, i have the row : jacques ALL=(ALL)  
NOPASSWD: ALL So with sudo, i don't have to write the root password.
Changing the password should not cause any problems, and that sudo  
entry look fine.


It is not version bash related as i tried to re-emerge the installed  
app-shells/bash and it fails.

So you DO still have the problem.
[snip]

--quoted attachment  
“app-shells:bash-4.4_p23-r1:20190119-102517.log”--

[snip much of emerge log]
So the problem occurs at the end of the ./configure stage.  You did not  
include this in your original post.
checking which library has the termcap functions... (cached) using  
libcurses

checking whether /dev/fd is available...
ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be  
preloaded (cannot open shared object file): ignored.

So this is the real error - portage can't (pre)load libsandbox.so.
1) When is the last time you did a full upgrade?  I'm now wondering if  
you have inconsistent versions of different packages installed.

2) Try re-emerging sys-apps/sandbox.
3) If that does not work, try running revdep-rebuild.  It should not  
normally be necessary, but there are times.  Did an emerge world ever  
get interrupted?




We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

Sorry, try again.
sandbox:stop  caught signal 2 in pid 10364
sudo: 1 incorrect password attempt
sandbox:stop  Send signal 4 more times to force SIGKILL

[snipped repeated error]

Jack

Re: [gentoo-user] Re: bash upgrading problem

[Jacques Montier]

*--*
*Jacques*

*https://sites.google.com/site/jacquesfr35/
*


Le ven. 18 janv. 2019 à 21:36, Nikos Chantziaras  a
écrit :

> On 18/01/2019 13:29, Jacques Montier wrote:
> > Hello all,
> >
> > I encounter some problem about upgrading app-shells/bash from 4.4_p12
> > to 4.4_p23-r1.
> > After the checking phase, it stops asking for password (attached file).
> > All passwords (root, user) are rejected, so i can't go further.
> >
> > Any idea ?
>
> Log in as root with:
>
> su -
>
> and then try emerging from there. Reboot.
>
>
>
Thanks Jack and Nikos,

I did not have any problem with bash emerge so far.
Here is the attached log.
As usual, i successfully logged with my root password (su -) and then
#emerge -uv bash

The only thing i did some days ago, was to change my user jacques password.
In the sudoers file, i have the row : jacques ALL=(ALL) NOPASSWD: ALL
So with sudo, i don't have to write the root password.

It is not version bash related as i tried to re-emerge the
installed app-shells/bash and it fails.

Thanks again,

Regards,

--
Jacques
 * Package:app-shells/bash-4.4_p23-r1
 * Repository: gentoo
 * Maintainer: base-sys...@gentoo.org
 * USE:abi_x86_64 amd64 elibc_glibc kernel_linux net nls readline userland_GNU
 * FEATURES:   preserve-libs sandbox userpriv usersandbox
>>> Unpacking source...
>>> Unpacking bash-4.4.tar.gz to /var/tmp/portage/app-shells/bash-4.4_p23-r1/work
>>> Source unpacked in /var/tmp/portage/app-shells/bash-4.4_p23-r1/work
>>> Preparing source in /var/tmp/portage/app-shells/bash-4.4_p23-r1/work/bash-4.4 ...
 * Applying bash44-001 ...
 [ ok ]
 * Applying bash44-002 ...
 [ ok ]
 * Applying bash44-003 ...
 [ ok ]
 * Applying bash44-004 ...
 [ ok ]
 * Applying bash44-005 ...
 [ ok ]
 * Applying bash44-006 ...
 [ ok ]
 * Applying bash44-007 ...
 [ ok ]
 * Applying bash44-008 ...
 [ ok ]
 * Applying bash44-009 ...
 [ ok ]
 * Applying bash44-010 ...
 [ ok ]
 * Applying bash44-011 ...
 [ ok ]
 * Applying bash44-012 ...
 [ ok ]
 * Applying bash44-013 ...
 [ ok ]
 * Applying bash44-014 ...
 [ ok ]
 * Applying bash44-015 ...
 [ ok ]
 * Applying bash44-016 ...
 [ ok ]
 * Applying bash44-017 ...
 [ ok ]
 * Applying bash44-018 ...
 [ ok ]
 * Applying bash44-019 ...
 [ ok ]
 * Applying bash44-020 ...
 [ ok ]
 * Applying bash44-021 ...
 [ ok ]
 * Applying bash44-022 ...
 [ ok ]
 * Applying bash44-023 ...
 [ ok ]
 * Applying bash-4.4-jobs_overflow.patch ...
 [ ok ]
 * Applying bash-4.4-set-SHOBJ_STATUS.patch ...
 [ ok ]
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/app-shells/bash-4.4_p23-r1/work/bash-4.4 ...
 * econf: updating bash-4.4/support/config.sub with /usr/share/gnuconfig/config.sub
 * econf: updating bash-4.4/support/config.guess with /usr/share/gnuconfig/config.guess
./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --docdir=/usr/share/doc/bash-4.4_p23-r1 --htmldir=/usr/share/doc/bash-4.4_p23-r1/html --libdir=/usr/lib64 --disable-profiling --docdir=$(datarootdir)/doc/bash-4.4_p23-r1 --htmldir=$(docdir)/html --with-curses --disable-mem-scramble --enable-net-redirections --enable-readline --enable-bang-history --enable-history --without-afs --without-bash-malloc --with-installed-readline=.
configure: loading site script /usr/share/config.site
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu

Beginning configuration for bash-4.4-release for x86_64-pc-linux-gnu

checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checkin

[gentoo-user] Re: bash upgrading problem

[Nikos Chantziaras]

On 18/01/2019 13:29, Jacques Montier wrote:

Hello all,

I encounter some problem about upgrading app-shells/bash from 4.4_p12 
to 4.4_p23-r1.

After the checking phase, it stops asking for password (attached file).
All passwords (root, user) are rejected, so i can't go further.

Any idea ?


Log in as root with:

su -

and then try emerging from there. Reboot.