[Buildroot] debugging inittab

[Buildroot] debugging inittab

[Jenkins, Lee]

Hello. I am debugging a boot problem for a few hours. I'm clearly in over my head and I could use some insight.

For debugging purposes, I am booting from a kernel and rootfs on an nfs share of my dev machine. The console is ttyS0.

The kernel boots and rootfs is mounted and the scripts in /etc/init.d are executed. The kernel messages and startup script messages appear on the tty.

The problem is that right after the init.d scripts this message appears: "can't open /dev/ttyS0: Permission denied". This message is repeated in an infinite loop.

If I boot with the kernel argument "init=/bin/sh" then the init is bypassed and the system boots OK. So the problem is definitely in the init.

I'm new to debugging init-time and I cannot even figure out who is printing this message.

The error message sounds like a permissions problem, so I added a hack script /etc/init.d/S99chmod, which does chmod 777 /dev/ttyS0 and then ls to show the result. The chmod works but the error still occurs.

Then I thought maybe getty was having trouble opening ttyS0, so I wrote a "wrapper" script called getty.shell to print a debug message and then modified the entry in inittab like this:

# Put a getty on the serial port
ttyS0::respawn:/sbin/getty.shell -L ttyS0 115200 vt100 # GENERIC_SERIAL

It doesn't look like the wrapper script is ever called because the debug message never appears.

So, any ideas? What happens between /etc/init.d and /sbin/getty?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130822/428adbc4/attachment.html>

[Buildroot] debugging inittab

[Arnout Vandecappelle]

On 22/08/13 22:11, Jenkins, Lee (ISS Houston) wrote:
> Hello. I am debugging a boot problem for a few hours. I?m clearly in over
> my head and I could use some insight.
>
> For debugging purposes, I am booting from a kernel and rootfs on an nfs
> share of my dev machine. The console is ttyS0.

  The nfs-share is an extracted output/images/rootfs.tar, right? You're 
not using the target directory?

  Is busybox setuid root? Is the nfs not exported with rootsquash and such?


> The kernel boots and rootfs is mounted and the scripts in /etc/init.d are
> executed. The kernel messages and startup script messages appear on the tty.
>
> The problem is that right after the init.d scripts this message appears:
> ?can?t open /dev/ttyS0: Permission denied?. This message is repeated in
> an infinite loop.
>
> If I boot with the kernel argument ?init=/bin/sh? then the init is
> bypassed and the system boots OK. So the problem is definitely in the init.
>
> I?m new to debugging init-time and I cannot even figure out who is
> printing this message.
>
> The error message sounds like a permissions problem, so I added a hack
> script /etc/init.d/S99chmod, which does chmod 777 /dev/ttyS0 and then ls
> to show the result. The chmod works but the error still occurs.
>
> Then I thought maybe getty was having trouble opening ttyS0, so I wrote a
> ?wrapper? script called getty.shell to print a debug message and then
> modified the entry in inittab like this:
>
> # Put a getty on the serial port
>
> ttyS0::respawn:/sbin/getty.shell -L ttyS0 115200 vt100 # GENERIC_SERIAL
>
> It doesn?t look like the wrapper script is ever called because the debug
> message never appears.
>
> So, any ideas? What happens between /etc/init.d and /sbin/getty?

  The ttyS0 at the beginning of the line instructs (busybox) init to send 
the stderr/stdout of the process that is started to /dev/ttyS0. But the 
process is never started, because init cannot open /dev/ttyS0.

  You can try removing that, just start the line with ::


  Regards,
  Arnout

>
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] debugging inittab

[Jenkins, Lee]

-----Original Message-----
From: Arnout Vandecappelle [mailto:arnout at mind.be] 
Sent: Thursday, August 22, 2013 6:36 PM
To: Jenkins, Lee (ISS Houston)
Cc: buildroot at busybox.net
Subject: Re: [Buildroot] debugging inittab
Importance: Low

> On 22/08/13 22:11, Jenkins, Lee (ISS Houston) wrote:
> > Hello. I am debugging a boot problem for a few hours. I'm clearly in 
> > over my head and I could use some insight.
> >
> > For debugging purposes, I am booting from a kernel and rootfs on an 
> > nfs share of my dev machine. The console is ttyS0.
>
>   The nfs-share is an extracted output/images/rootfs.tar, right? You're not using the target directory?
>

That was the problem. Thanks!

[Buildroot] debugging inittab

[Arnout Vandecappelle]

