Re: [gentoo-embedded] CF Sub-Package Mgmt. was Re: hardened uclibc gentoo stages

[Ned Ludd]

On Tue, 2004-08-24 at 09:02, Jason Cooper wrote:
> Natanael Copa (mlists@××××××.org) scribbled:
> > On Mon, 23 Aug 2004 21:36:18 -0400
> > Jason Cooper <gentoo@××××××××××.net> wrote:
> > > I come from a commercial engineering/development house.  We like
> > > version control (Well, someone does, not sure who). We do one-off's,
> > > applications, production items, mil-spec, LEO, and other stuff. (yeah,
> > > I know, great sales pitch :)
> >
> > We use our stuff non commercial. We don't intend to make money out of
> > every version. We want to run a network and we dislike downtimes.
>
>  From what I understand (I do R&D support right now), we don't make money
> off of individual versions either.  More support/services/products
> oriented (govt contractor).  I can fully agree with disliking downtimes.
>
> > > I can see where one would want to be able to add packages on the
> > > fly to say a wrt54g or an nslu2.  Does it seem viable to do that from
> > > a host system (faster compiles, more space), and generate a new images
> > > each time?  Or try to unpack the package on the fly on the target?
> > > I'm not sure I see the viability of the latter wrt diskless systems.
> >
> > We are running harddisk-less bering routers (when we get all of them up
> > and running there will probably be over 200 of them) Those are pulling
> > runtime packages on the fly. Even if we do that, we need to reboot
> > during upgrades. This year there have been a numbers of upgrades and it
> > would be very nice to prevent the reboots. It is possible.

indeed I don't think any of us want or are willing to reboot for simple
upgrades.

>
> I think one of questions I have regards systems that have flash and ram
> as their only means of storage.  It's my understanding that the initrd
> image must be written to the flash as a whole.  Of course, any changes
> to the running system would work, but would not be persistent.  In this
> case, a package system may not be desirable.  Doesn't mean it shouldn't
> be an option, just that there should be some means of upgrading the
> image on the host and then flashing the target(s).  Also, target package
> management tools should be optional.

squashfs + jffs2 make a nice combo which you can build fail safe systems
with. One of the things that really impressed me about the OpenWrt
project was the use of these file systems together.

The merits of jffs2 on a compact flash are not clear however. 
The arguments seem to go both ways of (good vs bad)
A gentoo user yoann.at.prelude-ids.dot.org (http://www.prelude-ids.org/)
is doing a trial run of such a setup on compact flash.

>
> I think both approaches have merit.
>
> Hypothetical build process:
>
> # emerge crossdev
>
> # crossdev --arch=powerpc ...

Unfortunately the crossdev does not support uClibc yet.
I've started on a patch for it, but somebody else will have to write one
missing & needed function to make all the glue work.

http://dev.gentoo.org/~solar/toolchain/crossdev-uclibc-20040802.diff
The needed function is InstallUClibcCore() 

If anybody else has an interest is making crossdev uClibc aware here is
what said function can be based on.
http://uclibc.org/cgi-bin/cvsweb/toolchain/gcc-3.3.x/make/uclibc.mk?rev=1.7&view=auto


>
> # export EMBEDDED="powerpc"  ??? pulled out of thin air :)
>
> build the kernel... then
>
> # export E_ROOTFS=/opt/powerpc/rootfs ??? same here...
>
> # emerge system (this will go to $E_ROOTFS, for $EMBEDDED)
>
> emerge individual packages (ssh, nfs, ntpd, ipkg-tools, etc)
>
> add your app (if needed).
>
> edit rc script for app.
>
> configure everything.
>
> disconnect loopback file (rootfs), compress
>
> flash.
>
>
> Do I have the right idea?  It almost looks like a separate
> 'portage/embedded/' tree may be necessary so package maintainers
> aren't bothered with embedded issues.  The embedded tree would
> essentially be ebuild wrappers pulling extra patches, etc.  Maybe
> '.e_ebuild' or '.eebuild'?

I really really don't want to go that route. oe exist for that.

>
> I'm sure a lot of this has already been covered... Unfortunately, I
> can't find the archives to browse. :(

http://marc.theaimsgroup.com/?l=gentoo-embedded

>
> Cooper.
>
> --
> gentoo-embedded@g.o mailing list
-- 
Ned Ludd <solar@g.o>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer