Patchwork Remove ttyS* from /etc/inittab that are not present

This will prevent error message that pop up when the serial
port is not present
---
This seems quite hacky to me, but we have an issue where if we remove
a serial port from the device tree the serial port won't work.

It seems link it's still in /dev/ttySN but it's not configured properly.
I looked for udev rules and items in /proc and /sys to try to use but
I did not see anything...

Is there a better approach than this?

 .../sysvinit/sysvinit-inittab_2.88dsf.bb           |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

NACK!


This enforces online use so won't work for read-only-fs.

Please use SERIAL_CONSOLE value to write iniitab but supporting offline use

On Thu, Nov 17, 2011 at 20:47, Matthew McClintock <msm@freescale.com> wrote:
> This will prevent error message that pop up when the serial
> port is not present
> ---
> This seems quite hacky to me, but we have an issue where if we remove
> a serial port from the device tree the serial port won't work.
>
> It seems link it's still in /dev/ttySN but it's not configured properly.
> I looked for udev rules and items in /proc and /sys to try to use but
> I did not see anything...
>
> Is there a better approach than this?
>
>  .../sysvinit/sysvinit-inittab_2.88dsf.bb           |   19 ++++++++++++++++++-
>  1 files changed, 18 insertions(+), 1 deletions(-)
>
> diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
> index 3a716d7..3031442 100644
> --- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
> +++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
> @@ -2,7 +2,7 @@ DESCRIPTION = "Inittab for sysvinit"
>  LICENSE = "GPLv2"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
>
> -PR = "r6"
> +PR = "r7"
>
>  SRC_URI = "file://COPYING \
>            file://inittab"
> @@ -56,6 +56,23 @@ EOF
>     fi
>  }
>
> +pkg_postinst_${PN} () {
> +# run this on the target
> +if [ "x$D" == "x" ]; then
> +       tmp="${SERIAL_CONSOLES}"
> +       for i in $tmp
> +       do
> +               j=`echo ${i} | sed s/^.*\;//g`
> +               if [ -z "`dmesg | grep ${j}`" ]; then
> +                       sed -i /^.*${j}$/d /etc/inittab
> +               fi
> +       done
> +       kill -HUP 1
> +fi
> +
> +exit 1
> +}
> +
>  # USE_VT and SERIAL_CONSOLE are generally defined by the MACHINE .conf.
>  # Set PACKAGE_ARCH appropriately.
>  PACKAGE_ARCH = "${MACHINE_ARCH}"
> --
> 1.7.6.1
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

On Thu, Nov 17, 2011 at 6:08 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> This enforces online use so won't work for read-only-fs.

Online use is sort of the point here - I think it should be configurable though.

> Please use SERIAL_CONSOLE value to write iniitab but supporting offline use

Already done but sometimes we want to run the same root file system
with boards with 1 or 2 serial ports. So we need to dynamically add or
remove entries.

I'm mostly soliciting ideas for how we detect if a serial port is
actually present besides 'dmesg'

-M

On Thu, Nov 17, 2011 at 22:23, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Thu, Nov 17, 2011 at 6:08 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> This enforces online use so won't work for read-only-fs.
>
> Online use is sort of the point here - I think it should be configurable though.
>
>> Please use SERIAL_CONSOLE value to write iniitab but supporting offline use
>
> Already done but sometimes we want to run the same root file system
> with boards with 1 or 2 serial ports. So we need to dynamically add or
> remove entries.
>
> I'm mostly soliciting ideas for how we detect if a serial port is
> actually present besides 'dmesg'

I see your point but add more "must be online" requirements is wrong
IMO. This could be done with a specific package that could mangle the
image at first boot if really need but doing it by default on oe-core
seems the wrong way.

On Thu, Nov 17, 2011 at 6:29 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> I see your point but add more "must be online" requirements is wrong
> IMO.

It must be online though in this case?

> This could be done with a specific package that could mangle the
> image at first boot if really need but doing it by default on oe-core
> seems the wrong way.

Isn't that exactly what this is doing?

Easy enough to add this to a separate recipe or bbapends elsewhere if
there is disagreement.

-M

On Fri, 2011-11-18 at 00:23 +0000, McClintock Matthew-B29882 wrote:
> I'm mostly soliciting ideas for how we detect if a serial port is
> actually present besides 'dmesg'

I guess the obvious one is to try opening it.  Something like:

if [ true < /dev/ttyS0 ]; then
  echo present
else
  echo not present
fi

maybe.  Or teach init not to try to spawn getty on ttys that don't exist
and leave the inittab alone.

p.

On Fri, Nov 18, 2011 at 2:07 AM, Phil Blundell <philb@gnu.org> wrote:
> if [ true < /dev/ttyS0 ]; then

This test returns 0 if the serial node is in my device tree or not
(e.g. there or not).

-M

On Fri, 2011-11-18 at 17:54 +0000, McClintock Matthew-B29882 wrote:
> On Fri, Nov 18, 2011 at 2:07 AM, Phil Blundell <philb@gnu.org> wrote:
> > if [ true < /dev/ttyS0 ]; then
> 
> This test returns 0 if the serial node is in my device tree or not
> (e.g. there or not).

That sounds like a shell bug to me.  What shell are you using?

p.

On Fri, Nov 18, 2011 at 00:32, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Thu, Nov 17, 2011 at 6:29 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> I see your point but add more "must be online" requirements is wrong
>> IMO.
>
> It must be online though in this case?

The code you add needs to be running on target and doesn't work at
rootfs built time. This is bad and adds more complications to
read-only-fs support.

>> This could be done with a specific package that could mangle the
>> image at first boot if really need but doing it by default on oe-core
>> seems the wrong way.
>
> Isn't that exactly what this is doing?
>
> Easy enough to add this to a separate recipe or bbapends elsewhere if
> there is disagreement.

The need to diverge from machine default is the exception and this
could be handled on the image being built, as post rootfs hook or an
specific package with postinst to be run at target boot to setup it,
and not by default.

I see possible use cases for it, I just against it being the default behaviour.

On Sat, Nov 19, 2011 at 8:29 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
>> It must be online though in this case?
>
> The code you add needs to be running on target and doesn't work at
> rootfs built time. This is bad and adds more complications to
> read-only-fs support.

This works *perfectly* with a read only fs. Each time it boots removes
the non-working serial ports. One could argue that it does NOT work
completely as expected with a writable file system.

>>> This could be done with a specific package that could mangle the
>>> image at first boot if really need but doing it by default on oe-core
>>> seems the wrong way.
>>
>> Isn't that exactly what this is doing?
>>
>> Easy enough to add this to a separate recipe or bbapends elsewhere if
>> there is disagreement.
>
> The need to diverge from machine default is the exception and this
> could be handled on the image being built, as post rootfs hook or an
> specific package with postinst to be run at target boot to setup it,
> and not by default.

This will not work as a post rootfs hook as I've explained before. Let
me give you a more concrete example: We have a root file stored in
flash. We use it to boot from on a system with 4 serial ports. We use
the same image again to boot several kvm instances each of which only
have 1 serial port. The kvm instances will have spurious init messages
about respawning getty.

-M

On Sat, 2011-11-19 at 18:59 +0000, McClintock Matthew-B29882 wrote:
> On Sat, Nov 19, 2011 at 8:29 AM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
> >> It must be online though in this case?
> >
> > The code you add needs to be running on target and doesn't work at
> > rootfs built time. This is bad and adds more complications to
> > read-only-fs support.
> 
> This works *perfectly* with a read only fs. Each time it boots removes
> the non-working serial ports. One could argue that it does NOT work
> completely as expected with a writable file system.

Um, the patch you sent seems to modify /etc/inittab on the rootfs.  How
can that work if the filesystem is read only?

p.

