Re: Yet another [cross] installer
On Mon, Mar 1, 2010 at 7:02 PM, Hector Oron <zumbi@debian.org> wrote:
> Hello,
hi hector, this is a timely message / issue to raise: it's very
relevant for the (newly discovered) CT-PC89E arm netbook which a
friend of mine found.
> Nowadays, the number of devices (non x86) is growing and growing.
> Lots of these devices have not upstream linux kernel support, which
> makes it a bit harder to maintain in the context of debian-installer.
in the case of the CT-PC89E, we haven't yet taken on the burdensome
and patient task of explaining the implications of the GPL to the
factory, yet, and of the need and obligation for them to provide the
GPL source code of both the linux kernel _and_ of the u-boot startup.
i'm not mentioning this in order for people to go, "well, you're a
fool, and you can expect every problem you get, can't you, and don't
expect anyone on any debian mailing to ever provide you with any
assistance whatsoever".
i'm mentioning it because with the increased uptake in guhoogul
anderoyd, the complete lack of understanding of the hardware
manufacturers - chinese - for the implications and obligations of the
GPL is going to be much more commonplace.
thus, _realistically_, it makes sense to take into consideration that
some devices aren't going to _immediately_ get the linux source code,
and thus the fact that there may be binary-only linux kernels to work
from - initially - would also need to be taken into consideration.
> Also, afaict, debian-installer team does not like to add complexity to
> d-i, which I understand, so it has better maintainability in the
> future.
>
> Also live-installer could be the path to track for such kind of
> devices, but again, live-installer was not meant for such purposes and
> I believe maintainer won't be happy to add such extra features.
>
> Ubuntu people has been working on a nice tool (evolution from
> build_arm_rootfs) named 'rootstock' which basically prepares a
> filesystem for ARM targets.
yes - i heard about this. i did the hack-job approach before i'd
heard of it: qemu for ARM, installed rsync, then rsync'd the root
filesystem out. not ideal, but it did the job.
> Which is best way forward, in your opinion, for supporting non-x86
> arches installations (even installation done from a x86 platform)?
> (debian-installer, live-installer, rootstock or start from scratch)
there are two different main categories of systems.
the first is one where you have access to the storage device: it can
be removed (SD card), the system can somehow be booted from SD card,
USB, etc. whatever it is, it's possible to just "blop" a root
filesystem onto it, and go.
for these, i think the absolute ideal case would be to have a netboot
installer which can replace itself. for example, by creating a
ramdisk, pivot-rooting onto it and then umounting the root filesystem.
exactly the _opposite_ of initrd :) then the root filesystem is free
to be wiped out, and the "real" OS installed. variations on this
theme include the CD / ISO "searcher" - the usbstick stuff. having
pivot-rooted into a ramdisk, it would be handy to have an option of
going hunting on usb and other storage for iso filesystems or iso
images. [i imagine that this is pretty much what, or is near-as-damnit
similar to what debian-live does, but that's another story]
the second case is where you have absolutely no chance of gaining
access to the root filesystem in any kind of "normal" sense. this is
the example of the CT-PC89E: what we've got, that's it, we're hosed
(for now), and we have to work within the structure that the factory
has imposed, which is this:
http://www.denx.de/wiki/view/DULG/RootFileSystemInAReadOnlyFile
this is our "way in", because they've followed that procedure, and it
turns out that yes, we can press-and-hold power and both mouse
buttons, activating the factory's "upgrade" procedure, and thus "drop"
the contents of a .tgz archived root filesystem directly onto the NAND
flash, by creating our own "datang-epc.tar.gz". this was how i
managed to get debian/lenny onto the CT-PC89E:
http://elinux.org/CT-PC89E_Debian
now, what would have been _really nice to have_ would have been a
debian-installer tarball (as described in case 1, with the preparation
to get itself into a ramdisk that's then pivot_root'd) which could be
unpacked onto the NAND flash by the hardware manufacturer's "upgrade"
procedures, and then, after a reboot, it would go directly into the
debian installer etc. etc. just as in case 1).
and no, right now, we don't even have access to the serial console on
which u-boot is displaying its startup messages: there's an
unpopulated header on the CPU+RAM+NAND SO-DIMM.
other important caveats:
* the binary-only kernel we're working with, they haven't even
bothered to put in ext2,3 or 4 and so despite the u-boot-loaded initrd
being able to gain access to the ext2 root filesystem, we can't mount
any partitions other than FAT, once debian is actually running. the
implications of this are that ISO images searched for (and
loop-mounted) NEED to be capable of being searched for on "any kind of
media" i.e. not just extN but also FAT.
* installing a kernel should not be assumed as part of the debian
installer phase, nor should grub, grub-efi, lilo, u-boot or in fact
any boot loader or kernel at all should be assumed to be installable
or required to be installed.
* the binary-only kernel we're working with: whilst they've set up the
/dev/fb0 through to /dev/fb2 for LCD, VGA-out and TV-out, they
*haven't* compiled in any console fonts!! thus, it cannot be assumed
that there will be any /dev/ttyNs available (!) or if you do try to
use them, they'll be black on black squares! and, therefore a libsvga
or x-windows-based installer will be required (helloooo
xserver-xfbdev, hello upstream-unmaintained xserver-kdrive, pleased to
ironically meet you: you'll do nicely for fitting into a pivot-rooted
ramdisk, i'm so pleased that your build instructions are described
here: http://kemovitra.blogspot.com/2009/10/linux-compiling-xorg-kdrive-server.html)
questions to consider: how much of this is simply one-off effort by me
to regain control over hardware and thus be in a position to give
better feedback to the factory _despite_ their lack of information to
us right now, and how much of it would be beneficial to actually
implement because it's clear that it's going to be needed time and
time again, only you can decide that one.
l.
Reply to: