[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Emdebian 1.0 ?



On 2008-08-15 10:12 -0300, Neil Williams wrote:
> On Sun, 2008-08-10 at 12:41 +0200, Michelle Konzack wrote:
> > > Subsequent work is :
> > > 
> > > To implement D-I support for Emdebian root filesystems (needs a fix for
> > 
> > How dou you want to implement the D-I for EmDebian?
> 
> Provide a root filesystem to D-I and skip all the package installation
> stages of normal D-I by doing so. Use existing support to combine the
> root filesystem (from emsandbox) with a kernel and kernel modules.tgz
> for D-I to handle. Possibly support partitioning before unpacking,
> certainly support setting a user-specified root password and supporting
> adding new users during the install. That's about it - basically make
> Emdebian look more like Debian from the install onwards.

Wookey was doing some work on scripting Emdebian installations
> for balloon at TCl - not sure how easy that could be to adapt into a
> generic D-I method.

The problem with generic D-I has been for years that there is no
support for flash partitioning as opposed to disk partitioning. So far
as I know that is still true. This is because it depends on partman
for this and partman doesn't do flash. Has that changed in the last
couple of years?

I have never really got my head round exactly whether it was better to
simply replace partman with something else for flash installs or to
add support to partman. Part of the problem is that the multitude of
bootloaders use different partitioning schemes. In practice it may be
that this is not too big a job, but I think everyone so far has
decided it was too much effort. 

The other thing is that D-I does exactly what most embedded people
don't want - installs on the target (slowly!). They want to do the
install on the build system and just copy an image over to the target
device. We currently copy a debootstrapped/emsandboxed image over to
the device, do the 2nd-stage install there, then pack up the result
and save it as an installable image. The problem with this is that it
is difficult to fully automate and some things which should be
different on every box end up the same (generated keys, for example).

This is why slind used the BSD installer, for example. 

What we really want is support for local cross-installs a-la stag or
stage and splitting of install scripts into native/non-native parts.
This is a really big, scary, job within debian. Discussion on this
subject in extremadura would be productive, I think, as to what the
best short and long-term approaches are.  

Wookey
-- 
Principal hats:  Balloonz - Toby Churchill - Aleph One - Debian
http://wookware.org/


Reply to: