[Buildroot] [PATCH 0/1] Bug in the boot process using mdev

[Buildroot] [PATCH 0/1] Bug in the boot process using mdev

[Luca Ceresoli]

Hi,

I ran into trouble when trying to activate mdev in buildroot.
The symptoms were amazing, but I won't delight you with them.
I'll report my analysis of the cause and a solution instead.

The init process I use is busybox's init, with the inittab that comes with
buildroot. This starts with:

  # Startup the system
  null::sysinit:/bin/mount -t proc proc /proc
  null::sysinit:/bin/mount -o remount,rw /
  null::sysinit:/bin/mkdir -p /dev/pts
  null::sysinit:/bin/mount -a
  null::sysinit:/bin/hostname -F /etc/hostname
  # now run any rc scripts
  ::sysinit:/etc/init.d/rcS

Busybox init takes the first field, adds "/dev/" in front if it and uses the
result as the input and output device the the process to be launched.
This is normally used for ttys, but in this case the processes will read from
and write to /dev/null.

Alas, /dev/null does not exist when the first few "sysinit" lines are executed,
since it will be created by mdev, which in turn will be launched only by rcS,
in the last of the cited inittab lines.

The result is that some of these processes may spit out weird error messages on
the console, and some will fail.
I didn't go further down on this, but on some tests I got a system without mdev
working and with a /dev/null created as a regular file -- not as a char device.

The story is long, but the solution is actually simple, as you can see in the
patch: just create the /dev/null character device in the target root filsystem,
so it is there also before mdev starts.

I sould not test udev, but it should have the same problem, and the same
solution should work.

Luca

Luca Ceresoli (1):
  Fix boot with mdev

 target/generic/Config.in                    |    2 +-
 target/generic/device_table_dynamic_dev.txt |   10 ++++++++++
 2 files changed, 11 insertions(+), 1 deletions(-)
 create mode 100644 target/generic/device_table_dynamic_dev.txt

-- 
1.7.4.1

[Buildroot] [PATCH 1/1] Fix boot with mdev

[Luca Ceresoli]

Since 726b15f64a10b, buildroot supports automatic creation of /dev entries
via mdev or udev. This can result in an incorrect boot sequence with
the default inittab, which uses /dev/null before mdev is started.

This is fixed adding a new device_table that creates the minimal /dev
entries that need to exist before starting mdev, and use it by default
when mdev or udev is used.

This list only contains /dev/null.

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
 target/generic/Config.in                    |    2 +-
 target/generic/device_table_dynamic_dev.txt |   10 ++++++++++
 2 files changed, 11 insertions(+), 1 deletions(-)
 create mode 100644 target/generic/device_table_dynamic_dev.txt

diff --git a/target/generic/Config.in b/target/generic/Config.in
index 4969fcd..cab6938 100644
--- a/target/generic/Config.in
+++ b/target/generic/Config.in
@@ -36,7 +36,7 @@ config BR2_ROOTFS_DEVICE_TABLE
 	string "Path to the device tables"
 	default "target/generic/device_table.txt target/generic/device_table_dev.txt" \
 		if BR2_ROOTFS_DEVICE_CREATION_STATIC
-	default "target/generic/device_table.txt" \
+	default "target/generic/device_table.txt target/generic/device_table_dynamic_dev.txt" \
 		if (BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV || \
 		    BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV || \
 		    BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS)
diff --git a/target/generic/device_table_dynamic_dev.txt b/target/generic/device_table_dynamic_dev.txt
new file mode 100644
index 0000000..ea25a94
--- /dev/null
+++ b/target/generic/device_table_dynamic_dev.txt
@@ -0,0 +1,10 @@
+# See package/makedevs/README for details
+#
+# This device table is used only when mdev or udev are in use, to create
+# device files that need to be present before dynamic creation of devices
+# is started.
+#
+# <name>	<type>	<mode>	<uid>	<gid>	<major>	<minor>	<start>	<inc>	<count>
+
+# Normal system devices
+/dev/null	c	666	0	0	1	3	0	0	-
-- 
1.7.4.1

[Buildroot] [PATCH 0/1] Bug in the boot process using mdev

[Thomas Petazzoni]

Hello Luca,

Le Sun,  3 Jul 2011 12:47:57 +0200,
Luca Ceresoli <luca@lucaceresoli.net> a ?crit :

