Leslie Donaldson wrote:
> Got the new kernel here are my results.
I also downloaded 2.5.61 today. I wasn't able the last 2 days. :-(
> -) Base kernel now compiles out of box.
For me too.
> -) firewire dma.c no compile. patch was late should be in next rev.
> Maintainers already found bug.
> -) Sound opl3sa2 no compile. Entered patch today
I don't use firewire, sound and so on, therefor I can't tell you my results
regarding this.
> -) make modules_install still has
> depmod: Unhandled relocation of type 10 for .text
There were also some problems with make modules_install for me!
> well there you go. For clarification until I get a clean install I'm
> not going to try and boot this thing. (I like my raid working.)
I'll let it run now... Let's see. If the machine crashes I don't mind too much.
It's just an old Compaq AS1000 5/333 only used by me as Alpha-teststation and
some kind of "fileserver".
If it works well now and hopefully without crashing, I believe 2.6 will also
work fine... :-)
Best regards,
Oliver
On Mon, 2003-02-17 12:25:35 +0100, Oliver Pitzeier <[email protected]>
wrote in message <[email protected]>:
> Leslie Donaldson wrote:
> > Got the new kernel here are my results.
>
> I also downloaded 2.5.61 today. I wasn't able the last 2 days. :-(
I'm running 2.5.60bk3 for nearly three days now.
> > -) Sound opl3sa2 no compile. Entered patch today
The pnp stuff... This bites PCs, too.
> > -) make modules_install still has
> > depmod: Unhandled relocation of type 10 for .text
>
> There were also some problems with make modules_install for me!
Worked out of the box for me.
> > well there you go. For clarification until I get a clean install I'm
> > not going to try and boot this thing. (I like my raid working.)
>
> I'll let it run now... Let's see. If the machine crashes I don't mind too much.
> It's just an old Compaq AS1000 5/333 only used by me as Alpha-teststation and
> some kind of "fileserver".
AXPpci33, I'd probably also switch on my Miata and my Avanti.
> If it works well now and hopefully without crashing, I believe 2.6 will also
> work fine... :-)
Sometimes, running Linux on != i386 is a bit problematic, typically
because core interfaces or basic functionalities where touched with
arch-specific code only written for i386... But I continue to run my
hardware zoo, asking for the missing bits:-)
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur
fuer einen Freien Staat voll Freier B?rger" | im Internet!
Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/
> There were also some problems with make modules_install for me!
How did you handle it?
What version of modutils was installed?
Fred
On Mon, 2003-02-17 10:39:38 -0500, Fred K Ollinger <[email protected]>
wrote in message <[email protected]>:
> > There were also some problems with make modules_install for me!
>
> How did you handle it?
I had nothing to handle - everything went out of the box.
> What version of modutils was installed?
For recent 2.5.x kernels, you don't any longer need modutils. There was
a major rewrite of all module related code which requires new tools.
These are called "module-init-tools", my distribution has got a package
for it (with the same name). If you cannot get that brand new software
from your distributor, look at
ftp://ftp.kernel.org/pub/linux/kernel/people/people/rusty/modules/ .
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur
fuer einen Freien Staat voll Freier B?rger" | im Internet!
Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/
On Mon, 17 Feb 2003, Jan-Benedict Glaw wrote:
> On Mon, 2003-02-17 10:39:38 -0500, Fred K Ollinger <[email protected]>
> wrote in message <[email protected]>:
> > > There were also some problems with make modules_install for me!
> >
> > How did you handle it?
>
> I had nothing to handle - everything went out of the box.
>
> > What version of modutils was installed?
>
> For recent 2.5.x kernels, you don't any longer need modutils. There was
> a major rewrite of all module related code which requires new tools.
> These are called "module-init-tools", my distribution has got a package
> for it (with the same name). If you cannot get that brand new software
> from your distributor, look at
> ftp://ftp.kernel.org/pub/linux/kernel/people/people/rusty/modules/ .
Be aware that for Redhat and SuSE distributions (and mandrake??) "make
install" will fail because mkinitrd doesn't know about the new modules
format.
I asked Rusty about this and he noted that he doesn't use mkinitrd, isn't
qualified to patch it, and has no plans to provide a working version.
Another user noted that there is an alpha version of the Debian program of
the same name which does work, but it isn't compatible (to what degree I
don't know).
So you can give up using modules for anything you want to use to boot,
change to Debian, or try and find the Debian alpha version and port that
to other distributions.
I'm sure the vendors will do this port at some point, until then there are
no quick solution but "build it all in."
There are issues with probe and probeall as well, as I recall one is
missing and the other doesn't work. They may both be missing and I just
got different error messages, or made different notes in my notes file,
don't know.
I haven't seen a detail doc on exactly how the new interface works, which
seems useful if someone other than a guru wants to start porting modules
to the new system. It's probably in the doc which tells what benefits have
come from the new system, I haven't found that one, either.
Read the man page for modprobe.conf, it says there are many missing
features, then says the features which are there are so powerful you won't
miss the features you don't have, then says it's so easy you can write
your own if you think there's a need.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 2003-02-19 13:00:39 -0500, Bill Davidsen <[email protected]>
wrote in message <[email protected]>:
> On Mon, 17 Feb 2003, Jan-Benedict Glaw wrote:
> > On Mon, 2003-02-17 10:39:38 -0500, Fred K Ollinger <[email protected]>
> > wrote in message <[email protected]>:
> > > What version of modutils was installed?
> >
> > For recent 2.5.x kernels, you don't any longer need modutils. There was
> > a major rewrite of all module related code which requires new tools.
> > These are called "module-init-tools", my distribution has got a package
> > for it (with the same name). If you cannot get that brand new software
> > from your distributor, look at
> > ftp://ftp.kernel.org/pub/linux/kernel/people/people/rusty/modules/ .
>
> Be aware that for Redhat and SuSE distributions (and mandrake??) "make
> install" will fail because mkinitrd doesn't know about the new modules
> format.
>
> So you can give up using modules for anything you want to use to boot,
Which is what I prefer - I personally don't like initrd and I don't use
it.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur
fuer einen Freien Staat voll Freier B?rger" | im Internet!
Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/
On Wed, 19 Feb 2003, Jan-Benedict Glaw wrote:
> On Wed, 2003-02-19 13:00:39 -0500, Bill Davidsen <[email protected]>
> > Be aware that for Redhat and SuSE distributions (and mandrake??) "make
> > install" will fail because mkinitrd doesn't know about the new modules
> > format.
> >
> > So you can give up using modules for anything you want to use to boot,
>
> Which is what I prefer - I personally don't like initrd and I don't use
> it.
If you have simple needs that's fine. I build for multiple groups of
machines, and with a working mkinitrd I can just build a file for the boot
controller on each type of machine, and only build a single kernel which
will run anywhere with the proper initrd file.
using initrd files also allows easy control of the order in which SCSI
controllers are loaded, which prevents drives from changing names.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 2003-02-19 15:39:44 -0500, Bill Davidsen <[email protected]>
wrote in message <[email protected]>:
> On Wed, 19 Feb 2003, Jan-Benedict Glaw wrote:
> > On Wed, 2003-02-19 13:00:39 -0500, Bill Davidsen <[email protected]>
> > > Be aware that for Redhat and SuSE distributions (and mandrake??) "make
> > > install" will fail because mkinitrd doesn't know about the new modules
> > > format.
> > >
> > > So you can give up using modules for anything you want to use to boot,
> >
> > Which is what I prefer - I personally don't like initrd and I don't use
> > it.
>
> If you have simple needs that's fine. I build for multiple groups of
> machines, and with a working mkinitrd I can just build a file for the boot
> controller on each type of machine, and only build a single kernel which
> will run anywhere with the proper initrd file.
I do it the other way around - I've collected a number of .config files
(one for each machine) which includes everything the machine needs to
*boot*. Any additional features (LVM/DM, filesystems, iptables, ...)
ships as modules. Things which require a distinct order are placed into
/etc/modules (Debian's list of modules which need to be loaded in given
order), all the rest is done via alias/install lines in
modules.conf/modprobe.conf.
This is, you do keep a machine's local config in its initrd, I do keep
it on the machine itself.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur
fuer einen Freien Staat voll Freier B?rger" | im Internet!
Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/
On Thu, 20 Feb 2003, Jan-Benedict Glaw wrote:
> On Wed, 2003-02-19 15:39:44 -0500, Bill Davidsen <[email protected]>
> > If you have simple needs that's fine. I build for multiple groups of
> > machines, and with a working mkinitrd I can just build a file for the boot
> > controller on each type of machine, and only build a single kernel which
> > will run anywhere with the proper initrd file.
>
> I do it the other way around - I've collected a number of .config files
> (one for each machine) which includes everything the machine needs to
> *boot*.
But... if you have it in .config, then you have to rebuild the kernel each
time. Maybe on an Alpha that doesn't matter, on anything I use a kernel
build takes minutes and an initrd create take seconds.
> Any additional features (LVM/DM, filesystems, iptables, ...)
> ships as modules. Things which require a distinct order are placed into
> /etc/modules (Debian's list of modules which need to be loaded in given
> order), all the rest is done via alias/install lines in
> modules.conf/modprobe.conf.
>
> This is, you do keep a machine's local config in its initrd, I do keep
> it on the machine itself.
Okay, now I see what you are doing, I guess you just have enough system
power to invest the time and disk space in building a kernel for each
config. When there was a working mkinitrd I was happily able to use fewer
of my resources to generate boot setups for all my systems, at least of a
given arch.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Thu, 2003-02-20 06:23:46 -0500, Bill Davidsen <[email protected]>
wrote in message <[email protected]>:
> On Thu, 20 Feb 2003, Jan-Benedict Glaw wrote:
> > On Wed, 2003-02-19 15:39:44 -0500, Bill Davidsen <[email protected]>
> > > If you have simple needs that's fine. I build for multiple groups of
> > > machines, and with a working mkinitrd I can just build a file for the boot
> > > controller on each type of machine, and only build a single kernel which
> > > will run anywhere with the proper initrd file.
> >
> > I do it the other way around - I've collected a number of .config files
> > (one for each machine) which includes everything the machine needs to
> > *boot*.
>
> But... if you have it in .config, then you have to rebuild the kernel each
> time. Maybe on an Alpha that doesn't matter, on anything I use a kernel
Guess, I do rebuilds nearly every time Linus releases a new full kernel
or one of his bk snapshots. So that doesn't really matter...
At times, even cross compiles succeed. On a dual Athlon (1.4GHz each),
building kernels doesn't really take thaaaaat long:-) Esp. if you can
keep all the kernel sources and a dozend compilers in memory:-P
> > Any additional features (LVM/DM, filesystems, iptables, ...)
> > ships as modules. Things which require a distinct order are placed into
> > /etc/modules (Debian's list of modules which need to be loaded in given
> > order), all the rest is done via alias/install lines in
> > modules.conf/modprobe.conf.
> >
> > This is, you do keep a machine's local config in its initrd, I do keep
> > it on the machine itself.
>
> Okay, now I see what you are doing, I guess you just have enough system
> power to invest the time and disk space in building a kernel for each
> config. When there was a working mkinitrd I was happily able to use fewer
> of my resources to generate boot setups for all my systems, at least of a
> given arch.
This reminds me that I wanted to have a look at an additional feature -
building the kernel _not_ within its source tree. So I wouldn't need to
place 10 copies of the kernel onto disk / into memory...
Haven't I seen patches flyin' around? Anyone?
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur
fuer einen Freien Staat voll Freier B?rger" | im Internet!
Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/
On Thu, Feb 20, 2003 at 12:36:24PM +0100, Jan-Benedict Glaw wrote:
>
> This reminds me that I wanted to have a look at an additional feature -
> building the kernel _not_ within its source tree. So I wouldn't need to
> place 10 copies of the kernel onto disk / into memory...
>
> Haven't I seen patches flyin' around? Anyone?
I have made a patch that enabled that feature which I posted some
time ago. I'm reworking it for the moment, awaiting a few pending
kbuild changes + I need to put a bit more work in the script.
Last version posted had problems with oprofile and xfs - and
I do not think ia64 will build with current version.
Expect something to show up within a few weeks.
Sam
On Thu, Feb 20, 2003 at 12:36:24PM +0100, Jan-Benedict Glaw wrote:
> This reminds me that I wanted to have a look at an additional feature -
> building the kernel _not_ within its source tree. So I wouldn't need to
> place 10 copies of the kernel onto disk / into memory...
>
> Haven't I seen patches flyin' around? Anyone?
You can save your buffercache memory by doing a
"cp -al linux-2.5.61 linux-2.5.61-buildfoo", for each value of buildfoo,
and do your builds in a cloned tree. Hard links save the day!
-andy