build / test / target ... embedded system ...
 

Hi gentoo-embeddeds,

i am a fellow gentoo user since nearly six or seven years now, and i
dont want to switch over to any other distribution out there, especially
when it comes to embedded linux stuff, gentoo for me is *THE* way to go!

however things could be more comfortable when it comes to cross
compiling, but this will evolve with time - i am sure - at least the
last post regarding "openmoko" "speaks out of my heart" (maybe there are
some german guys on this list who understand this phrase better) ;)

anyway, the crosscompiling stuff only hit me once when i wantetd to put
gentoo on a mips arch ... but there was a "denx" image already existing
so it was easier to crosscompile the few packages with this ... however,
gentoo was very helpful alsoin tis case as it had all the magic to cross
compile python for the 160MHz mips cpu ;)))

ok, enough of the introductory stuff ;) - now off to what i really want
to discuss with you ...

as i am mostly doing embedded gentoo on x86 hardware (epia and the like)
i currently have the following setup:

imagine you have lots of identical boxes around the world with only
remote access (ssh) running gentoo and want to have them all up to
date ...

i have
- development system chrooted or nfs-root (with all the dev stuff)
- test system (where i rsync only parts from the dev system -
mostly to save space, i leave out all the doc and dev-stuff)
- form this test system i make an image (via rsync into a loop-mounted
file)
- on the targets i have two root partitions who only differ
in /etc/fstab
- normally the target runs on "root1"
- i can upgrade (via rsync) from the image-file into "root2"
- then i switch over with grub to boot "root2" the next time
and define "root1" as the fallback if "root2" fails ...
- reboot
- if it was successful, i can log into "root2" and sync back
to "root1"
- if it wasnt successful, a check-script (via watchdog) triggers
a reboot, because of the "fallback" definede in grub, i end up
booting "root1"
-> so if the update doesnt work i can log in to the "old"
"root1" system and check what went wrong
-> if everything was successful, i sync "root2" to "root1",
reboot and everything is fine ;)

as i suppose that not only i have such a setup to maintain i would like
to discuss this approach with you - maybe we can come to an even better
solution ....

one thing which is not covered is the kernel upgrade ... or when the
system hangs when it boots "root2" ...

i assume a failsafe mechanism for a kernel upgrade will be hard to
find ... mind the dependency of /lib/modules/... along with different
kernel images ....

i know catalyst is out there, but i doubt it is flexible enough ... but
i would be fine off if you could teach me different ...

what are your approaches to such a scenario ... ?!?!

i also thought about building bin-pkgs and distributing them on the
targets ... is it possible to kepp all the .h and doc stuff out of a
bin-pkg ?!?!

well, thanks for reading this rather long post and i appreciate all your
comments !!!

thanks,
marcus.

build / test / target ... embedded system ...
 

Marcus Priesch wrote:
> i know catalyst is out there, but i doubt it is flexible enough ...
> but i would be fine off if you could teach me different ...

I like catalyst and use stage4 for all targets.

The nice thing about catalyst is 1. it's automated and 2. you can
pick and choose at which files you want to delete.


> i also thought about building bin-pkgs and distributing them on the
> targets ...

I'd like this too. In practice, catalyst uses tbz2s behind the
scenes, so everything doesn't have to be rebuilt every time.

> is it possible to kepp all the .h and doc stuff out of a bin-pkg ?!?!

Right, this is a good question, catalyst just makes tbz2s of the
normal packages and applies cleanup stuff at the end, so the tbz2s
themselves are not very deployable.


//Peter

build / test / target ... embedded system ...
 

Hi peter, thanks for your answer ....

On Thu, 2008-09-04 at 00:35 +0200, Peter Stuge wrote:
> Marcus Priesch wrote:
> > i know catalyst is out there, but i doubt it is flexible enough ...
> > but i would be fine off if you could teach me different ...
>
> I like catalyst and use stage4 for all targets.
>
> The nice thing about catalyst is 1. it's automated and 2. you can
> pick and choose at which files you want to delete.

yes, but thats exactly what portage and rsync also can handle ;)

> > i also thought about building bin-pkgs and distributing them on the
> > targets ...
>
> I'd like this too. In practice, catalyst uses tbz2s behind the
> scenes, so everything doesn't have to be rebuilt every time.

yes, but what about after a emerge --sync ?!?! - the problem with
working with "outdated" portage trees is - despite that you dont have
all the bugs fixed - that the .tgz's become unavailable after some
time .... thats why i want to stay "tuned" ...

furthermore updating a 2 year old gentoo system could be very time
consuming .... thats also a reason why i want to stay up to date ... and
i doubt that catalyst really supports this in a better way than plain
portage does ... at least the reusability of the components is no plus
than either ...


> > is it possible to kepp all the .h and doc stuff out of a bin-pkg ?!?!
>
> Right, this is a good question, catalyst just makes tbz2s of the
> normal packages and applies cleanup stuff at the end, so the tbz2s
> themselves are not very deployable.

yup ... what about "config-protect" - can this be "mis"used for such a
function ?!?!

regards,
marcus.

build / test / target ... embedded system ...
 

Marcus Priesch wrote:
> > > i also thought about building bin-pkgs and distributing them on the
> > > targets ...
> >
> > I'd like this too. In practice, catalyst uses tbz2s behind the
> > scenes, so everything doesn't have to be rebuilt every time.
>
> yes, but what about after a emerge --sync ?!?!

You write explicit snapshot you want to work with in each spec file.


> - the problem with working with "outdated" portage trees is -
> despite that you dont have all the bugs fixed - that the .tgz's
> become unavailable after some time .... thats why i want to stay
> "tuned" ...

If you need to keep old versions I would recommend mirroring them
locally. If you are really serious you'll create your own snapshots
too.


> furthermore updating a 2 year old gentoo system could be very time
> consuming .... thats also a reason why i want to stay up to date ...

This is a design decision. If you want to update your systems often
then go ahead. But catalyst will require you to at least create a new
spec file each time.


> and i doubt that catalyst really supports this in a better way than
> plain portage does ... at least the reusability of the components
> is no plus than either ...

What is "better" in your opinion.

The massive advantage with catalyst is that one or a few trivial
files reliably generate the same system image over and over. The
spec files also serve as documentation, or source code for your
system if you like.

If you don't appreciate this then there's no point in using catalyst
at all, but I do think catalyst can work for you.


> > Right, this is a good question, catalyst just makes tbz2s of the
> > normal packages and applies cleanup stuff at the end, so the tbz2s
> > themselves are not very deployable.
>
> yup ... what about "config-protect" - can this be "mis"used for
> such a function ?!?!

No, not to control individual files I think, only on the directory
level. I believe there is a newish feature in emerge/portage that
allows you to specify which files should actually go into root from
image/ but last I heard I think there was some bug with it.


//Peter