On Sat, Nov 19, 2011 at 1:12 PM, Phil Blundell <philb@gnu.org> wrote:
>> This works *perfectly* with a read only fs. Each time it boots removes
>> the non-working serial ports. One could argue that it does NOT work
>> completely as expected with a writable file system.
>
> Um, the patch you sent seems to modify /etc/inittab on the rootfs.  How
> can that work if the filesystem is read only?

Ok - I was thinking the root file system being reloaded each time and
the changes not being saved... not quite read only.

I guess it would not work read only but like I said it would be configurable.

-M

On Sat, Nov 19, 2011 at 16:59, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Sat, Nov 19, 2011 at 8:29 AM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>>> It must be online though in this case?
>>
>> The code you add needs to be running on target and doesn't work at
>> rootfs built time. This is bad and adds more complications to
>> read-only-fs support.
>
> This works *perfectly* with a read only fs. Each time it boots removes
> the non-working serial ports. One could argue that it does NOT work
> completely as expected with a writable file system.

It does not. Only if you have tmpfs on it too.

>>>> This could be done with a specific package that could mangle the
>>>> image at first boot if really need but doing it by default on oe-core
>>>> seems the wrong way.
>>>
>>> Isn't that exactly what this is doing?
>>>
>>> Easy enough to add this to a separate recipe or bbapends elsewhere if
>>> there is disagreement.
>>
>> The need to diverge from machine default is the exception and this
>> could be handled on the image being built, as post rootfs hook or an
>> specific package with postinst to be run at target boot to setup it,
>> and not by default.
>
> This will not work as a post rootfs hook as I've explained before. Let
> me give you a more concrete example: We have a root file stored in
> flash. We use it to boot from on a system with 4 serial ports. We use
> the same image again to boot several kvm instances each of which only
> have 1 serial port. The kvm instances will have spurious init messages
> about respawning getty.

This usecase ought to be fulfilled with a specific package our boot
script that does this setup on runtime. As I said I see the use-case
but disagree about it being done on oe-core.

On Sat, Nov 19, 2011 at 1:36 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
>> This will not work as a post rootfs hook as I've explained before. Let
>> me give you a more concrete example: We have a root file stored in
>> flash. We use it to boot from on a system with 4 serial ports. We use
>> the same image again to boot several kvm instances each of which only
>> have 1 serial port. The kvm instances will have spurious init messages
>> about respawning getty.
>
> This usecase ought to be fulfilled with a specific package our boot
> script that does this setup on runtime. As I said I see the use-case
> but disagree about it being done on oe-core.

This is fine by me... thanks for the review.

-M

Op 19 nov. 2011, om 19:59 heeft McClintock Matthew-B29882 het volgende geschreven:

> On Sat, Nov 19, 2011 at 8:29 AM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>>> It must be online though in this case?
>> 
>> The code you add needs to be running on target and doesn't work at
>> rootfs built time. This is bad and adds more complications to
>> read-only-fs support.
> 
> This works *perfectly* with a read only fs. Each time it boots removes
> the non-working serial ports. One could argue that it does NOT work
> completely as expected with a writable file system.
> 
>>>> This could be done with a specific package that could mangle the
>>>> image at first boot if really need but doing it by default on oe-core
>>>> seems the wrong way.
>>> 
>>> Isn't that exactly what this is doing?
>>> 
>>> Easy enough to add this to a separate recipe or bbapends elsewhere if
>>> there is disagreement.
>> 
>> The need to diverge from machine default is the exception and this
>> could be handled on the image being built, as post rootfs hook or an
>> specific package with postinst to be run at target boot to setup it,
>> and not by default.
> 
> This will not work as a post rootfs hook as I've explained before. Let
> me give you a more concrete example: We have a root file stored in
> flash. We use it to boot from on a system with 4 serial ports. We use
> the same image again to boot several kvm instances each of which only
> have 1 serial port. The kvm instances will have spurious init messages
> about respawning getty.

Or you could just ditch sysvinit and switch to systemd. Systemd will only spawn a getty when udev says the device is there. And even better, every getty config is a file you can delete to disable it if for some reason the kernel reports the serial port to be there and you don't want a getty.

regards,

Koen