[Aboriginal] Back to work.

[Rob Landley]

On 03/28/2011 05:39 PM, David Seikel wrote:
> On Wed, 23 Mar 2011 18:17:08 -0500 Rob Landley <rlandley at parallels.com>
> wrote:
> 
>> On 03/23/2011 09:01 AM, David Seikel wrote:
>>> In the end the client seems to have decided to go for generic x86
>>> systems, not the tiny 486 board I was looking at initially.
>>> Performance is not a big issue though, anything better than a 486 is
>>> way more than we actually need.  Plus, I still have copies of that
>>> 486 board that I want to use for other things. So I'll go ahead and
>>> keep working on that 486 target I had previously contributed.  I'll
>>> also make a variant that works on the 486 AND generic x86s.  Like I
>>> said, performance is not critical.
>>
>> As far as I know the 486 version does work on generic x86s?  (Or do
>> you mean there's still an actual 386 system in use somewhere?)
> 
> Nope, not 386.  I'm seeing kernel panics on the old one I made last
> year when running it on things more powerful than that 486.  I'll see
> if it happens with the latest version.  Something for me to investigate
> and send patches if needed.

Odd.  I haven't seen these panics, but I haven't really been banging on
the 486 target very heavily (or running it outside of qemu).

> After playing with it a bit, but only running things under QEMU, looks
> like I'll start with the lfs bootstrap stuff and modify that a bit.
> Suits my project perfectly.

Woot.

On my todo list are making a gentoo bootstrap and a debian bootstrap,
but I need to finish the uClibc transition first.

> Been working through the night, I'm dead tired, but I can't seem to see
> if there is a way to actually run the results of building the lfs
> bootstrap, under QEMU easily.  At least without hacking something up.

Um...

It makes a tarball, and uploads it to the host.  (All the native builds
do that.)  Afterwards, you can:

1) Run dev-environment.sh reusing the hdb.img file, find the appropriate
directory under /home and chroot into it.  (I think your chroot can run
sbin/init.sh and it'll detect it's not PID 1 and do chroot setup instead
of fresh boot setup, but I haven't tested that since last year.)

2) wget the tarball into a fresh /home directory, extract it, and chroot
into it there.

3) Play around with genext2fs or loopback on the host to make your own
bootable ext2 image.  (I should make a script to convert a tarball to an
ext2 or squashfs image, but things like /dev nodes and suid bits are
nontrivial to handle as non-root.  It can be done, but parsing them out
of a tarball...  Hmmm, actually I could do tar txv and have the script
parse the output to generate a device table for genext2fs...  But then I
have to extract the tarball in such a way that errors from being unable
to create dev nodes don't kill the script but errors from the tarball
being corrupt are...)

Might be a fun todo item, but not a particularly small one.  And if I
got it to work of course I'd want to redo system-image.sh to take
advantage of it...

Rob

 1301393272.0