[Buildroot] Slow boots caused by ca520507fc15a8213334a76339a3e6d567e91ea0 (udev, inittab)

[Buildroot] Slow boots caused by ca520507fc15a8213334a76339a3e6d567e91ea0 (udev, inittab)

[Diego Iastrubni]

I am seeing that my boot is now ~60 seconds, and hte boots hangs ~40 secs
while starting udev.

This is caused by ca520507fc15a8213334a76339a3e6d567e91ea0 which claims that
/sys/ and friends are moutned by inittab. I found no such code in the
ininttab installed is my unit,  and the inittab available in the head
(59af9a8..ce1ae87)  in fs/skeleton/etc/inittab does not mount /sys/ at boot
time. Reverting the inittab to the one before this change fixes the boot
time.

What am I missing?

I am using busybox's init, code sourcry ARM toolkit, and bootinsg from NFS
into an OMAP3.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110517/ed29e5de/attachment.html>

[Buildroot] Slow boots caused by ca520507fc15a8213334a76339a3e6d567e91ea0 (udev, inittab)

[Thomas Petazzoni]

On Tue, 17 May 2011 16:19:36 +0300
Diego Iastrubni <diegoiast@gmail.com> wrote:

> I am seeing that my boot is now ~60 seconds, and hte boots hangs ~40 secs
> while starting udev.
> 
> This is caused by ca520507fc15a8213334a76339a3e6d567e91ea0 which claims that
> /sys/ and friends are moutned by inittab. I found no such code in the
> ininttab installed is my unit,  and the inittab available in the head
> (59af9a8..ce1ae87)  in fs/skeleton/etc/inittab does not mount /sys/ at boot
> time. Reverting the inittab to the one before this change fixes the boot
> time.

Well inittab does "mount -a" and /etc/fstab says that sysfs should be
mounted.

Moreover the ca520507fc15a8213334a76339a3e6d567e91ea0 you're pointing
did not change the inittab, so I don't know how reverting could modify
the inittab. Are you referring to the udev startup script ?

Regards,

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

[Buildroot] Slow boots caused by ca520507fc15a8213334a76339a3e6d567e91ea0 (udev, inittab)

[Diego Iastrubni]

On Tue, May 17, 2011 at 4:28 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Well inittab does "mount -a" and /etc/fstab says that sysfs should be
> mounted.
Noted. My inittab does contain those line... and the ininttab does
contain "mount -a"...


> Moreover the ca520507fc15a8213334a76339a3e6d567e91ea0 you're pointing
> did not change the inittab, so I don't know how reverting could modify
> the inittab. Are you referring to the udev startup script ?
I reverted S10udev of course.
How can I debug this?

[Buildroot] Slow boots caused by ca520507fc15a8213334a76339a3e6d567e91ea0 (udev, inittab)

[Diego Iastrubni]

On Tue, May 17, 2011 at 4:45 PM, Diego Iastrubni <diegoiast@gmail.com>
wrote:
>> Moreover the ca520507fc15a8213334a76339a3e6d567e91ea0 you're pointing
>> did not change the inittab, so I don't know how reverting could modify
>> the inittab. Are you referring to the udev startup script ?
> I reverted S10udev of course.
> How can I debug this?

I debugged it by writing "set -x" and see what is executed over RS323 and
also looking at the output of "mount".

Eventually, it seems that the delay was caused by the RAMFS not booing
mounted on /dev/ which means that udev was writing real files (about 200)
over my NFS share to my real limux machine. That *is* kinda slow....

Adding the following lines fixed it (note that this mount point is not
available is fstab!):

      grep -q "^udev $udev_root" /proc/mounts || mount -t ramfs udev
$udev_root || exit 1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110519/e99644c3/attachment.html>

[Buildroot] Slow boots caused by ca520507fc15a8213334a76339a3e6d567e91ea0 (udev, inittab)

[Peter Korsgaard]

>>>>> "Diego" == Diego Iastrubni <diegoiast@gmail.com> writes:

Hi,

 Diego> Eventually, it seems that the delay was caused by the RAMFS not booing mounted
 Diego> on /dev/ which means that udev was writing real files (about 200) over my NFS
 Diego> share to my real limux machine. That *is* kinda slow....

Do you have devtmpfs + mount enabled in your kernel? (DEVTMPFS +
DEVTMPFS_MOUNT). If you do so, /dev is already a tmpfs.

-- 
Bye, Peter Korsgaard

[Buildroot] Slow boots caused by ca520507fc15a8213334a76339a3e6d567e91ea0 (udev, inittab)

[Diego Iastrubni]

On Thu, May 19, 2011 at 2:47 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
> Do you have devtmpfs + mount enabled in your kernel? (DEVTMPFS +
> DEVTMPFS_MOUNT). If you do so, /dev is already a tmpfs.

