NetBSD Problem Report #36963
From martin@duskware.de Mon Sep 10 12:32:13 2007
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by narn.NetBSD.org (Postfix) with ESMTP id D74AA63B89F
for <gnats-bugs@gnats.netbsd.org>; Mon, 10 Sep 2007 12:32:13 +0000 (UTC)
Message-Id: <20070910115001.4979E63B89F@narn.NetBSD.org>
Date: Mon, 10 Sep 2007 11:50:01 +0000 (UTC)
From: jan.m.danielsson@gmail.com
Reply-To: jan.m.danielsson@gmail.com
To: netbsd-bugs-owner@NetBSD.org
Subject: NetBSD complains about permissions problems
X-Send-Pr-Version: www-1.0
>Number: 36963
>Category: kern
>Synopsis: NetBSD complains about permissions problems
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Sep 10 12:35:00 +0000 2007
>Closed-Date: Fri Sep 30 08:05:08 +0000 2016
>Last-Modified: Fri Sep 30 08:05:08 +0000 2016
>Originator: Jan Danielsson
>Release: NetBSD/amd64 4.0 RC1
>Organization:
Confuse A Cat Inc.
>Environment:
NetBSD nl102-238-202.student.uu.se 4.0_RC1 NetBSD 4.0_RC1 (ANCABOOT) #0: Wed Sep 5 14:40:43 CEST 2007 jan@nl102-238-202.student.uu.se:/home/jan/netbsd4/rc1/obj.amd64/home/jan/netbsd4/rc1/src/sys/arch/amd64/compile/ANCABOOT amd64
>Description:
When I start postfix, I get this:
--------
nl102-238-202# /etc/rc.d/postfix start
postsuper: fatal: scan_dir_push: open directory defer: Permission denied
postfix/postfix-script: fatal: Postfix integrity check failed!
--------
When I start postgresql, I get this:
--------
nl102-238-202# /etc/rc.d/pgsql start
Initializing PostgreSQL databases.
The files belonging to this database system will be owned by user "pgsql".
This user must also own the server process.
The database cluster will be initialized with locale C.
creating directory /var/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 40
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating configuration files ... ok
creating template1 database in /var/pgsql/data/base/1 ... FATAL: could not open directory "pg_twophase": Permission denied
child process exited with exit code 1
initdb: removing data directory "/var/pgsql/data"
could not open directory "/var/pgsql/data": Permission denied
initdb: failed to remove data directory
--------
In both cases, I have "verified" (with "ls -l") that the permissions are ok.
>How-To-Repeat:
All I need to do on my NetBSD/amd64 4.0 RC1 system is:
# /etc/rc.d/postfix start
# /etc/rc.d/pgsql start
>Fix:
None.
>Release-Note:
>Audit-Trail:
From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/36963
Date: Mon, 10 Sep 2007 14:57:03 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I just remembered a really odd problem I had which is probably
related. I have a user called pkgsrc which (obviously) is for sync:ing
pkgsrc, etc. I su:ed to the pkgsrc user, checked out a new fresh copy of
pkgsrc, and started to browse around the tree. Then I did something else
for a while. When I switched back to the pkgsrc terminal, and typed "ls
- -l", I got an error about the directory not being readable. No matter
what I did, it behaved like someone had pulled the rug from under its
feet (read: it suddenly lost all it's permissions to its own directory).
One common denominator between postfix, postgresql and the pkgsrc
user problem is "su". But I don't know if it's relevant.
- --
Kind regards,
Jan Danielsson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
iD8DBQFG5T8euPlHKFfKXTYRCsNFAJwIhlNW9LtUDogZ55fgCtYPWSIVHgCfQ/Sl
ZSqOI/LqvfCgvbk7pCCEgTY=
=QlOq
-----END PGP SIGNATURE-----
From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/36963
Date: Mon, 10 Sep 2007 17:31:53 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Another thing which may be, or is probably not, relevant. I have
"init chrooted" (sysctl init.root) from a booted memory disk to a
harddrive partition. It shouldn't matter, but I'm mentioning it anyway,
for the record.
- --
Kind regards,
Jan Danielsson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
iD8DBQFG5WNpuPlHKFfKXTYRCsNbAJ9zoO4tN9wc4RaLSfurcPE3iM4TPACcCxFd
g+EbVMnmA0bHr79jsDPeWaI=
=/X0o
-----END PGP SIGNATURE-----
From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/36963
Date: Sat, 15 Sep 2007 21:30:54 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I tried to add a new user, and logged in with it, and ran "ls -l",
but it immediately complained about a permission problem with ".". But I
can log in with my normal user without this problem. The only relevant
difference between between these, afaict is that the new user didn't
belong to the "wheel" group. I added the new user to the wheel group,
and tried to log in again, and ran "ls -l". This time it worked.
So, simply belonging to the group "wheel" seems to make a difference.
The home directory ownership and group are correct; i.e. owned by the
user, and the group is "users", and the permissions are rwxr-xr-x.
- --
Kind regards,
Jan Danielsson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
iD8DBQFG7DLuuPlHKFfKXTYRCiiCAJwIaYUDl6P9QgPJIXs8V8ryDUJ8fACeNuoj
rXZnxtgEMohKizTyqUsrm7k=
=YUIT
-----END PGP SIGNATURE-----
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: jan.m.danielsson@gmail.com
Subject: Re: kern/36963
Date: Sat, 15 Sep 2007 21:44:33 +0200
On Sat, Sep 15, 2007 at 07:35:03PM +0000, Jan Danielsson wrote:
> So, simply belonging to the group "wheel" seems to make a difference.
Could you ktrace the working and the failing "ls" and check for differences
in the kdump output?
Martin
From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/36963
Date: Sun, 16 Sep 2007 18:11:23 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
The previous comment about how belonging to "wheel" changes things
may not be relevant. It turns out the permission problem comes and goes.
It's mostly there, but at times the system seems to behave very
normally. I must have had some really good timing.
As Martin Husemann suggested, I tried to kdump the "ls -l", both when
it was working and when it wasn't. I finally gave up waiting for it to
work again, so I rebooted. The beginning of the files follows.
fails.log:
- --------------------------------------------------------
24778 1 ktrace EMUL "netbsd"
24778 1 ktrace CALL
execve(0x7f7fffffe870,0x7f7fffffed68,0x7f7fffffed80)
24778 1 ktrace NAMI "/home/pkgsrc/bin/ls"
24778 1 ktrace RET execve -1 errno 2 No such file or directory
24778 1 ktrace CALL
execve(0x7f7fffffe870,0x7f7fffffed68,0x7f7fffffed80)
24778 1 ktrace NAMI "/bin/ls"
24778 1 ktrace NAMI "/libexec/ld.elf_so"
24778 1 ls EMUL "netbsd"
24778 1 ls RET execve JUSTRETURN
24778 1 ls CALL mmap(0,0x8000,3,0x1002,0xffffffff,0,0)
24778 1 ls RET mmap 140187698954240/0x7f7ffdff8000
24778 1 ls CALL open(0x7f7ffde0a82e,0,0x7f7ffde0a82e)
24778 1 ls NAMI "/etc/ld.so.conf"
24778 1 ls RET open -1 errno 2 No such file or directory
24778 1 ls CALL open(0x7f7fffffe5d8,0,0xff31302d6e722d62)
24778 1 ls NAMI "/lib/libc.so.12"
24778 1 ls RET open 3
24778 1 ls CALL __fstat30(3,0x7f7fffffe508)
24778 1 ls RET __fstat30 0
24778 1 ls CALL mmap(0,0x1000,1,1,3,0x7f7f00000000,0)
24778 1 ls RET mmap 140187698950144/0x7f7ffdff7000
24778 1 ls CALL munmap(0x7f7ffdff7000,0x1000)
24778 1 ls RET munmap 0
24778 1 ls CALL
mmap(0,0x207000,5,0x14000002,3,0x7f7f00000000,0)
24778 1 ls RET mmap 140187693744128/0x7f7ffdb00000
24778 1 ls CALL
mmap(0x7f7ffdceb000,0xb000,3,0x12,3,0x7f7f00000000,0xeb000)
24778 1 ls RET mmap 140187695755264/0x7f7ffdceb000
24778 1 ls CALL
mmap(0x7f7ffdcf6000,0x11000,3,0x1012,0xffffffff,0x7f7f00000000,0)
24778 1 ls RET mmap 140187695800320/0x7f7ffdcf6000
24778 1 ls CALL mprotect(0x7f7ffdbeb000,0x100000,0)
24778 1 ls RET mprotect 0
24778 1 ls CALL close(3)
24778 1 ls RET close 0
24778 1 ls CALL
__sysctl(0x7f7fffffecb0,2,0x7f7ffdcfa320,0x7f7fffffeca8,0,0)
24778 1 ls RET __sysctl 0
24778 1 ls CALL issetugid
24778 1 ls RET issetugid 0
24778 1 ls CALL ioctl(1,TIOCGETA,0x7f7fffffecc0)
24778 1 ls GIO fd 1 read 44 bytes
"\^F#\0\0\^C\0\0\0\0\v\0\0\M-O\^E\0
\^D\M^?\M^?\^?\^W\^U\^R\M^?\^C\^\\^Z\^Y\^Q\^S\^V\^O\^A\0\^T\M^?\0\M^V\0\0\0\M^V\0\0"
24778 1 ls RET ioctl 0
24778 1 ls CALL ioctl(1,TIOCGWINSZ,0x7f7fffffed00)
24778 1 ls GIO fd 1 read 8 bytes
"@\0\M^D\0\0\0\0\0"
24778 1 ls RET ioctl 0
24778 1 ls CALL getuid
24778 1 ls RET getuid 1001/0x3e9, 1001/0x3e9
24778 1 ls CALL
__sysctl(0x7f7fffffeb80,2,0x7f7fffffeb9c,0x7f7fffffeb90,0,0)
24778 1 ls RET __sysctl 0
24778 1 ls CALL readlink(0x7f7ffdbd92ac,0x7f7fffffebb0,0x3f)
24778 1 ls NAMI "/etc/malloc.conf"
24778 1 ls RET readlink -1 errno 2 No such file or directory
24778 1 ls CALL mmap(0,0x1000,3,0x1002,0xffffffff,0,0)
24778 1 ls RET mmap 140187698950144/0x7f7ffdff7000
24778 1 ls CALL break(0x505838)
24778 1 ls RET break 0
24778 1 ls CALL break(0x506838)
24778 1 ls RET break 0
24778 1 ls CALL break(0x507000)
24778 1 ls RET break 0
24778 1 ls CALL break(0x508000)
24778 1 ls RET break 0
24778 1 ls CALL break(0x509000)
24778 1 ls RET break 0
24778 1 ls CALL break(0x50a000)
24778 1 ls RET break 0
24778 1 ls CALL break(0x50b000)
24778 1 ls RET break 0
24778 1 ls CALL __lstat30(0x50a168,0x50a170)
24778 1 ls NAMI "."
24778 1 ls RET __lstat30 0
24778 1 ls CALL open(0x7f7ffdbd52fc,0,0)
24778 1 ls NAMI "."
24778 1 ls RET open 3
24778 1 ls CALL fcntl(3,2,1)
24778 1 ls RET fcntl 0
24778 1 ls CALL fchdir(3)
24778 1 ls RET fchdir 0
24778 1 ls CALL open(0x7f7ffdbd52fc,0,0)
24778 1 ls NAMI "."
24778 1 ls RET open 4
24778 1 ls CALL open(0x509000,4,0x50a100)
24778 1 ls NAMI "."
24778 1 ls RET open 5
24778 1 ls CALL fcntl(5,2,1)
24778 1 ls RET fcntl 0
24778 1 ls CALL __fstat30(5,0x7f7fffffeb40)
24778 1 ls RET __fstat30 0
24778 1 ls CALL
__sysctl(0x7f7fffffe210,2,0x7f7ffdd05a60,0x7f7fffffe208,0,0)
24778 1 ls RET __sysctl 0
24778 1 ls CALL fstatvfs1(5,0x7f7fffffe270,2)
24778 1 ls RET fstatvfs1 -1 errno 13 Permission denied
24778 1 ls CALL close(5)
24778 1 ls RET close 0
24778 1 ls CALL fchdir(4)
24778 1 ls RET fchdir 0
24778 1 ls CALL close(4)
24778 1 ls RET close 0
- --------------------------------------------------------
works.log:
- --------------------------------------------------------
959 1 ktrace EMUL "netbsd"
959 1 ktrace CALL
execve(0x7f7fffffe870,0x7f7fffffed68,0x7f7fffffed80)
959 1 ktrace NAMI "/home/pkgsrc/bin/ls"
959 1 ktrace RET execve -1 errno 2 No such file or directory
959 1 ktrace CALL
execve(0x7f7fffffe870,0x7f7fffffed68,0x7f7fffffed80)
959 1 ktrace NAMI "/bin/ls"
959 1 ktrace NAMI "/libexec/ld.elf_so"
959 1 ls EMUL "netbsd"
959 1 ls RET execve JUSTRETURN
959 1 ls CALL mmap(0,0x8000,3,0x1002,0xffffffff,0,0)
959 1 ls RET mmap 140187698954240/0x7f7ffdff8000
959 1 ls CALL open(0x7f7ffde0a82e,0,0x7f7ffde0a82e)
959 1 ls NAMI "/etc/ld.so.conf"
959 1 ls RET open -1 errno 2 No such file or directory
959 1 ls CALL open(0x7f7fffffe5d8,0,0xff31302d6e722d62)
959 1 ls NAMI "/lib/libc.so.12"
959 1 ls RET open 3
959 1 ls CALL __fstat30(3,0x7f7fffffe508)
959 1 ls RET __fstat30 0
959 1 ls CALL mmap(0,0x1000,1,1,3,0x7f7f00000000,0)
959 1 ls RET mmap 140187698950144/0x7f7ffdff7000
959 1 ls CALL munmap(0x7f7ffdff7000,0x1000)
959 1 ls RET munmap 0
959 1 ls CALL
mmap(0,0x207000,5,0x14000002,3,0x7f7f00000000,0)
959 1 ls RET mmap 140187693744128/0x7f7ffdb00000
959 1 ls CALL
mmap(0x7f7ffdceb000,0xb000,3,0x12,3,0x7f7f00000000,0xeb000)
959 1 ls RET mmap 140187695755264/0x7f7ffdceb000
959 1 ls CALL
mmap(0x7f7ffdcf6000,0x11000,3,0x1012,0xffffffff,0x7f7f00000000,0)
959 1 ls RET mmap 140187695800320/0x7f7ffdcf6000
959 1 ls CALL mprotect(0x7f7ffdbeb000,0x100000,0)
959 1 ls RET mprotect 0
959 1 ls CALL close(3)
959 1 ls RET close 0
959 1 ls CALL
__sysctl(0x7f7fffffecb0,2,0x7f7ffdcfa320,0x7f7fffffeca8,0,0)
959 1 ls RET __sysctl 0
959 1 ls CALL issetugid
959 1 ls RET issetugid 0
959 1 ls CALL ioctl(1,TIOCGETA,0x7f7fffffecc0)
959 1 ls GIO fd 1 read 44 bytes
"\^B+\0\0\^C\0\0\0\0K\0\0\M-K\^E\0
\^D\M^?\M^?\^?\^W\^U\^R\M^?\^C\^\\^Z\^Y\^Q\^S\^V\^O\^A\0\^T\M^?\M^@%\0\0\M^@%\0\0"
959 1 ls RET ioctl 0
959 1 ls CALL ioctl(1,TIOCGWINSZ,0x7f7fffffed00)
959 1 ls GIO fd 1 read 8 bytes
"2\0P\0\0\0\0\0"
959 1 ls RET ioctl 0
959 1 ls CALL getuid
959 1 ls RET getuid 1001/0x3e9, 1001/0x3e9
959 1 ls CALL
__sysctl(0x7f7fffffeb80,2,0x7f7fffffeb9c,0x7f7fffffeb90,0,0)
959 1 ls RET __sysctl 0
959 1 ls CALL readlink(0x7f7ffdbd92ac,0x7f7fffffebb0,0x3f)
959 1 ls NAMI "/etc/malloc.conf"
959 1 ls RET readlink -1 errno 2 No such file or directory
959 1 ls CALL mmap(0,0x1000,3,0x1002,0xffffffff,0,0)
959 1 ls RET mmap 140187698950144/0x7f7ffdff7000
959 1 ls CALL break(0x505838)
959 1 ls RET break 0
959 1 ls CALL break(0x506838)
959 1 ls RET break 0
959 1 ls CALL break(0x507000)
959 1 ls RET break 0
959 1 ls CALL break(0x508000)
959 1 ls RET break 0
959 1 ls CALL break(0x509000)
959 1 ls RET break 0
959 1 ls CALL break(0x50a000)
959 1 ls RET break 0
959 1 ls CALL break(0x50b000)
959 1 ls RET break 0
959 1 ls CALL __lstat30(0x50a168,0x50a170)
959 1 ls NAMI "."
959 1 ls RET __lstat30 0
959 1 ls CALL open(0x7f7ffdbd52fc,0,0)
959 1 ls NAMI "."
959 1 ls RET open 3
959 1 ls CALL fcntl(3,2,1)
959 1 ls RET fcntl 0
959 1 ls CALL fchdir(3)
959 1 ls RET fchdir 0
959 1 ls CALL open(0x7f7ffdbd52fc,0,0)
959 1 ls NAMI "."
959 1 ls RET open 4
959 1 ls CALL open(0x509000,4,0x50a100)
959 1 ls NAMI "."
959 1 ls RET open 5
959 1 ls CALL fcntl(5,2,1)
959 1 ls RET fcntl 0
959 1 ls CALL __fstat30(5,0x7f7fffffeb40)
959 1 ls RET __fstat30 0
959 1 ls CALL
__sysctl(0x7f7fffffe210,2,0x7f7ffdd05a60,0x7f7fffffe208,0,0)
959 1 ls RET __sysctl 0
959 1 ls CALL fstatvfs1(5,0x7f7fffffe270,2)
959 1 ls RET fstatvfs1 0
959 1 ls CALL break(0x50c000)
959 1 ls RET break 0
959 1 ls CALL __fstat30(5,0x7f7fffffeb50)
959 1 ls RET __fstat30 0
959 1 ls CALL fchdir(5)
959 1 ls RET fchdir 0
959 1 ls CALL lseek(5,0,0,1)
959 1 ls RET lseek 0
959 1 ls CALL __getdents30(5,0x50b000,0x1000)
959 1 ls GIO fd 5 read 440 bytes
- --------------------------------------------------------
Lines 40 and 92 (and below) differ.
When ls fails:
24778 1 ls CALL fstatvfs1(5,0x7f7fffffe270,2)
24778 1 ls RET fstatvfs1 -1 errno 13 Permission denied
When ls succeeds:
959 1 ls CALL fstatvfs1(5,0x7f7fffffe270,2)
959 1 ls RET fstatvfs1 0
I find it important to stress that I have done no system
configuration changes between these runs.
- --
Kind regards,
Jan Danielsson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
iD8DBQFG7VWruPlHKFfKXTYRCu+lAKCWYHfLAtOoDta01GQlF/9WjsgoVgCghCSb
JWXrT45cH+YQ9y9Yo4Ed7YQ=
=/CTo
-----END PGP SIGNATURE-----
From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/36963
Date: Sun, 16 Sep 2007 23:06:12 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I put together the program below. And tried running it in various
environments.
- ----------------------------------
#include <stdio.h>
#include <dirent.h>
int main(void)
{
DIR *dirp = opendir(".");
if (dirp != NULL)
{
puts("Success!");
(void)closedir(dirp);
}
else
{
puts("Error!");
}
return 0;
}
- ----------------------------------
Using my normal "jan" user (it has never exhibited the permission
problem):
$ gcc -o permtest permtest.c
$ ./permtest
Success!
$ cp permtest /tmp/permtest
$ chmod 755 /tmp/permtest
$ ls -l /tmp | grep perm
- -rwxr-xr-x 1 jan wheel 8431 Sep 16 22:55 permtest
root:
# useradd -m test
# su - test
$ pwd
/home/test
$ /tmp/permtest
Error!
.. a few minutes later ..
# su - test
$ /tmp/permtest
Success!
Note: No changes were made between the runs. It will revert to
showing "Error!" sooner or later.
- --
Kind regards,
Jan Danielsson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
iD8DBQFG7ZrEuPlHKFfKXTYRCuTFAJ0bfDyB24T1PvxR2AqlMaiyGs8ewgCfVg/i
ulS3IVkMSw6AK9kf4jWoqt0=
=Ptre
-----END PGP SIGNATURE-----
From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/36963
Date: Mon, 17 Sep 2007 16:24:04 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I think I figured out how to make the permissions work again, though
only temporarily. I simply login with my normal user "jan", and then log
out again. For some reason, that user always works. And once I have
performed the login, the other users (pgsql, the www user (for apache),
pkgsrc, and other test users) can perform the opendir(".") call without
errors. But after a while, the bug does show up again, and I need to
login/logout with my "jan" user.
The only differences between my user "jan" and those which fail are:
- user id
- home dir
- I use bash, the others use nologin, ksh or sh. (But my root user
also uses ksh, without problems).
- I belong to the group "wheel", the others don't
- --
Kind regards,
Jan Danielsson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
iD8DBQFG7o4EuPlHKFfKXTYRCpSeAKCZwR5DwgusoLHOZLvhORf6hWVIogCbBwZ/
KgZDiLIRsvYUddq7CMZ61UE=
=cDas
-----END PGP SIGNATURE-----
From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/36963
Date: Sun, 15 Mar 2009 15:26:02 +0100
It's strange, but it seems like the problem may be circumvented by
booting from a CD rather than from a USB memory key. I have only tried
various configurations on three different computers, but it seems that
the weird permission problem manifests itself when the system is booted
from an USB memory key, while booting from a CD results in a stable OS.
I haven't seen the problem on i386 (and it doesn't seem like anyone
else has, either), so it seems to affect NetBSD/amd64 when booting off USB.
State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Wed, 27 Aug 2014 18:52:09 +0000
State-Changed-Why:
Have you seen this problem recently?
I suspect kauth.
From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@gnats.netbsd.org
Cc:
Subject: Re: kern/36963
Date: Fri, 05 Sep 2014 21:46:46 +0200
I haven't tried for a while. When time permits, I will merge my
patches to netbsd-7 and see if the problem is reproducible.
--
Kind Regards,
Jan
State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Fri, 30 Sep 2016 08:05:08 +0000
State-Changed-Why:
feedback timeout
this is most likely tmpfs problems that have since been fixed.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home