|| ||Ingo Molnar <mingo-AT-elte.hu> |
|| ||"Eric W. Biederman" <ebiederm-AT-xmission.com> |
|| ||[bug] /etc/profile: line 30: /dev/null: Permission denied (Was:
Re: [PATCH] Remove broken by design and by implementation devtmpfs
maintenance disaster) |
|| ||Thu, 17 Sep 2009 20:53:06 +0200|
|| ||Greg KH <greg-AT-kroah.com>,
Linus Torvalds <torvalds-AT-linux-foundation.org>,
linux-kernel-AT-vger.kernel.org, Kay Sievers <kay.sievers-AT-vrfy.org>|
|| ||Article, Thread
* Eric W. Biederman <firstname.lastname@example.org> wrote:
> Greg this code does not live up to the standards you have repeatedly
> asserted are required for accepting core kernel code. Neither you nor
> Kay show any interest in fixing even the most trivial of bugs. Must
> less discuss alternate solutions to the problem.
on a tangential note - i have no opinion yet in this discussion, but i
found no pull request email on lkml and wanted to report a devtmpfs bug:
I've reproduced a bug with the following .config options:
/dev/null and /dev/zero are not read/writable to ordinary users,
breaking normal bootup and login:
PTY allocation request failed on channel 0
/etc/profile: line 30: /dev/null: Permission denied
/etc/profile.d/colorls.sh: line 3: /dev/null: Permission denied
/etc/profile.d/colorls.sh: line 4: /dev/null:
/etc/profile.d/vim.sh: line 5: /dev/null: Permission denied
Connection to m
closed by remote host.
Connection to m closed.
Regarding the wish to have in-kernel code: another solution which i have
not seen mentioned would be to move udev into tools/udev/ instead. That
would give a single, coherent user-space kernel-space combo.
The concept certainly works great for tools/perf/.
The system boots up fine with devtmpfs disabled:
Last login: Fri Sep 18 02:48:19 2009 from sirius
to post comments)