Re: debian-installer on arm status
+++ vince@debian.org [04-02-23 18:53 +0000]:
> On Mon, Feb 23, 2004 at 05:49:57PM +0000, Wookey wrote:
> > +++ Peter Naulls [04-02-23 13:07 +0000]:
> > > In message <20040223104910.GA15886@azure.humbug.org.au>
> > > Anthony Towns <aj@azure.humbug.org.au> wrote:
> > >
> > > > It's time to get debian-installer ported to arm; all the major porting
> > > > work should already have been done getting it to work on other arches,
> > > > so what's left should be fairly straightforward.
> > > >
> > > > If you can't get this working, arm's status as a supported arch will
> > > > have to be reviewed: there's no point releasing a distribution that
> > > > can't be installed. (It'd be possible to release arm with a different
> > > > installation toolset than d-i, but I can't imagine that'd be any easier
> > > > or much more useful than getting d-i ported)
> >
> > You're right of course, and as you observe it really is getting to 'make it
> > work or have arse kicked' time. Part of the problem is of course that arm
> > installation has always been somewhat 'distributed' - there is a special
> > version of bootfloppies for most 'supported' machines because the default
> > one doesn't actaully work, and an awful lot of people using debian-derived
> > stuff don't use either b-f or d-i to get things installed - they use some
> > random bootloader for the board in question.
> >
> > So in fact debian-arm remains useful to a lot of people even without a
> > working debian-installer.
> >
> > That's not really an adequate excuse for not making it work on at least the
> > suitable machines, and hopefully it will be better suited to weird hardware
> > than b-f was. We'll see.
I've now got uptodate on d-i again at alioth and will take a look at
what needs doing for lart/balloon.
> > Poor old vince has found he can't do the kernel _and_ D-I - there aren't
> > enough hours in the day.
>
> While true to some extent I did get D-I to the point where I had
> working tftp images for winder, bast, riscstation. I tried to talk to
> #debian-boot about autobuilders and kernel-image builders and (as
> usual) got blown off, this was several months ago and my tree is now
> very very out of date so needs to be done again...
>
> One point, I was going to use the kernel udeb image thingy but in its
> current form adding all the ARM sub arches would make it generate an
> additional 40odd packages from the one source...this seemed grossly
> excessive and I wanted to find a more elegant solution.
>
> One issue which was being cleared up but hadn't been resolved was that
> the final image stuff wanted to put a single vmlinuz file down for all
> sub arches...with several subarches to choose from we ended up without
> a sensible kernel for the bootloader to start except for one target :-/
OK - we need to have this discussion on debian-boot I think, in order to
work out how best to proceed, so I've added it.
D-B people - Is the above still true? ARM currently has (approximately) one
kernel per machine. Even just supporting the existing supported stuff and
things that have enough resources for installing Debian to be a vaguely
sensible thing to do (which excludes quite a lot of potential machines),
means at least 10 kernel udebs, and some lesser number of initrds and module
sets.
Likely targets that someone cares about enough to support are:
Iyonix, RiscPC, Riscstation, Netwinder, Balloon, CATS, LART.
Advice on best way to proceed is welcome.
For much arm hardware using debootstrap rather than D-I may actually make
more sense/be easier. We (arm people) need to look at that too.
Wookey
--
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Reply to: