[Buildroot] [PATCH] system/device_table.txt: add /dev/null entry

[Buildroot] [PATCH] system/device_table.txt: add /dev/null entry

[Baruch Siach]

/dev/null is the "console" for system startup commands listed in the default
/etc/inittab. These commands fail when /dev/null isn't there. This breaks
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV, as /proc and /sys are not mounted when
mdev runs, causing the following errors:

can't open /dev/null: No such file or directory
can't open /dev/null: No such file or directory
can't open /dev/null: No such file or directory
can't open /dev/null: No such file or directory
can't open /dev/null: No such file or directory
can't open /dev/null: No such file or directory
...
Starting mdev...
/etc/init.d/S10mdev: line 19: can't create /proc/sys/kernel/hotplug: nonexistent directory
mdev: /sys/class: No such file or directory

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
 system/device_table.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/system/device_table.txt b/system/device_table.txt
index 8e7dbd218a2c..7b92d23b822f 100644
--- a/system/device_table.txt
+++ b/system/device_table.txt
@@ -7,6 +7,7 @@
 #
 # <name>				<type>	<mode>	<uid>	<gid>	<major>	<minor>	<start>	<inc>	<count>
 /dev					d	755	0	0	-	-	-	-	-
+/dev/null				c	666	0	0	1	3	0	0	-
 /tmp					d	1777	0	0	-	-	-	-	-
 /etc					d	755	0	0	-	-	-	-	-
 /root					d	700	0	0	-	-	-	-	-
-- 
2.1.3

[Buildroot] [PATCH] system/device_table.txt: add /dev/null entry

[Peter Korsgaard]

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

 > /dev/null is the "console" for system startup commands listed in the default
 > /etc/inittab. These commands fail when /dev/null isn't there. This breaks
 > BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV, as /proc and /sys are not mounted when
 > mdev runs, causing the following errors:

 > can't open /dev/null: No such file or directory
 > can't open /dev/null: No such file or directory
 > can't open /dev/null: No such file or directory
 > can't open /dev/null: No such file or directory
 > can't open /dev/null: No such file or directory
 > can't open /dev/null: No such file or directory
 > ...

Hmm, is this on a kernel without devtmpfs? Devtmpfs is expected to be
used with mdev (and we automatically enable it if you build a kernel
with BR).

> Starting mdev...
 > /etc/init.d/S10mdev: line 19: can't create /proc/sys/kernel/hotplug: nonexistent directory
 > mdev: /sys/class: No such file or directory

So you don't have /proc and /sys? Is this also a custom rootfs skeleton
/ inittab? With the default one we do a mount -a before running /etc/init.d/rcS.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] system/device_table.txt: add /dev/null entry

[Baruch Siach]

Hi Peter,

On Thu, Nov 27, 2014 at 08:56:40AM +0100, Peter Korsgaard wrote:
> >>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
> 
>  > /dev/null is the "console" for system startup commands listed in the default
>  > /etc/inittab. These commands fail when /dev/null isn't there. This breaks
>  > BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV, as /proc and /sys are not mounted when
>  > mdev runs, causing the following errors:
> 
>  > can't open /dev/null: No such file or directory
>  > can't open /dev/null: No such file or directory
>  > can't open /dev/null: No such file or directory
>  > can't open /dev/null: No such file or directory
>  > can't open /dev/null: No such file or directory
>  > can't open /dev/null: No such file or directory
>  > ...
> 
> Hmm, is this on a kernel without devtmpfs? Devtmpfs is expected to be
> used with mdev (and we automatically enable it if you build a kernel
> with BR).

I am currently using a kernel built with no devtmpfs support. Don't we support 
mdev without devtmpfs anymore? Once I added /dev/null the system seems to boot 
successfully as is, with /dev fully populated.

> > Starting mdev...
>  > /etc/init.d/S10mdev: line 19: can't create /proc/sys/kernel/hotplug: nonexistent directory
>  > mdev: /sys/class: No such file or directory
> 
> So you don't have /proc and /sys? Is this also a custom rootfs skeleton
> / inittab? With the default one we do a mount -a before running /etc/init.d/rcS.

I use the default inittab. The thing is that since /dev/null is missing, all 
inittab commands having "null" as console don't run, as I explained in the 
commit log above.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH] system/device_table.txt: add /dev/null entry

[Peter Korsgaard]

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

Hi,

>> > can't open /dev/null: No such file or directory
 >> > can't open /dev/null: No such file or directory
 >> > can't open /dev/null: No such file or directory
 >> > can't open /dev/null: No such file or directory
 >> > can't open /dev/null: No such file or directory
 >> > can't open /dev/null: No such file or directory
 >> > ...
 >> 
 >> Hmm, is this on a kernel without devtmpfs? Devtmpfs is expected to be
 >> used with mdev (and we automatically enable it if you build a kernel
 >> with BR).

 > I am currently using a kernel built with no devtmpfs support. Don't
 > we support mdev without devtmpfs anymore? Once I added /dev/null the
 > system seems to boot successfully as is, with /dev fully populated.

