Re: what is the whole purpose of kernel-image-di?
Ben Collins wrote:
> I can understand it being the first milestone, but it seems to be the
> only focus, and nothing is being considered as to how it affects other
> ports.
That's not entirely true; I know of a group (who I cannot name or go
into any detail on since they told me about this privatly) who is using
the the basic debian-installer design and code as the base for something
(very cool) involving installation on powerpc. The pa-risc porters were
also looking at using d-i some months back, but it wasn't far enough along
at that point.
> For sparc, there has to be atleast two different boot kernels. One for
> sun4cdm (32bit CPU), and one for sun4u (64bit CPU).
As Glenn said, the kernel-image-di kernel is intended to have initrd and
ext2 built in, plus anything else needed to boot the system from initrd
and get a console. Everything else should be configured as a module. As
I told Daniel Jacobowitz when he asked about powerpc (unrelated to thing
above), send me a .config file and any logic necessary to detect the
arch (and subarchitectures), and I will integrate it into the package.
I will also need various lists of module names, like a list of common NIC
card modules and so on.
Oh by the way Dan has been involved earlier in porting most of the d-i
modules to the powerpc, or rather, compiling them on the powerpc. They
seemed to work ok, but this was a while back, before the system did
anything.
A glance at the debian archive shows that this many udebs have been ported:
joeyh@auric:/org/ftp.debian.org/ftp/dists/sid/main/debian-installer>for dir in * ; do echo -n $dir ; grep Package: $dir/Packages |wc -l ; done
binary-alpha 9
binary-arm 6
binary-hppa 1
binary-hurd-i386 1
binary-i386 22
binary-ia64 1
binary-m68k 4
binary-mips 3
binary-mipsel 1
binary-powerpc 11
binary-s390 1
binary-sh 1
binary-sparc 8
This is one of the nice things about the debian-installer using standard debian
sources that generate deb files: autobuilders automatically treat d-i modules
just like regular packages. Anyone want to go check the build logs for
problems to see if some of the missing items failed to build or have just not
need attempted yet?
(Good grief, I didn't know binary-ia64 had made it into the archive already..)
> My main concern is whether or not it
> is being documented as to how other ports need to handle getting the
> installer working for it. Is there a checklist of what a port needs in
> order to have support in the installer, such as a minimum of required
> packages (boot loader setup, kernel-images, etc.)?
Breifly:
a. Autobuild all the udebs. File RC bugs on any that fail to build, per
the usual. If you just want to build a few, build those listed in
build/lists/base, although you'll need at least one additional set, like
build/lists/net to actually have a useful system.
b. Send me an appropriate kernel config and related information, and build
kernel-image-di once I integrate it.
c. Some things such as network card involve hardware autodetection. We have
concentrated on i386 since it has the most variety (and crap) hardware.
udebs are generally available which let the user specify it manually
instead of using hardware autodetection. Other than those and some minor
crossovers, other architectures are on their own, and someone will have to
work on it.
d. The build/ directory is what builds actual bootable media. That code is
currently flagged:
# Create a bootable floppy image. i386 specific. FIXME
Obviously that will need to be fixed, on a case-by-case basis. I personally
flag anything I do that is i386-specific as such, although I haven't
had to do that much so far.
But we're really all too busy writing this thing to have ready-made checklists
yet. I'm scrambling to keep the existing design documentation current.
> Note, every arch is different, which was the main reason for so much
> speciality and hacking in the boot-floppies. It's held together by
> ducktape and string. Have the issues involved in the boot-floppies
> struggle with multi-platform support been brought into consideration of
> the debinst design?
You're not going to magically get a new installer for your architecture
dropped in your lap, it will take work. Anyone is free to jump in and make
support for another architecture happen *now*, while we are still in the
middle of writing the thing. Or you can wait and complain after the fact
about us not anticipating the needs of every architecture. Up to you.
--
see shy jo
Reply to: