Subject: User/Group Problem

From: Ian Chilton <[email-masked]>
Date: Tue, 7 Nov 2000 11:06:10 +0000

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 : [email-masked]              |
 \-------------------------------------------/

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 8 Nov 2000 05:01:58 +0100

> 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

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 13 Nov 2000 20:02:48 +0100 (MET)

>    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: [email-masked], 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

---

From: "Ian Chilton" <[email-masked]>
Date: Mon, 13 Nov 2000 20:02:21 -0000

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: [email-masked]     Web: http://www.ichilton.co.uk  |
 \-----------------------------------------------------------------/

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 13 Nov 2000 23:19:49 +0100

> 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

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 14 Nov 2000 15:19:11 +0100 (MET)

> 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

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 15 Nov 2000 08:52:45 +0100

> space is available anywhere to satisfy the requested length.

No argument about that, I do agree.

> 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

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 16 Nov 2000 13:13:40 +0100 (MET)

> 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. 

> Linux/MIPS has shared libs.  It's just that this is the first time this bug

 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