Well, it presumably doesn't get a lot of testing atleast as none of this
stuff afaik has changed the last few years.

Is there any specific reason why you don't use devtmpfs? It's quite
small and has been in the kernel since 2.6.32.

With that said, if just adding /dev/null fixes it for you then we can
certainly add it. What about similar things like /dev/console, /dev/tty
or your serial port?

Alternatively we can just ask people who don't want to use devtmpfs to
use system/dev_table_dev.txt as well, similar to how we do it for static /dev.


 >> > Starting mdev...
 >> > /etc/init.d/S10mdev: line 19: can't create /proc/sys/kernel/hotplug: nonexistent directory
 >> > mdev: /sys/class: No such file or directory
 >> 
 >> So you don't have /proc and /sys? Is this also a custom rootfs skeleton
 >> / inittab? With the default one we do a mount -a before running /etc/init.d/rcS.

 > I use the default inittab. The thing is that since /dev/null is missing, all 
 > inittab commands having "null" as console don't run, as I explained in the 
 > commit log above.

Ahh yes.

-- 
Bye, Peter Korsgaard 

[Buildroot] [PATCH] system/device_table.txt: add /dev/null entry

[Baruch Siach]

Hi Peter,

On Thu, Nov 27, 2014 at 10:01:54AM +0100, Peter Korsgaard wrote:
> >>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
> >> > can't open /dev/null: No such file or directory
>  >> > can't open /dev/null: No such file or directory
>  >> > can't open /dev/null: No such file or directory
>  >> > can't open /dev/null: No such file or directory
>  >> > can't open /dev/null: No such file or directory
>  >> > can't open /dev/null: No such file or directory
>  >> > ...
>  >> 
>  >> Hmm, is this on a kernel without devtmpfs? Devtmpfs is expected to be
>  >> used with mdev (and we automatically enable it if you build a kernel
>  >> with BR).
> 
>  > I am currently using a kernel built with no devtmpfs support. Don't
>  > we support mdev without devtmpfs anymore? Once I added /dev/null the
>  > system seems to boot successfully as is, with /dev fully populated.
> 
> Well, it presumably doesn't get a lot of testing atleast as none of this
> stuff afaik has changed the last few years.
> 
> Is there any specific reason why you don't use devtmpfs? It's quite
> small and has been in the kernel since 2.6.32.

I have just started with a precompiled kernel image that I got with this 
evaluation board to see how far I can get. Eventually I plan to rebuild 
everything and also enable devtmpfs.

> With that said, if just adding /dev/null fixes it for you then we can
> certainly add it. What about similar things like /dev/console, /dev/tty
> or your serial port?

/dev/console is already in the rootfs.tar image, I'm not sure whare it comes 
from. All other device nodes are later generated by mdev.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH] system/device_table.txt: add /dev/null entry

[Peter Korsgaard]

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

Hi,

>> > I am currently using a kernel built with no devtmpfs support. Don't
 >> > we support mdev without devtmpfs anymore? Once I added /dev/null the
 >> > system seems to boot successfully as is, with /dev fully populated.
 >> 
 >> Well, it presumably doesn't get a lot of testing atleast as none of this
 >> stuff afaik has changed the last few years.
 >> 
 >> Is there any specific reason why you don't use devtmpfs? It's quite
 >> small and has been in the kernel since 2.6.32.

 > I have just started with a precompiled kernel image that I got with this 
 > evaluation board to see how far I can get. Eventually I plan to rebuild 
 > everything and also enable devtmpfs.

Ok.

 >> With that said, if just adding /dev/null fixes it for you then we can
 >> certainly add it. What about similar things like /dev/console, /dev/tty
 >> or your serial port?

 > /dev/console is already in the rootfs.tar image, I'm not sure whare it comes 
 > from. All other device nodes are later generated by mdev.

The only thing that comes to mind is that you are creating a cpio:

fs/cpio/cpio.mk:PACKAGES_PERMISSIONS_TABLE += /dev/console c 622 0 0 5 1 - - -$(sep)

-- 
Bye, Peter Korsgaard 

[Buildroot] [PATCH] system/device_table.txt: add /dev/null entry

[Baruch Siach]

Hi Peter,

On Thu, Nov 27, 2014 at 11:24:38AM +0100, Peter Korsgaard wrote:
> >>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
>  >> With that said, if just adding /dev/null fixes it for you then we can
>  >> certainly add it. What about similar things like /dev/console, /dev/tty
>  >> or your serial port?
> 
>  > /dev/console is already in the rootfs.tar image, I'm not sure whare it comes 
>  > from. All other device nodes are later generated by mdev.
> 
> The only thing that comes to mind is that you are creating a cpio:
> 
> fs/cpio/cpio.mk:PACKAGES_PERMISSIONS_TABLE += /dev/console c 622 0 0 5 1 - - -$(sep)

You are right that I was creating a cpio, but apparently that's not the cause. 
Disabling the cpio image followed by 'make clean; make' didn't remove 
/dev/console. The code at fs/cpio/cpio.mk indicates that the above line always 
takes effect when !BR2_ROOTFS_DEVICE_CREATION_STATIC regardless of 
BR2_TARGET_ROOTFS_CPIO.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH] system/device_table.txt: add /dev/null entry

