Re: Building boot images with boot-floppies on PowerMac
On Thu, 26 Jun 2003, Eduard Bloch wrote:
> #include <hallo.h>
> * debian@computerdatasafe.com.au [Thu, Jun 26 2003, 11:11:39AM]:
>
> > > > 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.
>
> That is the reason for first asking the arch maintainer. RTF intro files
> in the package, starting at README.
I've read (several times) README, README-Overview (nothing relevant) and
README-CVS. It should have been obvious to you when I submitted the
patch that I'd read this last, because the patch complies with your
requirements.
The "arch maintainer" for what? My problem is with b-f, according to
those documents you mention, this list is the right place.
> > > 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
>
> Because we need a controllable way to take the _stable_ packages for
> _stable_ branch of boot-floppies.
My initial problem is that that is precisely what I cannot do. If I can
do that, then I have a base to work on.
>
> > 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.
>
> A-Ha.
>
> > > > /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.
>
> And it won't change. If you are willing to make radical changes, look at
> the Debian installer project. There a such problem has never existed
> since they have a separated tree in the FTP archive.
I don't have any great objection to trying d-i on the Macs. Are there
prebuilt binaries some place?
>
> > > 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.
>
> Who are you speaking for? Newbies? They are users, not developers.
I am a user. I'm one of many who's been using Red Hat Linux for years
(in my case since some time in '96), who's been helping out on the
various Red Hat support lists, and who doesn't like recent changes to
Red Hat's business model.
>From discussions we had on Red Hat's lists, a fair few of us have
decided to move to Debian, I think a couple decided on other distros,
though with the SCO fiasco they may be rethinking the U-L consortium.
They're not new to Linux, they are amongst the most experienced users
Red Hat had, many have RHCE certification.
I don't speak for them, but I often try to argue the case for less
capable users.
> > > > 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
>
> Loool. And KDE is just a user tool, not so different from cdrecord (in
> your categories), isn't?
Certainly, it's tool, but I don't see that it has much similarity to
cdrecord;-)
> > data from various sources, processes it in magical ways, and produces
> > outputs.
>
> There is not magic in mkisofs, clean code based on almost clean specs.
> The job ob BFs is quite different. (and before you start bichting: I am
> the cdrtools comaintainer).
I think you're concentrating on differences, I see similarities. As a
user, I don't care for specs, I care for results. Both take some data
(files), fiddle round and create files containing essentially the same
data structured differently.
As for you being the cdrtools comaintainer, that doesn't carry much
weight: I have used mkisofs and cdrecord, I know what they do. I don't
care how they do it, though you might;-)
>
> > 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
> > configuration.
>
> And if a developers wants to commit the changes on his personal files,
> he has to move it first? Sounds more like a cludge for me.
I don't understand what you're saying here.
> > 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
> > boot images.
>
> Redhat does not have multiple kernels (does it?), so many installation
> ways withing the first stage installer, etc.
Red Hat has many kernels for IA32. I'm not sure what the latest
selection is (it changes from time to time to keep the total volumne
down, and whenever it does change the selection, people complain), but
I've seen
i386
i386-BOOT
i586
i586-smp
i686
i686-smp
i686-enterprise
athlon
athlon-smp
athlon-enterprise
RHL is also available for other architectures, to be sure not as many as
Debian.
IA64
S390
S390x (64-bit)
I think there's a version for the Opteron too.
If I were to install Red Hat Linux on my Athlon, Anaconda (Red Hat's
installer) would choose the athlon kernel. If ran an Athlon-MP, then it
would install the athlon-smp (I think as well).
It will also install the i686-optimised GLIBC.
I can use the kickstart facility to install RHL fully automatically.
Unlike FAI, it doesn't clone, it installs from the package repository.
I can do a kickstart install of RHL on the various IA32 machines here:
The Athlon would get the Athlon kernel and the i686 GLIBC.
My Pentium III and Pentium II systems would get the i686 kernel and
GLIBC. (so would a Pentium IV if I had one).
My Pentiums and K6 would get the i586 kernel.
This is all using the same configuration file, the same installation
media.
A Pentium II Celeron 733 system I timed took about 15 minutes to create
a desktop system with KDE as the default desktop, all updates applied.
All I did was boot from floppy, remove floppy when booted. In this case
I did have some post-install configuration scripts to edit some text
files and retrieve and install the updated packages.
>
> > Even if you disagree on /etc, ~/boot-floppies/ remains a good place for
> > personal customisation.
>
> WHY? We are developers, not users. We can use diff, patch and cvs.
Becase b-f is a tool for users? Shouldn't I want to make customised
floppies? Should I have to hack the code to do so?
> > > > 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
> > > incosistent.
> >
> > 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.
>
> Talk is cheap.
Let's try to be polite.
> > Robust means to me that when someone updates the repository, especially
> > with an official update, it continues to work.
>
> That is the core problem, and if you wanna complain, file a bug against
> ftp.debian.org.
Sometimes, a change to one package requires changes to another. IBM
recognised this back in the 70s, when it divided MVS into numerous
functional components. A change to one component was not allowed to
change another; instead there had to be a separately-packaged update to
the other. It's like a change to the kernel requiring a change to
e2fsprogs to support a change to ext2.
In this case, you have that dependency, but it's not documented (or not
enforced).
> > 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:
>
> man cvs | grep merge
The point?
I've used patch (to apply kernel patches mostly). It requires context to
fit the changes in, and if the context isn't there the patch doesn't
fit.
That's a problem the user shouldn't need to address.
--
Cheers
John Summerfield
Please, no off-list mail at all at all. This address accepts mail only
from Debian addresses.
Reply to: