[Aboriginal] Back to work.
rlandley at parallels.com
Tue Mar 29 03:07:52 PDT 2011
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>
>> 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.
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.
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...
More information about the Aboriginal