User/Group Problem

User/Group Problem

[Ian Chilton]

Hello,

I am building a Linux system on an SGI I2 (MIPS) with glibc 2.2

I am having the following problem....any ideas?

bash-2.04# chown root test.c 
chown: root: invalid user

bash-2.04# chgrp root test.c 
chgrp: invalid group name `root'



bash-2.04# cat /etc/passwd
root:1D0t80HeWTfNE:0:0:root:/root:/bin/bash

bash-2.04# cat /etc/group 
root:x:0:
 

Thanks!


Bye for Now,

Ian


                     \|||/ 
                     (o o)
 /----------------ooO-(_)-Ooo----------------\
 |  Ian Chilton                              |
 |  E-Mail : ian@ichilton.co.uk              |
 \-------------------------------------------/

Re: User/Group Problem

[Ralf Baechle]

On Tue, Nov 07, 2000 at 11:06:10AM +0000, Ian Chilton wrote:

> I am building a Linux system on an SGI I2 (MIPS) with glibc 2.2
> 
> I am having the following problem....any ideas?
> 
> bash-2.04# chown root test.c 
> chown: root: invalid user
> 
> bash-2.04# chgrp root test.c 
> chgrp: invalid group name `root'

Two possible reasons:

 - your /etc/nsswitch.conf is broken
 - your chown / chgrp binaries are statically linked.  In that case nss
   won't work on MIPS until it's fixed ...

  Ralf

Re: User/Group Problem

[Maciej W. Rozycki]

On Wed, 8 Nov 2000, Ralf Baechle wrote:

>  - your chown / chgrp binaries are statically linked.  In that case nss
>    won't work on MIPS until it's fixed ...

 That's actually not a MIPS-specific problem.  This happens due to a bogus
error from mmap() (when called by ld.so) which cannot handle certain valid
requests -- when there is a non-zero suggested VM address, but the area
and all space above it is already occupied or unavailable for other
reasons.  It can sometimes appear for other ports, as well (I have an i386
test case, for example), but it bites MIPS specifically, because of a
non-zero initial VMA set for our shared objects.

 Here is a patch I use since July successfully.  We need to wait until
2.4.1 or so (or maybe even 2.5) is released for it to be applied as
2.4.0-test* are currently code-frozen.  Maybe we could apply it to our CVS
for now?  Ralf, what do you think? 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

diff -u --recursive --new-file linux-2.4.0-test4.macro/mm/mmap.c linux-2.4.0-test4/mm/mmap.c
--- linux-2.4.0-test4.macro/mm/mmap.c	Sun Jul 16 22:27:29 2000
+++ linux-2.4.0-test4/mm/mmap.c	Tue Jul 25 05:06:21 2000
@@ -175,7 +175,7 @@
 	if ((len = PAGE_ALIGN(len)) == 0)
 		return addr;
 
-	if (len > TASK_SIZE || addr > TASK_SIZE-len)
+	if (len > TASK_SIZE || ((flags & MAP_FIXED) && (addr > TASK_SIZE - len)))
 		return -EINVAL;
 
 	/* offset overflow? */
@@ -356,20 +356,31 @@
 unsigned long get_unmapped_area(unsigned long addr, unsigned long len)
 {
 	struct vm_area_struct * vmm;
+	int pass = 0;
 
 	if (len > TASK_SIZE)
 		return 0;
-	if (!addr)
-		addr = TASK_UNMAPPED_BASE;
-	addr = PAGE_ALIGN(addr);
-
-	for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) {
-		/* At this point:  (!vmm || addr < vmm->vm_end). */
-		if (TASK_SIZE - len < addr)
-			return 0;
-		if (!vmm || addr + len <= vmm->vm_start)
-			return addr;
-		addr = vmm->vm_end;
+
+	while (1) {
+		if (!addr)
+			addr = TASK_UNMAPPED_BASE;
+		addr = PAGE_ALIGN(addr);
+
+		for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) {
+			/* At this point:  (!vmm || addr < vmm->vm_end). */
+			if (TASK_SIZE - len < addr) {
+				if (pass > 0)
+					return 0;
+				else {
+					pass = 1;
+					addr = 0;
+					break;
+				}
+			}
+			if (!vmm || addr + len <= vmm->vm_start)
+				return addr;
+			addr = vmm->vm_end;
+		}
 	}
 }
 #endif

RE: User/Group Problem

[Ian Chilton]

Hello,

>  That's actually not a MIPS-specific problem.

I actually got round this by copying /lib/libnss* from glibc 2.0.6 over,
until I had finished compiling everything..


>From the LFS-Book:

------------ Quote --------------
Copying old NSS library files
If your normal Linux system runs glibc-2.0, you need to copy the NSS library
files to the LFS partition. Certain statically linked programs still depend
on the NSS library, especially programs that need to lookup
usernames,userid's and groupid's. You can check which C library version your
normal Linux system uses by running:

strings /lib/libc* | grep "release version"

The output of that command should tell you something like this:

GNU C Library stable release version 2.1.3, by Roland McGrath et al.

If you have a libc-2.0.x file copy the NSS library files by running:

cp -av /lib/libnss* $LFS/lib

--------------- End Quote --------------


Bye for Now,

Ian


                                \|||/
                                (o o)
 /---------------------------ooO-(_)-Ooo---------------------------\
 |  Ian Chilton        (IRC Nick - GadgetMan)     ICQ #: 16007717  |
 |-----------------------------------------------------------------|
 |  E-Mail: ian@ichilton.co.uk     Web: http://www.ichilton.co.uk  |
 \-----------------------------------------------------------------/

