On Fri, 19 Nov 2004, Matthew Dillon wrote:
> :Hey,
> :
> :I had just finished updating to a very recent kernel (yesterday, HEAD),
> :and ran make upgrade. After this I couldn't use top(1) any more. It
> :reported access problems with /dev/mem (or /dev/kmem? dunno, doesn't
> :matter really).
> :
> :so this came up (after a fresh make upgrade!)
>
> :[...]
> :+ mknod kmem c 2 1 root:kmem
> :+ rm -f kmem
> :+ /sbin/mknod kmem c 2 1 root:kmem
> :+ chmod 640 kmem
> :[...]
> :21:37:49 corecode@sweatshorts:/dev % ll kmem
> :crw------- 1 root kmem 2, 1 Nov 17 21:37 kmem
> :
> :something was changing the mode, but I didn't run any weird program, so
> :I suspect the kernel. Unfortunately I'm no longer able to reproduce it,
> :still I could do so several times in a row.
> :
> :cheers
> : simon
>
> I couldn't reproduce it either.
>
> The next time this happens try to do the rm, mknod, and chmod manually
> and see if that works.
>
> Then run ktrace -i on the command you were using that reproduced the
> problem and if the problem is still present ship the ktrace file over
> to leaf. e.g.
>
> ktrace -f /tmp/kt.out -i make upgrade
The last two times I ran make upgrade I had wrong perms on /dev/null
afterward. When running the 'upgrade' I watched MAKEDEV run (without
errors) and on reboot /dev/null had the wrong perms.
Both times I fixed the problem by doing 'MAKDEV all' by hand,
so it doesn't look like there is anything wrong with MAKEDEV or
chmod. Could this have to do with the environment in which
MAKEDEV is run during the upgrade target?