[Aboriginal] Couple of bugs.

[David Seikel]

On Sun, 10 Apr 2011 01:11:20 -0500 Rob Landley <rlandley at parallels.com>
wrote:

> On 04/09/2011 10:52 AM, David Seikel wrote:
> > On Sat, 9 Apr 2011 10:35:56 -0500 Rob Landley
> > <rlandley at parallels.com> wrote:
> >>> Could be both separate, and being able to use Aboriginal Linux as
> >>> the build environment by having the two side by side, so people
> >>> can run both with simple scripts, then use the results to build
> >>> some sort of bootable image, or keep running it under qemu.
> >>>
> >>> Could also have the option of combining it into one image, and not
> >>> two where one is mounted automatically, then have to manually
> >>> chroot into it to actually do anything with the bootstrap under
> >>> qemu.
> >>
> >> 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.

> >> 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.

> >>> I'd probably dump a EFL on frame buffer, and EFL on X minimal
> >>> bootstrap into the EFL repo, as an example to others to not start
> >>> dumping random collections of bootstraps into your repos.  They
> >>> already have an OpenEmbedded area in their SVN.
> >>
> >> I do want to set up a vnc desktop export.  In theory x.org does
> >> this built-in, in practice I've misplaced the instructions I got
> >> it to work with last time.  (Maybe it was in BLFS somewhere...)
> > 
> > Or don't pass -nographic to qemu, which I already have a modified
> > run-emulator.sh doing.  Something I'll need to play with more for
> > this project.
> 
> The target's settings file creates the run-emulator.sh script, you can
> put anything you want in there.  (Even use an emulator other than
> qemu.)
> 
> However, what I meant was having the image export VNC rather than
> having qemu emulate a VNC-based video card.  (Part of the reason is
> I'm fiddling with LXC containers in my day job, and I want to be able
> to export a VNC desktop from within a container and run it in a
> window on a host.  Kir Kolyshkin (OpenVZ maintainer and a co-worker
> of mine) made this work at Scale, and I had it working on the Xylinx
> microblaze last year, I think the instructions are buried down in
> BLFS somewhere.  My recent attempts to google for it have just pulled
> up external VNC projects when x.org has built-in support for it these
> days.  (It's on the todo list.  The fact my OLS paper proposal "Why
> containers are awesome" has been accepted means I need to start
> seriously researching this soon...)

For this project I'm not using X, just using the kernels frame buffer.
So no VNC for me.

> > 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.  I wont be completely to spec with the latest LFS,
but for bootloaders, don't think either of us care.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal-landley.net/attachments/20110410/a9fcaf6e/attachment-0003.pgp>