[Aboriginal] Couple of bugs.

[Rob Landley]

On 04/10/2011 02:31 AM, David Seikel wrote:
>>>> The control images are target independent, the system images are
>>>> target specific.  (And the control images can be pretty darn big,
>>>> the LFS one is 350 megs.)  It makes sense to me to keep them
>>>> separate.
>>>
>>> Eventually a lot of users of the system will want to build bootable
>>> images, plus for the likes of LFS, include the toolchain that has
>>> been used so far.
>>
>> Yes, that's why it's important to allow them to be used together
>> easily.
> 
> That's what I'm saying.

How is this not already the case?

wget
http://landley.net/aboriginal/downloads/binaries/control-images/lfs-bootstrap.hdc
wget
http://landley.net/aboriginal/downloads/binaries/system-image-i686.tar.bz2
tar xvjf system-image-i686.tar.bz2
cd system-image-i686
./native-build.sh ../lfs-bootstrap.hdc

It helps to install distccd and to download the cross compiler and add
its bin directory to your $PATH (so dev-environment.sh detects it and
sets up distcc in the system image, calling out to the cross compiler on
the host), but that merely speeds things up rather than changing the
outcome.

>>>> If you use the run-emulator.sh, it runs the build automatically,
>>>> but there's a 3 second delay where it prompts you to press a key
>>>> to get a shell prompt, and only starts the build if you don't.
>>>>
>>>> I can easily change how that works, but it's really a user
>>>> interface question.  (Aesthetic issue, not necessarily a one true
>>>> answer there.)
>>>
>>> Does it do the chroot step into the bootstrap image when you press
>>> that key?
>>
>> Currently you have to go:
>>
>>   . /mnt/functions.sh
>>   do_in_chroot /home/lfs /mnt/run-build-stages.sh
>>
>> Next release (which is horribly overdue and I think I need to back out
>> the uClibc-NPTL upgrade and put that until the following release just
>> to get it unblocked), I'm breaking out do_in_chroot to its own script
>> and putting it in the system image, at which point you should be able
>> to just go:
>>
>>   do-in-chroot /home/lfs /mnt/run-build-stages.sh
> 
> Ah, so not automated.

Semi-automated, and working on improving it.  Right now you have to type
two lines, I'm making it so you only have to type one, and documenting
it in the FAQ.

And I suspect "setup-chroot" is a better name for the script...

(Sigh.  FAQ, multiple readmes, the "about" page, documentation.html,
presentation.pdf...  I need to collate it all into one document that
does everything.  Except it's hard for something to be both a tutorial
and a reference and a quick start card.  It's also hard to keep multiple
sources of documentation up to date and in sync, and makes it harder for
people to be sure they've read it all or to know where to start...)

>>> Think I have come up with an acceptable way for me to create a multi
>>> partition bootable image suitable for DDing onto a CF card, without
>>> having to use root on the host.
>>
>> I used to have scripts that did this... (Rummage, rummage...  Oh,
>> duh.)
>>
>>   http://landley.net/code/mkhda.sh
>>
>> See also attached control-image script which I whipped up for somebody
>> on the old list a year or so back.  (Alas, it involved lilo so was
>> x86-specific, which is why I never followed up on it or merged it.
>> You could almost make a universal bootloader out of u-boot, but since
>> it went GPLv3 it doesn't count anymore.  Since QEMU _has_ a built in
>> universal bootloader with the -kernel option, I declared victory and
>> moved on...)
> 
> That attached script is similar to what I'm doing, only I plan on using
> grub legacy instead of lilo.  Unfortunately LFS switched to grub2, so I
> have to back track.

LFS always bought into the idea that GNU software was a good thing.

Personally I treat it like Windows: widely deployed and most people are
already familiar with it, but it's technically utter crap put out by an
organization formed to pursue a non-technical agenda which only does
software as a sideline in service of that other goal.  (One's driven by
profit and the other idology, but neither goal has anything to do with
good engineering.)

> I wont be completely to spec with the latest LFS,
> but for bootloaders, don't think either of us care.

My lfs-bootstrap script is at least one version out of date, I should
update it.

Rob

 1302431126.0