Re: Building boot images with boot-floppies on PowerMac
On Mon, 30 Jun 2003, Eduard Bloch wrote:
> #include <hallo.h>
> * debian@computerdatasafe.com.au [Sat, Jun 28 2003, 11:16:30AM]:
>
> > The "arch maintainer" for what? My problem is with b-f, according to
> > those documents you mention, this list is the right place.
>
> For the problem with your powerpc kernel package which was your initial
> problem.
>
> > > > > 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
>
> And that is, precisely, and edge and chicken problem. The build cannot
> take the kernel images since they are not in the archive, but it uses
> the archive structure to decide which package to take (expecting
> "stable" package). And the packages do _not_ land in the stable branch
> immediately because the distro is frozen. So you stuff _will_ be
> buildable when r2 has been released and the SRM accepted the
> kernel-image* and according pcmcia-modules-* packages to stable. Until
> this happens and since you are using a development version of
> boot-floppies (*), please stop fighting windmills.
The _only_ reason I've tried anything other than the stable version is
this:
The stable version did not work. See my first post in this thread.
When I posted the initial problem here, someone (Chris, I think) said to
use one of the other versions: I think he said testing, but no matter,
I've tried testing and I've tried CVS.
If the stable version worked, I'd be content. I want to build a stable
installation with only _my_ changes.
I have r1 ISOs here: if you think those will work, I will burn off as
many more as I need and/or extract the files from them,
>
> (*): or an outdated/wrong version, bug FTP maintainers, and this is
> another story
>
> > do that, then I have a base to work on.
>
> As said, your work won't be honored enough.
>
> > > > 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.
>
> Fine. Comming back to your mkisofs example, it's typical daily job for a
> normal user to recompile mkisofs again and again?
I am using b-f source only because when I tried to "apt-get install" I
didn't find a package to install.
>
> > > > > 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;-)
>
> Oh, please, you tried to escape the correct answer.
>
> > > > 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
>
> I do not concentrate on anything or close my eyes, I just tell you the
> facts. Please estimate the level of complexity in the cooperation of
> different tool, platforms specifics, etc.
>
> > user, I don't care for specs, I care for results. Both take some data
>
> There won't be any results if you break with the roots.
>
> > (files), fiddle round and create files containing essentially the same
> > data structured differently.
>
> With this attitude you can argument even for LFS.
>
> > 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 did not say cdrecord. It was your idea to distract from the
> KDE-vs.-single-tool argument.
>
> > > > 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.
>
> Doesn't matter.
>
> > > 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
>
> Yet another distraction. How many do you select when starting the
> installer?
>
> > I've seen
> > i386
> > i386-BOOT
> > i586
> > i586-smp
> > i686
> > i686-smp
> > i686-enterprise
> > athlon
> > athlon-smp
> > athlon-enterprise
>
> We have a similar set of kernels, the user is free to install them.
> After the base system and the installation kernel has been installed.
The important distinction is that Anaconda chooses it. Even on your
first-ever RHL install, you'd get the appropriate kernel.
> > RHL is also available for other architectures, to be sure not as many as
> > Debian.
>
> YEAH! And exactly here is the problem. Redhat supports only the "new"
> architectures which don't create much trouble.
Sure you have more work to do, but then you probably have more people.
Do people work on architectures they wouldn't otherwise not use? I think
not.
> > If I were to install Red Hat Linux on my Athlon, Anaconda (Red Hat's
>
> Maybe. We have this idea too and I think the D-I people wanted to
> implement the automatical selection too. Please consider that the B-F
> development has been stopped one year ago. There is no progress, and it
> was not a fun to convince the conservatives even to allow the bf2.4
> installation flavor to be included, since kernel 2.4 was extremely
> unstable 1.5 years ago.
I absolutely require a 2.4 kernel to support my Hotrod 66 card. For
quite a while I was booting and running on a drive attached to it. At
that time I would have been completely unable to install Debian.
>
> > installer) would choose the athlon kernel. If ran an Athlon-MP, then it
> > would install the athlon-smp (I think as well).
>
> I do not think so. It may be possible, but only with a kernel patch
> since the normal kernel does not display the SMP capabilities when you
> are running a non-SMP kernel.
OTOH I've read posts from people who have installed RHL to an SMP
system, and it did install two kernels. How it detects that a second CPU
exists I've never felt the need to find out.
>
> > It will also install the i686-optimised GLIBC.
>
> 686 optimised compilations are food for marketing people. In fact, the
> average performance gain is about 5 percent.
I'm sure you're right, but the fact remains that the installer, not the
user, makes the choice.
>
> <removed the list of fame for RHs autoselection of kernel and libc on x86>
>
> > This is all using the same configuration file, the same installation
> > media.
>
> As said before, the things are easy if you do not care about nasty
> things like compatibilities (cross- and backward) and a bunch of other
> architectures.
I've installed Debian on several architectures by now, and nothing
stands out on those that would prevent the kind of automation RH does.
Indeed, the PC is probably the hardest of the lot, because of the number
of different vendors shipping parts for them.
> > 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.
>
> Use KNOPPIX and you get it faster.
Actually, that's not true. I use Knoppix, I'm running 3.1 on my Pentium
III masquerading as an X-terminal.
Guess who wrote most of the detection tools Knoppix uses?
Red Hat.
>
> > All I did was boot from floppy, remove floppy when booted. In this case
>
> Then you are lucky. There are also lots of lucky Debian users that
Not lucky at all. RHL's installer is designed to be able to do it. It's
not the way a new user would do it, but the factility is there and it's
documented and it's not hard to do.
> installed it with two floppies. In 15 minutes, with running X. It does
> require a bit more knowledge about hardware, but you can get it. Debian
> is not for newbies from the sort of plug-and-play Windows users.
Debian does need to move in that direction though.
>
> > > > 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
>
> You use a tool. You don't compile it daily, see above. Why do you need
> customised boot-floppies?
So I can install it my way more easily. A 2.4 kernel for starters. Point
it at my servers. Cut down the excessive "do you really mean that?"
questions. I don't use swap partitions, but I do like a swap file
sometimes. Change the default package list. I don't like exim, I do like
lynx & less. On a Mac or a Sparc you really must have eject - how else
do you evict a floppy? It's not installed by default.
If I'm reusing old computers, setting them up as firewalls, I want them
all to have my idea of the right software set up _my_ way. The
particular computers could be any old HP, Dell, IBM, Digital or other
Pentium, or even a Mac. I want them all setup the same way, no mistakes.
It's hard to do that with an interactive install.
If I'm a sysadmin for a big company, I want to roll out lots quickly.
Maybe they all have the same hardware - until the vendor changes the
lineup, maybe not.
> > floppies? Should I have to hack the code to do so?
>
> Yes. And when you do, you have to know what you are doing. I think, D-I
> will be the perfect toy for you. Use it, and stop bitching about
> boot-floppies.
Does d-i work? When I looked into it, it was pre-alpha.
>
> > > > 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.
>
> I still am.
>
> > 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.
>
> Use D-I.
>
> > In this case, you have that dependency, but it's not documented (or not
> > enforced).
>
> The dependencies in the version 3.0.23 (which was released for Woody but
> was not shipped with source, only as installation images) did match when
> the distro has been released. It's not my fault when something went
> wrong later.
Umm. Doesn't the GPL say you mayn't ship without source?
>
> > > > 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.
>
> The V in CVS stands for Version. The server has the original version and
> cvs tries to preserve the modifications.
The point I was making is that changes I make might in order to
configure b-f could mean that I can no longer keep in step with the CVS
version without rehashing my changes.
The patch I offered fixes that by providing another place to store the
configuration information.
>
> > That's a problem the user shouldn't need to address.
>
> That's a problem the user should never come in touch with.
I was (and still am, for that matter) on the Red Hat lists that deal
with Anaconda and kick-start. I had a lot of company. There a lot of
sysadmin types who build CD sets based on RHL, who customise the
installation to their own (or their employer's) preferences. In my own
case, I choose KDE over GNOME, I set the timezone to Australia/Perth, I
customise syslogd to log to /dev/tty12, in some cases to C-A-D shuts
down.
It's perfectly reasonable for a user to customise the software. That's
why the GPL guarantees the source code including "scripts used to
control compilation and installation of the executable."
--
Cheers
John Summerfield
Please, no off-list mail at all at all. This address accepts mail only
from Debian addresses.
Reply to: