link /lib/modules/<vers.>/build

David A. Bandel david at pananix.com
Tue Jul 3 06:08:21 PDT 2001


Richard Lightman wrote:
> 
> Misquoted from David A. Bandel on 2001/07/ 2 at 08:17 +0000:
> > Richard Lightman wrote:
> > >
> > > Misquoted from Gerard Beekmans on 2001/07/ 1 at 11:19 +0000:
> > > >
> > > > The problem though, the kernel docs and config file. There's no official
> > > > place to store those. I could think of /usr/share/doc/linux (or
> > > > /usr/share/doc/kernel) for the Documentation/* stuff, but how about the
> > > > .config file? /usr/share/kernel-config perhaps?
> > > >
> > > How about:
> > > /lib/modules/$(uname -r)/config
> > >
> > > And while you are at it:
> > > /lib/modules/$(uname -r)/bzImage
> > > /lib/modules/$(uname -r)/System.map
> >
> > no -- the above two need to be in /boot.  Doing otherwise breaks
> > tradition (and may break LSB/LHS compliance).  You can do /boot/$(uname
> > -r)/ if you really want, though I see little need for it.
> >
> If you are upgrading the kernel, and keeping the old one as
> a fall back, how is klogd going to find the right symbols?
> I have seen /boot/System.map as a symlink to the correct
> file, but FHS says /boot can be mounted read-only, so
> you cannot be sure that you can correct the symlink.

Well, let's see.  I usually only build one kernel for any given kernel
release (2.4.4, 2.4.5, etc.), and build almost totally modular.  What I
do is:
kernel names:
bzImage-2.4.4
bzImage-2.4.5
System.map names:
System.map-2.4.4
System.map-2.4.5

my syslogd option line looks like:
-k /boot/System.map-`uname -r`

Works for me.  


> 
> FHS says nothing about 'System.map', but the standard
> behaviour of klogd is something you really want to override.
> 
> /boot makes some sense for people using lilo, they need
> somewhere to keep their sector map files. It is a bit
> pointless for grub, which does not use sector map files
> for the kernels. If you have more than one root partion,
> which is common among LFS'ers, grub is better off on a
> partition that you do not wipe once a month, like say
> /home, or a partition full of source tarballs.
> 
> I am happy to take the best ideas from FHS, and to do
> something sensible instead where the standard has
> accepted "common practice" instead doing something sensible.
> 

for me, /boot makes a _lot_ of sense regardless of the use of lilo,
grub, etc.  First, /boot resides on its own ext2 partition (20Mb).  All
other partitions are reiserfs (yes, I have to build reiser tools before
I can boot into LFS, no biggie, one of the last things I do).

I can boot into LFS, RH 7.1, Slackware 7.1, Debian, Caldera 3.1, or SuSE
7.2 (yes, I have and run them all -- one of the hazards of writing about
Linux in this day and age).  I only build one kernel for a system.  The
only difference is that the lilo.conf stanza between them is root =
/dev/hd??.  Every distro boots from the same kernel(s), so the
System.map is identical.  Why not?  The hardware is the same.  I abhor
the distro kernels.  I build my own and copy the modules and
/etc/modules.conf (and actually the entire /usr/src/linux tree) between
systems.  Copying the source tree is much faster than rebuilding the
kernel. (I run /etc/lilo.conf with the -r option if not in the system
with lilo.conf.) If I locate this stuff somewhere on one system,
maintenance becomes problematic (as does rescue -- hence the ext2 for
the 20Mb /boot partition, which is unmounted after bootup and only
mounted when I need to make a kernel change). As a side note, I have the
/boot partition imaged to each of the drives just in case.  So /boot and
/home are "shared".  /etc/passwd, group, and shadow are synced.  Other
than that, my systems are pretty vanilla.

OK, granted, I'm not normal and neither are any of my systems.  However,
all distros I know of now use /boot by convention if for no other
reason.  And a damn good poicy it is too (quote from unidentified taxi
driver in "Who's That Girl?"). ;-)

Ciao,

David A. Bandel
-- 
Focus on the dream, not the competition.
		-- Nemesis Racing Team motto
-- 
Unsubscribe: send email to lfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message



More information about the lfs-dev mailing list