[Aboriginal] Couple of bugs.

[Rob Landley]

On 04/09/2011 07:12 AM, David Seikel wrote:
> On Thu, 7 Apr 2011 19:11:47 -0500 Rob Landley <rlandley at parallels.com>
> wrote:
> 
>> On 04/07/2011 04:21 PM, David Seikel wrote:
>>> When using SYSIMAGE_TYPE=ext2 (or anything that is not squashfs),
>>> then the squashfs stuff is not built.  The bootstrap stuff still
>>> tries to use the non existent mksquashfs though.
>>
>> Argh.  Yeah, that's a problem.

Which ties into the "breaking it out into a separate project" issue,
which is a design problem rather than an implementation detail.

There's shared infrastructure that's convenient to leverage, but
conceptually this isn't part of aboriginal linux's design, but having
_example_ images to demonstrate the automated native build
infrastructure (and how to take advantage of it) probably would be, but
this is a can of worms and the way to handle cans of worms is to take
them outside...

Somewhere there needs to be a website describing how to bootstrap debian
and such.  Distros that expect to build under themselves have an
undocumented set of environmental dependencies, which _can_ be manually
satisfied to let you build Fedora under Gentoo and such (if by tweaking
the heck out of a chroot).  Somewhere there should be a website
documenting those environmental dependencies, and the best kind of
documentation for this sort of thing is the executable kind that you can
regression test.

In the absence of somebody else doing that (and I've been waiting
several years now and nobody's beaten me to it yet, you'd think the
Linux From Scratch guys would be interested but not so far), the control
images are likely to grow into doing that.  And they are NOT doing so
within the confines of the aboriginal linux project, because that's not
what this does.

So I've got a bit of egg-unscrambling to do, separating stuff out and
cleaning it up.  sigh...

>>> The bootstrap tarballs are being named foo.tar.gz-i486.
>>
>> Um, details?  (I haven't seen that one.)
> 
> In sources/control-images/bootstrap-skeleton/mnt/functions.sh there is
> this -
> 
> upload_result()
> {
>   ftpput $FTP_SERVER -P $FTP_PORT "$1-$HOST" "$1"
> }
> 
> The "$1-$HOST" part adds the target platform (in my case i486) at the
> end of the tarball name.  So it comes AFTER the .tar.gz part of the
> name.  That part of the file name should be added in during the tar
> command in init.sh.

Good point.  I cut and pasted that from static-tools.sh building
dropbear and strace.  (And once upon a time busybox, which requires a
postfix on the name "busybox" rather than a prefix, because that's what
Erik Andersen wanted way back when.  Except I cross compile a static
busybox by default, so building one natively is slightly silly.)

I need to figure out what infrastructure goes into aboriginal linux and
what goes into the separate control-images.  (Automative native build
control images.  Distro bootstrapping.  I suck at naming things, anybody
have a suggestion?  They can share the mailing list until there's enough
traffic ot justify splitting it off, but I have to name the mercurial
repository in order to put it online...)

>>> Both easy enough to fix, and you might have done so already anyway.
>>> This is with the last release.
>>
>> The first one's a design issue, which makes it tricky.
> 
> <snip> 
> 
>> Hmmm...  host-tools is already building distcc, which also isn't
>> really part of the build.  I suppose squashfs can become
>> unconditional...  but it's ugly.  Lemme think if there's a better way
>> to do this.  (I'd already have split control image building out if it
>> didn't need to use sources/download_functions.sh...)
> 
> I would fix it up the other way.  This problem happens when the user is
> asking for ext2 images.  So the control images should honour that and
> make ext2 images.  Then it does not matter that mksquashfs is not
> built, the user did not want it anyway.

Which argues for breaking system-image.sh into two parts.  (It's always
been kind of ugly, but initramfs is a form of packaging and that
requires building a kernel.  Plus building a kernel, by itself, doesn't
quite justify having its own script.  Or it does, but it would be in
sources/sections, not at the top level.)

It would be nice if the control-image infrastructure could use the
multiple filesystem format awareness of system-image, but really it's a
big if/else staircase with some hardwired hacks for /dev support.  (Read
the script, I'm open to suggestions on how to improve it...)

The problem is never implementation being too hard, the problem is
always figuring out what the right thing to do is.  Implementing it's
the easy bit (if often fiddly and time consuming)...

> Having said that, my quick and dirty hack to get back to working has to
> make mksquashfs unconditionally built.  I'm leaving a proper fix up to
> you.  At least until I sort out how I'm gonna make a bootable image
> file I can just dd to a CF card; one that includes multiple
> partitions.  I'm not liking the options for doing that so far.

SYSIMAGE_TYPE=initramfs

I've pondered adding jffs2 and yaffs2 and logfs and so on, but as you
can see there isn't a clear winner here, and to format one of these
suckers you have to know the flash erase block size and such which
doesn't abstract cleanly so far when I've poked at it...

Rob

 1302358616.0