[Buildroot] Open bug overview: help wanted!

Yann E. MORIN yann.morin.1998 at free.fr
Sun Jul 13 14:56:23 UTC 2014


Mike, All,

On 2014-07-13 08:29 -0500, Mike Zick spake thusly:
> On Sun, 13 Jul 2014 11:05:35 +0200
> "Yann E. MORIN" <yann.morin.1998 at free.fr> wrote:
> > On 2014-07-12 20:54 -0500, Mike Zick spake thusly:
> > > Some members here in the past have expressed interest in supporting
> > > after-market firmware creation for consumer devices.
> > 
> > And I am completely OK with that. What I'm arguing about is whether we
> > want to support running a Buildroot system out-side of / , ie. when
> > the root of the generated filesystem is not the root at runtime.
> > 
> > What I'm saying is that, if one wants to run the Buildroot generated
> > system as a complement to an existing system, that should be done by
> > chrooting into the Buildroot system, so that / is seen as / .
> >
> 
> Well, in this application of after-market support (the Amazon Kindle)
> that is how we run Debian on the grayscale e-books.
> In fact, have been doing that for about 4 years now. ;)
> http://www.mobileread.com/forums/showthread.php?t=96048

Everything I could see in that post actually uses a chroot, and is not
running the Debian stuff from outside the chroot.

> But a chroot (by design) does place significant limits on what parts
> of the existing system outside of the chroot can be used/accessed.

Well, the post you pointed to has explicit explanations on how to do
that for the kindle. It points to:
    http://wiki.mobileread.com/wiki/Debi...n_Kindle_Touch

which contains:
    In case you want to have access to userstore from debian execute
    before chrooting:
    mount -o bind /mnt/us /mnt/debian/mnt/us

[--SNIP--]
> And, in fact, I found that I don't need to use it.
> Going down that usage path lead to too many complications.  ;)

Yes, I can imagine that. Programs that expects things (e.g.) in /etc
will be very unpleased when that stuff is in fact in /somewhere-else/etc.

So, what about the bug report? Should we close it?

[--SNIP--]
> > But OK, either we make it work (without adding too much complexity),
> > or we document it as a limitation.
> 
> I don't think it is a major limitation to the Buildroot user community.

I tried to add the script approach, but I bailed out after I banged my
head for two hours.

> A mention in the options help text, a mention in the manual and an
> addition to the known bugs list should be enough until someone really 
> needs it fixed.

Yep, that's the way I've gone with. If the maintainers don;t agree, then
someone will need to do the job. I tried, I failed. :-(

> I would be all right with just mentioning that the ld.so token "$ORIGIN"
> can not be included in the custom link options field.

I have been a bit more conservative in my change, in that I document
that as soon as there is a $ sign, expansion of the variable is
unpredictable, so it is not supported.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'


More information about the buildroot mailing list