From: Paul W. <pd...@ex...> - 2004-02-16 19:48:57
|
I'm trying to build my own UML kernel, but am having problems. The error I get is: # ./linux Checking for the skas3 patch in the host...found Checking for /proc/mm...found open - cannot create /tmp/vm_file-XXXXXX: Invalid argument ccs= I've checked the permissions on /tmp, tried changing TMPDIR, and tried compiling a test program that calls mkstemp with the same argument which works fine. Pre-built kernels work fine. I'm trying to compile 2.4.21, but have had exactly the same problems with 2.4.23. The host machine is roughly RH 7.2, with: [root@dragon uml]# uname -r 2.4.21 [root@dragon uml]# rpm -q glibc glibc-2.2.5-43 Google seems to have failed me on this problem. This thread: http://marc.theaimsgroup.com/?l=user-mode-linux-user&m=102058816401127&w=2 seems to be the same problem, but appears to be without a solution. I'd be grateful for any pointers. Paul |
From: Jeff D. <jd...@ad...> - 2004-02-17 00:44:34
|
pd...@ex... said: > I've checked the permissions on /tmp, tried changing TMPDIR, and tried > compiling a test program that calls mkstemp with the same argument > which works fine. The next to do would be to strace UML and see exactly what system call is failing. Jeff |
From: Paul W. <pd...@ex...> - 2004-02-17 01:34:02
|
On Mon, Feb 16, 2004 at 08:08:25PM -0500, Jeff Dike wrote: > pd...@ex... said: > > I've checked the permissions on /tmp, tried changing TMPDIR, and tried > > compiling a test program that calls mkstemp with the same argument > > which works fine. > > The next to do would be to strace UML and see exactly what system call is > failing. I did try that, but it didn't occur to me that the lack of any relevant system calls was actually suspicious: open("/dev/anon", O_RDWR) = -1 ENOENT (No such file or directory) rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 write(2, "[[/tmp/vm_file-XXXXXX]]\n", 24[[/tmp/vm_file-XXXXXX]] ) = 24 write(2, "open - cannot create /tmp/vm_fil"..., 59open - cannot create /tmp/vm_file-XXXXXX: Invalid argument ) = 59 write(2, "ccs=", 4ccs=) = 4 munmap(0x40000000, 4096) = 0 _exit(1) = ? It's not trying very hard, is it? (the first write is my debug). I have discovered that upgrading to glibc 2.3.2 fixes this problem. I had previously tried upgrading glibc, but only within 2.2.x. Paul |
From: Jeff D. <jd...@ad...> - 2004-02-17 03:21:51
|
pd...@ex... said: > It's not trying very hard, is it? (the first write is my debug). No it's not. You'd think that it would at least try to open a file. > write(2, "ccs=", 4ccs=) = 4 Do you know what this is? I checked the usage of it against the man page in case UML got tripped up by stricter argument checking, but it looks OK. The man page says: EINVAL The last six characters of template were not XXXXXX. Now tem- plate is unchanged. but it seems pretty clear that the template is right. So I'd chalk this up to being libc wierdness rather than a UML bug. Jeff |
From: Paul W. <pd...@ex...> - 2004-02-17 20:49:17
|
On Mon, Feb 16, 2004 at 10:45:39PM -0500, Jeff Dike wrote: > pd...@ex... said: > > It's not trying very hard, is it? (the first write is my debug). > > No it's not. You'd think that it would at least try to open a file. Quite. > > write(2, "ccs=", 4ccs=) = 4 > > Do you know what this is? No. I had assumed that it was coming from the kernel as an indirect result of mkstemp call, but grep and strings suggest that it's coming from libc. > EINVAL The last six characters of template were not XXXXXX. Now tem- > plate is unchanged. > > but it seems pretty clear that the template is right. > > So I'd chalk this up to being libc wierdness rather than a UML bug. Yeah. Paul |