RE: User/Group Problem

[Ian Chilton]

Hello,

>  That's actually not a MIPS-specific problem.

I actually got round this by copying /lib/libnss* from glibc 2.0.6 over,
until I had finished compiling everything..


From the LFS-Book:

------------ Quote --------------
Copying old NSS library files
If your normal Linux system runs glibc-2.0, you need to copy the NSS library
files to the LFS partition. Certain statically linked programs still depend
on the NSS library, especially programs that need to lookup
usernames,userid's and groupid's. You can check which C library version your
normal Linux system uses by running:

strings /lib/libc* | grep "release version"

The output of that command should tell you something like this:

GNU C Library stable release version 2.1.3, by Roland McGrath et al.

If you have a libc-2.0.x file copy the NSS library files by running:

cp -av /lib/libnss* $LFS/lib

--------------- End Quote --------------


Bye for Now,

Ian


                                \|||/
                                (o o)
 /---------------------------ooO-(_)-Ooo---------------------------\
 |  Ian Chilton        (IRC Nick - GadgetMan)     ICQ #: 16007717  |
 |-----------------------------------------------------------------|
 |  E-Mail: ian@ichilton.co.uk     Web: http://www.ichilton.co.uk  |
 \-----------------------------------------------------------------/

Re: User/Group Problem

[Ralf Baechle]

On Mon, Nov 13, 2000 at 08:02:48PM +0100, Maciej W. Rozycki wrote:

> >  - your chown / chgrp binaries are statically linked.  In that case nss
> >    won't work on MIPS until it's fixed ...
> 
>  That's actually not a MIPS-specific problem.  This happens due to a bogus
> error from mmap() (when called by ld.so) which cannot handle certain valid
> requests -- when there is a non-zero suggested VM address, but the area
> and all space above it is already occupied or unavailable for other
> reasons.  It can sometimes appear for other ports, as well (I have an i386
> test case, for example), but it bites MIPS specifically, because of a
> non-zero initial VMA set for our shared objects.
> 
>  Here is a patch I use since July successfully.  We need to wait until
> 2.4.1 or so (or maybe even 2.5) is released for it to be applied as
> 2.4.0-test* are currently code-frozen.  Maybe we could apply it to our CVS
> for now?  Ralf, what do you think? 

There is second interpretation of this problem - the address passed to
mmap is bogus, so this computation needs to be fixed.

  Ralf

Re: User/Group Problem

[Maciej W. Rozycki]

On Mon, 13 Nov 2000, Ralf Baechle wrote:

> >  Here is a patch I use since July successfully.  We need to wait until
> > 2.4.1 or so (or maybe even 2.5) is released for it to be applied as
> > 2.4.0-test* are currently code-frozen.  Maybe we could apply it to our CVS
> > for now?  Ralf, what do you think? 
> 
> There is second interpretation of this problem - the address passed to
> mmap is bogus, so this computation needs to be fixed.

 Where is it written mmap() is allowed to fail when a bogus VM address is
passed but MAP_FIXED is not set?  I believe mmap() should choose a
different VM address in this case, as long as much enough contiguous VM
space is available anywhere to satisfy the requested length.

 Surely, map_segment() (see dl-load.c) might call mmap(0, ...) after
mmap(<some_address>, ...) fails when MAP_FIXED is not set but wouldn't
that be a dirty hack?  We'd better fix the kernel. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: User/Group Problem

[Ralf Baechle]

On Tue, Nov 14, 2000 at 03:19:11PM +0100, Maciej W. Rozycki wrote:

> > There is second interpretation of this problem - the address passed to
> > mmap is bogus, so this computation needs to be fixed.
> 
>  Where is it written mmap() is allowed to fail when a bogus VM address is
> passed but MAP_FIXED is not set?  I believe mmap() should choose a
> different VM address in this case, as long as much enough contiguous VM
> space is available anywhere to satisfy the requested length.

No argument about that, I do agree.

>  Surely, map_segment() (see dl-load.c) might call mmap(0, ...) after
> mmap(<some_address>, ...) fails when MAP_FIXED is not set but wouldn't
> that be a dirty hack?  We'd better fix the kernel. 

Ld.so isn't linked to the same base address as all other libraries for
obscure reasons.  Right now dl-machine.h use the constant value of 0x5ffe0000
as the base address which it assumes all libraries to be linked to - and that
makes us calculate the wrong base address which we're passing to mmap.

So we've got two bugs, not just one.  I knew about the ld.so part since
Linux/MIPS has shared libs.  It's just that this is the first time this bug
bites us.

  Ralf

Re: User/Group Problem

[Maciej W. Rozycki]

On Wed, 15 Nov 2000, Ralf Baechle wrote:

> Ld.so isn't linked to the same base address as all other libraries for
> obscure reasons.  Right now dl-machine.h use the constant value of 0x5ffe0000
> as the base address which it assumes all libraries to be linked to - and that
> makes us calculate the wrong base address which we're passing to mmap.

 I don't count this as a bug.  The ELF spec allows shared objects to be
loaded with any load address.  In fact it's great we are non-standard here
-- this makes catching bugs easier.  I've already found and fixed a few
bugs in gdb thanks to this difference. 

> So we've got two bugs, not just one.  I knew about the ld.so part since
> Linux/MIPS has shared libs.  It's just that this is the first time this bug
> bites us.

 I insist there is a kernel bug only.  We might change the enforced base
address within ld.so one day to be more like other archs, but let's keep
it for now -- this really benefits.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +