Re: versatile architecture image suitable for qemu usage?

[Junichi Uekawa <dancer@netfort.gr.jp>]

Hi,

At Fri, 9 Jan 2009 09:44:33 +0100,
Loïc Minier wrote:
> 
> On Thu, Jan 08, 2009, Junichi Uekawa wrote:
> > I tried to test qemubuilder armel support and realized that I don't
> > have the latest kernel.
> > 
> > initrd isn't distributed inside a package, and I don't think there's a 
> > kernel which doesn't work without a initrd.
> > 
> > Is there a kernel which contains minimal support for ext2/3 and/or
> > initrd which contains them ? (and supports parsing init= kernel
> > command-line option).
> 
>  I agree that it's too hard right now; what would make that situation
>  much easier would be either:
>  - kernels with ext3 and some IDE drivers; enough builtin to boot into a
>    fs and run a command
>  - or generic initrds downloadable from some place; something like the
>    d-i ones, but with enough to load a fs and run a command
>  - or a mean to create foreign initrds; currently both initramfs-tools
>    and yaird hardcode the root dir, so you can't tell your host's initrd
>    generator to build an initrd for a debootstrap-ed dir
>  - or a mean to run commands in a native chroot, that is run armel code
>    from a x86 host for instance; this might be possible with e.g. qemu's
>    CPU emulator and scratchbox, but I didn't try it out
>  It's much easier in the x86 guest on x86 host case as you can just
>  create the initrd by chrooting into a debootstrap-ed dir.

It's hard to bootstrap right now.  Maybe I can run d-i preseeded
rescue mode and script something. But if I had to go that far, I think
it's much easier if I just provide a tool to create initrd for
qemubuilder, or use initrd as primary means of running/controlling
qemubuilder instead of a ext2-formatted block device (qemubuilder
creates a script inside ext2 formatted block device to instruct what
will happen inside the virtual machine).

regards,
	junichi
-- 
dancer@{netfort.gr.jp,debian.org}