[PATCH] slugos-image: fix opkg-cl hanging on installing device tables

[PATCH] slugos-image: fix opkg-cl hanging on installing device tables

[Henry von Tresckow]

opkg-cl was hanging during slugos image builds due to opkg-cl waiting for an answer for overwriting the device tables.
adding " -force-defaults" to IPKG_ARGS allows the image to build

Signed-off-by: Henry von Tresckow <hvontres@gmail.com>
---
 recipes/images/slugos-image.inc |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/recipes/images/slugos-image.inc b/recipes/images/slugos-image.inc
index 6a4b7b9..809459c 100644
--- a/recipes/images/slugos-image.inc
+++ b/recipes/images/slugos-image.inc
@@ -23,3 +23,5 @@ IMAGE_LINGUAS = ""
 IMAGE_PREPROCESS_COMMAND += "rm -f ${IMAGE_ROOTFS}/boot/?Image*;"
 
 inherit image
+
+IPKG_ARGS += " -force-default"
\ No newline at end of file
-- 
1.6.3.3

Re: [PATCH] slugos-image: fix opkg-cl hanging on installing device tables

[Khem Raj]

On (08/05/10 18:24), Henry von Tresckow wrote:
> opkg-cl was hanging during slugos image builds due to opkg-cl waiting for an answer for overwriting the device tables.
> adding " -force-defaults" to IPKG_ARGS allows the image to build
> 
> Signed-off-by: Henry von Tresckow <hvontres@gmail.com>
> ---
>  recipes/images/slugos-image.inc |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/recipes/images/slugos-image.inc b/recipes/images/slugos-image.inc
> index 6a4b7b9..809459c 100644
> --- a/recipes/images/slugos-image.inc
> +++ b/recipes/images/slugos-image.inc
> @@ -23,3 +23,5 @@ IMAGE_LINGUAS = ""
>  IMAGE_PREPROCESS_COMMAND += "rm -f ${IMAGE_ROOTFS}/boot/?Image*;"
>  
>  inherit image
> +
> +IPKG_ARGS += " -force-default"

hmm when I look at the sources of opkg in .dev I dont see -force-default option
am I missing something. 

-Khem

Re: [PATCH] slugos-image: fix opkg-cl hanging on installing device tables

[Hans Henry von Tresckow]

On Sat, May 8, 2010 at 7:00 PM, Khem Raj <raj.khem@gmail.com> wrote:

> On (08/05/10 18:24), Henry von Tresckow wrote:
> > opkg-cl was hanging during slugos image builds due to opkg-cl waiting for
> an answer for overwriting the device tables.
> > adding " -force-defaults" to IPKG_ARGS allows the image to build
> >
> > Signed-off-by: Henry von Tresckow <hvontres@gmail.com>
> > ---
> >  recipes/images/slugos-image.inc |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/recipes/images/slugos-image.inc
> b/recipes/images/slugos-image.inc
> > index 6a4b7b9..809459c 100644
> > --- a/recipes/images/slugos-image.inc
> > +++ b/recipes/images/slugos-image.inc
> > @@ -23,3 +23,5 @@ IMAGE_LINGUAS = ""
> >  IMAGE_PREPROCESS_COMMAND += "rm -f ${IMAGE_ROOTFS}/boot/?Image*;"
> >
> >  inherit image
> > +
> > +IPKG_ARGS += " -force-default"
>
> hmm when I look at the sources of opkg in .dev I dont see -force-default
> option
> am I missing something.
>
> -Khem


I think slugos still uses an older version of opkg:

slugos:

 henry@FozzieBear:~/oe/slug/tmp/work/nslu2be-linux-gnueabi/slugos-image-1.0-r1/slugos-image-1.0$
opkg-cl --version
 opkg version 0.1.6

angstrom:
henry@FozzieBear:~/oe/dev/tmp/work/poodle-angstrom-linux-gnueabi/console-image-1.0-r0/console-image-1.0$
opkg-cl --version
opkg version 0.1.8



>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Henry von Tresckow (hvontres)

Re: [PATCH] slugos-image: fix opkg-cl hanging on installing device tables

[Mike Westerhof]

Henry von Tresckow wrote:
> opkg-cl was hanging during slugos image builds due to opkg-cl waiting for an answer for overwriting the device tables.
> adding " -force-defaults" to IPKG_ARGS allows the image to build

This is fixing a symptom, not the real problem.  I've just committed a
SlugOS-specific fix that dodges this problem, so I don't recommend we
apply this.  Specifically, we *do* want to know if we're overwriting a
config file while building the rootfs so that we can use a
PREFERRED_PROVIDER or similar mechanism to select the correct one.

The root cause is the original commit a week or two ago that incorrectly
changed the handling of the device_table file.

The "fix" I committed "backs out" one line of that bad commit in a
SlugOS-specific recipe -- which isn't a fix, but at least it gets SlugOS
building again, is no worse than things were originally, and it affects
no other distros.

-Mike (mwester)

> Signed-off-by: Henry von Tresckow <hvontres@gmail.com>
> ---
>  recipes/images/slugos-image.inc |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/recipes/images/slugos-image.inc b/recipes/images/slugos-image.inc
> index 6a4b7b9..809459c 100644
> --- a/recipes/images/slugos-image.inc
> +++ b/recipes/images/slugos-image.inc
> @@ -23,3 +23,5 @@ IMAGE_LINGUAS = ""
>  IMAGE_PREPROCESS_COMMAND += "rm -f ${IMAGE_ROOTFS}/boot/?Image*;"
>  
>  inherit image
> +
> +IPKG_ARGS += " -force-default"
> \ No newline at end of file

Re: [PATCH] slugos-image: fix opkg-cl hanging on installing device tables

[Hans Henry von Tresckow]

On Sun, May 9, 2010 at 7:12 PM, Mike Westerhof <mike@mwester.net> wrote:

> Henry von Tresckow wrote:
> > opkg-cl was hanging during slugos image builds due to opkg-cl waiting for
> an answer for overwriting the device tables.
> > adding " -force-defaults" to IPKG_ARGS allows the image to build
>
> This is fixing a symptom, not the real problem.  I've just committed a
> SlugOS-specific fix that dodges this problem, so I don't recommend we
> apply this.  Specifically, we *do* want to know if we're overwriting a
> config file while building the rootfs so that we can use a
> PREFERRED_PROVIDER or similar mechanism to select the correct one.
>
> The root cause is the original commit a week or two ago that incorrectly
> changed the handling of the device_table file.
>
> The "fix" I committed "backs out" one line of that bad commit in a
> SlugOS-specific recipe -- which isn't a fix, but at least it gets SlugOS
> building again, is no worse than things were originally, and it affects
> no other distros.
>
> -Mike (mwester)
>
>
Thanks for fixing this.
-- 
Henry von Tresckow (hvontres)