It seems not. The sad thing is that I cannot even recompile the
kernel, since the n00bs who engineered this crap did not think about
updating the kernel from remote... and we have a few of them in the
wild.
# zcat /proc/config.gz | grep DEVTM
# CONFIG_DEVTMPFS is not set
# uname -a
Linux buildroot 2.6.32 #1 Sun Jul 18 10:54:29 UTC 2010 armv7l GNU/Linux

[Buildroot] Slow boots caused by ca520507fc15a8213334a76339a3e6d567e91ea0 (udev, inittab)

[Peter Korsgaard]

>>>>> "Diego" == Diego Iastrubni <diegoiast@gmail.com> writes:

Hi,

 >> Do you have devtmpfs + mount enabled in your kernel? (DEVTMPFS +
 >> DEVTMPFS_MOUNT). If you do so, /dev is already a tmpfs.

 Diego> It seems not. The sad thing is that I cannot even recompile the
 Diego> kernel, since the n00bs who engineered this crap did not think about
 Diego> updating the kernel from remote... and we have a few of them in the
 Diego> wild.

Argh - Then your best bet is probably to add a local hack to mount a
tmpfs on /dev before starting udev.

-- 
Bye, Peter Korsgaard

[Buildroot] Slow boots caused by ca520507fc15a8213334a76339a3e6d567e91ea0 (udev, inittab)

[Diego Iastrubni]

On Thu, May 19, 2011 at 2:59 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
> ?>> Do you have devtmpfs + mount enabled in your kernel? (DEVTMPFS +
> ?>> DEVTMPFS_MOUNT). If you do so, /dev is already a tmpfs.
>
> ?Diego> It seems not. The sad thing is that I cannot even recompile the
>
> Argh - Then your best bet is probably to add a local hack to mount a
> tmpfs on /dev before starting udev.

And I propose adding a back that check in the udev script, as it wan
before. This should not hurt existing users.

[Buildroot] Slow boots caused by ca520507fc15a8213334a76339a3e6d567e91ea0 (udev, inittab)

[Diego Iastrubni]

Arggg... now SSH does not work, since the server cannot allocate a PTY....
Again - the fix is to re-add this line to the S10udev script:

mount -t devpts /dev/pts /dev/pts || (echo "FAIL" && exit 1)

On Thu, May 19, 2011 at 3:04 PM, Diego Iastrubni <diegoiast@gmail.com> wrote:
>
> On Thu, May 19, 2011 at 2:59 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
> > ?>> Do you have devtmpfs + mount enabled in your kernel? (DEVTMPFS +
> > ?>> DEVTMPFS_MOUNT). If you do so, /dev is already a tmpfs.
> >
> > ?Diego> It seems not. The sad thing is that I cannot even recompile the
> >
> > Argh - Then your best bet is probably to add a local hack to mount a
> > tmpfs on /dev before starting udev.
>
> And I propose adding a back that check in the udev script, as it wan
> before. This should not hurt existing users.

[Buildroot] Slow boots caused by ca520507fc15a8213334a76339a3e6d567e91ea0 (udev, inittab)

[Peter Korsgaard]

>>>>> "Diego" == Diego Iastrubni <diegoiast@gmail.com> writes:

 Diego> Arggg... now SSH does not work, since the server cannot allocate
 Diego> a PTY....  Again - the fix is to re-add this line to the S10udev
 Diego> script:

 Diego> mount -t devpts /dev/pts /dev/pts || (echo "FAIL" && exit 1)

This happens automatically by the mount -a in your inittab as
/dev/pts is listed in the default /etc/fstab.

Notice you also need the mkdir -p /dev/pts to ensure the mount point is
available. Again, this is all handled in the default /etc/inittab.

Naturally none of this works because of your local hack to mount a tmpfs
in S10udev, so you'll need extra hackery to workaround your workaround.

-- 
Bye, Peter Korsgaard

[Buildroot] Slow boots caused by ca520507fc15a8213334a76339a3e6d567e91ea0 (udev, inittab)

[Diego Iastrubni]

On Thu, May 26, 2011 at 5:02 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Diego" == Diego Iastrubni <diegoiast@gmail.com> writes:
>
> ?Diego> Arggg... now SSH does not work, since the server cannot allocate
> ?Diego> a PTY.... ?Again - the fix is to re-add this line to the S10udev
> ?Diego> script:
>
> ?Diego> mount -t devpts /dev/pts /dev/pts || (echo "FAIL" && exit 1)
>
> This happens automatically by the mount -a in your inittab as
> /dev/pts is listed in the default /etc/fstab.
>
> Notice you also need the mkdir -p /dev/pts to ensure the mount point is
> available. Again, this is all handled in the default /etc/inittab.
>
> Naturally none of this works because of your local hack to mount a tmpfs
> in S10udev, so you'll need extra hackery to workaround your workaround.

Of course. Just documenting this is google for the next poor fool who
has this problem.