> The init process I use is busybox's init, with the inittab that comes
> with buildroot. This starts with:
> 
>   # Startup the system
>   null::sysinit:/bin/mount -t proc proc /proc
>   null::sysinit:/bin/mount -o remount,rw /
>   null::sysinit:/bin/mkdir -p /dev/pts
>   null::sysinit:/bin/mount -a
>   null::sysinit:/bin/hostname -F /etc/hostname
>   # now run any rc scripts
>   ::sysinit:/etc/init.d/rcS
> 
> Busybox init takes the first field, adds "/dev/" in front if it and
> uses the result as the input and output device the the process to be
> launched. This is normally used for ttys, but in this case the
> processes will read from and write to /dev/null.
> 
> Alas, /dev/null does not exist when the first few "sysinit" lines are
> executed, since it will be created by mdev, which in turn will be
> launched only by rcS, in the last of the cited inittab lines.

I initially implemented mdev support as you proposed, with a separate
static device table for the few device nodes that are mandatory to get
the system up to a point where mdev can be started.

However, after discussions on the list, we decided that both our mdev
and udev configurations should rely on devtmpfs. So when the mdev or
udev mechanisms are selected in Buildroot configuration, we assume that
devtmpfs will be mounted in /dev at boot time.

This is automatically ensured when Buildroot is responsible for
building the kernel. See linux/linux.mk :

ifneq ($(BR2_ROOTFS_DEVICE_CREATION_STATIC),y)
        $(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS,$(@D)/.config)
        $(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS_MOUNT,$(@D)/.config)
endif

However, if you build your kernel separately, then indeed, it's your
responsibility to make sure that DEVTMPFS and DEVTMPFS_MOUNT are
enabled.

This is probably a requirement that should be better documented, at
least in the static/devtmpfs/mdev/udev configuration option help.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 0/1] Bug in the boot process using mdev

[Luca Ceresoli]

Hi Thomas,

Thank you very much for your reply.

Thomas Petazzoni wrote:
...
> I initially implemented mdev support as you proposed, with a separate
> static device table for the few device nodes that are mandatory to get
> the system up to a point where mdev can be started.
>
> However, after discussions on the list, we decided that both our mdev
> and udev configurations should rely on devtmpfs. So when the mdev or
> udev mechanisms are selected in Buildroot configuration, we assume that
> devtmpfs will be mounted in /dev at boot time.
>
> This is automatically ensured when Buildroot is responsible for
> building the kernel. See linux/linux.mk :
>
> ifneq ($(BR2_ROOTFS_DEVICE_CREATION_STATIC),y)
>          $(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS,$(@D)/.config)
>          $(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS_MOUNT,$(@D)/.config)
> endif
>
> However, if you build your kernel separately, then indeed, it's your
> responsibility to make sure that DEVTMPFS and DEVTMPFS_MOUNT are
> enabled.

Shame on me!
My kernel _is_ built by buildroot, and the two DEVTMPFS options _are_
activated. The problem is that I was unaware of that, and went on using
the previously compiled kernel uImage I had lying in /dev/tftp.

>
> This is probably a requirement that should be better documented, at
> least in the static/devtmpfs/mdev/udev configuration option help.
>

Really, as I just proved in such a clumsy way.
But I admit I'd rather wait for it to be done by anybody seriously
knowing the issue (which is probably you). :)

Luca

--------------------------------------------------------------------------
Luca Ceresoli
Comelit R&D - Progettazione Software

Phone
Fax
Mail
Web
YouTube 

luca.ceresoli at comelit.it
http://www.comelitgroup.com/
http://www.youtube.com/comelitgroup
--------------------------------------------------------------------------
Prima di stampare pensa all'ambiente / Think about environment before printing
AVVISO DI CONFIDENZIALIT?
Questo messaggio ed i suoi eventuali allegati pu? contenere informazioni confidenziali, di propriet?, legalmente protette.? destinato all'utilizzo esclusivo del destinatario sopra indicato; privatezza e confidenzialit? non sono modificati da eventuali errori di trasmissione. Se il messaggio non ? a lei destinato, non deve utilizzarlo, diffonderlo, copiarlo con qualunque mezzo, o intraprendere azioni basandosi su di esso. Se ha ricevuto questo messaggio per errore, la preghiamo di volerlo distruggere (unitamente ad eventuali copie dello stesso) e di volerci cortesemente informare del fatto scrivendo al mittente.
CONFIDENTIALITY NOTICE
This message and its attachments (if any) may contain confidential, proprietary or legally privileged information and it is intended only for the use of the addressee named above. No confidentiality or privilege is waived or lost by any erroneous transmission. If you are not the intended recipient of this message you are hereby notified that you must not use, disseminate, copy it in any form or take any action in reliance on it. If you have received this message in error, please, delete it (and any copies of it) and kindly inform the sender.