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
--
dan...@{netfort.gr.jp,debian.org}
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