[Peter Korsgaard]

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

 >> The only thing that comes to mind is that you are creating a cpio:
 >> 
 >> fs/cpio/cpio.mk:PACKAGES_PERMISSIONS_TABLE += /dev/console c 622 0 0 5 1 - - -$(sep)

 > You are right that I was creating a cpio, but apparently that's not the cause. 
 > Disabling the cpio image followed by 'make clean; make' didn't remove 
 > /dev/console. The code at fs/cpio/cpio.mk indicates that the above line always 
 > takes effect when !BR2_ROOTFS_DEVICE_CREATION_STATIC regardless of 
 > BR2_TARGET_ROOTFS_CPIO.

Ahh yes, that's a bug (but pretty harmless).

-- 
Peter Korsgaard 

[Buildroot] [PATCH] system/device_table.txt: add /dev/null entry

[Thomas Petazzoni]

Dear Baruch Siach,

On Thu, 27 Nov 2014 08:44:36 +0200, Baruch Siach wrote:
> /dev/null is the "console" for system startup commands listed in the default
> /etc/inittab. These commands fail when /dev/null isn't there. This breaks
> BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV, as /proc and /sys are not mounted when
> mdev runs, causing the following errors:
> 
> can't open /dev/null: No such file or directory
> can't open /dev/null: No such file or directory
> can't open /dev/null: No such file or directory
> can't open /dev/null: No such file or directory
> can't open /dev/null: No such file or directory
> can't open /dev/null: No such file or directory
> ...
> Starting mdev...
> /etc/init.d/S10mdev: line 19: can't create /proc/sys/kernel/hotplug: nonexistent directory
> mdev: /sys/class: No such file or directory
> 
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
>  system/device_table.txt | 1 +
>  1 file changed, 1 insertion(+)

So, in the end, my proposal would be to drop this patch, and instead
have a patch that fixes the cpio code to not create this
useless /dev/console device when cpio is not enabled. We have not
supported udev/mdev without devtmpfs since a long time, I don't really
see the point of bringing this back, as 2.6.32 is now very old and most
people have the possibility of moving to a 2.6.32+ kernel.

Baruch, do you agree with this proposal?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] system/device_table.txt: add /dev/null entry

[Baruch Siach]

Hi Thomas,

On Thu, Nov 27, 2014 at 08:37:20PM +0100, Thomas Petazzoni wrote:
> On Thu, 27 Nov 2014 08:44:36 +0200, Baruch Siach wrote:
> > /dev/null is the "console" for system startup commands listed in the default
> > /etc/inittab. These commands fail when /dev/null isn't there. This breaks
> > BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV, as /proc and /sys are not mounted when
> > mdev runs, causing the following errors:
> > 
> > can't open /dev/null: No such file or directory
> > can't open /dev/null: No such file or directory
> > can't open /dev/null: No such file or directory
> > can't open /dev/null: No such file or directory
> > can't open /dev/null: No such file or directory
> > can't open /dev/null: No such file or directory
> > ...
> > Starting mdev...
> > /etc/init.d/S10mdev: line 19: can't create /proc/sys/kernel/hotplug: nonexistent directory
> > mdev: /sys/class: No such file or directory
> > 
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> >  system/device_table.txt | 1 +
> >  1 file changed, 1 insertion(+)
> 
> So, in the end, my proposal would be to drop this patch, and instead
> have a patch that fixes the cpio code to not create this
> useless /dev/console device when cpio is not enabled. We have not
> supported udev/mdev without devtmpfs since a long time, I don't really
> see the point of bringing this back, as 2.6.32 is now very old and most
> people have the possibility of moving to a 2.6.32+ kernel.
> 
> Baruch, do you agree with this proposal?

Supporting a non devtmpfs with mdev only requires creating /dev/null and 
/dev/console statically. I think this is a small price to pay for an 
out-of-the-box working build. Anyway, I don't feel strongly about it. I can 
easily work around the problem with a custom device table file, at least as 
long as I haven't rebuilt the kernel.

By the way, the kernel that comes with this board IS 2.6.32, and we have just 
now started development based on the SoC on the board.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH] system/device_table.txt: add /dev/null entry

[Peter Korsgaard]

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

Hi,

>> Baruch, do you agree with this proposal?

 > Supporting a non devtmpfs with mdev only requires creating /dev/null and 
 > /dev/console statically. I think this is a small price to pay for an 
 > out-of-the-box working build. Anyway, I don't feel strongly about it. I can 
 > easily work around the problem with a custom device table file, at least as 
 > long as I haven't rebuilt the kernel.

That might be true today, but the point is that it doesn't get any
testing so chances are something else will break in the future. It looks
like the issue you reported today has been present for several years.


 > By the way, the kernel that comes with this board IS 2.6.32, and we have just 
 > now started development based on the SoC on the board.

Poor you. I'm currently stuck on 2.6.37 for a project, so I know your
pain :/

-- 
Bye, Peter Korsgaard