On 08/28/13 00:38, Jenkins, Lee (ISS Houston) wrote:
> -----Original Message-----
> From: Arnout Vandecappelle [mailto:arnout at mind.be]
> Sent: Thursday, August 22, 2013 6:36 PM
> To: Jenkins, Lee (ISS Houston)
> Cc: buildroot at busybox.net
> Subject: Re: [Buildroot] debugging inittab
> Importance: Low
>
>> On 22/08/13 22:11, Jenkins, Lee (ISS Houston) wrote:
>>> Hello. I am debugging a boot problem for a few hours. I'm clearly in
>>> over my head and I could use some insight.
>>>
>>> For debugging purposes, I am booting from a kernel and rootfs on an
>>> nfs share of my dev machine. The console is ttyS0.
>>
>>    The nfs-share is an extracted output/images/rootfs.tar, right? You're not using the target directory?
>>
>
> That was the problem. Thanks!

  Right. Maybe we should just rename target/ to 
THIS_IS_NOT_YOUR_ROOT_FILESYSTEM instead of just creating the file. The 
latter is obviously not enough.

  What was the reason we didn't do that in the first place?

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] debugging inittab

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

 >> That was the problem. Thanks!

 Arnout>  Right. Maybe we should just rename target/ to
 Arnout> THIS_IS_NOT_YOUR_ROOT_FILESYSTEM instead of just creating the
 Arnout> file. The latter is obviously not enough.

 Arnout>  What was the reason we didn't do that in the first place?

People didn't seem to like it when I suggested it.

It would mean a change of behaviour, so perhaps we need to add a target
symlink like we did for staging?

-- 
Bye, Peter Korsgaard

[Buildroot] debugging inittab

[Arnout Vandecappelle]

On 08/29/13 09:29, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
>
>   >> That was the problem. Thanks!
>
>   Arnout>  Right. Maybe we should just rename target/ to
>   Arnout> THIS_IS_NOT_YOUR_ROOT_FILESYSTEM instead of just creating the
>   Arnout> file. The latter is obviously not enough.
>
>   Arnout>  What was the reason we didn't do that in the first place?
>
> People didn't seem to like it when I suggested it.
>
> It would mean a change of behaviour, so perhaps we need to add a target
> symlink like we did for staging?

  That pretty much defeats the purpose, doesn't it?

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] debugging inittab

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Thu, 29 Aug 2013 07:17:57 +0200, Arnout Vandecappelle wrote:

> > That was the problem. Thanks!
> 
>   Right. Maybe we should just rename target/ to 
> THIS_IS_NOT_YOUR_ROOT_FILESYSTEM instead of just creating the file. The 
> latter is obviously not enough.
> 
>   What was the reason we didn't do that in the first place?

I personally find it a bit ugly. Moreover, having a file allows to add
contents to explain *why* it is not the root filesystem, while a
directory cannot contain an explanation :)

Since we've added the THIS_IS_NOT_YOUR_ROOT_FILESYSTEM file, this is
the *first* time we have a new report of people using output/target
directly for NFS mounting. At this point, with a file with such a name,
and the contents of the file explaining how to do NFS mounting, I think
there's not much else we can do except pointing users at this file
which documents why what they are doing cannot work.

Best regards,

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

[Buildroot] debugging inittab

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

 Arnout> On 08/29/13 09:29, Peter Korsgaard wrote:
 >>>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
 >> 
 >> >> That was the problem. Thanks!
 >> 
 Arnout> Right. Maybe we should just rename target/ to
 Arnout> THIS_IS_NOT_YOUR_ROOT_FILESYSTEM instead of just creating the
 Arnout> file. The latter is obviously not enough.
 >> 
 Arnout> What was the reason we didn't do that in the first place?
 >> 
 >> People didn't seem to like it when I suggested it.
 >> 
 >> It would mean a change of behaviour, so perhaps we need to add a target
 >> symlink like we did for staging?

 Arnout>  That pretty much defeats the purpose, doesn't it?

Well, yes - More or less. How do we educate people who are now doing
minor tweaks to output/target and rerunning make to test rootfs changes
(E.G. before they put them under configuration with the overlay
support) to use the new location?

-- 
Bye, Peter Korsgaard

[Buildroot] debugging inittab

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> What was the reason we didn't do that in the first place?

 Thomas> I personally find it a bit ugly. Moreover, having a file allows
 Thomas> to add contents to explain *why* it is not the root filesystem,
 Thomas> while a directory cannot contain an explanation :)

 Thomas> Since we've added the THIS_IS_NOT_YOUR_ROOT_FILESYSTEM file,
 Thomas> this is the *first* time we have a new report of people using
 Thomas> output/target directly for NFS mounting. At this point, with a
 Thomas> file with such a name, and the contents of the file explaining
 Thomas> how to do NFS mounting, I think there's not much else we can do
 Thomas> except pointing users at this file which documents why what
 Thomas> they are doing cannot work.

True. Let's keep it like it is.

-- 
Bye, Peter Korsgaard