Re: Building boot images with boot-floppies on PowerMac
On Wed, 25 Jun 2003, Eduard Bloch wrote:
> #include <hallo.h>
> * email@example.com [Wed, Jun 25 2003, 02:47:44PM]:
> > > > > Stable still has 3.0.22. Is there a reason 3.0.23 never moved to
> > > > > stable, Eduard?
> > >
> > > See above. Woody has been moved to stable under our asses, and to this
> > > time there were an RC bug about potential security problems. One of the
> > > problems with Debian's release system.
> > I have tried the testing version. It fails too:
> > 1393+1 records out
> You did not understand the problem. It is not the version of BFs
The problem, I thought, is that the three versions of b-f I've used do
not produce bootable images.
> whereever it now are, it is the location of the supplementary packages
> like kernel-image-*; they are still located in unstable while the
> build scripts look in Woody.
Why is that? I would have thought it logical to distribute b-f configured
to look for kernels in places where they may be found. I'm new to all
this, I don't have a clue where to look.
My plan was to build bootable floppies as near as possible to what I can
download from the local Debian mirror, and having done that, figure how
to make the changes I desire.
> > /archive/debian/download/var/lib/apt/lists/debootstrap.invalid_dists_woody_main_binary-powerpc_Packages
> > E: Couldn't download pcmcia-modules-2.4.18-newpmac
> > E: ./kernel.sh abort
> And the solution is: get those packages from the pool and store them in
> your local package directory (see the "config" file).
IMV that's more a workaround than a cure. While it will likely fix it
for me, the next person along will encounter the same difficulties.
> > It seems to me part of the problem is that it has hard-coded into it
> > versions of kernels to use, and the kernel maintainers have replaced
> > those packages.
> The kernel maintainers cannot replace or move packages easily - Woody is
That should make hard-coding versions less of a problem, but it's still
a flawed approach.
> > I'm sure I can hack this thing to build the bootfloppies _I_ need, but
> > that won't help others. Part of what I would do is prevent it from
> > building for boxes I don't have.
> And that is the reason why boot-floppies are no built by build daemons
> but manually by each architecture maintainer.
> > What I think should be happening is this:
> > 1. Default to using mirror(s) from /etc/apt/sources.list. That would
> > eliminate one of the customisations I must make.
> > 2. Parse the Packages to the extent necessary to discover the most
> > recent of each of the packages needed.
> You can define a mirror in the config, that is not the problem. The problem is the Debian release which the
> packages belong to. A possible workaround would be modifying the build
> scripts to work with the pool structure (read: having a private version
> of the /etc/apt directory where you can specify the priority of the
> packages, scanning every Packages file available on that mirror), taking
> the stable version of a package if possible and if not, fall-back on the
> Sid version of the same package. Maybe you can use apt for this purpose,
> but who is going to make this work? Many people declared the BFs as
> doomed, I doubt that you really wish to stand up and work on it.
Something needs to be done in the short term. From what I've seen there
are quite a few refugees from Red Hat come to Debian recently. A lot of
them are capable at what they do (installing and configuring Linux), and
they will be finding this part of Debian a nasty shock.
> > 3. Maybe source a site configuration file from /etc/bootfloppies/ where
> > the results of steps 1 and 2 can be adjusted.
> Why /etc? We are just building a package, the changes on the host system
> should be minimal.
At this level, b-f is a tool, not so different from mkisofs, that takes
data from various sources, processes it in magical ways, and produces
I've not tried using it except as root - in my environment the usual
advice not not be root doesn't seem so sensible - but it does require
configuration, and /etc seems to me a sensible place for that
Red Hat's equivalent tool is Anaconda, and you don't go fooling round
with the package itself to build your CDs (Anaconda does a bit more) and
Even if you disagree on /etc, ~/boot-floppies/ remains a good place for
> > 4. Source a personal configuration file for further fine-tuning.
> Feel free to create a such thing, I won't accept it in the "stable"
Very likely, you'd not like anything I'm likely to come up with. In a
shell script, i'd so something like
[ -f $HOME/boot-floppies/config ] && . $HOME/boot-floppies/config
at a point that seems good to me;-).
How I would do that in a make file, I really don't know.
> > I'm sure you can argue whether this idea is slightly broken: the main
> > objective is to achieve something that is robust enough to work for the
> It is quite robust as-is. It is just the FTP archive that is
Robust? It doesn't work at all at present. As a user, I don't care
whether the particular problem is that the Debian respository has
changed since b-f was packaged. I don't have to be a car mechanic to
diagnose that my car won't start, and I don't care whether it's because
it's out of fuel or the spark plugs are dirty. Either way, the engine
cranks but doesn't start.
Robust means to me that when someone updates the repository, especially
with an official update, it continues to work.
> > unsuspecting (me, for example) and to simplify customisation for more
> > advanced use. Customising the config file doesn't seem to me especially
> > elegant or robust, and I can imagine it causing problems with updates
> > from CVS.
> Nack. There only were few problems with CVS mergin in the hot
> development phase.
I may be mistaken, but I think that if you changed a line near here,
then my attempt to update from CVS would run into trouble:
## Debian mirror we can download from, must be http://, ftp:// or
export MIRRORS := http://ftp.wa.au.debian.org/debian
## How to achieve root
Please, no off-list mail at all at all. This address accepts mail only
from Debian addresses.